Microsoft is working on a major change to the way C# handles memory safety. The company wants developers to more explicitly indicate when code performs potentially unsafe memory operations. With this, Microsoft aims to make memory management errors more visible, especially as AI tools increasingly generate code automatically.
In a blog post, Microsoft explains that, in its view, the current use of the unsafe keyword in C# does not sufficiently clarify where risks arise. Currently, a method can be marked as unsafe without all potentially risky operations actually being contained within a delimited block. As a result, it is not always clear to developers and analysis tools where memory-unsafe code begins and ends.
Microsoft wants to change this by treating “unsafe” more as an explicit contract. Specifically, this means that pointer operations and other unsafe actions must take place within a separate “unsafe” block. Methods that pass such risks to other parts of the application must also be explicitly declared as “unsafe.”
Safety label propagates through code
Under the new model, the unsafe label also propagates to code that calls such functions, explains The Register. This makes it easier to see which parts of an application depend on potentially risky memory operations. According to current proposals, for example, overrides will no longer be marked as unsafe if the base method is considered safe.
Microsoft also aims to further refine the use of “unsafe.” It will no longer be possible to mark entire types as “unsafe.” That scope will shift to individual methods, properties, and fields.
Pointer types themselves will also no longer be automatically considered unsafe. An unsafe context will only arise when code actually accesses unmanaged memory via pointer dereferencing. With this, Microsoft is attempting to more precisely distinguish between high- and low-risk operations.
AI code increases the importance of verification
In the explanatory notes, Microsoft explicitly refers to the rise of AI-generated code. According to the company, the volume of automatically generated software is growing faster than human developers can manually review it all. Therefore, it is becoming more important for programming languages to indicate more explicitly where security risks may arise.
The change fits within a broader trend in which programming languages are adopting stricter security models. Although C# retains automatic memory management functions via the .NET runtime and garbage collection, these changes do shift the language somewhat toward languages like Rust.
Microsoft initially plans to make the new security model optional. This means existing applications can continue to operate under the current model for the time being. At the same time, the company has indicated that the .NET runtime libraries themselves will switch to the new model immediately.
In addition, Microsoft is exploring whether NuGet packages can be given a visible label when they support the new security model. This should make it easier to see which libraries explicitly focus on memory safety.
According to Microsoft, the goal is not to make unsafe code less dangerous, but rather to make it more visible and easier to monitor for developers, security tools, and reviewers.
Phased introduction
Microsoft expects to first make the new approach available as a preview feature in C# 15 and .NET 11. The final production version is currently scheduled for C# 16 and .NET 12, which are set to be released in late 2027, per the regular release schedule. .NET 12 will also be an LTS release.