# C# Language Design Meeting for September 17th, 2025

## Agenda

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