C# Language Design Meeting for September 17th, 2025

Agenda

• Unsafe evolution

Quote of the Day

• "I looked at the MITRE CVEs, and this is the bad stuff they classify as memory safety. Let's have none of that."

Discussion

Unsafe evolution

Champion issue: https://github.com/dotnet/csharplang/issues/9704
Proposal: https://github.com/dotnet/designs/blob/656ade997fceb32d6ff1c3ebd5a8ef10e798361e/proposed/caller-unsafe.md

Today, we took a look at a proposal on expanding the definition of unsafety in C#. This was a very broad overview session; we did not dig heavily into specifics of how it would actually work, other than a bit of digression around inheritance. The proposal is far more complex than we have gone over today and will need much more detail to be formalized before LDM can truly sign off on the specifics. On inheritance, we had some discussion around what unsafe means on a type in this new world, and whether overrides can add unsafe where the overridden method is not marked unsafe. Initial reactions here suggest that we may block both of these things; in this new proposal on unsafety, types are not inherently unsafe in and of themselves. Just having a pointer field is not unsafe by itself; the unsafety occurs when that pointer is dereferenced, or passed to a location that the compiler cannot verify for safety (such as interop).

Overall, we are positive on the direction of this feature, but we'll definitely need to dig into specifics of the language proposal as it becomes clearer and more filled out.