[API Proposal]: Implement IEnumerable<int> for Range

[CREAsTIVE]

Background and motivation

I would like to implement a more convenient and readable way to pass through all the elements of the range than

foreach (int i in Enumerable.Range(1, 5))
    Console.WriteLine(i);

and

for (var i = 1; i < 5; i++)
    Console.WriteLine(i);

I immediately remembered the Range type (which can be defined using a..b), and tried to use it inside foreach loop, but as it turned out, it does not contain an implementation of IEnumerable

API Proposal

namespace System.Collections.Generic;

public class Range : IEnumerable<T>
{
    public IEnumerator<int> GetEnumerator()
    {
        // something like
        for (var i = range.Start.Value; i < range.End.Value; i++)
            yield return i;
    }
}

API Usage

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

Risks

You may need to add a check for the not null of Start and End fields (or set their values ​​to default if they null), which can add a couple of extra instructions for each loop that uses Range. However, this can be fixed by checking Start and End fields at compile time and (possibly) adding a new type, which will be a limited range, and which can be implicitly converted to a regular range

[vcsjones]

This has been discussed before and decided against. See #46679 (comment) for background.

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

I would like to implement a more convenient and readable way to pass through all the elements of the range than

foreach (int i in Enumerable.Range(1, 5))
    Console.WriteLine(i);

and

for (var i = 1; i < 5; i++)
    Console.WriteLine(i);

I immediately remembered the Range type (which can be defined using a..b), and tried to use it inside foreach loop, but as it turned out, it does not contain an implementation of IEnumerable

API Proposal

namespace System.Collections.Generic;

public class Range : IEnumerable<T>
{
    public IEnumerator<int> GetEnumerator()
    {
        // something like
        for (var i = range.Start.Value; i < range.End.Value; i++)
            yield return i;
    }
}

API Usage

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

Risks

You may need to add a check for the not null of Start and End fields (or set their values ​​to default if they null), which can add a couple of extra instructions for each loop that uses Range. However, this can be fixed by checking Start and End fields at compile time and (possibly) adding a new type, which will be a limited range, and which can be implicitly converted to a regular range

Author:	CREAsTIVE
Assignees:	-
Labels:	api-suggestion, area-System.Runtime, untriaged
Milestone:	-

[CREAsTIVE]

This has been discussed before and decided against. See #46679 (comment) for background.

It was because of this that I clarified about the possible addition of a new type "limited range"

[CREAsTIVE]

And perhaps it is worth adding serious restrictions, it is even possible that it would be only at compile time (for example, remove the ability to set range from a variable, and make such a foreach a separate syntactic construct)

foreach (var i in <INT_TYPE (like variable or value)>..<INT_TYPE>){}

[neon-sunset]

Limited range

This is exactly how it is expressed in Rust. The main issue here it would effectively be another place constrained to int-based indexing/iteration, which is already becoming a problem sometimes.

If I understand the linked discussion correctly, the decision for the time being is that the intention for Range is to always be a slice-like projection of offsets that can be applied to some sequence of elements, therefore having nothing to be applied to, that would make the foreach (var i in 0..num) expression to be conceptually not valid.

With that said, you can implement your own extension method .GetEnumerator() that takes this Range and returns some enumerator implementation, which has been done numerous times and is actively being suggested in replies on StackOverflow and the like, you can even somewhat come close to the codegen emitted for regular for loops (check a library in my profile, but keep in mind it might have unsound behavior if you misuse it (if you call movenext one more time after it returned false, but codegen in .NET 8 perhaps might allow a larger struct without regressing now to handle that)).

Maybe in the future the type system will be more flexible to allow multiple range implementations to be selected addressing some of the concerns stated in the discussions (like not being tied to int-based Ranges) or, which is more likely, for Enumerable.Range(0, n) to get optimized to a point where it would not add significant overhead.

[colejohnson66]

This has been discussed before and decided against. See #46679 (comment) for background.

It was because of this that I clarified about the possible addition of a new type "limited range"

Just have GetEnumerator throw if the range isn’t iteratable.