Force Non-Null

[lazyloader]

Often times we write code like this:

public Foo _foo; 
public Foo Foo 
{ 
    get => _foo ?? _foo = new Foo(); 
    set => _foo = value; 
} 

This: 

```csharp
public Foo! Foo; 

Foo will be never be null, and will return a new copy the instance it's needed. Also note, that adding the field keyword will only make this marginally better.

[DavidArno]

As suggested in #2001, other proposals would lead to a nice syntax for this:

public Foo Foo 
{
    set; get => field ??= new Foo();
}

and they have the advantage of allowing flexibility around what is assigned when the field is null, rather than hard-coding new Foo() as your proposal would do.

[lazyloader]

@DavidPrio Right, but we could have both, and if we did, I would tend to use Foo! as it's 4x les amount of lines. Even if we put your idea on one line:

public Foo Foo { set; get => field ??= new Foo(); }
public Foo! Foo;

We can see that it's also 3x shorter in terms of characters, making it more ideal in the case of new() which is fairly common.

[HaloFour]

@lazyloader

It also looks like a normal field, not a property. That alone makes it much more difficult to reason about.

[Austin-bryan]

@DavidArno Actually, if you include #100, it becomes:

public Foo Foo
{
    set; get => Foo ??= new();
}

@lazyloader which makes the one line version:

public Foo Foo { set; get => field ??= new(); }
public Foo! Foo;

So not too dramatic of an improvement, but if Foo was instead a Dictionary<Foobaz, FoobazManager> it would be a much bigger improvement.

[CyrusNajmabadi]

i don't see any value (no pun intended) in trying to make it that much easier to write mutable properties.

[jnm2]

@CyrusNajmabadi I'm the first person to want to go immutable, but that doesn't sound entirely realistic to me in many cases nor entirely in the paradigm-inclusive spirit of C#.

[DavidArno]

@jnm2,

I may be putting words in @CyrusNajmabadi's mouth here, but it's not so much "never make it easy to write externally mutable properties", it's a case of "never make externally mutable properties easier to write than externally read-only properties".

[jnm2]

I like that C# in the past hasn't taken the stance that it's a zero-sum game. If a lot of folks are doing something, why not make it easier no matter what other paradigms may or may not be available to them in their particular project?

[DavidArno]

"Pit of success"? Make it hard to do bad things, easier to do neutral things and even easier to do good things.

(Though I feel like I've wondered into the realms of D&D's alignment system here, rather than programming 😃)

[jnm2]

Deciding that mutability itself is a bad thing is not paradigm-inclusive, in line with what I would have said the spirit of C# is.

[CyrusNajmabadi]

I like that C# in the past hasn't taken the stance that it's a zero-sum game. If a lot of folks are doing something, why not make it easier

I'd rather make other stuff easier :)

@CyrusNajmabadi I'm the first person to want to go immutable, but that doesn't sound entirely realistic to me in many cases

That wasn't my argument. :) I was simply saying that i don't see a lot of value in making this pattern easier. You can still implement the pattern today, without too much muss or fuss. That seems a good enough state to be in for me.

[alrz]

i don't see any value (no pun intended) in trying to make it that much easier to write mutable properties.

Since C# is heavily used for a lot of stuff including GUI I think it actually makes total sense and is valuable. (As it seems, swift included didSet willSet mostly for that single use case).

Also, as for get; set => syntax, I think one of the bonus features is that it hides the underlying field, I think that was the motivation behind a "property-scoped field" proposal. I'd prefer the former though.

[theunrepentantgeek]

The OP seeks to enshrine a very specific special case:

A lazily populated property

• where the type of the property is a concrete type (no abstracts, no interfaces)
• and get triggers assignment of the value
• and the parameterless constructor of the property type returns a properly configured instance that's ready for use

I can see that this isn't an astonishingly rare situation, but I don't see it being common enough to justify the overwhelming cost of a language change, especially since the syntax currently available in C# (i.e. already available for use by all) is clean, concise, and straightforward.

[Richiban]

This seems to me to be solved with a very oft-requested feature for lazily initialized properties (although I seem to remember that those have unfortunately been shot down in the past due to inability to decide on locking mechanisms):

public string MyProp
{
    get; init => GetValueFromExpensiveComputation();
}