Memory Safety v2 Tracking Issue

[richlander]

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.

Current backlog

• C# Unsafe Evolution
  • Initial Implementation
  • Test Plan
  • Follow ups
• Unsafe Evolution Attributes
• Library annotations
  • Annotate libraries with RequiresUnsafe attribute #125145
  • Add analyzer+codefix for applying RequiresUnsafe to pointer methods #125196

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

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.