Consider changing record syntax to `record class XYZ(...) { ... }`

[Unknown6656]

I'd like to ask the LDT to consider changing the current record-syntax to record class MyRecord(...) instead of record MyRecord(...).

... why?

I would want to propose the change for the following reasons:

• Records are currently implemented as classes. As such, I do see records as classes - analogously to how I see (value)tuples as structs. It therefore feels wrong to me to remove the class keyword from a record declaration. Furthermore, Visual Studio displays the following when hovering over the record's identifier:
• Provide some syntactic symmetry to the record struct proposal (maybe planned for C# 10?)
• It would have some symmetry with primary constructors, should they be introduced to existing class/struct-declarations (without explicitly using the concept of records).
• Less ambiguity with the traditional method syntax (at least Visual Studio 16.7-prev.6 highlights the record's name as if it were a regular method)
• Provide some kind of syntax design freedom: We could still drop the class-keyword in a later iteration of C# .... the other way around would be a breaking change.

The alternative would be to change VS' tooltips and syntax highlighting, in order to hide the class-implementation of the record-concept from the developer.

I hope that there is still enough time left before November (the month in which C#9 will be released to the larger public).

[kofifus]

You are missing my point. It is true that I can probably achieve what I want using my own code-conventions/containers/etc and an analyzer. I am in fact already doing that though I am yet to write the analyzer. However it was exactly a language feature of a record that is restricted and therefore guaranteed to be both strongly immutable and with value semantics that I was expecting/hoping for/disappointed that it is not there. Having such a language construct would have IMO pushed C# to the next level and encourage developers to write more functional/clear/bugfree/safe/etc code. But I feel that we are moving in circles here. I thank you for the responses.

[HaloFour]

@kofifus

Having such a language construct would have IMO pushed C# to the next level and encourage developers to write more functional/clear/bugfree/safe/etc code.

Having these be the default behavior is encouraging developers to write code in such a style. The developer has to go out of their way to break value identity and "readonly"-ness with positional records. What you describe beyond that is not a goal of C#.