Memory Safety v2 Tracking Issue #125800

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.

See Improving C# Memory Safety for a higher-level view.

Current backlog

• C# Unsafe Evolution
  • Initial Implementation
  • Test Plan
  • Follow ups
• Unsafe Evolution Attributes
• Library annotations
  • Annotate libraries with caller-unsafe keyword #125145
  • Add analyzer+codefix for applying RequiresUnsafe to pointer methods #125196
• Library source generators/analyzers
  • LibraryImport source generator should generate unsafe code by default

Out of scope

The following components are out of scope for the project.

• Reflection

Context

We expect that user requirements will increasingly favor memory safe languages as Cloud and AI domains evolve. C# is already a memory safe language, however, we can do more to increase user confidence. Our project has significant overlap with Swift 6.2. It also has overlap with Rust behavior.

A related effort is reducing unsafe code in the codebase. This includes: adopting newer safe patterns that deliver acceptable (sometimes better) performance relative to and older unsafe pattern, removing unsafe code where it is needed/warranted, and creating new safe patterns (often in the JIT) to apply.

Learn more:

• Memory Safety in .NET
• Annotating members as unsafe
• SDK Unsafe Adoption
• .NET 9 Unsafe Study
• Enumerating type safety guarantees in MemoryMarshal and friends
• Unsafe code best practices