- "I have made a critical error: I forgot to write down quotes of the day today."
#2691
https://github.com/dotnet/csharplang/blob/bff4265098ff92551a9cc6aef17b0210f737c42a/proposals/primary-constructors.md
We started today by going through the primary constructors specification, and verifying the feature we are going to ship in preview soon. There were few comments
on the specification, which is generally unchanged from the initial review. We do think that there is room to relax ref and out restrictions on record primary
constructors in the future, to align with primary constructors on non-record classes and structs, but that is an orthogonal feature that we're not going to
do at this time. We also do think that we potential future work on primary constructors to address more scenarios. For example:
- Primary constructor bodies
- Generating public properties, and naming convention discussions that will inevitably occur when this happens.
However, we don't think any of these future features are blocked by the current state of the proposal, and will continue with the plan to merge the feature branch into an upcoming preview of VS and .NET.
We will move forward with the preview.
Prototype progress on extensions (formerly roles and extensions, formerly shapes) has been proceeding in the working group. We're bringing the recommendations and changes
the working group has suggested back to the LDM for debate and approval. In order to help the prototype proceed, today we are focussing on syntax questions. The working
group explored a number of syntax options, including the original role/extension, view, shape, and alias, ultimately deciding on extension with a modifier:
explicit and implicit. The LDT agreed that this feels like it unifies the proposal: where previously the distinction between an extension and a role was hard to
remember and non-obvious, we feel that it is now much clearer. There is a single feature, extensions, which is about adding new functionality to an existing type. That
extra functionality can be added implicitly (like existing extension methods are today, but with the ability to add more) or explicitly (completely new functionality).
We also went over the newly-added for X syntax for specifying the underlying type of an extension. This is necessary for partial extensions to work. An example
with the old syntax vs the new syntax:
// Old syntax - Which of these is the interface getting extended, and which is the interface getting added?
partial explicit extension Ext1 : Interface1;
partial explicit extension Ext2 : Interface2;
// New syntax - Unambiguous for both human and computer compilers. Interface1 is the extended type, and Interface2
// is the type being added.
partial explicit extension Ext1 for Interface1;
partial explicit extension Ext1 : Interface2;Overall, the LDT is very happy with these syntax changes, and the prototype will be moving forward with them.
We also looked at another issue the working group has started to consider, extension conversions. This covers conversions in all directions: up/down (from extension to
underlying type and from underlying type to extension) as well as lateral conversions (from extension to extension with compatible underlying types). There is general
sentiment that lateral implicit conversions might not be a great thing: moving from a JsonViewExtension to a XmlViewExtension is probably not something that should
happen unintentionally. At the same time, the initial proposal envisioned the conversion to/from an extension as an identity conversion: it would be odd if there were
identity conversions from a to b, and b to c, but not a to c. The working group will continue to consider these scenarios, as well as things such as validation on conversion
to an extension, and come back to the LDM with a more complete view of the various pros and cons.
Syntax are changes, the working group will turn its attention to conversion questions.