C# Language Design Meeting for January 21st, 2026

Agenda

• Unsafe evolution

Quote of the Day

• "To be more meaningfully unsafe"

Discussion

Unsafe evolution

Champion issue: https://github.com/dotnet/csharplang/issues/9704
Spec: https://github.com/dotnet/csharplang/blob/37a912407b377f8a3fd5f7396549977e1207e759/proposals/unsafe-evolution.md
Proposal: https://github.com/dotnet/csharplang/blob/37a912407b377f8a3fd5f7396549977e1207e759/meetings/working-groups/unsafe-evolution/unsafe-alternative-syntax.md

Today we took another look at the syntax around the unsafe proposal. So far, our discussions have leaned heavily into the breaking changes aspect, taking a fairly maximally-breaking approach. However, we wanted to fully explore our options for non-breaking versions of the change as well. To help guide discussion, there are two types of break we talk about in this area:

• A syntax breaking change. This is taking existing syntax, and changing the meaning of it. This is the type of change where, given a method definition, a reader cannot know what it means without knowing the flags passed to the compiler. Namely, does public unsafe void M() {} mean that the caller must be in an unsafe context, or not?
• An ecosystem breaking change. This is where, upon upgrading to a new version of .NET and turning on the feature, what is unsafe and what is not changes interpretation, because the user is consuming a BCL and set of dependencies that have added safety information to their APIs. This break is not under debate today; it will happen, but it can happen independently of the syntax break.

There is a tension in our design between wanting a simple set of rules, without needing to know about new attributes or keywords, and ensuring that users can actually adopt the changes and drive a safer .NET ecosystem. We feel that, given a brand new language, we would likely have unsafe on the method body mean the caller must be in an unsafe context, which would then likely drive other decisions such as unsafe on the method signature not automatically marking the body as an unsafe context. However, this is truly the largest syntax breaking change we would have ever done in C#. Even though we hope it will only hit a small segment of our users, it will likely hit those users heavily, and those are the users we want to adopt the change to ensure safety for the rest of the ecosystem. This was a shorter session, so we didn't arrive to any kind of final conclusion today. The LDM is generally leaning in favor of trying to avoid the syntax break, but how exactly (i.e., attribute vs a new keyword) is not something we were able to drill into today. Further, several members of the LDM are still interested in the original proposal, syntax break and all. Therefore, we want to continue exploring this topic, in particular drilling into the attribute vs new keyword discussion, and we'll come back to this next week.