[Proposal]: Shorthand property setter

[murshex]

Shorthand property setter

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Easier way to quickly define a setter only property (Similar to the shorthand getter property feature) This feature assumes we want to have a default get method

Motivation

I think it makes sense because we already have the shorthand getter.

Detailed design

Its already there for the getter so why not have it for the setter.

public int hello <= 100 * value;

Drawbacks

None that I can think of.

Alternatives

Using the normal set:

private int _hello;
public int hello
{
    get => _hello;
    set => _hello = 100 * value;
}

Unresolved questions

None that I can think of

Design meetings

Sorry but I'm not sure about this one either.

[theunrepentantgeek]

What is the value of this? What problem does it solve?

public int hello <= 100 * value;

This world declare a write-only property with an inaccessible field for storage, so the only code that can read the value will be using reflection. Doesn't seem to be widely useful.

Note that this can't be equivalent to your alternative as the backing fields for autoproperties have inexpressible names to avoid name collisions.

[jnm2]

Just like you can assign to a get-only auto property in the constructor, I'd assume you could read from a set-only auto property everywhere in the declaring class, too.

[murshex]

@theunrepentantgeek @jnm2
This is not set only/write only.

This:

public​ ​int​ ​hello​ ​<=​ ​100​ ​*​ ​value​;

Is supposed to behave the same as this:

private​ ​int​ ​_hello​;
​public​ ​int​ ​hello​
{
    ​get​ ​=>​ ​_hello​;
    ​set​ ​=>​ ​_hello​ ​=​ ​100​ ​*​ ​value​;
}

Thank you for your reply.

[jnm2]

@c0nd3v Sorry I missed that. "Setter only property" has a very specific meaning, and the evidence that you wanted something different from that was subtle.

[jnm2]

@theunrepentantgeek I doubt that the name _hello is part of the proposal. It only appears in the desugaring example and it looks like it's supposed to represent the normal autoprop backing field.

[jnm2]

@theunrepentantgeek I just realized I disagree with your third point. It's not at all strange to transform the value that was set. For example:

public string Name <= value?.Trim() ?? string.Empty;

[theunrepentantgeek]

@jnm2 I agree with you; that's why I used the phrase "dramatic transformation". 😁

Apologies for not being clearer.

[murshex]

I doubt that the name _hello is part of the proposal.

Yes, thats correct.

[jnm2]

#140 would enable this syntax:

public int Hello { get; set => field = 100 * value; }

This wouldn't have the downside of secretly emitting a get accessor that isn't present in the syntax.

[murshex]

While that is nice, my proposal represents the normal autoprop backing field, while this requires you to declare a class member variable (If I understand correctly)

Okay well, yeah that is a good alternative too. but, I still think my proposal still has value.

[murshex]

I understand why secretly emitting a get accessor might look bad but, without it, its basically a useless variable, and it seriously should not cause any problems.

[jnm2]

It seems like we've barely been able to convince the team to look at #140, and #140 generalizes so well that I'm doubtful of convincing them to add an additional syntactic form beyond that to save 20 characters on one line for a case that I see once every two years in the wild (ymmv). No harm in asking though!

[theunrepentantgeek]

I suspect that widespread developer confusion caused by magic semantics should really be considered a problem.

FWIW don't think I'm exaggerating very much - C# has a strong history of being explicit (eg requiring new or override for virtual methods, requiring async if you use await, and so on). A magic get that appears when someone innocently refactors code would be surprising.

#140 has all of the benefits and none of the downsides of this proposal.

[CyrusNajmabadi]

We'll be looking at #140 in two weeks :-)

[Joe4evr]

I still think my proposal still has value.

The language team does not: #1278 (comment)

[dylanrafael05]

This could work well if only applied to set, for example:

public string Name {
    get;
    set <= value + " ";
}

This would be rendered useless without #140, since its useless to get a value in a different way then setting it. If #140 is ever passed, then this syntax could be useful;

public string Name {
    get => field.Substring(0, file.Length - 1);
    set <= value + " ";
}

The fact that <= is also the less-than-or-equals operator might also complicate things, consider <-, <~, =<, or <==