get/set Expression bodied properties

[MkazemAkhgary]

Allow to get and set with expression Bodied properties

public int X <=> point.X;

Equivalent to

public int X
{
    get => point.X;
    set => point.X = value;
}

Could be used for indexers too.

public int this[int index] <=> _source[index]; 

Equivalent to

public int this[int index]
{
    get => _source[index];
    set => _source[index] = value;
}

---

Notes to consider

• expression must be a valid l-value and r-value (as suggested by @benaadams)

[Logerfo]

int Foo <=> bar = baz = qux; // sets all values.

and returns...?

[DavidArno]

I initially upvoted this as a simple idea for mapping read/write properties to some value other than the default backing field. But I've removed that upvote as your "Notes to consider" addendum just muddies the proposal.

Keep it simple:

1. For property, x <=> item, item can be a (non-readonly) field or a read/write property,
2. For indexer, this[int index] <=> item, item must be another indexer.

[benaadams]

@DavidArno More explicit on the indexer?

this[int index] <=> item[index];
this[int index] <=> item[_offset + index];

i.e. must always resolve to a single value/ref

[MkazemAkhgary]

@Logerfo returns what => x = y = z; returns.

@DavidArno indeed, i tried to expand usage in conjunction with get only properties. Chained assignments could be prevented. Its not something i do usually, in fact i never did it.

[MkazemAkhgary]

@benaadams i liked that but what if item is jagged array int[][]?

Then it has to be either explicit like what you suggest or implicit item.

I guess explicit version pays off more.

[Logerfo]

@MkazemAkhgary in C#, multiple assignments returns the rightmost value of the chain. In your examples, qux or z, but that can be really confusing. I see you already remove that from the notes, so we don't need to proceed with this discussion.

[benaadams]

i liked that but what if item is jagged array int[][]?

Defined via type, an array is still a single item

private int[][] item;

public int[] this[int index] <=> item[index];

or

private int[][] item;

public int this[int i1, int i2] <=> item[i1][i2];

or the other type

private int[,] item;

public int this[int i1, int i2] <=> item[i1, i2];

[benaadams]

I think it just needs to be

"expression must be a valid l-value and r-value"

i.e. valid on both sides of an equals

For example it could happily be a ref returning function so for example given

private int[] items;

private ref int FindEntry(int index)
{
    // ...
}

This

public int X
{
    get => FindEntry(0);
    set => FindEntry(0) = value;
}

public int this[int index]
{
    get => FindEntry(index);
    set => FindEntry(index) = value;
}

Could be converted to

public int X <=> FindEntry(0);

public int this[int index] <=> FindEntry(index);

[Logerfo]

Another possibility is to use just the => syntax and change its behavior to act like you propose, now allowing the readonly modifier on properties to behave the way the operator does today. That would change existing properties, but I don't know how big deal that would be.

[benaadams]

That would change existing properties, but I don't know how big deal that would be.

Would be a significant breaking change as all current simple readonly properties would suddenly become read/write e.g.

private int _x;

public int X => _x; // now read/write, was readonly before

[Logerfo]

@benaadams Since the assignment is not possible today, that change would not actually break anything, as it's more kind of a relaxation. It can break analyzers, but anything can. I think it would only break reflection/cecil for properties like IsWriteable or IsReadonly, which would have different values due to this change.

[MkazemAkhgary]

@Logerfo not all properties can become writable. issue is they will remain get only or become writable. so whether property will be readonly or not would become vague. I guess => should be left as it is for get only properties.

for example X => 1 + 2 is impossible to be writable.

[benaadams]

@Logerfo hmm true; but it would also mean everyone who had written a readonly property would then have to change/audit their code to keep the properties readonly

[MkazemAkhgary]

@benaadams very good explanation. that is more general, updated.

[ghost]

I suggest using instead of <=>:

public int this[int index] using _source[index]; 

#2291

[Happypig375]

That syntax deviates too much from =>. It looks too different from =>.

[heku]

Maybe extend the ref's usage is better:

public int this[int index] ref _source[index]; 
public int Prop ref _field;

[TahirAhmadov]

I know the <=> syntax is very short, but I was thinking a slightly different syntax which is a bit more verbose but I think easier to read:

public string Prop { get, set => this._field; }

[FaustVX]

With proposal #140 the syntax public string Prop { get; set => this._field; } but with a ; after the get, it will be a too much close syntax.

[TahirAhmadov]

Good catch. I take it back.

[sab39]

Personally I think <=> wins out on readability anyway: since we're all already used to => as a "one way" mapping, adding the other arrow intuitively means the same thing but bidirectional.

[LWChris]

Alternative 1

T P <=> X;

where

• T is any type
• P is a property name
• X is an expression for a readable and writable property or field of type T

Alternative 2

T M <=> X;

• T is any type
• M is a property name or indexer
• X is an expression for a readable and writable property, indexer or field of type T

---

I'm in full support of alternative 1, and somewhat supportive of alternative 2.

I'm per se not a fan of "complex" expressions on the RHS like

T M <=> x = y;

I know it's already possible to write

T M {
    get => x = y;
    set => x = y = value;
}

but I am a bit worried that people might read the shorthand syntax as

T M <=> x = y;

and not realize that get will have a side effect on x and set will overwrite y. Therefore I'm leaning towards strict limitations what X can be if possible.

Indexer expressions are on the boundary of "complex" RHS expressions, because they take additional arguments. But seeing that indexer delegation is probably often required alongside property delegation, if the wrapped/delegated object happens to have an indexer property, I'm slightly less worried about that.

[LWChris]

As for the syntax, I'm heavily in favor for <=> because it is the natural instinct, when tasked "make => bi-directional", to make it <=>.

I know multiple people, especially @CyrusNajmabadi wants to have <=> (aka "spaceship operator") for three-way-comparison (result is not bool but something that can be "greater than, less than, equal"), but for that I'd prefer <>=, precisely to avoid making the expression x <=> y look like an arrow opposed to x <>= y.