Microsoft wants safer C# without turning it into Rust

.NET product manager Richard Lander has written a lengthy post describing how the team intends to improve the memory safety of C# by introducing a new model and redefining the existing unsafe keyword, making the language more like Rust, though without giving up automatic memory management. "We envision a future where C# is among a set of languages chosen and noted for the type- and memory-safety enforcement," said Lander. Many C# developers never use unsafe, but it has been part of the language from its first release. "Writing unsafe code is like writing C code within a C# program," said an early book called The C# Programming Language, written by its inventor Anders Hejlsberg and others. Examples of where unsafe code is necessary include interop with the underlying operating system, accessing memory-mapped devices, or implementing time-critical code. Unsafe code allows the use of pointer types, which are not tracked by the .NET garbage collector, and pointer operators. Other than that, the existing unsafe modifier has no effect on a type or member. This will change in C# 16, which is two versions in the future and will be released in late 2027, according to the usual annual .NET cycle, along with .NET 12, which will be a long-term support (LTS) release. Developers can also expect a preview in C# 15 and .NET 11. In the new model, marking a method as unsafe will "also mark it as requires-unsafe, meaning callers must be in an unsafe context and overrides cannot be unsafe if the base members is safe," states the current language proposal. This means that the unsafe designation propagates to callers until it is suppressed by including an unsafe context within a method, but not marking the method as unsafe. Some have questioned why the team will rely on the absence of unsafe to suppress propagation, rather than using the safe modifier. "I've been advocating the design team for just this thing," said Lander. It will no longer be possible to mark a type as unsafe; the unsafe scope moves down to individual methods, properties, and fields. Another change is that the use of pointer types and some pointer expressions will no longer be considered unsafe; it is only dereferencing a pointer and therefore accessing unmanaged memory that will require an unsafe context. The changes will be opt-in for C# 16, meaning that developers can continue with the C# 1.0 model, but the .NET runtime libraries will opt-in, said Lander. In addition, Microsoft is considering adding badges on packages in NuGet, the .NET package repository, to show whether they have opted in and to encourage adoption. A future version of C# may make the model opt out instead. "Our intention is to make the new C# safety model the new normal," said Lander. The idea is not to make unsafe code less dangerous, but rather to make it more visible and easier to review. This extends to safety documentation, via a comment on an unsafe member that defines a contract for its use, which will be encouraged by static code analyzers. Developer reaction so far is largely positive. "I'm both a C# and Rust dev, and I really welcome it ... I wouldn't hate it if C# became closer to a managed Rust," said one. One odd thing about this proposal is that C# developers working on business applications will not notice any change, as they never use unsafe code. Nevertheless, Lander stated that "this feature is among the highest-leverage changes that we can make" to improve confidence in C# code safety. (R)