ContextQMD
Back to Csharplang

C# Language Design Meeting for May 15th, 2023

meetings/2023/LDM-2023-05-15.md

latest3.5 KB
Original Source

C# Language Design Meeting for May 15th, 2023

Agenda

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.