Added: LDM Notes for October 5th, 2020

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-10-05.md

Agenda

• record struct primary constructor defaults
• Changing the member type of a primary constructor parameter
• data members

[HaloFour]

Did the team consider readonly struct record? I think that affords developers the option as to whether they want the members to be mutable. I can see that being desired especially for ref-heavy code.

[333fred]

Can I interpret this as "we can easily add immutability later"?

No. I would interpret it as "there exists in C# a very familiar keyword for making something have shallow immutability, and it would be very easy to allow it to be applied here." Further, we think that, unlike in reference types, lack of shallow immutability is not a significant issue with value types.

[AlgorithmsAreCool]

Further, we think that, unlike in reference types, lack of shallow immutability is not a significant issue with value types.

Forgive me, I've seen this come up before and haven't quite understood. I thought the language introduced the readonly modifier for structs because it allowed the compiler to elide copies for in parameters at least. If that was a motivating scenario then, why wouldn't it be a motivating scenario now?

[HaloFour]

The use of in parameters and ref types in general is fairly niche and intended for high performance scenarios. Under normal circumstances the copy-by-value nature of value types in general eliminates most of the concerns with mutability. Except in very specific scenarios you aren't sharing state where mutations could lead to unexpected results.

[AlgorithmsAreCool]

Ah, I can understand that. Although it is still a little disappointing.

I've spent too much time in F# over the years and maybe my brain is bent now, but immutable types make reasoning about code so much simpler, I'm always a little disappointed to not see them prioritized in C#.

I'll hold out hope for next year.

[333fred]

immutable types make reasoning about code so much simpler, I'm always a little disappointed to not see them prioritized in C#.

To be fair, I am too. But the truth of the matter is, deep in the core of C#'s initial design, is mutable-first. Every time we try and and prioritize the other direction, we end up at a solution that doesn't feel like C#, but like an entirely different language. For things like value equality on reference types, it's truly an antipattern to make them mutable, so we feel that it's worth the language inconsistency with the rest of C# to make them immutable-first, with an ability to opt them into mutability if you know what you're doing. But for non-reference type scenarios, it's too far against the rest of the language.

[alrz]

With this, is there any point to redclare ValueTuple as records? or it wouldn't be backward compatible?

[orthoxerox]

With improved Equals available to all structs, how much of a benefit will record structs provide? Especially if we do get primary constructors and withers as standalone features.

[333fred]

It will expose additional public surface area that we can't expose for all struct types.

[MgSam]

I think it's somewhat ironic that the LDN explicitly differentiates record struct from record **class**, but we are unable to do so in the language syntax :)

[alrz]

It was easy to foresee this situation but at the time LDT seemed to be aiming on making it unnecessary to mark a struct as record.

[CyrusNajmabadi]

Positoin is there are record classes and record structs and the former is likely to be the most common for the majority of the ecosystem, so can be abbreviated as just record for niceness.

[AartBluestoke]

comment withdrawn, 333fred pointed out that this has changed.

[AartBluestoke]

And to that point, is record a modifier or struct, or is struct a modifier of record? Either way is pretty confusing given that class, struct and record are considered to be separate types based on previous LDM decisions.

record must be a modifier, as the LDM has stated that 'record' is not considered a separate type at runtime, and that there isn't supposed to be any reliable way to tell if a class has had some of its members autogenerated via the 'record' declaration.

[333fred]

Positoin is there are record classes and record structs and the former is likely to be the most common for the majority of the ecosystem, so can must be abbreviated as just record for niceness.

fixed that for you.

No, as we decided just yesterday, you can abbreviate it. Not you must.