make Range in C# 8.0 Enumerable

[dylech30th]

I do not understand why Range didn't inherit from IEnumerable, I think one of the biggest usage of range is iterate it like

    foreach (var i in 1..3) {
        Console.WriteLine(i);
    }

and there's no way to do it in C# 8.0

[yaakov-h]

How would you enumerate ranges with open or from-end indices, such as “1..^3” or “..”?

[dylech30th]

How would you enumerate ranges with open or from-end indices, such as “1..^3” or “..”?

I think it is easy to avoid this by check the range is valid at compile time

[dylech30th]

How would you enumerate ranges with open or from-end indices, such as “1..^3” or “..”?

or just throw exception when the range is invalid, like if you try to iterate 1..^3 then throw an exception to remind you that you cannot iterate a range like this

[HaloFour]

@Rinacm

Because the team decided to concentrate on slicing as the motivation behind the feature first and explore expanding on it in later iterations.

[gfoidl]

See also dotnet/runtime#462

[GrabYourPitchforks]

Per my comment at dotnet/runtime#462 (comment), I don't think it would make sense to have Range implement IEnumerable<int> just to allow the iterator syntax listed in this issue. Developers would almost certainly expect the foreach (int i in 1..3) syntax to yield inclusive values (i.e., [ 1, 2, 3 ]), which we wouldn't be able to do in the Framework from a Range-based enumerator.

If we wanted to allow this syntax I'd recommend making Range not implement IEnumerable<int> and instead having the C# compiler rewrite the syntax foreach (int i in x..y) as for (int i = x; (uint)i <= (uint)y; i++), but where x and y are evaluated only once, are both typed as int32, and fulfill the requirement 0 <= x <= y.

If those checks aren't practical for the compiler to emit then we could introduce a helper API in the CompilerServices namespace. Instead of rewriting the line as a for the compiler could instead turn it into foreach (int i in RuntimeHelpers.MakeIterator(x, y)), and the Framework would implement the 0 <= x <= y checks within that helper method.

namespace System.Runtime.CompilerServices
{
    public static class RuntimeHelpers
    {
        // return type is a struct which implements IEnumerable<int>
        public static SomeCustomEnumerable MakeIterator(int startInclusive, int endInclusive);
    }
}

[quinmars]

Developers would almost certainly expect the foreach (int i in 1..3) syntax to yield inclusive values (i.e., [ 1, 2, 3 ])

I disagree, I would expect the following to work:

foreach (var i in 0 .. a.Length)
    a[i] = 0;

[HaloFour]

@quinmars

I think that there'd be enough of a variance in the opinion of what that does to make it confusing for a substantial percentage of developers. IMO it should be discussed with the conversation about adding clusivity modifiers to the range syntax, and perhaps even require those modifiers in this case for the sake of clarity, e.g.:

// assigns each element of the array
foreach (var i in 0 ..< a.Length)
    a[i] = 0;

// prints 1, 2, 3
foreach (var i in 1 ..= 3)
    Console.WriteLine(i);

[quinmars]

@HaloFour
I think it is very clear that Ranges are end-exclusive. Giving them a new meaning in foreach would indeed cause confusion. I actually hoped that the LDT would consider ranges to be more then index ranges and and add syntax for the limit inclusion/exclusion from the beginning. They decided to focus on index ranges and there those asymetric limits make sense. But extending the syntax now does not make sense. No matter how long you look on 0<..=4, it feels wrong. That ship is sailed.

[ronnygunawan]

I believe the initial confusion will be brief. Developers will get used to it and carve it in their mind that 0..3 is end exclusive.

Also, it's easy to write:

int Inclusive(int index) => index + 1;

foreach (var i in 1..Inclusive(10)) {
}

[Pzixel]

You can take a loot at other languages.

For example, Rust: 1..n - exclusive, 1..=n - inclusive.

---

Also I think they actually should implement IReadOnlyColletion<T> because we always know how much elements will be produced. And it will simplify lots of stuff like IIListProvider checks in LINQ methods.

[pha3z]

Some History on Rust and their design choice...
Rust's motivation for exclusivity was largely influenced by Python -- not necessarily because people actually agreed it was the soundest way to do it. I personally hate the exclusivity default and was against it with Rust. However they went with it and what happened: after release they realized that exclusivity caused a fundamental bug in some of their iterator code, so they added the inclusive operator as a way to fix it.

Despite that, the world seems to have seized on to exclusivity. I'm an example of someone who hates it, but I'm fully aware of it and would rather see exclusivity everywhere than ambiguous variation depending on context. It is a bad idea to use inclusivity in For loops without clear syntax (like Rust chose) to distinguish between inclusive/exclusive.

[YairHalberstadt]

With C# 9.0 you can foreach over a range by defining an extension GetEnumerator or installing the RangeForeach nuget package.

[NetMage]

I actually wrote AsEnumerable that converts to Enumerable.Range (throwing exception if IsFromEnd is true) and then GetEnumerator uses that. Initially I have inclusive which seems natural when dealing with constants for (var i in 1 .. 3) but the inconsistency and inability to use Length or Count as the end made me change. I like the idea of an inclusive method, I think I will make it an extension method on int however: for (var i in 1..3.Inclusive()).

[cheong00]

I thought that's the main usage difference between for loop and foreach loop pattern.

You use for when you're operating on number ranges, and then foreach if you just want to iterate a collection.

How would the optimizer be able to detect and optimize your use case then?

[VBAndCs]

I thought of it as I found myself writing: for (i = 1 to 20 ) after long dealing with vb code, so, I tried to use C# ranges as an alternative bit it doesn't work. for(var i = 1; i <= 20; i++) is too verbose in such direct simple loops. In fact ranges end is confusing, so, I thing an array ring expression can be useful:

foreach (int i in {1..20})
{
}
``

[CyrusNajmabadi]

This is already doable today with System.Range and a simple extension method.

See: #3004 (comment)

[VBAndCs]

Yes, but it cann't accept negative numbers:

foreach (int i in 20..10)
    Console.WriteLine(i);

public static class Extensions {
    public static IEnumerator GetEnumerator(this System.Range range)
    {
        int start = range.Start.Value;
        int end = range.End.Value;
        if (end > start)
            for (int i = start; i <= end; i++)
                yield return i;
        else
            for (int i = start; i >= end; i--)
                yield return i;
    }
}

[CyrusNajmabadi]

Feel free to just use tuples , with an extension on those then.