The foreach<T> generic constraint

[Happypig375]

So, why would we need this?

Suppose a function obtaining an approximate typographic width in a library:

//Definition
public int GetEffectiveLength(IEnumerable<char> enumerable)
{
  int length = 0;
  foreach (var c in enumerable)
    if (c is 'M' || c is 'm') length += 2;
    else length++;
  return length;
}

//Usage
List<char> charList = AccumulateUserInput();
int width = GetEffectiveLength(charList);

Now some of the input sources are of fixed length.

ReadOnlySpan<char> dataField = source.Slice(...);
int width = GetEffectiveLength(dataField.ToArray()); //allocation!

Let's try changing the input type to ReadOnlySpan<char>...

//Definition
public int GetEffectiveLength(ReadOnlySpan<char> enumerable)
{
  int length = 0;
  foreach (var c in enumerable)
    if (c is 'M' || c is 'm') length += 2;
    else length++;
  return length;
}

//Usage
List<char> charList = AccumulateUserInput();
int width = GetEffectiveLength(charList.ToArray()); //allocation!

Seems like either ReadOnlySpan<char> and IEnumerable<char> cannot fit both worlds.
As libraries should accommodate as many use cases as possible, we would result in something like this:

public int GetEffectiveLength(IEnumerable<char> enumerable)
{
  int length = 0;
  foreach (var c in enumerable)
    if (c is 'M' || c is 'm') length += 2;
    else length++;
  return length;
}

public int GetEffectiveLength(ReadOnlySpan<char> enumerable)
{
  int length = 0;
  foreach (var c in enumerable)
    if (c is 'M' || c is 'm') length += 2;
    else length++;
  return length;
}

Now that is duplication of code.

How would foreach<T> look like?

public int GetEffectiveLength<T>(T enumerable) where T : foreach<char>
{
  int length = 0;
  foreach (var c in enumerable)
    if (c is 'M' || c is 'm') length += 2;
    else length++;
  return length;
}

What could be a foreach<T>?

Anything that could be used in a foreach statement, aka anything matching the definition of IEnumerable<T> structurally. For example:

• Span<T>
• ReadOnlySpan<T>
• T[]
• string
• IEnumerable<T>
• ICollection<T>
• IList<T>
• List<T>
• LinkedList<T>
• Stack<T>
• Queue<T>
• Dictionary<TKey, TValue>
• ...

Span safety?

YES. As Spans can be used in such a statement, the same rules for Spans will be enforced for foreach<T>.

public T Ouch<T>(T t) where T : foreach<char>
{
  var list = new T[3]; //ERROR (no span arrays)
  Action<T> action = x => { }; //ERROR (no spans as normal type arguments)
  var o = (object)t; //ERROR (no span boxing)
  return t; //allowed (ref-safe-to-return)
}

The only meaningful operation allowed for foreach<T> is to literally enumerate it in a foreach statement.
To use foreach<T> as a field, put it in a ref struct.

ref struct A<E, I> where E : foreach<I>
{
  public E enumerable;
}

What methods on foreach<T> are available?

ToString() only. As with Spans, GetHashCode() and Equals() make no sense here and should be hidden.
We should also not expose GetEnumerator() here as we cannot determine the type of it statically inside the method (it is inferred at the call site), and writing custom enumerator functions are very rare in practice.

Shapes and extensions? Intersection types?

Reference: TEnumerable : foreach<TItem>
Design 1: TEnumerable : SEnumerable<TItem>, maybe ref struct
Problem 1: You can't tell the SEnumerator<TItem> in the SEnumerable<TItem> to be a ref struct conditionally.
Design 2: TEnumerable : Span<TItem> | ReadOnlySpan<TItem> | IEnumerable<TItem>
Problem 2: This excludes ref structs that match IEnumerable<TItem> structurally.
Design 3: TEnumerable : SRefEnumerable<TItem> | SEnumerable<TItem>
Problem 3: We have to define two new shapes for such a basic use. It's a bit redundant. We could make foreach<TItem> a shorthand for this though.

Type classes?

See the disadvantages in Section 2.3.4 of this document

[yaakov-h]

Shapes (#164) should solve this problem in a much more general manner.

[Happypig375]

@yaakov-h
Shapes would result in longer code for such a basic need.
I tried several shapes that would result in similar code, each with their own disadvantages.
Please read this part specifically:

Shapes and extensions? Intersection types?

Reference: TEnumerable : foreach<TItem>
Design 1: TEnumerable : SEnumerable<TItem>, maybe ref struct
Problem 1: You can't tell the SEnumerator<TItem> in the SEnumerable<TItem> to be a ref struct conditionally.
Design 2: TEnumerable : Span<TItem> | ReadOnlySpan<TItem> | IEnumerable<TItem>
Problem 2: This excludes ref structs that match IEnumerable<TItem> structurally.
Design 3: TEnumerable : SRefEnumerable<TItem> | SEnumerable<TItem>
Problem 3: We have to define two new shapes for such a basic use. It's a bit redundant. We could make foreach<TItem> a shorthand for this though.

[yaakov-h]

Problem 3 could be solved with a simple wrapper type, and would be the most correct definition considering you're trying to unify two similar structured, but go for a lowest common denominator.

If you just try solve it for IEnumerable<T> and [ReadOnly]Span<T> today, you could use a wrapper similar to the following. In theory, this you should be able to replace those two type references with SEnumerable<T> and SRefEnumerable<T> in future.

using System;
using System.Collections.Generic;

public static class Program
{
    public static void Main(string[] args)
    {
        foreach (var arg in args.AsForEach())
        {
            Console.WriteLine(arg);
        }

        Console.WriteLine();

        foreach (var arg in args.AsSpan().AsForEach())
        {
            Console.WriteLine(arg);
        }
    }
}

static class ForEachExtensions
{
    public static ForEach<T> AsForEach<T>(this IEnumerable<T> e)
    {
        return new ForEach<T>(e);
    }

    public static ForEach<T> AsForEach<T>(this Span<T> s)
    {
        return new ForEach<T>(s);
    }
}

ref struct ForEach<T>
{
    public ForEach(IEnumerable<T> e)
    {
        enumerable = e;
        span = default;
    }

    public ForEach(ReadOnlySpan<T> s)
    {
        enumerable = default;
        span = s;
    }

    readonly IEnumerable<T> enumerable;
    readonly ReadOnlySpan<T> span;

    public Enumerator GetEnumerator() => new Enumerator(enumerable, span);

    public ref struct Enumerator
    {
        public Enumerator(IEnumerable<T> enumerable, ReadOnlySpan<T> s)
        {
            enumerator = enumerable?.GetEnumerator();
            span = s;
            spanIndex = -1;
        }

        readonly IEnumerator<T> enumerator;
        readonly ReadOnlySpan<T> span;
        int spanIndex;

        public bool MoveNext()
        {
            if (enumerator != null) return enumerator.MoveNext();
            return ++spanIndex < span.Length;
        }

        public T Current
        {
            get
            {
                if (enumerator != null) return enumerator.Current;
                return span[spanIndex];
            }
        }
    }
}

[lazyloader]

Going off @yaakov-h but making it even shorter (almost half as short) for simplicity:

using System;
using System.Collections.Generic;

public static class Program
{
    public static void Main(string[] args)
    {
        foreach (var arg in args.AsForEach())
            Console.WriteLine(arg);

        Console.WriteLine();
        foreach (var arg in args.AsSpan().AsForEach())
            Console.WriteLine(arg);
    }
}
public static class ForEachExtensions
{
    public static ForEach<T> AsForEach<T>(this IEnumerable<T> e) => new ForEach<T>(e);
    public static ForEach<T> AsForEach<T>(this Span<T> s) => new ForEach<T>(s);
}
public ref struct ForEach<T>
{
    private readonly IEnumerable<T> enumerable;
    private readonly ReadOnlySpan<T> span;
    
    public ForEach(IEnumerable<T> e)  => (enumerable, span) = (e, default);
    public ForEach(ReadOnlySpan<T> s) => (enumerable, span) = (default, s);
    public Enumerator GetEnumerator() => new Enumerator(enumerable, span);

    public ref struct Enumerator
    {    
        private readonly IEnumerator<T> enumerator;
        private readonly ReadOnlySpan<T> span;
        private int spanIndex;
        
        public Enumerator(IEnumerable<T> enumerable, ReadOnlySpan<T> s) => (enumerator, span, spanIndex) = (enumerable?.GetEnumerator(), s, -1);

        public bool MoveNext()
        {
            if (enumerator != null) return enumerator.MoveNext();
            return ++spanIndex < span.Length;
        }
        public T Current { get {
            if (enumerator != null) return enumerator.Current;
            return span[spanIndex];
        }}
    }
}

[CyrusNajmabadi]

Why even have singel wrapper struct for all these cases? Why not just have an SEnumerable and SEnumerator shapes, and then just have hte appropriate witnesses for them perf type being wrapped?

[spixy]

Idea: Your proposal could be generalized to be duck typing-like constraint, e.g. :

int GetEffectiveLength(T enumerable) where T: GetEnumerator()  // IEnumerable, ReadOnlySpan
async T DoSomethingMore(T task) where T: GetAwaiter()          // Task or ValueTask

[Happypig375]

@spixy à la F#
Probably will be an inline syntax for a shape.