.Net Standard 2.1?

[RussKeldorph]

From @jherby2k on March 7, 2018 19:35

I can't find any information about a .net standard 2.1.

I really want to use the new Span-ified methods like Stream.Read in my class libraries, but it looks like that stuff isn't in System.Memory but rather the .net core 2.1 SDK. Any other way to get these APIs, or do I have to wait for .net standard 2.1. And is there any ETA on that?

Copied from original issue: dotnet/coreclr#16806

[RussKeldorph]

From @danmosemsft on March 8, 2018 0:0

@ahsonkhan are these in OOB packages?

[RussKeldorph]

From @ahsonkhan on March 8, 2018 0:15

I really want to use the new Span-ified methods like Stream.Read in my class libraries, but it looks like that stuff isn't in System.Memory but rather the .net core 2.1 SDK. Any other way to get these APIs, or do I have to wait for .net standard 2.1. And is there any ETA on that?

You do not have to wait for them to be added to .net standard 2.1 if your applications can target .NET Core 2.1.

are these in OOB packages?

The System.Memory package (which contains Span/Memory/etc) is available OOB (for full framework and older version of .net core (like 2.0), and it complies with netstandard1.1 so can be used on any of the platforms that meet netstandard1.1+ spec.

The new overloads being added throughout the BCL, like the Stream methods, as part of the "Spanification," are only available starting on .NET Core 2.1, as far as I know. So those ones are not in OOB packages.

I can't find any information about a .net standard 2.1.

Can you help address this, especially if I missed something?
cc @terrajobst, @KrzysztofCwalina, @stephentoub

[RussKeldorph]

From @jherby2k on March 8, 2018 3:39

But i'm writing a class library, not an application, and targeting .net standard as per Microsoft's recommendation. So if i want access to these Stream APIs (my library does a ton of file IO and parsing) i'm pretty much going to have to wait indefinitely, or target .net core 2.1 and forgo netfx support? Disappointing.

[RussKeldorph]

From @Joe4evr on March 8, 2018 7:3

But i'm writing a class library, not an application, and targeting .net standard as per Microsoft's recommendation.

Yes, I've been wondering myself why there are methods in netcoreapp that aren't available in the equivalent netstandard TFM. Basic things like ConcurrentQueue<T>.Clear() not being available in any .NET Standard (while ConcurrentStack<T>.Clear() is available everywhere) is what boggles my mind the most.

[davidfowl]

Even if there was a netstandard 2.1 the only thing that would implement it on day one would be .NET Core. It takes time for new standards to be implemented so regardless so I’m not 100% sure what your nuget package was going to run on in the short term anyways.

[jherby2k]

Well, yes. Another way of phrasing my question would be “when will spanified APIs make their way to full framework?” It sounds like there is no plan to do so, which is very disappointing given the enthusiasm Microsoft displayed when announcing this stuff.

[bartonjs]

@jherby2k Right now we're focused on successfully delivering .NET Core 2.1 (including the Span work). So while it may be fair to say that "there is no plan" it's more that "no plan has been made" (as opposed to "we plan to not do it"). So I'd amend the statement to be "there is no plan yet".

[arkadiuszwojcik]

Link to related mono project issue mono/mono#6845

[charlesroddie]

Most people would assume that new stuff that goes in .Net Core will also get put in .Net Standard and that the version numbers are in sync, so that new stuff in .Net Core 2.1 will go in .Net Standard 2.1. This is just so natural that it would be a working assumption of .Net users, and presumably also of people working on other .Net platforms and on .Net Core itself. Please tell us if that's not the case. If it is the case then it's a de facto plan already, just awaiting official confirmation and scheduling.

[ThatRendle]

While the only implementation that supports the Span APIs is .NET Core, it doesn't make sense to have them as part of any standard. As soon as another implementation adds support, whether that be .NET, Mono, Xamarin or whatever, then there is a need for a Standard profile to cover it.

The counter to that, I suppose, is that since other implementations adding Span support is pretty much a given, it's annoying that we're currently publishing NuGet packages tied to netcoreapp2.1 and will have to republish when netstandard2.1 becomes available.

Having watched a couple of API reviews over streams, though, I do understand why the work needed to add them to a Standard is being deferred until Core 2.1 is released

[devsko]

Are the new APIs available on UWP (6.1 or whatever version)? If they are, it is a good reason for a .net standard 2.1. If not, its very disappointing.

[jherby2k]

I know that .NET standard was kind of retrofitted over the current frameworks, but going forward, shouldn't the standard be established first? I mean, if its truly a specification, shouldn't the specification be agreed upon prior to implementation? It would also give non-MS implementations (i.e. mono) something concrete to target for their future releases.

[fredericDelaporte]

Same issue for me, but looking for System.Runtime.Caching (ported to core2.1, dotnet/corefx#14529) for extending tagets supported by a library (nhibernate/NHibernate-Caches#38). I would rather add a netstandard2.1 target than a netcoreapp2.1 target, even if at first only .Net Core will implement it.

[stakx]

This issue makes for a very sobering read.

I dare say that the new Span<T> and Memory<T> APIs are going to be deal breakers for many people in many circumstances.

If they are only available in .NET Core for any extended period, then quite frankly what's the point in using .NET Standard, or the .NET Framework for that matter, any longer? These types are fast becoming a cornerstone for high-performance code, and I for one want to use them in my libraries. Hence I'm forced to target just netcore2.x in order to do so.

Alternatively, I won't use these new types in my code at all (just by themselves, without supporting APIs, they are about as useless as ArraySegment<T> was) and continue to use .NET Standard to automatically multi-target my libraries to several platforms. (That for me is the more preferable goal, over putting performance first.)

But there's no viable third way in my opinion. What I expressly don't want to do is to go back to manually multi-targeting different platforms, sprinkling #if FEATURE_SPAN_APIs across my whole code bases (libraries), and writing alternate code in the #else using traditional APIs in order to support Span-less platforms. .NET Standard (esp. version 2) was supposed to rescue us from having to maintain this kind of mess.

The new types, along with the C# 7.2 language enhancements, the JIT improvements, and the new APIs are hugely promising for performance and have been clearly advertised as such. Also, the barrier to entry was made to appear appealingly low by having the System.Memory package target .NET Standard 1.1. This alone suggested that JIT improvements and APIs would soon be added to the .NET Framework, too.

And now all of a sudden the word is that these new APIs are .NET Core 2.1 only for the foreseeable future?

That strikes me as either bad communication, or a very dissapointing decision.