Why can't the setter of a struct's indexer be called without assigning the struct to a variable?

[jnm2]

using System;

var value = Foo.Bar[1]; // Works

/* ❌ CS1612 Cannot modify the return value of 'Foo.Bar' because it is not a variable
↓↓↓↓↓↓↓ */
Foo.Bar[1] = 1; // Starts working if Accessor is changed to a class

var bar = Foo.Bar;
bar[1] = 1; // Works

struct Accessor
{
    private readonly Func<int, int> getter;
    private readonly Action<int, int> setter;

    public int this[int p]
    {
        get => getter.Invoke(p);
        set => setter.Invoke(p, value);
    }
}

static class Foo
{
    public static Accessor Bar { get; }
}

[333fred]

Consider the following example:

using System;

Foo.Bar[1] = 1;

Console.WriteLine(Foo.Bar[1]);

struct Accessor
{
    private int _value;
    public int this[int p]
    {
        get => _value;
        set => _value = value;
    }
}

static class Foo
{
    public static Accessor Bar { get; }
}

What do you expect to printed by that Console.WriteLine? There are two possible answers:

1. You expect 1 to be printed. That really means the compiler needs to generate the following code, as the struct is returned from Bar by value, not by ref:

var tmp = Foo.Bar;
tmp[1] = 1;
Foo.Bar = tmp;

2. You expect 0 to be printed. I would find this extremely confusing, as it does not behave how a reference type would in this scenario.

Hopefully this helps.

[jnm2]

Fully anticipating this counterexample, I would still have preferred for the original code to remain unblocked by the compiler even at the cost of missing the problem in the counterexample. (Maybe an IDE hint or compiler warning?)

Or, a refinement could be made to allow readonly indexers/structs to be used this way with no error.

[jnm2]

Your suggestion on Discord of .Get/.Set methods helpfully reminded me that the accessor indexer syntax reads a bit backwards, so I went with .Read/.Write methods.

[bernd5]

You could return by ref. In your sample Accessor is returned by value and discarded afterwards
If it would be allowed the expected result is (in my eyes) "0" because the copy of "Accessor" has to be discarded.

Adjusted code:

using System;

var value = Foo.Bar[1]; //
Foo.Bar[1] = 1; // Starts working if Accessor is changed to a class

var bar = Foo.Bar;
bar[1] = 1; // Works

struct Accessor
{
    public Func<int, int> getter { get; init; }
    public readonly Action<int, int> setter {get; init; }

    public int this[int p]
    {
        get => getter.Invoke(p);
        set => setter.Invoke(p, value);
    }
}

static class Foo
{
    private static Accessor bar = new(){
        setter = (a, b) => Console.WriteLine($"{a} {b}"),
        getter = (a)=> 42 +a
    };
    public static ref Accessor Bar => ref bar;
}

[bernd5]

But it looks like that you want Named Indexers like we have in VB.

[jnm2]

In this case, I actually wouldn't want named indexers. The static properties are initialized by calling helpers to create the accessors; if they static properties were named indexers, they'd have to delegate both accessors to helper code.

Also in this case, the storage location is not something that a ref could be taken to.

[CyrusNajmabadi]

We had a good chat about this over at discord: https://discord.com/channels/732297728826277939/732297994699014164/908109390798786600

To sum up the language side of this:

1. We want to help people avoid mutations of struct-copies that are then then discarded.
2. In general, the presumption/intuition on how the language thinks of certain features is that the normal case for indexers and properties is that they are used to mutate owned-state.
3. As such, in this case we see Foo.Bar and we know that produces a copy (or, in language parlance, it's not an L-Value). We then see Foo.Bar[1] = 1 and we assume the indexer mutates the value of that copy. As that mutation would be discarded, we feel an error is warranted.

Clearly though the above could could work. So we have to reconcile our desire to catch real bugs, with the limits not being too onerous for code that would work. In this case the above code doesn't fit under this formalization because indexer isn't mutating the copied value.

However, with the code as structured like above, this would be hard to tell. Specifically, Accessor might be from metadata, so we wouldn't know that it wasn't mutating itself.

We could attempt to refine the rules here if the struct itself were potentially readonly (or something like that), but we risk ending up with a very subtle exception that doesn't really end up adding that much value.

In general, the two LDM members participating here (@333fred and myself) feel that the amount of true-positives this catches is worthwhile, and the amount of false-positives it reports is minimal. And as such, the simplicity and clarity of hte current approach is likely where we'd want to stay.