Checklist and open issues for C# range (..) operator

[gafter]

A Range .. operator is proposed for C# 7.3. This tracks compiler work for that feature.

Proposals:

• https://github.com/dotnet/csharplang/blob/master/proposals/csharp-8.0/ranges.cs
• https://github.com/dotnet/csharplang/blob/master/proposals/csharp-8.0/index-range-changes.md

See also some discussion elsewhere

• Champion "slicing" / Range (16.3, Core 3) csharplang#185
• http://khyperia.com/range.html
• [Proposal] Syntactic ranges #7632
• Discussion: Range operator csharplang#198
• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-07-05.md#slicing
• https://github.com/dotnet/csharplang/blob/master/meetings/2016/LDM-2016-11-01.md#slicing
• Proposal: Slicing #120
• Slicing pattern with range corefxlab#1306
• Generic implementation of Range. corefxlab#1859
• dotnet/corefx#25220
• https://github.com/terrajobst/designs/blob/27a6b1c7df08ae42baa2d5f13bcd9d0e259b47e2/accepted/system-range/system-range.md

Compiler

• Start work on a new feature branch
• New token ..
• Fit into operator precedence somewhere
• Parser for range expressions
• Built-in operator overloading
  • Range operator ..(int, int)
  • LongRange operator ..(long, long)
  • Requires some well-known APIs be present
• Permit user-defined operator
  • Accepting and binding the syntax
  • Decide on some underlying special name
• Overload the user-defined ones when applicable

API questions

• What is the name of the thing?
• Closed interval, half-open interval, or start and count?
• step?
• Implements IEnumerable pattern (using value types)?
• Conversions to array, List, IEnumerable, etc?
• Constructor vs static factory methods
• Is there a conversion (built-in or otherwise) from an int range to a long range?
• Were the types ported to mono? Add types supporting C# 8.0 Ranges mono/mono#12020

namespace System
{
    public struct Range
    {
        public Range(int left, int right) ...
    }
    public struct LongRange
    {
        public LongRange(long left, long right) ...
    }
}

• Supported in Span<T> and ReadonlySpan<T>?

Span<T> x = ...;
Span<T> y = x.Slice([1..0]);

IDE

• The ForEachToFor refactoring should recognize range syntax (not applicable to new design)

Open Issues

• Shall we support dropping one or more operands
  • 1..
  • ..10
  • ..
• Should we have two versions for half-open and closed intervals
  • Rust: .. for half-open and and ... for closed
  • Swift: ..< for half-open and ... for closed
• Do we want to do something with arrays for a[1..10]?
• Do we want to do something with pattern-matching?

[HaloFour]

Would a type be able to accept a Range as an indexer argument, e.g. foo[1..10]? Personally, from an API/syntax point of view I think that's what I'd prefer for slicing arrays, strings or spans.

Would also be nice for the compiler to know how to optimize away enumerating over a range, so that:

foreach (var number in 0..<10) { ... }

would be translated to:

for (var number =  0; number < 10; number++) { ... }

[khyperia]

Would a type be able to accept a Range as an indexer argument, e.g. foo[1..10]?

Yes - to me, this is 95% of the purpose of this feature.

We had two options to support slicing:

• Add a new operator type, "slice". This would be entirely distinct from an indexer, and part of the syntax to call this operator is the x..y syntax (.. would sort of become something like the comma in a method call - very built-in to the calling of the operator itself).
• Add a very minor language feature: the expression x..y produces an ordinary struct (perhaps called Range), then perform plain-old API changes to add a Range overload to indexers on relevant types.

The second is what we went with: it's clear to see that the Range type can be used outside of pure slicing scenarios, and it's useful to make it be a distinct type (e.g. supporting more complex slicing scenarios involving manipulation of Range objects - for example, an array of Range, for slicing an n-dimensional array). So, of course it will be supported as an indexer overload - it's the primary use case driving this feature.

Would also be nice for the compiler to know how to optimize

That would indeed be cool! Before looking into doing this, though, I would want to look into how the JIT performs on a plain Range struct (with a pattern-based struct enumerator), and see how much worse it is than a plain for loop. That performance test can actually be done right now, though - it'd be super useful information to have!

[gafter]

@HaloFour

Would also be nice for the compiler to know how to optimize

I would expect Range to both implement IEnumerable<int> and also implement the IEnumerable pattern using a value type. The latter is generally what permits the runtime to optimize it; the C# compiler then doesn't need to do anything.

[portal-chan]

minor nitpick: Rust is changing the syntax for closed intervals from ... to ..=

[HaloFour]

@khyperia @gafter

I whipped up a quick "benchmark" and I'm seeing that a struct enumerator over a range struct being about 4x slower in 64-bit release mode outside of any debuggers. I'm sure that someone could write a better benchmark but I doubt that you could ever actually approach a raw loop short of the JIT completely converting the range enumeration to one.

I look at a Range type as being more to support a language feature of ranges and I'd rather it serve more as a "dumb" container that the language could optimize away where it could. This would be similar to how C# treats tuples.

[HaloFour]

Also, this has come up before in some other proposals but I don't see it mentioned in the ones linked, but it would be nice to support the range syntax as a pattern, too:

int value = GetValue();
if (value is 0..10) { }

var person = GetPerson();
switch (person) {
    case Student { Gpa is 3.0..4.0 }:
        ...
        break;
}

[alrz]

3.0..4.0

I don't know what would it take to support that (in literals). From the links, only int and long are considered.

[HaloFour]

@alrz

I don't know what would it take to support that. From the links, only int and long are considered.

True, and if it's limited to just those types that is fine, but it would be nice if the operator support could be extended to any comparable type. I'm more making the case to allow the range syntax to be used in patterns. The supported types should be a separate conversation altogether.

[alrz]

It's easily practical in patterns -- you won't be able to pass it around so it doesn't need an underlying type. But for range literals there is obviously a need for a data structure.