.NET 9 Unsafe Study

[AndyAyersMS]

In .NET 9 we plan to study the use of unsafe constructs within the BCL, to better assess the risks they incur and benefits they provide. The aim of this study is to ensure we are making responsible use of unsafe.

The scope and outcome of this study is not yet determined, but may include things like:

• Modernizing the definition of “unsafe” (or unsafe-equivalent) code
• Guidelines for introduction of new unsafe code in the BCL, and possibly guidelines for general .NET development
• Identification of existing unsafe code that can be replaced with safe equivalents
• API changes or additions to avoid the need to rely on unsafe constructs
• Recommendations for new or improved JIT optimizations to widen the set of unsafe code that can be replaced
• Tooling to track the aggregate amount of unsafe code
• The possibility of using source generators to “safely” generate unsafe code

Initially we will be gathering data about overall usage (and how it has changed over time) and doing case studies of code that uses unsafe constructs. As the study progresses, we will update this issue to keep track of interim findings, examples, discussions, proposals, and eventually, plans and work items.

.NET 10 Work

• Remove unsafe code from number parsing #10397
• [Uri] Rewrite UriHelper.UnescapeString to remove unsafe code and improve perf #31173
• Remove a number of calls to Unsafe.AsPointer #99144
• Safe vectorization is a lot slower than unsafe #111309
• Remove the unsafe code from Kestrel aspnetcore#4720
• JIT: Redundant bounds check is not eliminated #109677
  • JIT: (x u>> cns) -> [0..(x's max value >> cns)] #109900
• Remove redundant unsafe contexts (or narrow their scope)
  • Remove redundant 'unsafe' context #110953
• Improve safety around existing stackallocs
  • Safer stackallocs #110864

Misc:

• Remove unsafe code from IPAddress #110824
• Remove unsafe perf quirks from System.Text.Encodings.Web #109896
• Remove unsafe modifier from Memory<T>.Span #106085
• Remove unsafe code from Boolean.TryFormat #108572
• Remove unsafe bool casts #111024
• Simplify AssemblyName.EscapeCodeBase and remove unsafe. #111095
• Avoid Unsafe.As for Memory<T> and ReadOnlyMemory<T> conversion #111023

[ghost]

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

Issue Details

---

In .NET 9 we plan to study the use of unsafe constructs within the BCL, to better assess the risks they incur and benefits they provide. The aim of this study is to ensure we are making responsible use of unsafe.

The scope and outcome of this study is not yet determined, but may include things like:

• Modernizing the definition of “unsafe” (or unsafe-equivalent) code
• Guidelines for introduction of new unsafe code in the BCL, and possibly guidelines for general .NET development
• Identification of existing unsafe code that can be replaced with safe equivalents
• API changes or additions to avoid the need to rely on unsafe constructs
• Recommendations for new or improved JIT optimizations to widen the set of unsafe code that can be replaced
• Tooling to track the aggregate amount of unsafe code
• The possibility of using source generators to “safely” generate unsafe code

Initially we will be gathering data about overall usage (and how it has changed over time) and doing case studies of code that uses unsafe constructs. As the study progresses, we will update this issue to keep track of interim findings, examples, discussions, proposals, and eventually, plans and work items.

Author:	AndyAyersMS
Assignees:	-
Labels:	area-Meta, User Story
Milestone:	9.0.0

[jeffhandley]

@AndyAyersMS I know we made some progress on this in 9.0.0. I'm going to move this to 10.0.0 to keep the effort going.