Add initialiser to property syntax

[MikeLeicester]

This is a feature request

currently when creating a property you have get and set option

ie

public int Progress { get ;set ;}

the feature that i would like is to have the ability to specify an initialiser
ie

public int Progress
{
	new => 0;
	get;set;
}

this would allow lazy loading
so would be the equivalent of

Lazy<int> _Progress = new lazy<int>(()=>0);
public int Progress
{
	get => _Progress;.Value;
	set =>  _Progress =  new Lazy<int>(()=>value;);
}

this would allow for the property to be set once to a default on the first read, but if set before being read initialisation wouldn't occur, this would promote the use of lazy loading plus simplifying the use

[jnm2]

See also: #312, #681

I'd absolutely hate for the compiler to bless one particular mechanism, like Lazy<> or ??= or CAS. They each have their strengths for different applications. It would be terribly imbalanced for the language itself to decide that one way of doing lazy loading was the idiomatic way.

[MikeLeicester]

@jnm2 i'm not proposing the mechanism only the behaviour,

this is just some syntactic sugar to remove boiler plate code same as ?. was introduced to reduce

if(nullable.HasValue)
	return nullable.Value;

for a much simpler and easier to read syntax,

as you pointed out there are other ways of doing this than with the lazy

but a quick and simple way of doing if property not set, set to a calculated value would be useful and time saving, especially when leaving out the initialise clause would cause the current behaviour to be unaffected

[Mteheran]

it is another way to do the same, I mean this is good but I cannot see a real new value to C#

[MikeLeicester]

@Mteheran you could say the same about all the recent changes the the language, aync await did nothing that couldn't be done with Tasks, or being able to declares out variables inline with the function call, or pattern matching in switch statements. the question isn't does it add value its is this a task that you do often enough that abbreviating it will save people time and effort, for me it is which is why i suggested it

[HaloFour]

@MikeLeicester

aync await did nothing that couldn't be done with Tasks

Except allow you to write such code in a synchronous imperative style which makes such things as error handling, looping, etc. about a trillion times easier. If anything I think async/await was one of the most impactful changes to the C# language, to the extent that so many other languages are following suit. Not that my opinion here is particularly relevant to this proposal.

My problem with proposals like lazy initialization is that they imply a lot of policy concerns that end up implemented in exactly one way which would make the feature non-applicable in a lot of scenarios or they require a lot of additional syntax to capture those concerns. Lazy<T> has three different modes for handling concurrency.

[bondsbw]

Agreed with the points @HaloFour makes.

But I could get on board with something like this:

public int Progress { get; set; } using new Lazy<int>(0);

get/set calls are forwarded to basic getter and setter methods implemented by Lazy<T>, which could be as simple as:

T Get<T>();
void Set<T>(T t);

This is even more powerful. It doesn't bind the language to one approach for lazy properties. And it doesn't have to relate to lazy loading at all.

[MikeLeicester]

@HaloFour that is exactly the point i was making, they didn't DO anything new but the results doing it in a different way (ie of adding it to the language spec) was to make it much easier and more fluid to do a previously laborious and difficult task that has resulted in a vast improvement.