# C# Language Design Meeting for January 21st, 2026

## Agenda

- [Unsafe evolution](#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.
