# C# Language Design Meeting for February 22nd, 2023

## Agenda

- [Primary Constructors](#primary-constructors)
- [Extensions](#extensions)

## Quote of the Day

- "I have made a critical error: I forgot to write down quotes of the day today."

## Discussion

### Primary Constructors

https://github.com/dotnet/csharplang/issues/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` `class`es and `struct`s, 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.

#### Conclusion

We will move forward with the preview.

### Extensions

https://github.com/dotnet/csharplang/issues/5497  
https://github.com/dotnet/csharplang/pull/6880

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 `extension`s to work. An example
with the old syntax vs the new syntax:

```cs
// 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.

#### Conclusion

Syntax are changes, the working group will turn its attention to conversion questions.
