Added: LDM Notes for June 24th, 2020

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-06-24.md

Agenda

1. Confirming Function Pointer Decisions
2. Parameter Null Checking
3. Interface static Member Variance
4. Property Enhancements

[HaloFour]

Were there any thoughts around the use of !! to force a null check in code instead of just for parameters?

[333fred]

Were there any thoughts around the use of !! to force a null check in code instead of just for parameters?

Nothing new from last time. However, the sentiment last time was that the ability to do this was viewed as a significant positive to the !! syntax.

[HaloFour]

@333fred

One more question about !!, does the Null Catcher try to lure the nulls out of the basement with candy? No null can resist treacle tarts and ice cream.

[bbarry]

Call it the "double tap" operator?

[jnm2]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-06-24.md#Property-Enhancements

I think it's great that property-scoped fields (#133) are getting attention. The asks leading to the field keyword (#140) are usually explicitly around brevity maybe 2-1 or better, so I don't think demand for #140 will diminish when #133 is usable.

The 95% case for me looks like this:

private SomeType someProperty;
public SomeType SomeProperty { get => someProperty; set => Set(ref someProperty, value); }

That's two lines and two manually synced names across four rename spots. Property scoping gets rid of the private keyword, but it's hard to argue that it makes this common case more readable, and it's still two manually synced names across four rename spots:

public SomeType SomeProperty { SomeType someProperty; get => someProperty; set => Set(ref someProperty, value); }

I wouldn't want to go from two to six lines per property, so I won't even write that out here.

This would be my ideal:

public SomeType SomeProperty { get; set => Set(ref field, value); }

It sounds like this might happen no earlier than C# 11. That's a long wait for something that has accrued as much feedback as #140. I'm happy that the discussion is happening though!

[orthoxerox]

For me the 95% case is "set the backing value, and also...". Since the "also" can happen either before, or after setting the value I am rooting for delegated properties.

[bbarry]

I'm totally in favor of #133 over #140 or #2657 though they are certainly not contradictory from each other at all.

A weak version of #2657 is coming in .net 5 with the additive compiler functionality. I suspect it will not hit the syntax that would be ideal but it will be better than nothing.

#133 would appreciatively widen the net of safely falling into the pit of success using C#. The benefit is not "property scoping saves you from typing private" but rather "property scoping ensures safe access to the fields by limiting scope to a specific point"

#140 merely saves you a little bit of typing over #133. It could do more though by saving a slot when inheriting I think in some circumstances?

[jnm2]

@bbarry For a safety net in the meantime that's just for INPC, you might be interested in https://www.nuget.org/packages/PropertyChangedAnalyzers. It's quite sharp.

[bbarry]

The vast majority of my cases fit into:

This addresses the issue of properties backed by a different storage type: if you have a property that uses a Lazy<T> to initialize itself on first access, for example.

Though not Lazy<T> specifically (mutable BTS types backing immutable properties for example). I feel fortunate to have never really been in the need of INPC.

[quinmars]

This addresses the issue of properties backed by a different storage type: if you have a property that uses a Lazy to initialize itself on first access, for example.

How does that usage look like?

I do not use Lazy<T> that often, but when I do, it looks like the following lines:

private readonly Lazy<SomeHeavyClass> _someProperty;
public SomeHeavyClass SomeProperty => _someProperty.Value;

The backing field assignment might happen in the constructor may happen in the constructor or directly next to the declaration. Doing the same with #133

public SomeHeavyClass SomeProperty
{
    private readonly Lazy<SomeHeavyClass> _field = ...;
    get => _field.Value;   
}

needs more lines and a few keystrokes less. Plus, you cannot assign the backing field in the constructor. In ReactiveUI there is a ObservableAsPropertyHelper<T> that uses the same pattern as the Lazy example above. There, the backing field is usually set in the constructor.
But, I actually cannot think of an realistic example, where you need a backing field of a different type for a property with getter and setter.

[quinmars]

..., and it's still two manually synced names across four rename spots

@jnm2, to be fair, you could always use the same name for the backing field. For example field.

public SomeType SomeProperty { SomeType field; get => field; set => Set(ref field, value); }

You still have to manually snyc the type, though.

[theunrepentantgeek]

But, I actually cannot think of an realistic example, where you need a backing field of a different type for a property with getter and setter.

I've used this pattern many times:

public IEnumerable<Item> Items 
{
    get => _items;
    set
    {
        _items.Clear();
        if (value != null)
        {
            _items.AddRange(value);
        }
    }
}

private readonly List<Item> _items = new List<Item>();

Publishing the property as IEnumerable<Item> gives maximum flexibility for consumers, but storing it internally as List<T> gives a richer API for internal use.

[CyrusNajmabadi]

How does that usage look like?

It would look like this:

public SomeHeavyClass SomeProperty
{
    Lazy<SomeHeavyClass> _someProperty;
    get => _someProperty.Value;
}

It's longer, but nicely scopes things so that other code doesn't use the backing field inappropriately.

[jnm2]

@CyrusNajmabadi Often Lazy<T> instances are initialized in the constructor because field initializers can't reference this. What would that look like?

[jnm2]

@quinmars That's an excellent point that I hadn't considered. The scoping actually does let me get away from maintaining a second name. Thank you!

[quinmars]

@theunrepentantgeek, good point! I haven't thought about that.

With #140 you could write

public IEnumerable<Item> Items 
{
    get;
    set => field = value.ToList();
}

But I acknowledge that this shows a slightly different behaviour. I'm not decided if that is better or not.

[quinmars]

@jnm2, you're welcome!

[jnm2]

@quinmars I think you mean #140 for #3615 (comment)?

[quinmars]

Indeed, corrected. Thank you.

[binki]

How does that usage look like?

It would look like this:

public SomeHeavyClass SomeProperty
{
    Lazy<SomeHeavyClass> _someProperty;
    get => _someProperty.Value;
}

It's longer, but nicely scopes things so that other code doesn't use the backing field inappropriately.

Due to the issue @jnm2 raised and to avoid making many instances of Lazy<T>, one might use LazyInitializer.EnsureInitialized<T>() instead. When using EnsureInitialized<T>(), it is all the more critical to ensure that the backing field cannot be accidentally accessed because you’ll get a NullReferenceException.

[alrz]

In my opinion, an attribute approach is superior to unwieldy !! operator

[Handler]
class N : Attribute { 
  public static void Handle<T>(T o, [CallerArgumentExpression(nameof(o))] string name = null) where T : class? {
    if (o is null) throw new ArgumentNullException(name);
  }
}

public void M([N] Chitty chitty) 
{
}

// ->

public void M([N] Chitty chitty)
{
    N.Handle(chitty);
}

You can define your own logic or make it [Conditional] if Debug.Assert behavior is all you want.

[CyrusNajmabadi]

In my opinion, an attribute approach is superior to unwieldy !! operator

We considered this and it was soundly outvoted by all the participants fwiw.

[BobSammers]

@jnm2, to be fair, you could always use the same name for the backing field. For example field.

public SomeType SomeProperty { SomeType field; get => field; set => Set(ref field, value); }

This is a good point and having a "conventional" identifier for the backing field would definitely be a benefit, negating problems with refactoring property / field names.

I think the argument for property-scoped fields is well made in the LDM notes, particularly in the case of backing fields of differing types to the property, but I'm also encouraged (because I still think there is a lot of use where simply using an automatically generated field would be the simplest and clearest option) that the proposals set out in #140 are still being considered because they are not mutually exclusive...

... which leads me to wonder what will happen to #140 if property-scoped fields are implemented ahead of #140 and developers start writing all their code with field (or other, similar names) used as a property-scoped backing field!

[BobSammers]

If field was allowed to be overridden as an identifier by using a declaration and implied if not, the above might be a moot point.

[jnm2]

@BobSammers It wouldn't change the fact that #140 already requires binding field as a keyword only if it doesn't bind to a name in scope. Similar to how var and nint work.

[HaloFour]

Nod, if #140 is implemented based on property-scoped fields the compiler would still have to recognize the difference between the two:

public class C {
    public string field;

    public string Prop1 {
        string field;
        // references property-scoped field
        get => field; set => field = value;
    }

    public string Prop2 {
        // references class field
        get => field; set => field = value;
    }
}

[BobSammers]

Yes, @jnm2 and @HaloFour, you're both right, of course, it shouldn't change anything. field couldn't become a reserved word without it being a breaking change, which I'm sure wouldn't be considered.