LDM Notes for July 31st, 2023

[333fred]

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

Agenda

• Primary constructor parameters and readonly

[qrli]

We also investigated whether we can confidently promote primary constructor parameters to full type members in a simple fashion: could we, for example, have private automatically turn into a private readonly field, and public automatically turn into a public { get; init; } property?

My understanding of current design is that primary constructor in non-record types won't generate properties. Will it or this paragraph is talking about possible future extensions?

In terms of evolution, there also a number of LDM members who are concerned about the slippery slope that is evolution in the first place. ... At what point do we say that we've gone far enough and that any further member-like things need to be actual type members?

If this is talking about bringing in many of record features, either now of potentially in future, I can understand. But if this is talking about primary constructor, I'm confused as it does not sound relevant.

we think that there's a core set of rules around mutation that apply everywhere in the language, except for records. records exist to allow C# users to work with data more easily, and they contain a number of opinions that make this easier, from value-based equality to readonlyness for reference types. We think that this is the C# we want to explain; the alternative would be explaining that primary constructors differ from the rest of C# by bringing in opinions from record types.

My impression is that all your arguments are around on the idea that "primary constructor parameters are normal parameters like in any other functions". If the scope of primary constructor parameters was just within the primary constructor body, as other functions, I'd fully agree. However, it is visible and mutable in the whole class, including other files with partial. That is the problem, and why we want it to be readonly. Unfortunately, it sounds like this is not even part of your consideration.

[CyrusNajmabadi]

IMO, I don't think that matters,

I think it does. Take, for example, the for construct. It already has a plce to put variables. So, if you use an out-varit goes into that scope. So, for the sake of example, if you had this very weird code:

        for(bool b = true, c = int.TryParse("1", out int result1); int.TryParse("2", out var result2); )
        {
            Console.WriteLine(result1);
            Console.WriteLine(result2);
        }

        // Not legal.
        Console.WriteLine(result1);
        Console.WriteLine(result2);

You'd see that result1/result2 are scoped inside teh for (like the existing variables it can declare).

Basically, we were consistent with scoping new variables in the location they would have been scoped in before. You can argue that we were inconsistent by not introducing new scopes for these embedded-statement-owners to match some of the other flow-constructs. Both are reasonable forms of consistency to argue for. We ended up going with the former because, well, it made much more sense to us to fit with existing scoping and to make it so that we would then not have to then go add more constructs to the langauge whose only purpose was to do the same, but with wider scope.

I guess it'd have to be called "anti-flow shadowing"?

Sure, why not :D

[HaloFour]

Basically, we were consistent with scoping new variables in the location they would have been scoped in before.

As if you declared the variable outside of the control statement. But you're not declaring the variable outside of the control statement. Pretending it's like that only exposes the warts of the implementation, and still creates scenarios where variables declared literally side-by-side within the same construct have completely different scopes.

The argument as to where the variable is actually declared was the same one made by C compilers that held onto wider scoping for for loops. ANSI settled that, and C# copied the ANSI behavior.

[CyrusNajmabadi]

As if you declared the variable outside of the control statement.

Right. We've been consistent with declaring the variable in the innermost scope where you would have had to declare it yourself.

But you're not declaring the variable outside of the control statement.

?

Maybe we're talking past each other, but (unless you're talking about for/foreach) we very much are. Note that for constructs that do have a scope to declare things in, we do declare in that scope. foreach works thsi was as well:

        foreach (var x in GetEnumerator(out var other))
        {
        }

        // Not legal either
        Console.WriteLine(other);

Pretending it's like that only exposes the warts of the implementation

I'm not sure what you mean by 'pretend'. There is no pretending here. We decided to be consistent with the scopes that existed prior to out-vars. for/foreach/using all have scopes to place their variables into. out-vars properly respect that and go into those scopes.

if simply has no variable scopes, period. So anything declared within its condition just goes up to the nearest scope and places into that.

--

I do get the argument that we're inconsistent in that not all flow constructs declare scopes. That would have been another way to get consistency. But choosing to not introduce new scopes and just use the ones that exist today is consistent with how scopes have always worked.

[HaloFour]

@CyrusNajmabadi

We decided to be consistent with the scopes that existed prior to out-vars.

Oops, I forgot that decision was made. Shows how often I use patterns or out vars in loops. 😅

But I do think that it's weird that if is treated differently just because there was no syntax that allowed to declare a variable in that control statement before. Feels like it should have the same scoping rules as all of the other control statements.

Anyway, tangent, obviously not being reconsidered at this point.

[CyrusNajmabadi]

Oops, I forgot that decision was made. Shows how often I use patterns or out vars in loops.

Right. It was a decision to be consistent with the past. It was also very easy to explain, and it also made several core scenarios just work out nicely without any extra effort. :)

Feels like it should have the same scoping rules as all of the other control statements.

Yes. That was another 'consistency' direction we could have gone with (and you know we cetainly did consider that and even prototype that :)).

[RenderMichael]

I respect the LDM's decision on readonly-ness of primary constructors, but I will have to abstain from using them in C# 12. Hopefully the open questions surrounding it can be hashed out By C# 13 and my team can use this feature outside of preview by late 2024.