News

Microsoft Extends Rust-Influenced Memory-Safety Push to C#

• By David Ramel
• 05/27/2026

Microsoft's multi-year campaign around memory-safe programming, long associated with Rust as an alternative to C and C++ for some systems-level work, has now reached C# language design.

In a big May 21 post titled "Improving C# Memory Safety", Richard Lander, product manager for .NET at Microsoft, said the company is "significantly improving memory safety in C#" by redesigning the language's unsafe keyword. The planned change seeks to make C#'s unsafe boundary work more like Rust's model, where unsafe operations are explicitly marked, scoped and tied to caller obligations.

"The result is that safety contracts and assumptions become visible and reviewable instead of implied by convention," Lander said in his ~7,400-word treatise on the subject.

He frames the new model as a C# 16 feature, planned for preview in .NET 11 and production release in .NET 12. Microsoft said it will be opt-in at first and may become the default later, with project templates updated to enable the model as the company previously did with nullable reference types.

A related GitHub issue updated four days ago frames the initiative, wherein Lander refers to his post and says: "Memory safety is a critical characteristic for Cloud and AI scenaros. We are making the definition of unsafe code more strict (more patterns are unsafe), making the use of unsafe code more viral (propogation), and making it easier to audit dependencies."

From C++ Memory Bugs to Rust
The new C# work lands in a context Microsoft has been building for years. In 2019, the Microsoft Security Response Center (MSRC) said about 70 percent of Microsoft security vulnerabilities assigned Common Vulnerabilities and Exposures IDs were caused by memory-safety issues, despite code review, training, static analysis and other mitigations.

That research was covered in the Visual Studio Magazine article "C++ Memory Bugs Prompt Microsoft to Eye Rust Instead", which noted Microsoft's exploration of Rust as a safer replacement for some C/C++ code. In the underlying MSRC post, Microsoft said it was "near impossible to write memory-safe code using traditional systems-level programming languages at scale."

A follow-up MSRC post, "Why Rust for safe systems programming", argued that Rust represented the best available alternative to C and C++ for some systems programming scenarios because it offered memory safety while preserving performance, control and predictable execution. VSM later revisited that theme in "So What's Up with Microsoft's (and Everyone Else's) Love of Rust?"

Since then, Microsoft's Rust story has moved from research and security argument to product work. Windows 11 version 24H2 documentation notes a Rust implementation of GDI region in win32kbase_rs.sys, saying users will see "more use of it in the kernel." Microsoft Research also announced in 2025 that it is rewriting SymCrypt in Rust, describing SymCrypt as Microsoft's open source cryptographic library used in Windows, Azure Linux, Xbox and other platforms.

For developers, the Rust thread has also shown up in Microsoft tooling and platform work, including Rust for Windows, developer requests for native Rust support in Visual Studio, and Microsoft's Azure SDK for Rust beta, which VSM covered in "Microsoft's Rust Embrace Continues with Azure SDK Beta".

What Is New for C#
Lander now shifts the focus from replacing memory-unsafe systems code to tightening the unsafe edges of a language Microsoft already describes as memory-safe by default. A separate .NET overview says C# provides "type- and memory-safety as baseline capabilities", but C# also includes unsafe features for native interop, manual memory access and performance-sensitive code.

That is where the new proposal applies. Today, C#'s unsafe keyword primarily enables pointer-related syntax. Under the planned model, Microsoft says unsafe becomes a caller-facing contract. Unsafe operations must appear inside inner unsafe { } blocks, while unsafe method signatures propagate obligations to callers unless those obligations are discharged inside a safe boundary.

Lander said the new model "most closely resembles the Rust implementation."

The post lays out four main mechanics: inner unsafe blocks for unsafe operations, propagation of unsafe obligations through method signatures, safety documentation using a /// <safety> block, and suppression at a boundary method that performs checks or otherwise satisfies the unsafe callee's requirements before returning to safe-callable code.

Microsoft also plans to apply the model more uniformly to APIs such as System.Runtime.CompilerServices.Unsafe and System.Runtime.InteropServices.Marshal. Lander uses Marshal.ReadByte as an example of an API that is effectively unsafe by convention today because it can read from caller-supplied unmanaged memory, even though some such APIs have historically been callable from safe code.

Under the new model, violations are compile errors rather than warnings. The point, according to Lander, is not to make unsafe code easier to write, but to make it easier to reason about and review.

Developer Reaction Focuses on Boundaries and Boilerplate
The post drew more than 20 comments as of this writing, with developers raising questions about how far the proposed model goes in practice. Some commenters welcomed the clearer contract model, with one writing, "I like this: unsafe as a contract, not a scope." Another said the approach "does not eliminate the consequences of unsafe code" but narrows the surface area and responsibilities.

Other commenters questioned whether the proposal does enough beyond making unsafe code more visible. Several focused on thread safety and ownership issues in the sample code, arguing that use-after-free and multithreaded access can still create unsafe memory behavior even when unsafe blocks and safety comments are present. Microsoft employees responding in the thread said thread safety is currently outside the feature's scope. Egor Bogatov wrote that "thread safety is out of scope of this feature," while Tanner Gooding said C# is "not inherently thread safe" and that making most framework types unsafe by default would be "a non-starter." The exchange underscores the proposal's narrower aim: improving visibility, contracts and auditability around unsafe operations, rather than making every unsafe interop or ownership scenario automatically safe.

Rust's Influence Without Replacing C#
The post's Rust references are important because they clarify the direction of the change. Microsoft is not saying C# should become Rust, nor that C# has the same memory-safety profile as C++. Instead, the company is importing part of Rust's safety vocabulary into C# for scenarios where C# developers step outside ordinary managed-code guarantees.

That distinction matters. Rust has been Microsoft's answer for some systems-level C/C++ problems, especially where garbage collection is not suitable. C# remains Microsoft's managed-language answer for application and platform code. The new proposal narrows the gap between those strategies by giving C# developers a Rust-like way to mark and audit unsafe boundaries.

The article also connects the work to software supply-chain standards and AI-assisted coding. Microsoft said memory safety has been a rising priority across industry and government, and that AI-assisted code generation adds a new dimension because software production is scaling faster than human review. In that setting, compiler-enforced project settings and explicit unsafe blocks become part of the audit story.

The Larger Microsoft Pattern
Taken with Microsoft's Rust work, the C# proposal suggests a broader pattern: Microsoft is not treating memory safety as a single-language issue. For C and C++ systems code, the company has repeatedly pointed to Rust where performance and low-level control are still required. For .NET, it is strengthening the parts of C# where developers interact with raw memory, native APIs and unsafe runtime helpers.

The new post therefore shifts the Rust story from replacement to influence. Earlier Microsoft discussions focused on whether Rust could reduce reliance on memory-unsafe C/C++ code in some systems-level scenarios. The C# proposal instead brings Rust-style safety contracts into .NET's unsafe boundary, while leaving C#'s safe-by-default model intact.