Null Coalescing Properties

[lazyloader]

Problem

I saw recently some code that looked something like this:

private string _foo;
public string Foo
{
    get => _foo;
    set => _foo == value ?? "";
}
private MyObject _bar;
public MyObject Bar
{
    get => _bar ?? new Bar();
    set => _bar;
}

I thought that that was a fairly common use for properties, but that's an awful load of code for such a simple idea.

Purposed Syntax:

public string Foo   { get; set ?? ""; }
public MyObject Bar { get ?? new Bar(); set; }

We could even allow for this syntax, where it will automatically call the default constructor if the value is null. If there is no parameterless constructor, a compile error will be thrown.:

public string Foo   { get; set!; }
public MyObject Bar { get!; set; }

This removes a lot of that fluff and better shows what's going on, taking up much less space.

[jnm2]

Some of us consider #140, which introduces the field keyword, to be the gold standard for this.

Lazy: { get => field ??= new(); set; }
INPC: { get; set => Set(ref field, value); }
Default in get: { get => field ?? new(); set; }
Default in set: { get; set => field = value ?? ""; }

It takes the pain out of 99% of the asks out there. (And there are a lot by now!)

(??= and new() are happening; see #34 and #100.)

[lazyloader]

@jnm2 I do love the idea of the field keyword, as the vast majority of the time we use properties, we want the back field only used within the property anyways. I also love the new() and ??= ideas.

However,

{ get => field ??= new(); set; }       // Lazy
{ get => field ?? new(); set; }`       // Default get
{ get; set => field = value ?? ""; }`  // Default set

Is still substantially longer than:

{ get ??= new(); set; }    // Lazy
{ get ?? new(); set; }`    // Default get
{ get; set ?? ""; }`      // Default set

The most extreme case here being Default Set, which is nearly half of what it used to be, and is pretty common to use, though the new syntax is indeed a huge improvement as is.

[jnm2]

I do like your syntax in that last comment. It only works if the value you want to replace is null though; it can't help you with default(int) or default(ImmutableArray<>). I'd prefer field first since its application would be less narrow.

[lazyloader]

@jnm2 Yes, but null checking is still very common, probably the most common of any value, so it makes sense to have it's own syntax. You could say the same thing about the ?? operator, but it's very useful. Besides, I think it's possible to have both features.

[kfsone]

I'd had a similar idea, which I mis-posted here: dotnet/docs#17922. I'd proposed '??=' rather than '??', which is effectively syntactic sugar over 'field ??= Thing2'.

[kfsone]

The case I'd been trying to address was actually parameters that default to other fields:

public string FirstName;
public string _preferredName;
public string PreferredName { get => _preferredName ?? FirstName; set; } = null;

becoming

public string FirstName;
public string PreferredName { get ??= FirstName; set; } = null;

[Joe4evr]

@kfsone Your proposed operator is practically guaranteed to not happen because as of C# 8.0, ??= is the Null-Coalescing Assignment operator.

You're gonna be better off waiting for #140 (which has a very real chance of coming out with C# 9.0), at which point you can write your case as

public string PreferredName { get => field ?? FirstName; set; } = null;

[kfsone]

@Joe4evr I'm aware of the null-coalescing operator, I was actually intentionally reusing it:

I'd proposed '??=' rather than '??', which is effectively syntactic sugar over 'field ??= Thing2'.

but the field syntax is nice and explicit, so I'm going to wait on that :)