Added: LDM Notes for Feb. 10 & 12, 2020

[agocke]

Feb 12

C# Language Design Notes for Feb. 12, 2020

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-02-12.md

Feb 10

C# Language Design Notes for Feb. 10, 2020

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

[Thaina]

Why both of this feature is keyword instead of attribute?

[YairHalberstadt]

record Point(int X, int Y); is currently a valid declaration in an interface.

[alrz]

but since the class keyword is implied by default

I thought we're going with data class for records, why the record keyword is preferable?

I think the former would allow declaring a data struct P(int X, int Y) aka "named tuples"

To me, record P syntax is not as expressive as spelling out class, since that's what it is.

[ghost]

I would also like to support the opinion that data class is better than record: it describes itself (new developer: "What is a record?" -> Google: "It is an immutable class with value equality" -> "Oh, I see, so that's like a class useful for data transfer!") and also clearly states that it is still a reference type.

[333fred]

I thought we're going with data class for records, why the record keyword is preferable?

@alrz all we've decided at this point is that there will be a keyword. We have not decided what the keyword will be.

[alrz]

From what I read, the plan was to distinguish between a record and primary constructor to use a keyword (data). I think now the argument is a type kind versus a modifier, I (and a few others on another thread) argued that a modifier is actually more flexible and expressive as it doesn't hide the fact that we have a class (or struct). data really acts as an extension to that declaration, e.g. adds equality support and properties. Unless the declaration syntax is dramatically different from what we have for a class/struct, I'd prefer we indicate that with a modifier and not introduce a whole new type kind.

btw, I don't see any reason to not support struct-based records, in which case we'd need to use class/struct anyways.

[HaloFour]

That keyword would do a lot more than just add value equality, right? What about deconstruction and various other forms of boilerplate that would also apply to structs?

public record struct Point(int x, int y);

[WolvenRA]

Just out of curiosity, why not use structures instead of a class for "records"? Seems like it would be a more natural fit. Also, maybe I'm not understanding something but, if you want immutable fields in the "record" isn't there already a "const" keyword for doing exactly that?

[Thaina]

@WolvenRA Because we already have tuple. We try to have record to be something like syntax for a fast declaration of reference type tuple

[theunrepentantgeek]

Because struct is a value type that's usually copied, not referenced, modifications often don't end up where people expect, hence the strong guidance from many that struct definitions should be immutable - and many people want mutable records.

[WolvenRA]

I pass structures by reference all the time... but mine are not immutable. The structures I create and use are specifically for the purpose of storing, changing, and passing data records around.

[DavidArno]

@theunrepentantgeek,

Why would you want mutable records when you’ve got withers? Withers provide a means of allowing records to be immutable by default without limiting functionality.

[orthoxerox]

@DavidArno to add to that, mutable records are already a thing, you just make a class with a bunch of public fields/autoprops and bam, that's your mutable record.

[agocke]

Right now we're assuming that you could make a struct or a class record. The syntax may make one the default.

[HaloFour]

@agocke

It's good to know that struct records will still be supported.

IMO it's not really worth it to allow omission of struct/class. It doesn't make the type any clearer to define, and it complicates the implementation in the compiler given that said syntax is already perfectly legal when declaring instance members. That makes record a contextual keyword and forces the compiler to consider the context in which it is used. If that record has a body and local functions it could require reading quite a bit ahead to figure that out. I imagine that both the compiler and the tooling could be quite confused by a partially defined record.

public class Foo {
    // what am I, a method declaration or a record type?
    public record Bar(int x, int y) {
        // field or local?
        int z = x + y;
        // instance method or local function?
        int Add(int z) {
            return x + y + z;
        }

        // oh, I guess I'm a method declaration
        return null;
    }
}

Seems worthwhile to eliminate that ambiguity by making the keyword a type modifier. I doubt anyone is going to protest over an additional six characters.

[theunrepentantgeek]

@DavidArno

Why would you want mutable records when you’ve got withers? Withers provide a means of allowing records to be immutable by default without limiting functionality.

I wouldn't. I strongly prefer writing immutable types and do so even now wherever possible; I'm a big fan of some of the proposed features that would make doing so less onerous.

But, it's my understanding that there are strong proponents for mutable records - and I don't see that my personal preferences/style should necessarily restrict them.

[DavidArno]

@theunrepentantgeek,

But, it's my understanding that there are strong proponents for mutable records - and I don't see that my personal preferences/style should necessarily restrict them.

I'm not suggesting they be restricted. I'm suggesting that immutable records be the default form, with extra syntax needed to enable the mutability. And all that syntax need be is:

public data struct Point(public int X, public int Y); // X and Y are readonly

public data struct MutablePoint(public int X { get; set; }, public int Y { get; set; }); 
// X and Y are mutable

And the "good practice" advice would be to use the read-only form with withers to modify them unless full mutability is eg needed for performance reasons.

[Joe4evr]

I'm suggesting that immutable records be the default form, with extra syntax needed to enable the mutability.

Of note, this falls in line with a statement by Gafter that the Language Team wants the norm to be that mutable constructs take more to express than immutable ones, so that developers keep getting encouraged to design around immutability first. 👌