Skip to content

Latest commit

 

History

History
116 lines (99 loc) · 5.92 KB

README.md

File metadata and controls

116 lines (99 loc) · 5.92 KB
Raw

.NET Standard vNext

This document describes the plan for .NET Standard 2.1, which includes the definition of its API surface.

Goals

  • Include Span<T>. In .NET Core 2.1 we've added Span<T> which is an array like type that allows representing managed and unmanaged memory in a uniform way and supports cheap slicing. It's at the heart of most performance- related improvements in .NET Core 2.1 as it allows managing buffers in a more efficient way as it helps in reducing allocations and copying. Span<T> is considered a primitive type and requires runtime and compiler support in order to be fully leveraged. Please note that when refer to Span<T> in this document, we really mean the family of span-related features which includes other types such as ReadOnlySpan<T>, Memory<T>, ReadOnlyMemory<T>, and the new System.Buffers namespace.

  • Include core-APIs working with spans. While Span<T> is available as a .NET Standard compatible NuGet package (System.Memory) adding this package cannot extend the members of .NET Standard types that deal with spans. For example, .NET Core 2.1 added many APIs that allow working with spans, such as Stream.Read(Span<Byte>). Part of the value proposition to add span to .NET Standard is to add the companion APIs as those cannot be added using a NuGet package.

  • General Goodness. Since .NET Core was open sourced, the community and us added many small features across the base class libraries such as System.HashCode for combining hash codes or new overloads on System.String. There are about ~800 new members in .NET Core that are on types that are already in .NET Standard 2.0.

Decisions

  • We should include Brotli as HttpClient depends on it
  • We should exclude DataAnnotations (OOB today)
  • We should exclude DiagnosticSource (OOB today)
  • We should exclude System.Reflection.Metadata (OOB today)
  • We should exclude System.Runtime.InteropServices.WindowsRuntime (OOB today)
  • We should exclude System.Runtime.Loader (currently a .NET Core only concept and not ready for standardization)
  • We should exlude RegexCompilationInfo as it throws on .NET Core & Xamarin and we don't plan on implementing the API ever.
  • We should exclude System.Threading.Tasks.Dataflow (OOB today)
  • We should exclude IApplicationResourceStreamResolver (was plumbing for Silverlight convergence. It's obsoleted.)
  • We should exclude System.Xml.Serialization.SchemaImporter (doesn't seem useful)

Open issues

  • Version number. In contrast to .NET Standard 2.0, which was a massive update in terms of APIs and the .NET Framework compatibility mode, this update seems relatively incremental. Also, the payload is comparable to .NET Core 2.1, hence .NET Standard 2.1 seems to make the most sense.
    • .NET Core and .NET Standard aren't the same thing. People will expect that the next version is 3.0 as that's what we called .NET Core. However, the API set is closer to 2.1 and argubly makes more sense within the context of the standard.
    • We could make it date-based
    • Or we could go with levels (10-16, 20, etc.)
  • Some features require runtime work. We need to make sure implementers are aware what adding these means to their runtime:
    • Span<T>
    • Vector<T>
    • DispatchProxy
    • RefEmit
    • For the full list, see issues labelled as runtime-impact.

API suggestions

All API suggestions are labelled as netstandard-api. API suggestions that might require runtime changes are labelled runtime-impact.

Major features

Miscellaneous improvements

The long tail of various small improvements have been broken down into PRs for each of the namespaces: