Added: LDM Notes for March 10th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-03-10.md

Agenda

1. Property improvements
   1. field keyword
   2. Property scoped fields
2. Parameterless struct constructors

[BreyerW]

I like that you switched priorities about field. As you noted yourself field actually trims useless boilerplate.

Im also curious how parametreless constructors will flesh out in the end considering legacy baggage

[HaloFour]

Are these truly only visible in the property? Or can they be seen from the constructor? If they're not visible in the constructor, then it seems like that restriction would mean Lazy<T> would be unusable, since it likely needs access to this.

IMO, I think this problem can be solved by allowing the property-scoped fields to access this from their initializer and silently insert those initializations into the constructor after the base constructor is called:

public class C {
    public string Foo {
        Lazy<string> lazy = new Lazy<string>(this.CalculateFoo);
        get => lazy.Value;
    }

    private string CalculateFoo() { /* expensive stuff here */ }
}

would translate into:

public class C {
    Lazy<string> $Unspeakable_Foo_lazy;

    public C() : base() {
        $Unspeakable_Foo_lazy = new Lazy<string>(this.CalculateFoo);
    }

    public string Foo {
        get => $Unspeakable_Foo_lazy.Value;
    }

    private string CalculateFoo() { /* expensive stuff here */ }
}

Even better would be if the property-scoped field could be treated like a static local and support inference:

public string Foo {
    var lazy = new Lazy<string>(this.CalculateFoo);
    get => lazy.Value;
}

Although even without that. with target-typed new I could see property-scoped fields being a very easy way to support lazy properties.

[333fred]

While we didn't discuss this as an option, I think this would be very confusing. What would happen if such a property had an initializer itself? And the fact that initializers for fields run at a different time than property-scoped fields is weird. It also eliminates the ability to use values passed into the constructor in such initializers... Suffice to say, I'm not a fan 🙂

[HaloFour]

What would happen if such a property had an initializer itself?

Doesn't make sense to support property initializers here, just like they're not supported for non-auto-properties. If you want to initialize the scoped backing field(s), do so in the declaration of the scoped backing fields. Property initializers only work when there is a single compiler-owned-and-controlled unspeakable backing field of the same type of the property to initialize.

And the fact that initializers for fields run at a different time than property-scoped fields is weird.

I'd suggest that the vast majority of developers wouldn't notice. It's practically unobservable, except when doing pathological things, like calling virtual members from within the base constructor. The inability to access this in a field initializer is already painful, particularly when using Lazy<T>, and I think the language would benefit from relaxing this restriction in general by reordering when initialization happens.

It also eliminates the ability to use values passed into the constructor in such initializers

IMO they're scoped specifically to make them inaccessible, even from the constructor. You can use a private init to initialize the property from the constructor. You'd have to invent an entirely new syntax to access the fields, especially since "dotting" into them would be ambiguous depending on the type of the property.

[alrz]

I'd agree these shouldn't have type-level initializers and the fields shouldn't be accessible anywhere outside the prop, but private init won't solve Lazy<T> initialization still, due to type mismatch.

IMO calling instance members in constructors is already error-prone and can result in access to uninitialized fields. I don't think making it available here is a good idea.

[huoyaoyuan]

While non-defaultable structs are an interesting idea that LDM has looked at in the past, it is orthogonal to this feature and will need a bunch more rules than we can put in here.

Are you really sure that introducing non-defaultable struct later won't cause more pain? If so, the decision should be OK.

[jnm2]

I'm not sure that new StructThatDoesntHappenToHaveAConstructorRightNow() should be discouraged. I've been doing it in cases where I'd want to be running the constructor if the struct ever started shipping it in the future.

[333fred]

That specifically means places that wouldn't use the constructor, regardless of whether one is added in the future. Adding a constructor would turn that warning into an error.

[jnm2]

On recompile it would, though. That's the 99% scenario where I use this. Almost impossible that the binary would be swapped out without recompiling. (Apps are this way. Libraries are different, but I also don't find myself writing libraries where I use this unless the library itself also defines the struct.)

[333fred]

On recompile it would, though.

On recompile what would? I'm not understanding. This warning or error would be reported in places like void M(S s = new S()) => ..., which will never use the constructor, no matter how many times you recompile.

[jnm2]

@333fred Oh, I misunderstood. I thought the warnings would extend to usages such as var x = new StructWithNoConstructor();.

[333fred]

No, those are fine 🙂

[YairHalberstadt]

Why not simply warn on private and internal parameterless constructors in a struct, rather than at the use site?