Added: LDM Notes for May 27, 2020

[agocke]

C# Language Design Notes for May 27, 2020

Record syntax
1. Record structs?
2. Record syntax/keyword
3. Details on property shorthand syntax

[HaloFour]

Do not support structs for now. They already support many features of records and we can add more, time permitting.

This is all fine or good, but deciding to make record it's own flavor of type instead of a modifier of existing types will only back the team into an awkward corner later if it is decided to extend some of the behaviors of records to structs. It also completely avoids the mentioned ambiguity and breaking change, and even if the ambiguity could be avoided in the compiler (by switching on the language version? really?). It's one additional keyword, one that could be written by auto-complete, and it's worth it for the sake of clarity and future flexibility.

So, based on these decisions, what does the following mean?

public struct Point(int X, int Y);

[agocke]

awkward corner later if it is decided to extend some of the behaviors of records to structs

It was mentioned that the syntax record struct Point(int X, int Y) could be added later. Some concern that this is asymmetric, but doesn't seem to be a dealbreaker.

public struct Point(int X, int Y);

As of last LDM, this is invalid syntax. When we have a complete primary constructor (not records) proposal, that will probably be a parallel construction to a non-record class with a primary constructor.

[HaloFour]

@agocke

It was mentioned that the syntax record struct Point(int X, int Y) could be added later. Some concern that this is asymmetric, but doesn't seem to be a dealbreaker.

Yes, it could, but now struct is a modifier instead of a type in it's own right? Or record is sometimes a modifier and sometimes a type? That just feels weird. Might as well go the F# route and make it an attribute for that extra bolted-on feeling. So many issues could be outright avoided by making record a modifier and leaving everything else alone.

Especially this notion that the following could mean two completely different things in C# 8.0 vs C# 9.0. Seems very unlike how C# has ever evolved contextual keywords. I don't think that the move to evolve the language with the runtime justifies it.

public class C {
    public record M(int x, int y) { }
}

[agocke]

Yes, it could, but now struct is a modifier instead of a type in it's own right?

You mean from the syntax perspective? That's not how I would implement it, I would just make it an optional token after the record keyword.

Especially this notion that the following could mean two completely different things in C# 8.0 vs C# 9.0.

Yup, as mentioned this is a breaking change, and will be interpreted one way before C# 9 and a different way after.

[qrli]

public record Point(int X, int Y);
public record Point
{
   data int X;
   data int Y;
}

I understand this makes nominal record more consistent with positional record. But suppose if I were to change Y to have explicit property get/init implementation, what changes should I do? Like below?

    // data int Y;
    int Y 
    {
        get => backingFieldOfY; 
        init => backingFieldOfY = value >= 0 ? value : throw new ArgumentException("..."); 
    }

Or, make the question in another way: does it mean data int Y is another way to say int Y { get; init; }?

[agocke]

@qrli Yes, data is a short-hand for init-only auto-prop

[iam3yal]

I know that what I'm going to propose here might be a bit weird but wouldn't it be possible to introduce record class later when record struct is introduced for symmetry and maybe for people who might want to be more explicit? so record gonna be a syntactic sugar to record class.

Personally, I prefer record class over record for consistency and because of that I wonder whether it might be sensible to add it later as suggested above.

[agocke]

I see no reason why we couldn't choose to do that.

[BreyerW]

I second all @HaloFour 's concerns. Since he already spilled everything i thought of i will leave it at that

[Unknown6656]

I agree with @eyalsk:
Introduce record [class|struct] .... instead of introducing a breaking change.

---

C# LDT meeting [ca. 2020, colorized]

_{'twas just a joke 😘}

[spydacarnage]

Joking aside, I totally agree. Not having a breaking change, and having the ability to potentially avoid somebody suggesting "valuerecord" or some-such in the future, is well worth having to write "record class" vs "record". Also, while structs currently have value equality, the ability to easily add "with" support to a struct would be something I'd like to see.

…

On Mon, 1 Jun 2020 at 11:28, Unknown6656 ***@***.***> wrote: I agree with @eyalsk <https://github.com/eyalsk>: Introduce record [class|struct] .... instead of introducing a breaking change. ------------------------------ [image: image] <https://user-images.githubusercontent.com/8807985/83400387-05f4ae00-a403-11ea-9394-eb81a284e979.png> *C# LDT meeting [ca. 2020, colorized]* 'twas just a joke 😘 — 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/3526#issuecomment-636769213>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADIEDQNJBEFJTAFYMH33A7TRUN7DRANCNFSM4NPLCSWA> .

[Joe4evr]

the ability to easily add "with" support to a struct would be something I'd like to see.

That would be as easy as this, once the work for the factory method attribute gets done:

public struct S
{
    [Factory]
    public S With() => this;
}

Though this does presume that any fields of reference types can't be mutated in-place. If there is such a case, you'd do new S(this) that makes a deeper copy.

[333fred]

We don't even need copy constructors to implement with on structs. We can just dup them and then set fields/properties.

[MgSam]

I don't understand the LDT's seeming obsession with shaving off every possible character for the records feature. Is record class vs record really such a burden? Is public int Age {get; init;} vs data int Age; really such a burden?

Snippets/autocomplete can handle most of the typing, and adding/changing types/members is not something most people are doing on a daily basis. You spend most of your time working with the types, not writing their definitions.

This isn't like adding var to the language where it's saving a ton of typing. The few saved characters are not worth the increased complexity and ambiguity to the language. Making records look like a 3rd fundamental kind of type is a mistake that will confuse newcomers and oldcomers alike. data saves so few characters it is not worth the ambiguity that it looks a lot like a field.

[HaloFour]

I'm conflicted about the notion of the data keyword and nominal records. I can sorta understand the desire to make the declarations shorter, especially compared to their positional brethren. But at the same time I think it obscures what the record is about and it limits what you can do now and potentially in the future with those members.

IMO, I'm not offended by having to have full and proper property declarations in a nominal record. They are, afterall, the focal point of what that type represents. Having them look and act like regular auto-properties would be fine to me and I think would decrease the cognitive load when learning about these types. What I don't want to have to write is all of the rest of the boilerplate code that goes into value equality and cloning. That's where I personally find the value of records. Not in trying to make the data declaration as terse as humanly possible. The data keyword kind of feels like an example of trying to make a new language feature stand out.

[HaloFour]

This seems to be what Scala is doing:

class Base1 {
  override def equals(that: Any): Boolean = false
}

class Base2 { }

case class Foo(val x: Int) extends Base1 { }
case class Bar(val x: Int) extends Base2 { }


object Main {
  def main(args: Array[String]): Unit = {
    
    if (Foo(123) == Foo(123)) {
      println("foo equals")
    } else {
      println("foo not equals")
    }
    
    if (Bar(123) == Bar(123)) {
      println("bar equals")
    } else {
      println("bar not equals")
    }
  }
}

prints:

foo not equals
bar equals

[CyrusNajmabadi]

I shouldn't be able to pass a record to a T where T : class

Sure you would. That's the constraint that says this is a reference type. We picked class there because it's convenient not because you're only restricted to classes.

For example you can pass interfaces to your type parameter here, as well as delegates. Interface are not classes. Delegates aren't either. But they are things that satisfy theclass constraint.

The same would hold for records.

[CyrusNajmabadi]

Similarly, the struct constraint doesn't mean structs or value types. That's why there are some structs you can't pass to methods that have that constraint. class/struct in constraints we're just really convenient wats for us to have a syntactic shorthand for the constraint concept here. It's never been a straight literally interpretation.

[CyrusNajmabadi]

Do library authors have to add overloads supporting records everywhere they're supporting classes?

No. As per above. If they have overloads to handle reference types specially, then records will just work there.

[CyrusNajmabadi]

Existing record-like class implementations can't be simplified to records.

Why not?

[CyrusNajmabadi]

When designing a new record, you have to be very careful, you won't be able to turn it to a fully fledged class if needed in the future without breaking all your consumers.

Why not? Our designs up to now have considered that an important migration path for code. I know of nothing in the design that would prevent or limit that. Indeed, I was planning on writing the ide features to do just this.

[omariom]

public record Point
{
   data int X;
   data int Y;
}

I would exchange data shortcut for struct records without thinking for a second.

[MrJul]

Sure you would. That's the constraint that says this is a reference type. We picked class there because it's convenient not because you're only restricted to classes.

That's fair, a record is just another reference type and where T : class has always allowed any reference type despite its name, I'm fine with that, that ship has sailed.

Why not? Our designs up to now have considered that an important migration path for code. I know of nothing in the design that would prevent or limit that. Indeed, I was planning on writing the ide features to do just this.

Then records are just classes, that's just not a compiler detail. For all intents and purposes records and classes are the same and interchangeable (and they really are under the hood). That's why others and I have difficulties agreeing to the concept of records as their own kind of entity and the drop of the class keyword (with a breaking change!) when even the tooling will help you convert from one to another.

When introducing tuples to people, they don't have to know how it's compiled: as you said I also think of a tuple as a separate entity and the implementation is a detail. With records, people will be taught that records are classes with sugar (a sweet one that is) since they have to know that to use them properly.

I really appreciate that you took the time to answer.

[CyrusNajmabadi]

Then records are just classes,

As I said myself:

"A record compiles down to a class."

Just as many other things in the language compile down to other things.

That's why others and I have difficulties agreeing to the concept of records as their own kind of entity

That's a perfectly fine opinion. I don't share it. Something can be it's own entity, but still be compatible with another. Tuples are their own entity for me, but they compile down to a standard struct and can be used anywhere that specifies a value type constraint. That doesn't bother me.

[CyrusNajmabadi]

I really appreciate that you took the time to answer.

Happy to :-)

[CyrusNajmabadi]

When introducing tuples to people, they don't have to know how it's compiled:

But a lot of people did care about this. It was actually a large point if contention for people (and still is), that it's a mutable value type.

You'll always have some people who care and pay attention to the underlying representation, and some who don't care.

[CyrusNajmabadi]

With records, people will be taught that records are classes with sugar (a sweet one that is) since they have to know that to use them properly.

I have no problem with that. TypeScript classes (before ecma introduced them) compiled down into JavaScript constructor functions. It was just sweet sugar. So what? We could have gone with a constructor keyword on functions (which was considered), but we decided we preferred not to and that a dedicated (i.e. non-modified) syntax was preferable.

If people get told that this is a nice simple shorthand for a class with lots of behavior baked in, I have no problem with that. And that doesn't make me not want a simple syntax here for these.

[AlgorithmsAreCool]

I am a little bummed to see struct support getting pushed out for now.

One important side effect of making type declarations easier/smaller, is that people will want to define more types now that it isn't as much of a pain.

Finer grained types can help the compiler assist in validating correct programs. But if they are all classes it holds this feature back from performance sensitive areas where chatty object allocation would impede performance. Which is doubly unfortunate, since performance oriented code often needs additional help in being proven correct.

My current workaround is to define my fine-grained types as struct records in F# then reference the assembly from my perfy C# code to try to have my cake and eat it too.

[ufcpp]

I wish primary constructor for (non-record) classes and structs will be in C# 9 and it is consistent with that for records.

[Unknown6656]

@ufcpp : I really hope that, too!