LDM Notes for July 17th, 2023

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-07-17.md

Agenda

• Compiler Check-in
• readonly parameters

[jnm2]

• Name isn't great. Many of us think it should have field in it somewhere, as that's what we've been internally calling it.
• field access for auto properties is the proposal.

🎉

[jnm2]

Is it still "field access for auto properties" in these cases? Are these referred to as auto properties now?

public int Foo => field ??= ComputeFoo();

public int StructPropertyWhereDefaultInstanceReturns10
{
    get => field + 10;
    set => field = value - 10;
}

[DavidArno]

@jnm2,

I think "field access for auto properties" is a really good descriptive name. There is no need to explicitly define a backing field for those properties, therefore they are auto properties. And that implicit backing field can be accessed via field giving us literally field access for those auto properties 🎉

[jnm2]

That's my question. Is the term "auto properties" now expanded from the original (I think), "auto-implemented properties"? The forms I shared above using field can't be said to be auto-implemented.

[DavidArno]

"auto-implemented properties" is correct: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/auto-implemented-properties

That is a good point. The docs around auto-implemented properties will need updating to clarify their change in meaning in this case.

[CyrusNajmabadi]

Yes. We always update our docs when new lang features come up that affect them :-). We will definitely do that here when this feature ships.

[yaakov-h]

I chuckled at the Quote of the Day, well done to whoever came up with that one.

[huoyaoyuan]

Roles/extensions
The name in this file needs to be renamed to catch up to the current feature name extensions, but as this will only be in preview for C# 12 we aren't tied to the name yet.
In preview for C# 12.

In dotnet/roslyn#69074 it's marked as Cut. What's the design progress of implementing interfaces?

I'm concerned about current ref-struct emitting strategy. If we don't commit IL compatibility for C# 12, we can have more space on this.

[CyrusNajmabadi]

Cut means that the final release will not be in 12. Previews will come out whenever ready. As there is a lot of uncertainty there, is hard to even estimate when that might be.

[KennethHoff]

Using that logic, aren't interceptors also "cut"? They're also in preview

[Richiban]

Using that logic, aren't interceptors also "cut"? They're also in preview

I suppose "cut" refers not just the fact that a feature's in preview but that it might have made the release in full and has been changed to preview.

Interceptors were always intended to be in preview for this version, if I understand correctly.

[CyrusNajmabadi]

Correct.

[333fred]

To be clearer than my notes: part of extensions may make preview when C# 12 releases, but they may also miss the initial release and enter preview at a later point during C# 12's life cycle.

[RenderMichael]

I think a much better idea for local mutability instead of adding readonly (which i think LDM has been right about, it would be insanely noisy and make “good code” look ugly) is actually a somewhat larger change.

I suggest adding a new MSBuild property akin to <Nullable> which makes every local and parameter variable immutable unless specified, and some syntax like mut var becomes the syntax for a mutable variable.

For both Roslyn developers and C# users, this would be a significantly smaller undertaking compared to nullability analysis. Much like adding ? across our codebases any mutability warnings would be easily fixed where necessary.

Drawbacks

this would be yet another flavor of C#, as well as another MSBuild property.

A good alternate plan would be to make mut optional by default, giving users a warning where a local is mutated, but not stopping users from doing so.

Although my preference is to enforce immutability, the alternate plan may be more appealing to the LDM.

[KennethHoff]

This has been suggested before (in this post?), and the general idea is that they (the LDM - "The team") really really really do not want "dialects"(code that works differently based on external context). I do believe there's only 1 example of it, and that's Nullable as you've mentioned.

However, there is one thing that can be done on this (which I believe is also mentioned here), and that's an analyzer-based approach where everything is assumed to be immutable unless is done to state it can be mutated. You can't add Attributes to locals (yet at least), so that can't be it, but maybe a prefix to the name? mut_firstName is mutable and firstName is immutable.

That said, I wish closed-first was an official option in C#. Basically a way to turn this boilerplate:

public sealed class Person
{
    public required string FirstName { get; init; }
}

to this:

public class Person // sealed by default 
{
    public string FirstName { get; init; } // required by default.. 

// "init by default" doesn't really make sense as set and init are both on equal footing, although if they weren't, that would also be the default
}

[333fred]

I do believe there's only 1 example of it, and that's Nullable as you've mentioned.

checked is another, one we regret.

[RenderMichael]

I think this could be a very minimal feature. An analyzer (warning by default) which warns on mutating variables; introduce mut as a way to suppress this warning.

no more a dialect than introducing using declarations over using statements IMO

[RenderMichael]

In fact, the only difference between the above and every other analyzer introduced with each new .NET version (aside from the unique mut suppression mechanism) is the crazy number of warnings it will produce. I assume larger projects would suppress the warnings while working through fixing them. Maybe there can even be a fix-all fixer to make everything mut but that sounds like a pit of failure

[333fred]

To be clear, @RenderMichael, the notes discussed and rejected this idea:

For readonly on parameters and locals, we feel similarly that we don't want the default of the language to be long modifiers on all parameters and locals, but are unconvinced that the scale of the problem is large enough to warrant language dialects like we did for nullable, given the narrow scope of locals and parameters.