Added: LDM notes for May 11, 2020

[agocke]

May 11, 2020

C# Language Design Notes for May 11, 2020

Records

[amis92]

Title says March, link is for May 😅

[qrli]

record class Person { string FirstName; string LastName; }

To me, this already feels like the default accessibility is public for records. Why still concern about "changing default accessbility" when adding private properties?

Other examples are interfaces, enums. For normal devs, their members are public by default, even though not accurate for language experts.

[MrJul]

My two cents:

I really don't like that I can't know without context whether string A; represents a private field (in a standard class) or a public property (in a record class). It will make going from a normal class to a record or vice versa a pain, even if I tooling will probably help. If I'm not mistaken, it's the first time the exact same syntax can mean two really different things.

Same thing with public by default without any keyword: it will break the nice rule that having no modifiers on a member means "the most restricted modifier that can be applied here is used", which has been true since C# 1.

Quoting gafter in #3231:

If (X) elements of a record's API are by default public (or may only be public), this creates the language Opinion that (Y) elements of APIs between program components may be implicit, unintentional choices.

Are the four extra characters of the data keyword to get all the nice stuff (public, equality, auto constructor assignment in case of primary constructors, etc.) explicitly really that much longer?

I really hope the LDT won't disallow adding other non public members to a record. Do you need to add some caching or pass some internal data to that nice record? You now have to ditch it completely and rewrite it as a class.

Don't get me wrong, I want records! They will really help simplify many classes in some codebases. But if they are too restricted, they risk becoming practically useless (not everything is as simple as Point(X, Y)). I know that this is a complex topic, that opinions will diverge and that's it's impossible to please everybody, but please don't cripple this feature :)

[YairHalberstadt]

If I'm not mistaken, it's the first time the exact same syntax can mean two really different things.

That's already the case for string A { get; set; } which is a private autoprop in a class, or a public abstract prop in an interface.

[YairHalberstadt]

I really don't like that I can't know without context whether string A; represents a private field (in a standard class) or a public property (in a record class).

I've pointed this out before, but I would like to reiterate: this is already the case in Scala, and I have never seen it cause any confusion. It mostly just works.

Records are extraordinarily useful for creating lots of small types whenever you use them. For them to be useful for this purpose, writing them has to be as short and low cost as possible.

[HaloFour]

@amis92

Title says March, link is for May 😅

[MrJul]

That's already the case for string A { get; set; } which is a private autoprop in a class, or a public abstract prop in an interface.

But they're both properties ;) We know that interfaces members are always public and abstract so it's fine. By writing this, I now realize the argument for having only public properties in a record: in this case there won't be any inconsistencies since that's just how record will work with all members being public and properties, no extra thinking needed (like for interfaces or enums). The second you add private fields, it becomes some weird hybrid approach where the syntax is ambiguous.

I understand the needs filled by this approach, but I personally don't like that there's no middle ground: you're either a simple record without logic nor private data, or you're a fully fledged class. The moment you need to add the slightest logic to your record, you have to rewrite it as a standard class and it won't be as simple as removing the record keyword.

I've pointed this out before, but I would like to reiterate: this is already the case in Scala, and I have never seen it cause any confusion. It mostly just works.

Thanks, that's good to know!

[YairHalberstadt]

But they're both properties ;) We know that interfaces members are always public and abstract so it's fine.

Ever since C# 8 they can be private sealed.

[333fred]

Title says March, link is for May

Fixed, thanks.

[HaloFour]

IMO a record keyword on the type shouldn't affect the visibility of said type. Forcing them to be public I think complicates scenarios where they would be defined for internal use but now there's no way to prevent exposing them on a public API surface. It also creates an inconsistency with the rest of the language where the lack of an accessibility modifier already defines the accessibility of the type, but not as public, which will make this impossible to revisit in the future.

I also don't think that records should prevent other members. There's certainly value in supporting computed properties or methods, and I can imagine that we'd want validator support as well. I don't even think that there's a problem with additional private state, even if they don't participate in value equality. I'm not aware of another language that prevents additional members, including F#. That said, restricting them in the short term wouldn't prevent enabling them again in a future release.

[MgSam]

I'm having a hard time following the records proposal over time as there doesn't seem to be a single living WIP document anywhere. The proposals in here are all out of date. I guess this is the closest thing to a most recent proposal?

I'm not even clear whether explicit accessors are allowed or not? I hope so, otherwise the uses for records will be severely limited.

I can't see how you could possibly disallow private members. Not having private members means that as soon as you do need a private member you now need to refactor into a normal class, which is a huge cliff to fall off of.

Your Person example is actually perfect for illustrating this.

record class Person 
{
    string FirstName;
    string LasName;
}

Ok, now the Boss wants a computed FullName.

record class Person
{
    string FirstName;
    string LastName;
    string FullName => $"{FirstName} {LastName}"; //Is this allowed???
}

Actually, let's cache that since this thing is immutable anyway.

record class Person
{
    string FirstName;
    string LastName;
    string FullName =>_fullName ??= $"{FirstName} {LastName}" //Is this allowed???
    private string _fullName; //Surely, this must be allowed???
}

[MgSam]

Has the LDC discussed records implementing == yet? It still seems bizarre to me implementing types with value semantics that don't have those semantics on ==.

Watching the C# video from Build the the most jarring part of the demo is watching them use Equals() explicitly rather than ==.

[spydacarnage]

That might have been so they could more easily demonstrate the difference between value and referential equality?

…

On Fri, 22 May 2020 at 20:21, Sam ***@***.***> wrote: Has the LDC discussed records implementing == yet? It still seems bizarre to me implementing types with value semantics that don't have those semantics on ==. Watching the C# video from Build the the most jarring part of the demo is watching them use Equals() explicitly rather than ==. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/dotnet/csharplang/issues/3470#issuecomment-632868973>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADIEDQIL5H33XMSCSOHN3Z3RS3GCJANCNFSM4NEYF76A> .

[MgSam]

@spydacarnage It's been an "open question" on whether to have records implement ==. Given the fluctuating design it's not clear if they've discussed or made a decision there yet.

[spydacarnage]

Would it not default to the standard definition of ==, which would mean that Equals and == worked differently, which would be even worse?