Microsoft’s Push for Safer C# Raises Questions About the Future of Unsafe Code

A new safety model on the horizon

In a detailed blog post, .NET product manager Richard Lander outlined a roadmap that would reshape how C# handles low‑level operations. Starting with C# 16 (targeted for late 2027) and previewed in C# 15, the language will treat the unsafe modifier as a requires‑unsafe flag. When a method is marked unsafe, every caller must also be in an unsafe context, and overrides cannot downgrade the safety level.

The proposal goes further:

• The unsafe keyword will no longer be applicable to whole types; it will be scoped to individual members.
• Pointer dereferencing will be the only operation that demands an unsafe context; merely declaring a pointer type will be allowed in safe code.
• Adoption will be opt‑in for the first release, with Microsoft planning to badge NuGet packages that have embraced the new model.

Lander frames the change as a way to make unsafe code more visible and easier to audit, not to eliminate it. The goal is to position C# alongside languages praised for strong type‑ and memory‑safety guarantees, while preserving the automatic memory management that has long been a hallmark of the .NET ecosystem.

Why the shift matters now

1. Security pressure – Recent supply‑chain attacks and memory‑corruption exploits have pushed platform vendors to surface safety concerns earlier in the development cycle. By surfacing unsafe usage at the call‑site level, static analysis tools can flag risky paths that were previously hidden behind a single unsafe annotation.
2. Interop demands – Interfacing with native APIs, device drivers, or high‑performance kernels still requires pointer manipulation. Making those hotspots explicit could reduce accidental misuse in large codebases.
3. Competitive signaling – Rust’s rise has highlighted the market appetite for memory‑safe languages. Microsoft’s move can be read as a response to developers who otherwise might consider Rust for low‑level components while keeping business logic in C#.

Community reaction: optimism tempered by caution

The initial response on GitHub, Reddit’s r/dotnet, and the .NET Discord server leans positive. A user who writes both C# and Rust said:

“I’m excited to see C# adopt a more Rust‑like safety posture. It could make mixed‑language projects feel more coherent.”

However, several concerns have emerged:

1. Added cognitive load for typical developers

Most business‑application developers never touch unsafe. Requiring them to understand propagation rules could feel like an unnecessary burden, especially when the change is opt‑in but the runtime libraries will adopt it by default.

2. Potential for breaking existing code

Even though the proposal is opt‑in, the shift in semantics for pointer declarations may cause subtle compilation differences. Libraries that expose pointer‑typed structs (e.g., Span<T>‑based interop layers) will need to be audited and possibly re‑published with the new safety badge.

3. Tooling readiness

Static analysis tools such as Roslyn analyzers, ReSharper, and SonarQube will need updates to understand the new requires‑unsafe flow. Until those tools catch up, developers might receive false positives or miss real issues.

4. Is “managed Rust” a realistic target?

Some argue that C#’s managed heap and garbage collector fundamentally differ from Rust’s ownership model. Adding safety checks around pointer dereferencing may improve visibility but will not provide the same compile‑time guarantees that Rust offers.

Counter‑perspectives: why the change could be a net win

• Gradual adoption – By making the new model opt‑in, Microsoft allows large enterprises to pilot the feature on non‑critical services before a full rollout. Early adopters can provide real‑world feedback without disrupting legacy systems.
• Better documentation and contracts – The proposal encourages developers to attach safety contracts to unsafe members, which static analyzers can surface in code reviews. This could lead to a cultural shift where unsafe code is treated as a first‑class citizen, documented like any public API.
• NuGet badge ecosystem – Visible safety badges could become a market signal, similar to security certifications. Packages that adopt the model may be preferred in high‑assurance environments, nudging the ecosystem toward safer defaults.

What to watch in the coming months

Milestone	Expected date	Impact
Preview of C# 15 with requires‑unsafe	Q4 2025	Early feedback from IDE extensions and CI pipelines
.NET 11 LTS preview with optional safety model	Early 2026	First production‑grade libraries can experiment
Full opt‑in release in C# 16 / .NET 12 LTS	Late 2027	Runtime libraries adopt the model; NuGet badges appear
Potential opt‑out transition	TBD (post‑2028)	Could make the safety model the default for new projects

Developers should start by reviewing any existing unsafe blocks, documenting the intent of each, and monitoring the upcoming preview releases. Keeping an eye on the evolving Roslyn analyzer updates will also help teams stay ahead of any breaking changes.

---

The shift toward a more explicit unsafe model reflects a broader industry trend: safety features are becoming a selling point, even for languages that already manage memory. Whether Microsoft’s approach will strike the right balance between safety and developer ergonomics remains to be seen, but the conversation it has sparked is already reshaping how the .NET community thinks about low‑level code.