LDM Notes for January 21st, 2026

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2026/LDM-2026-01-21.md#unsafe-evolution

Agenda

• Unsafe evolution

[huoyaoyuan]

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 was my original concern. In worst case, a library author will blindly or incorrectly make their method requiring caller unsafe, delivering unintended break to their users. This would have a cascade effect in the whole ecosystem.

[GeeLaw]

The idea of even considering the complete change of unsafe keyword meaning (from introducing unsafe context, which is internal to the implementation, to automatically requiring unsafe callers, which is API surface) is baffling to me, because it's severely breaking and the old model isn't wrong enough to justify it.

Re: new syntax. Aside from attribute and new keyword, one can also consider reusing unsafe with a different placement (cf. readonly ref readonly). Some simple ideas:

// `unsafe` after return type means the caller should be unsafe,
// or read it as Foo is unsafe.

// My best preferred, if `unsafe` were to be reused with a different placement.
public static void unsafe Foo() { }

// This is weird.
public static void Foo unsafe () { }

// This is somewhat C++-ish (cf. final/override in C++).
public static void Foo() unsafe { }

For accessor methods, unsafe get etc. did not have a meaning, now they can mean "caller should be unsafe".

But I feel playing with placement is confusing, and I think using a well-known attribute is the better approach.

[HaloFour]

The idea of even considering the complete change of unsafe keyword meaning (from introducing unsafe context, which is internal to the implementation, to automatically requiring unsafe callers, which is API surface) is baffling to me, because it's severely breaking and the old model isn't wrong enough to justify it.

The old model lacked this concept entirely. The question is if C# 1.0 were being designed today, would we end up with that same model? What would feel intuitive to someone coming to C# today, vs. having to learn more warts about why things are modeled differently in different places? I don't really think so. The unsafe keyword is pretty weird as a method modifier as it is, and no/few other scoped keywords can be treated as such. It's weird to have ergonomics concerns for something that really should be much more niche.

one can also consider reusing unsafe with a different placement

IMO that would make it incredibly confusing. It's already bad enough that some modifier keywords have specific placement and that is something that the team is planning to rectify.

[GeeLaw]

The old model lacked this concept entirely.

Nobody is saying otherwise. The baffling part is the idea of changing the keyword to mean just the new concept, something completely different from the old concept, which still exists and was expressed by the same keyword, hence completely changing the meaning of a piece of code.

The question is if C# 1.0 were being designed today, would we end up with that same model?

This is a good academic question, and the C# 1.0 unsafe is lacking, but it doesn't change what happens going forward. Because

Either way, 25 years in the behavior of the language isn't going to change.

---

IMO that would make it incredibly confusing.

That's already said.

But I feel playing with placement is confusing

[HaloFour]

This is a good academic question, and the C# 1.0 unsafe is lacking, but it doesn't change what happens going forward. Because

It's not just an academic question. While it's worthwhile to avoid breaks, something they're worthwhile for the sake of the health of the ecosystem as a whole. Layering on more separate concepts only increases complexity and cognitive load. This is very much why NRTs ended up designed as they were, and that was an enormous break with the existing mental model. Unsafe code is much more niche and advanced, accepting a source breaking change here should be more palatable.

[sator-imaging]

I expect something like this:

<Project Sdk="...">
  <PropertyGroup>
    <UnsafeMode>strict</UnsafeMode>  // disable, enable and strict
  </ProppertyGroup>

  <ItemGroup>
    <PackageReference Id="..." UnsafeMode="traditional" />  // explicitly relax per dependency
  </ItemGroup>
</Project>

[jnm2]

Nothing like a per-reference mode switch is currently proposed.