# C# Language Design Meeting for May 15th, 2023

## Agenda

- [Breaking Change Warnings](#breaking-change-warnings)
- [Primary Constructors](#primary-constructors)

## Quote of the Day

- "The main point of closing the door is so that people who are slightly late feel that bit of embarrassment opening the door"

## Discussion

### Breaking Change Warnings

https://github.com/dotnet/csharplang/discussions/7033  
https://github.com/dotnet/csharplang/blob/ab5afc419eed3d67bf064ec417f69a65aecbef5c/proposals/breaking-change-warnings.md

Our previous issue on this feature had a large number of moving parts and generated a lot of interesting discussion. This discussion was good, but
it left us wondering what a pared back and small-scale version of this proposal would look like: one where we simply did the break and very little
infrastructure around it, to avoid snowballing the proposal and adding many moving parts; in response, a small group sat down and made a minimal
version of this feature to see what that would actually look like. The minimal version of this is very simple; when using a newer .NET SDK with a
newer C# compiler targeting an older version of the language, warnings will be reported for any potential breaks detected. That's it, no flow
around upgrading. LDM members had a few immediate concerns with this:

* Is there any guarantee that users will actually enter this state? Particularly on systems where a new warning would fail the build, as opposed
  to on a machine where a new warning in the list might be missed?
* We have plenty of examples via MSBuild and NuGet where new warnings on toolset upgrade breaks our users. Is that something we're prepared to deal
  with?
    * All our new warnings on existing code (Warning Waves) are activated by an explicit user action; upgrading to a new version of .NET. This
      would be the opposite.
* If warnings are easily missed, should these be errors instead?
    * There's some concern that this is too harsh: is it really necessary to break the build with no recourse other than downgrading the toolset?
      There could be an opportunity to create a level between warning and error; diagnostics that appear as errors but are user-suppressible.
* In general, catching the moment of upgrade in this system is hard.

One additional consideration that was raised is that we might be trying to force this in too quickly, for the purposes of getting `field` out in C#
12 in its idealized form. If we instead made it so that C# 12 reported warnings, and the version after breaking the scenario. Unfortunately, this
has some of the same issues; there's no guarantee that C# 12 will actually be the migration target. It could be that user goes straight from 11, or
from .NET Framework, or any other non-12 version. Even if we do LTS->LTS, there could still be missed warnings, and we'd also significantly delay
new features.

#### Conclusions

No conclusions today. We've identified some significant problems with the minimal approach and need to keep thinking. We'll revisit again soon.

### Primary Constructors

https://github.com/dotnet/csharplang/issues/2691  
https://github.com/dotnet/csharplang/blob/7bd6a9ff7f19df1e5fdbe18f593e5b18264b50da/proposals/primary-constructors.md#double-storage-warning-for-initialization-plus-capture

Finally today, we looked at a small proposed potential double storage warning for primary constructors. We think this is completely inline with
our previous decisions and approved it unanimously. Several members were surprised we hadn't already made this a warning.

#### Conclusion

Approved as proposed.
