Memory Safety in C# 16 Microsoft Plans New Unsafe Model for C#

Microsoft wants to redefine the unsafe model in C#. Unsafe operations are to become more visible, verifiable, and more strongly controlled by the compiler. Regarding memory safety, Microsoft is guided by a principle of the relatively young programming language Rust.

Microsoft is working on a revision of the unsafe model of C#. The goal is to make memory access outside the normal managed runtime more clearly identifiable and easier to verify. The change is planned for C# 16, which is expected to be released alongside .NET 12.

The current unsafe model originates from C# 1.0. It allows, among other things, pointers, pointer arithmetic, and direct access to unmanaged memory. Such features are typically used for interop scenarios, low-level hardware access, or highly performance-critical code.

Microsoft justifies the planned change with the importance of memory safety for cloud, platform, and AI scenarios. An additional factor is AI-powered code generation: As code is created faster, the need for rules that clearly mark unsafe areas and make them accessible for reviews also increases.

Marked Insecurities Should Propagate Through Signatures

In the future, unsafe will be understood more as a contract. If a method is marked as unsafe, it not only signals internal unsafe operations but also places requirements on its callers. These must also be in an unsafe context or consciously encapsulate the unsafe section in a defined method.

With this, Microsoft adopts a principle reminiscent of Rust: Unsafe operations should not disappear unnoticed within seemingly safe APIs. Instead, assumptions, preconditions, and responsibilities should become visible along the call chain.

An important change concerns the scope of unsafe. Under the planned model, a type can no longer be broadly marked as unsafe. Instead, the designation shifts to the member level, i.e., to methods, properties, or fields where the unsafe access is actually relevant.

Pointer types are also set to be treated more specifically. Simply using a pointer type will no longer automatically be considered an unsafe operation. Only accessing the memory content, such as through dereferencing, will require an unsafe context. This aims to allow the code to more precisely indicate where unmanaged memory is actually being read or written.

Impacts Primarily on Low-Level And Library Code

For many developers of business applications, little is likely to change, as they generally do not use unsafe code directly. The change is more relevant for libraries, runtime-related components, native interop, serialization, performance code, and APIs such as System.Runtime.CompilerServices.Unsafe or parts of System.Runtime.InteropServices.Marshal.

Microsoft also plans to integrate security documentation more closely into the model. For unsafe members, a documented contract should describe under which conditions usage is correct. Static analysis tools could require or verify such information in the future.

The new regulation is initially intended to be introduced as an opt-in. A preview is planned for C# 15 and .NET 11, with the productive implementation scheduled for C# 16 and .NET 12. Microsoft is also considering designations for NuGet packages that activate the new model to make the transition in libraries more visible.

The new model does not automatically make unsafe code safe. However, it aims to reduce instances where unsafe memory access remains implicit. For developers, this means more explicit boundaries, increased compiler support, and likely somewhat more effort for APIs that deliberately operate outside managed safety guarantees.

Procurement

EIC Propel: IoT Platform for Microsoft's Azure Services