Proposal: Generic ranges or 'any-type' ranges

[antrv]

Generic ranges or any-type ranges

Summary

The currently implemented ranges in C# 8.0 beta is limited to the int type. However it would be nice to extend the usage of a new range syntax and to have a possibility to construct ranges of any type.

Examples:

var intRange = 1..2;
var doubleRange = -5.0..2.5;
var charRange = 'a'..'z';
var stringRange = "Alice".."Bob";

Version v1 = new Version(1, 0, 0);
Version v2 = new Version(2, 2, 0);
var versionRange = v1..v2;

MyType a = ..., b = ...;
var myTypeRange = a..b;

Possible usage cases

Enumeration for integral-type ranges and for custom-type ranges like for int type ranges:

foreach (var c in 'a'..'z')
{
   ...
}

Using as a condition in case of switch:

double d = 5.5;
switch (d)
{
    case 2.0..6.0: // between 2 and 6
         ...
}

Compatibility

The compatibility with the existing implementation in C# 8.0 beta should be kept.

Implementations

Option 1. Generic Index<T> and Range<T> types.

The compiler will use the existing Index and Range types for int ranges, and generic Index<T> and Range<T> types for ranges of another type.

Index and Range will have the implicit conversion operators to and from Index<int> and Range<int> correspondingly.

foreach statement will support the following extension methods to support integral-type range enumeration:

static IEnumerator<TItem> GetEnumerator<T, TItem>(this T obj);

Option 2. Attributes for the compiler to know the Index and Range type for the specific type.

CONS: All predefined types in BCL that have meaning to be used with ranges must have this attribute and defined XxxIndex and XxxRange types.

Option 3. Extension methods to construct indexes and ranges.

The compiler uses the constructors of the Index and Range structs in the current implementation. This behavior remains the same for int ranges.
The compiler will use one of the following extension method to construct indices (more specialized extension method must have higher priority):

static DoubleIndex ToIndex(this double value, bool fromEnd);
static CustomIndex<T> ToIndex(this T value, bool fromEnd);

and the following methods of the specific index types to construct Ranges:

public struct DoubleIndex
{
    public static DoubleRange ToRange(DoubleIndex from, DoubleIndex to);
}

public struct CustomIndex<T>
{
    public static CustomRange<T> ToRange(CustomIndex<T> from, CustomIndex<T> to);
}

[scottdorman]

var stringRange = "Alice".."Bob";

Version v1 = new Version(1, 0, 0);
Version v2 = new Version(2, 2, 0);
var versionRange = v1..v2;

MyType a = ..., b = ...;
var myTypeRange = a..b;

What is the expected set of values for these ranges? It's not clear to me, especially for stringRange and the myTypeRange.

The string range is the least clear to me. How would the compiler ever be able to figure out what the expected set of values are between "Alice" and "Bob"?

The versionRange seems like you're either wanting a range that can go from 1.0.0 through 2.2.0, so

1.0.n (where n goes from 0 to Int32.MaxValue)
1.1.n (where n goes from 0 to Int32.MaxValue)
2.2..n ((where n goes from 0 to Int32.MaxValue)

or a range that has just two Version instances in it (Version(1,0,0) and Version(2,2,0))

Would the type range just return a set of two type instances (a and b)?

[antrv]

The compiler doesn't need to interpret ranges like it doesn't do with int ranges. The compiler responsibility is to construct ranges from values only.

A range is just 2 values: start index and end index and nothing more (and this is true also for the current implementation in C# 8.0 beta). Consuming and interpreting ranges lies entirely on the developers (who write programs in C#).

So actually BCL and .NET standard contributors do the same now: they add methods to the .NET standard which consume int ranges and interpret them.

[yaakov-h]

The compiler doesn't need to interpret ranges like it doesn't do with int ranges.

Actually it does, it uses it for slicing.

[roji]

Partial dup of https://github.com/dotnet/corefx/issues/35420

[antrv]

The compiler doesn't need to interpret ranges like it doesn't do with int ranges.

Actually it does, it uses it for slicing.

No, it doesn't. The compiler translates the expression array[1..2] to the call Array<T>.this[Range range] and it doesn't need to know what this method does with the range argument.

[YairHalberstadt]

Isn't this just a pair of objects of the same type? What makes this worth a language feature over just using a type

public struct Pair<T>
{
    public T First { get; }
    public T Second { get; }
}

[YairHalberstadt]

In other words, what makes these things a range, over a pair of objects, if you can use them with arbitrary types?

[yaakov-h]

@antrv

No, it doesn't. The compiler translates the expression array[1..2] to the call Array<T>.this[Range range] and it doesn't need to know what this method does with the range argument.

Only if that method exists, which it doesn't. Using VS2019 and the latest .NET Core 3.0 SDK preview, this function:

public int[] M(int[] array) => array[1..2];

Gets compiled into the IL equivalent of this:

public int[] M(int[] array)
{
	Range range = new Range(1, 2);
	int num = range.Start.IsFromEnd ? (array.Length - range.Start.Value) : range.Start.Value;
	int num2 = (range.End.IsFromEnd ? (array.Length - range.End.Value) : range.End.Value) - num;
	int[] array2 = new int[num2];
	Array.Copy(array, num, array2, 0, num2);
	return array2;
}

[lostmsu]

@yaakov-h I think it has been made this way mostly for compatibility. Array types are special in many other ways. When you implement range indexing on a custom type (that includes List<T>), compiler does nothing of the sorts for you.

[verelpode]

@antrv
You're using a different definition of the word "range" than the people who proposed System.Range. You're not wrong, rather the problem is that the word "range" is ambiguous. It has multiple different meanings, especially if you include the strange jargon that comes from some mathematicians. This is one of the reasons why I chose a different name in my proposal "Advanced Extents & Segments Proposal re C# 8.0 Ranges" #2510.

You're using the definition of "range" that's like this example:

The tile cutting machine has a speed multiplication factor that can be configured in the range of 1.0 .. 2.5.

Your usage of "range" is totally fine, but System.Range is using a different definition of this word. System.Range is for the purpose of identifying a segment, slice, or substring of an array or other list of elements. For example:

Copy elements/items 5 .. 10 to the destination object.

That's why System.Range uses integers not floating-point -- because item 2.5 doesn't exist. Item numbers are ordinals -- integers not fractional numbers.

In my opinion, System.Range should be renamed and redesigned, and this would also conveniently avoid the problem that you experienced, where you used a valid definition of the word "range" but not the definition that System.Range uses.

[lostmsu]

@verelpode I see no reason to restrict this syntax to integer indexed data structure segments in the way you describe it. I'd be glad to be able to use it like this: var subsetOfIntervals = allIntervals[2.5f .. 3.9f]

[verelpode]

@lostmsu
In that case, I suggest adding a generic constraint that limits T to types that implement IEquatable<T> and IComparable<T>. For example:

public readonly struct InclusiveRange<T> : IEquatable<InclusiveRange<T>>, IComparable<InclusiveRange<T>> 
    where T : IEquatable<T>, IComparable<T>
{
    public readonly T LowerValue;
    public readonly T UpperValue;
    ...
}

That's an inclusive-range example but ofcourse it could also be designed to be exclusive of the second value if desired. There are advantages and disadvantages of both ways.

I like the idea of being able to write Range<double>. In this case, I'd prefer that a different struct be used for array/list slicing operations, such as the non-generic Extent struct in my proposal.

[solvingproblemswithtechnology]

I found this very useful. I use similar aproaches when working with dates and other types of number such double with stepping