System.Range package similar to System.ValueTuple

[lostmsu]

My understanding is System.Range and System.Index are going to be .NET Core 3.0 specific features.
That prevents me from creating a library, that targets .NET Standard 2.0 (for I need to support .NET 4.7), and implements range indexers for the types defined in it.

I think it is a huge problem, especially considering the next .NET Standard is not going to be implemented by .NET 4.8.

Are there any plans to deal with it?

Is the problem in the desire to implement range-based indexing for the core types like System.Array? If so, are there ways to work around that? Can .NET Core 3.0 instead define System._Range, and have hypothetical System.Range package implementing an implicit conversion System._Range -> System.Range? Any other alternatives?

[gfoidl]

Any other alternatives?

You can use multi-targeting. So you have a code path for .NET Core 3.0 and one for .NET Standard 2.0.

[lostmsu]

@gfoidl how would that work? I'd still need a System.ValueTuple-like package for .NET Standard 2.0 for System.Range to implement ranges. Otherwise consumers of my library will face name conflicts with other libraries.

If you are proposing to drop range indexing for .NET Standard 2.0, then that's exactly what I want to avoid.

[gfoidl]

I meant the latter, and don't know a better way.

[eerhardt]

/cc @terrajobst

[joshfree]

@tarekgh can you PTAL

[tarekgh]

@lostmsu Index and Range are not in netstandard 2.0. These types will be in netstandard 2.1. You may look at dotnet/standard#1018.

[lostmsu]

@tarekgh , yes, and that is the nature of the problem. The indexing feature of C# 8 will be unusable on .NET Framework.

[eerhardt]

It's not just the indexing feature of C# 8 being available on .NET Framework that I'm concerned about. (There are other C# 8 features that flat out won't ever work on .NET Framework 4.8. See Building C# 8.0 Blog).

But the core issue here is that you can't have a netstandard2.0 or less library that exposes APIs that will allow the indexing feature in C# 8 to work when it IS available (say in a .NET Core 3.0 app).

For example, in the System.Numerics.Tensors library (which targets netstanard1.1 today), we'd like to have a Slice method on a Tensor. Since tensors are multi-dimensional, you need to have a collection of start and stop indices - basically exactly what System.Range is. One for each dimension.

To expose the Slice API, we need some way of specifying the range in each dimension you want to slice off the tensor. Without having System.Range available, Numerics.Tensors will need to come up with their own "Range-like API". Let's say ValueTuple<int, int>. But here's the problem - is the 2nd int a Length or a stopping index? If it is a stopping index, is it inclusive or exclusive? Does it handle negative indices? etc. etc.

All of these problems would be solved if we had a common type that encapsulated these semantics. And we do have the type, we just aren't allowing libraries less than netstandard2.1 use it.

[johnnyasantoss]

Any updates on a package for Range and Index?

[bgrainger]

In lieu of an official solution, I created my own unofficial one last month:

• https://github.com/bgrainger/IndexRange
• https://www.nuget.org/packages/IndexRange/

[tarekgh]

@terrajobst @jaredpar do we have the final call on that?

[RayKoopa]

Also looking forward to a "backport" NuGet package for ranges in .NET Standard 2.0, just like System.Memory or Microsoft.Bcl.HashCode.

And here I wondered why I never get code style hints by VS for starting to use ranges... was because I also target classic .NET Framework... 👀

[joperezr]

ping @terrajobst can you please take a look?

[terrajobst]

I've recently discussed this. The problem is this:

1. ValueTuple was a bit of disaster. That's because we shipped an out of box (OOB) and in-box version on .NET Framework. This has caused significant pain with binding redirectcs and friends.
2. Range itself doesn't suffer from this because there is no version of .NET Framework that included it. We don't have any issues with pure OOBs (span, JSON) However, Range depends on tuples 😞

One could maybe argue that (1) is a thing of the past as .NET Framework 4.7 includes it in-box (and we generally recommend to be on 4.7.2 to consume .NET Standard 2.0 binaries). We should test this, but I think an OOB for range seems doable.

@ericstj any other concerns?

[ericstj]

I think we've created a pattern with the Microsoft.Bcl additions that solves the technical problems. I briefly looked at @bgrainger's solution and it follows this pattern. There is still the annoyance that the entire stack needs to target the framework with the component inbox to eliminate the need for the package, for example #35984.

[DjArt]

That's still actual problem. Any chance to make this happens?

[chucker]

@DjArt I've just backported a library from .NET 6.0 to .NET Standard 2.0, and one of the things I had to re-add was System.Range. Long story short:

	<PackageReference Include="IndexRange" Version="1.0.0" />

This seemed to do the trick for my relatively simple use case (get a string's characters except for the very first and very last, with [1..^1]). Some more complex needs may not work; see the issues at https://github.com/bgrainger/IndexRange

[saucecontrol]

I wouldn't hesitate to use @bgrainger's package in an app, but as a library author, I'm more concerned about the likelihood of downstream conflicts if I were to take a dependency on it. Not being an 'official' package, it doesn't show up in places like https://apisof.net/, making it more likely a similar third-party shim or a copy/paste of the BCL source might end up in a consuming project alongside my transitive dependency.

It would be really nice to see an 'official' package for this, if only to avoid such conflicts.

[IanKemp]

@terrajobst @ericstj bump.

[Crono1981]

This would be a huge help. I have legacy apps I still need to patch from time to time, and the ability to use one code base for both legacy and modern .NET apps is a lifesaver.

I want to adapt to the newer syntax elements but them not being supported in older SDKs makes adoption very complicated.

[gregsdennis]

So I'm guessing this probably isn't coming? It's been a year since any activity here.

[lostmsu]

@gregsdennis the abovementioned package IndexRange does the job.

[gregsdennis]

@lostmsu I'm in the same boat as @saucecontrol. I'm building a library, and I have to consider downstream impacts.

[chucker]

@gregsdennis @saucecontrol can’t you use PrivateAssets="All" to avoid downstream impact?

[saucecontrol]

You can't if you expose public APIs with Index or Range arguments, which I do, but FWIW I have been using the IndexRange package for over a year with no reported issues.

[saucecontrol]

Since it's not yet mentioned here, if you need Index/Range only for internal use (not exposing in public API surface), PolySharp includes those types, along with polyfills for the attribute types required to support modern C# features downlevel.

PolySharp can also make its generated Index/Range public, but then each project's definition of them is distinct. For public APIs, I'd still recommend the IndexRange package, as those types can be shared between projects.

[ericstj]

As of .NET 9.0 release last month this package is now available publicly as Microsoft.BCL.Memory for those who were previously waiting on this please give it a try.