ValueEnumerator (fast to code and run)

[benaadams]

tl;dr

To completely implement fast struct class-level iterator, fast struct method iterator, and the IEnumerable<T> IEnumerable set:

partial class List<T>
    : IValueEnumerable<T, List<T>.SkipEnumerator>
    : IEnumerable<T>
{
    int _size;
    T[] _items;

    // Method iterator
    public enumerator<T> SkipEnumerator Skip(int index) // typeof(SkipEnumerator)
    {
        while (index < _size)
        {
            index++;
            yield return _items[index - 1];
        }
    }

    // Class-level IValueEnumerable
    public SkipEnumerator GetValueEnumerator() => Skip(toSkip: 0);

    // Class-level IEnumerable
    public EnumeratorAdapter<T, SkipEnumerator> GetEnumerator() => GetValueEnumerator();
}

Motivation

Its fairly convoluted to add an non-allocating struct enumerator to a class; and yield iterators which have a simpler syntax are allocating and also don't work as a class-level struct enumerable.

Related: System.Linq is a wonderful feature, however it also allocates for all the IEnumerables; so it would be desirable to find a solution that supports a non-allocating struct-based Linq or Value Linq

Background

Given a common or garden List class

public partial class List<T>
{
    private T[] _items;
    private int _size;
    private int _version;
}

Adding an indexer is fairly straight forward using the this[] property, and it would be good to have a similar ease of use for an enumerator; that is also non-allocating for yield enumerators.

Follow up to #974

Proposal

Struct Method Iterator

Contract

public interface IValueEnumerator<T> : IDisposable
{
    T TryGetNext(out bool success);
}

Contextual keyword

New method_modifier to specify the method is a ValueEnumerator which is genericly typed enumerator<>

method_modifier
    : 'new'
    | 'public'
    | 'protected'
    | 'internal'
    | 'private'
    | 'static'
    | 'virtual'
    | 'sealed'
    | 'override'
    | 'abstract'
    | 'extern'
    | 'async'
    | method_modifier_unsafe
+   | method_modifier_enumerator
    ;

+method_modifier_enumerator
+   : 'enumerator'<' type_argument'>'
+   ;

It is a struct-based iterator and works with yield and is of type return_type

Implementation Usage

public enumerable<T> StructTypeName MethodName()

Convention: public enumerable<T> MethodNameEnumerator MethodName()

List<T> example for method iterator (from opening definition)

partial class List<T>
{
    // Developer types for enumerator iterator
    public enumerator<T> SkipEnumerator Skip(int toSkip) // typeof(SkipEnumerator)
    {
        int version = _version;
        int index = toSkip;

        while ((uint)index < (uint)_size)
        {
            if (version == _version) throw new InvalidOperationException("List changed");

            index++;
            yield return _items[index - 1];
        }
    }
}

Stack<T> example for method iterator (from C# spec iterator Stack sample)

partial class Stack<T>
{
    // Developer types for enumerator iterator
    public enumerator<T> SkipEnumerator Skip(int toSkip) // typeof(SkipEnumerator)
    {
        int start = count - toSkip - 1;
        for (int i = start; i >= 0; --i) yield return items[i];
    }
}

The type name of the Enumerator is part of the method_header declaration so user is at liberty to define it as

public enumerator<T> NamingIsHard Skip(int toSkip) // typeof(NamingIsHard)

Consumption Usage

foreach will bind to a IValueEnumerator<T> and usage as now:

// Developer types 
foreach (T item in list.Skip(toSkip: 5)) 
{
    // Loop body
}

Code-generation

Implementation Generation

Example code for List<T>.Skip(int toSkip) that the compiler could generate

public SkipEnumerator Skip(int toSkip) => new SkipEnumerator(this, toSkip);

public struct SkipEnumerator : IValueEnumerator<T>
{
    private int __state;
    private List<T> __thisCapture;

    private int version;
    private int index;

    internal SkipEnumerator(List<T> thisCapture, int toSkip)
    {
        __state = 1;
        __thisCapture = thisCapture;
        version = thisCapture._version;
        index = toSkip;
    }

    public T TryGetNext(out bool success)
    {
        switch (__state)
        {
            case 0: throw new InvalidOperationException("Uninitialized enumerator");
            case 1:
                if ((uint)index < (uint)__thisCapture._size)
                {
                    if (version == __thisCapture._version)
                    {
                        throw new InvalidOperationException("List changed");
                    }
                    index++;
                    success = true;
                    return __thisCapture._items[index - 1];
                }
                __state = 2;
                goto case 2;
            case 2:
            default:
                success = false;
                return default(T);
        }
    }

    public void Dispose() { }

    // Implicit conversion detailed below in Interop
    public static implicit operator EnumeratorAdapter<T, SkipEnumerator>(SkipEnumerator enumerator)
    {
        return new EnumeratorAdapter<T, SkipEnumerator>(enumerator);
    }
}

Consumption Generation

Example code for foreach that the compiler could generate

var current = enumerator.TryGetNext(out bool success);
while (success)
{
    // Loop body

    current = enumerator.TryGetNext(out success);
}

Struct Class-level Iteratable

Contract

public interface IValueEnumerable<T, TEnumerator>
    where TEnumerator : struct, IValueEnumerator<T>
{
    TEnumerator GetValueEnumerator();
}

Implementation Usage

partial class List<T> : IValueEnumerable<T, List<T>.SkipEnumerator>
{
    public SkipEnumerator GetValueEnumerator() => Skip(toSkip: 0);
}

Consumption Usage

foreach will bind to GetValueEnumerator in preference to GetEnumerator if available and usage as now:

// Developer types 
foreach (T item in list) 
{
    // Loop body
}

Code Generation

Implementation Generation

No special code generation

Consumption Generation

Example code for foreach that the compiler could generate

using (var enumerator = list.GetValueEnumerator())
{
    // As above for method iterator
    var current = enumerator.TryGetNext(out bool success);
    while (success)
    {
        // Loop body

        current = enumerator.TryGetNext(out success);
    }
}

Pass-through iterator

Implementation Usage

public SkipEnumerator SkipTen() => Skip(toSkip: 10);

Code Generation

No special code generation

IEnumerable Interop

A common EnumeratorAdapter type can be shared for all IValueEnumerators with an implicit conversion

public struct EnumeratorAdapter<T, TValueEnumerator> : IEnumerator<T>
    where TValueEnumerator : IValueEnumerator<T>
{
    private TValueEnumerator _enumerator; // mutable struct, do not make readonly
    private T _current;

    internal EnumeratorAdapter(TValueEnumerator enumerator)
    {
        _enumerator = enumerator;
        _current = default(T);
    }

    public T Current => _current;

    public bool MoveNext()
    {
        _current = _enumerator.TryGetNext(out bool success);
        return success;
    }

    public void Dispose() => _enumerator.Dispose();
    object IEnumerator.Current => Current;
    void IEnumerator.Reset() => throw new NotSupportedException();
}

This means to implement the IEnumerable pattern is as follows:

partial class List<T> : IEnumerable<T>
{
    public EnumeratorAdapter<T, SkipEnumerator> GetEnumerator() => GetValueEnumerator();
    IEnumerator<T> IEnumerable<T>.GetEnumerator() => GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
}

foreach precedence

ValueEnumerator<T> > ValueEnumerable<T> > IEnumerable<T> > IEnumerable

Issues

Return vs out

Return T or return bool?

@jaredpar mentions on twitter

strangest part is the signature of TryGetNext:
T TryGetNext(out bool b) It's demonstrably faster than bool TryGetNext(out T elem)

e.g.

public interface IValueEnumerator<T> : IDisposable
{
    T TryGetNext(out bool success);
}

vs

public interface IValueEnumerator<T> : IDisposable
{
    bool TryGetNext(out T value);
}

Disposal on iterator

Some questions

Covariance

I said fast right 😉 Though open question...

Type inference

Type inference isn't complete for Value Linq style extension methods

public static class Iterator
{
    // Can be inferred
    public static void ForEach<TValueEnumerator, TSource>(this TValueEnumerator enumerator, Action<TSource> action)
        where TValueEnumerator : struct, IValueEnumerator<TSource>
    {
        var current = enumerator.TryGetNext(out bool success);
        while (success)
        {
            action(current);

            current = enumerator.TryGetNext(out success);
        }
    }

    // Can't be inferred
    public static int Count<TValueEnumerator, TSource>(this TValueEnumerator enumerator)
        where TValueEnumerator : struct, IValueEnumerator<TSource>
    {
        int count = 0;
        enumerator.TryGetNext(out bool success);
        while (success)
        {
            count++;

            enumerator.TryGetNext(out success);
        }

        return count;
    }

    // Can be inferred, but unneeded extra param
    public static int Count<TValueEnumerator, TSource>(this TValueEnumerator enumerator, TSource _)
        where TValueEnumerator : struct, IValueEnumerator<TSource>
    {
        int count = 0;
        enumerator.TryGetNext(out bool success);
        while (success)
        {
            count++;

            enumerator.TryGetNext(out success);
        }

        return count;
    }
}

class Program
{
    void Main()
    {
        var list = new List<int>();

        // Works
        list.GetValueEnumerator().ForEach((int i) => Console.WriteLine(i));

        // The type arguments for method
        // 'Iterator.Count<TValueEnumerator, TSource>(TValueEnumerator)' 
        // cannot be inferred from the usage.
        // Try specifying the type arguments explicitly
        list.GetValueEnumerator().Count();

        // Works
        int _ = 0;
        list.GetValueEnumerator().Count(_);
    }
}

Value Linq

IValueEnumerable would be a preferred pattern

public static int Count<TEnumerable, TEnumerator, TSource>(this TEnumerable source)
    where TEnumerable : struct, IValueEnumerable<TSource, TEnumerator>
    where TEnumerator : struct, IValueEnumerator<TSource>

As it can then be type short-cut e.g.

if (source is ICollection)
{
    return ((ICollection)source).Count;
}
else
{
    // iterate
}

But then type inference for the generics is an extra step away

/cc @jaredpar @nguerrera @CyrusNajmabadi @davkean @HaloFour @sharwell @svick @HaloFour @karelz

[HaloFour]

@benaadams

Given that external code could obtain their own ValueEnumerable via new or default perhaps it would be better to use 1 as the initial __state value and reserve 0 for detecting an uninitialized enumerator?

public SkipEnumerator Skip(int toSkip) => new SkipEnumerator(this, toSkip);

public struct SkipEnumerator : IValueEnumerator<T>
{
    private int __state;
    private List<T> __thisCapture;

    private int version;
    private int index;

    internal SkipEnumerator(List<T> thisCapture, int toSkip)
    {
        __state = 1;
        __thisCapture = thisCapture;
        version = thisCapture._version;
        index = toSkip;
    }

    public T TryGetNext(out bool success)
    {
        switch (__state)
        {
            case 0: throw new InvalidOperationException("Uninitialized enumerator");
            case 1:
                if ((uint)index < (uint)__thisCapture._size)
                {
                    if (version == __thisCapture._version)
                    {
                        throw new InvalidOperationException("List changed");
                    }
                    index++;
                    success = true;
                    return __thisCapture._items[index - 1];
                }
                __state = 2;
                goto case 2;
            case 1:
            default:
                success = false;
                return default(T);
        }
    }

    public void Dispose() { }

    // Implicit conversion detailed below in Interop
    public static implicit operator EnumeratorAdapter<T, SkipEnumerator>(SkipEnumerator enumerator)
    {
        return new EnumeratorAdapter<T, SkipEnumerator>(enumerator);
    }
}

[benaadams]

@HaloFour updated

[nguerrera]

This is pretty close to what I was suggesting in #974 (comment), so obviously that makes me happy. :)

The difference is that I was proposing having both enumerator<T> and enumerable<T> with exactly the same use cases as IEnumerator<T> and IEnumerable<T> iterators today. The former is useful for implementing Get(Value)Enumerator() while the latter is useful for returning sequences from arbitrary methods.

I would caution against trying to make enumerators an exchange currency. In today's world, enumerator usage is always: get a fresh one at sequence start, enumerate, throw away. That's why their mutability doesn't matter. However, if we start having lots of things that return and accept enumerators directly, it will start to matter and get messy.

We should not conflate the concept of a sequence (enumerable) with the concept of a cursor over a sequence (enumerator).

[nguerrera]

I wonder if IValueEnumerable<T, E> -> IEnumerable<T> adapter could be default interface implementation (if that feature lands) with IValueEnumerable<T, E> : IEnumerable<T>. Ditto for IEnumerable<T> : IEnumerable that exists today. That could save a lot of boilerplate.

[benaadams]

I would caution against trying to make enumerators an exchange currency. In today's world, enumerator usage is always: get a fresh one at sequence start, enumerate, throw away.

Agreed; an issue that did come up was Dispose; for enumerable started it is clear to call Dispose for enumerator it is not clear. Also casting for fast-path (to ICollection/IList for .Count vs enumerating the entire collection). Listed them in Issues.

default interface implementation

This is nice :)

having both enumerator<T> and enumerable<T>

Will try again... 3rd time's the charm ;-)

[benaadams]

default interface implementation

Would be something like:

public interface IEnumerable<out T>
{
    IEnumerator<T> GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
}

public interface IValueEnumerable<T, TEnumerator> : IEnumerable<T>
    where TEnumerator : struct, IValueEnumerator<T>
{
    TEnumerator GetValueEnumerator();
    IEnumerator<T> IEnumerable<T>.GetEnumerator() => new EnumeratorAdapter<T, TEnumerator>(GetValueEnumerator());
}

[benaadams]

Not sure implementing GetEnumerator() in the default interface would achieve anything? (like implementing strongly typed enumerator for downlevel C#)

public partial interface IValueEnumerable<T, TEnumerator> : IEnumerable<T>
    where TEnumerator : struct, IValueEnumerator<T>
{
    TEnumerator GetValueEnumerator();
    IEnumerator<T> IEnumerable<T>.GetEnumerator() => new EnumeratorAdapter<T, TEnumerator>(GetValueEnumerator());
    // Achieve anything ?
    EnumeratorAdapter<T, TEnumerator> GetEnumerator() => new EnumeratorAdapter<T, TEnumerator>(GetValueEnumerator());
}

[benaadams]

@nguerrera 3rd approach showing all the variants would be

partial class List<T> : IValueEnumerable<T, List<T>.ValueEnumerator>
{
    int _size;
    T[] _items;

    // Class-level ValueEnumerable (iterator)
    public enumerator<T> ValueEnumerator GetValueEnumerator() // typeof(ValueEnumerator)
    {
        int index = 0;
        while (index < _size)
        {
            index++;
            yield return _items[index - 1];
        }
    }
    
    // Method iteratable (iteratable)
    public enumerable<T> SkipEnumerable Skip(int index) // typeof(SkipEnumerable)
    {
        while (index < _size)
        {
            index++;
            yield return _items[index - 1];
        }
    }

    // Pass-through Method iteratable (iteratable)
    public SkipEnumerable SkipTen() // typeof(SkipEnumerable)
        => Skip(10);

    // Pass-through Method iterator (iterator)
    public SkipEnumerable.Enumerator TenSkipped() // typeof(SkipEnumerable.Enumerator)
        => Skip(10).GetValueEnumerator();

    // Class-level Enumerable - downlevel C# struct enumerable support
    public EnumeratorAdapter<T, ValueEnumerator> GetEnumerator() => GetValueEnumerator();
    
    // IEnumerable.GetEnumerator() // implemented via default interface
    // IEnumerable<T>.GetEnumerator() // implemented via default interface
}

[benaadams]

The main issue is lack of inference of generic arguments based on constraints so you need to do:

list.Any<List<int>, List<int>.ValueEnumerator>();
list.Count<List<int>, List<int>.ValueEnumerator>();

Rather than

list.Any();
list.Count();

To resolve

public static int Count<TSource, TValueEnumerator>(this TSource source)
    where TSource : IValueEnumerable<TValueEnumerator>
    where TValueEnumerator : struct, IValueEnumerator

However, running a perf test for a "ValueLinq" https://gist.github.com/benaadams/294cbd41ec1179638cb4b5495a15accf

    Method | Categories |      Mean |     Error |    StdDev | Scaled | Allocated |
---------- |----------- |----------:|----------:|----------:|-------:|----------:|
      Linq |        Any | 16.718 ns | 0.0615 ns | 0.0480 ns |   1.00 |      32 B |
 ValueLinq |        Any |  8.241 ns | 0.0286 ns | 0.0253 ns |   0.49 |       0 B |
           |            |           |           |           |        |           |
      Linq |      Count | 69.538 ns | 0.3562 ns | 0.2781 ns |   1.00 |      32 B |
 ValueLinq |      Count | 35.665 ns | 0.1095 ns | 0.0970 ns |   0.51 |       0 B |

Its twice as fast and cuts allocations to zero

[bbarry]

small nit:

foreach(V c in x) lowerings should be:

if x is IValueEnumerable:

using (E e = ((C)x).GetValueEnumerator();) 
{
    while (true)
    {
        V c = (V)(T)e.TryGetNext(out bool success);
        if (!success) break;

        // Loop body
    }
}

and just the loop if x is IValueEnumerator.
Conversions skipped where unnecessary.

because this (and other conversions) should work (as they do in current foreach statements):

long Sum(List<int> list)
{
    long a = 0;
    foreach(long l in list)  { a += l; }
    return a;
}

And that it should be structurally done instead of depending on types.

[benaadams]

And that it should be structurally done instead of depending on types.

Works for foreach, but has issues with a ValueLinq or ValueEnumerator (rather than IEnumerable<T>) based methods?

[bbarry]

Yes that is what I meant. For foreach it would be a structural pattern (and thus would work with ref struct types). APIs that required the implementations here would require the interfaces at least until shapes comes along.

[sebas77]

I have some interesting application for this and would help my team writing allocation 0 code in a more comfortable way.

[arekbal]

But...

                  Method |       Mean |     Error |    StdDev | Scaled | ScaledSD |
------------------------ |-----------:|----------:|----------:|-------:|---------:|
          array_by_index |   883.7 ns | 13.486 ns | 11.262 ns |   1.27 |     0.05 |
     array_by_enumerator |   698.9 ns | 14.310 ns | 28.578 ns |   1.00 |     0.00 |
           list_by_index | 2,383.7 ns | 12.979 ns | 12.140 ns |   3.42 |     0.13 |
      list_by_enumerator | 2,941.2 ns | 22.656 ns | 21.192 ns |   4.22 |     0.17 |
     list_by_array_index |   711.3 ns | 13.976 ns | 29.785 ns |   1.02 |     0.06 |
      list_by_span_index |   777.0 ns | 15.518 ns | 25.058 ns |   1.11 |     0.06 |
 list_by_span_enumerator |   490.2 ns |  3.595 ns |  3.362 ns |   0.70 |     0.03 |

List is that unfortunate example...
List of structs, is holding items in continous memory space. It basically acts as resizable Array.
Index accessor and/or list enumerator should run as fast as Array without any new non-inlineable temporaries in between.
What List enumeration needs, first of all, is to expose some sort of ReadOnly/AsSpan() and/or T[] RawArray/RawData and/or index access by ref...
Looking at the table above... List<>.GetEnumerator() returning that SpanEnumerator would be miraculous...

I understand you guys hope for some linq over values. But please re-design for performance.
Biggest Linq(in all it's glory) failure was exactly performance considerations...
Other one having IEnumerable<> embedded directly into classes instead of just working with enumerators/iterators exposed through separate factory methods (which I am glad you are looking at).

Side Note: Interleaving is also important issue here.
for instance, summing all X's over Array<Point> would be noticably faster in some sort of InterleavedArray<Point> (where X's are listed first then Y's).
Why is that important... for bigger structs like 64 bytes or fixed buffers, all that striding(which memory readers don't like) if not cared about are slowing things to a crawl.

Here is an interesting topic on Rust SO. I don't see why C# have to be worse in this regards.

[manofstick]

Well 3 years have passed since this case was opened, but I have recently put my noggin to work on this, well not this precisely, but a particular facet on this which is a ValueLinq.

Now I'm probably one of a small number of people who have written an implementation of Linq from the ground up (Cistern.Linq) where it's raison d'etre was inverting the linq pull model into a push model via use of some fancy generics (It's good! give it a shot!). But it did have a couple of issues. It created a fair bit more garbage and wasn't fantastic with small collections due to the overhead of setting everything up (which was related to the garbage...)

I had basically escaped from my weird obsession with all things Linq until 3 days ago when #1931 was closed, which triggered an email sent to me, which triggered me thinking about a ValueLinq implementation, which... Yeah well enough life story. Just get on with it.

If you're a person who just likes code then go and take a look at the embryonic state of this ValueLinq here

So why would you bother with a new ValueLinq? I mean @kevin-montrose gave it a crack with LinqAF so is there any other need?

Well there are two key innovations here which different my version from his. The first is the realization that carrying around the Enumerator type all over the place is a bore (but don't we need it?). The second is that we need a common generic type to carry our implementation in so that c#'s type inference can work without having to resort to massive bloat of specific types for each container.

So working with those two idea I've prototyped some of the basic operations (and polyfilled the rest of the Linq API stubs with forwards to System.Linq which works, but isn't particularly performant - yet not terrible) and I must say I'm fairly pleased with the result.

Now I must admit I haven't checked out what underlying code the runtime creates from this stuff because it could be a monster with all the generic guff that I'm using to hold this ship together!

So key takeaways are:

• No garbage created at all for internal linq operations
• One object created if you want to use in a foreach loop
• Exposes IEnumerable<> to retain compatibility
• Very simple to add new operations (They are referred to as Nodes in the code)
• Very simple to add new wrappers for other data structures (although only List and Array are type cast if the source is IEnumerable<>)
• Common output type (ValueEnumerator<T, Inner> where Inner : INode)
• Very fast pipeline creation; faster than standard Linq

Now, as I always tell me children, you can't beat free (yet somehow they don't want the free stuff I give them....). So in the case, for example, of <<some enumerable>>.Sum() where <<some enumerable>> isn't an array or a list then I'm slower (stabilizing to around 20% slower at around 100 elements), but throw a simple .Select(x => x * 2) then I'm now faster for all sizes of containers, from 0 length up. Even though System.Linq contains a specific optimization for just such a case. Some performance results for these two cases are here and here.

The surface is pretty sparse at the moment - Select, Where, Sum (just int and double), ToList, Count - which you can find here. The whole of the surface with the stubs to System.Linq is here

There is also so totally crazy optimizations for Select.ToList, WhereSelect.ToList, Where.ToList and SelectWhere.ToList which don't follow the pattern I have created, because they are specific optimizations that are currently in System.Linq which I just can't equal without cheating (I mean cheating in the same way that System.Linq does, well except for the crazy mechanism I use to get there given I can't enquire via interfaces.)

Look, I'd love some help to crank out the rest of the functionality, or even someone to do some analysis on the bloat in the machine code that this generates. From my past experience with Cistern.Linq I'm assuming that no-one will ever actually use this, but hey. You never know.

[YairHalberstadt]

It's definitely cool that you're able to eke out these performance improvements, and reduce allocations so much!

However...

Looping is relatively fast, and it's rare that the cost of having to loop through a few enumerators makes that much of a difference to runtime. Reducing allocations is great, but unless you're doing SelectMany, it's two allocations per query which is really not that bad.

The real cost is the inability to inline the delegate. When you write a loop imperatively, the JIT has everything it needs in one place, and can really go to town on it. It can do all sorts of optimizations like loop unrolling, vectorizing, etc.

The moment you have one virtual function, that becomes impossible, as the JIT can't see through the loop. Here you have at least two: the delegate, and the enumerator.

For that reason I feel like we need to get quite a few more language improvements before linq really can be cost free, such as traits/associated types, and value type delegates. I discuss that all here: #2482.

[manofstick]

@YairHalberstadt

Oh I agree, but I think you're missing some of the magic here.

Here you have at least two: the delegate, and the enumerator.

But that is the beauty - one of these I don't have! The design here is such that I don't need to expose the enumerator to everybody on the outside, but internally I am using the value type enumerator it (in the case of list and array, but as stated it's very easy to provide your own value type enumerator for any collection, or pseudo collection i.e. Range/Repeat which is what I'll implement after this message, hopefully).

And secondly, due to the design it's very easy to do the second item on your list - i.e. the "value type IFunc" - albeit really only with pure functions due to copying around and the like. I can create this for you and you can have a play if you are interested. Obviously not with pretty c# syntax, but at least allows you to investigate how the JIT would handle the whole situation as of today...

Now do embedded inferface based value type inline properly? I really don't know, that not my skill set (I'm a wave the generics wand to make things pretty kinda guy...), but I believe it's possible.

So I see Cistern.ValueLinq as:

• allowing people to analyse the affects of all this crazy generic glue. How much does it bloat thing? Is it inlining all these nodes? What optimization opportunities exist? How much time is it taking to convert to asm? (maybe not an issue with AOT)
• it provides some benefit in it's current state, thus in theory (but not sure in reality...) it possible that it could be some level of adoption, which could drive the first point...

So I hear you when you talk about inlining benefits, but to me the benefit this framework brings to the table is a working model in which to progress, as although maybe a worthy goal, unless the stepping stones of working programmers are there to be trod on (ahem, I mean stand on shoulders of those giants...) then reaching that goal is near impossible ...

Whatcha think?

[YairHalberstadt]

TBH I looked at the code briefly, and couldn't make head or tails of it on GitHub 😆. I'll need to clone the code at some point and play around with it to see how it works.

Altogether sounds pretty cool

[manofstick]

Hahah! Well if you need a tour, let me know.

[Xyncgas]

I'm using linq a lots, would be nice if I can keep using it now that I am getting paid a lot

[monkey0506]

With the allows ref struct anti-constraint in C# 13, I created this proof-of-concept for working with ref struct enumerators.

I ran into the same issue that @benaadams mentioned above regarding generic type argument inference. By introducing an unused method parameter, I can get the compiler to deduce the generic type arguments. Something like .Any(default(int)) is definitely uglier than .Any(), but when chained several method calls deep the enumerator type (in my case) becomes much (much) more unwieldy.

I'm not sure if my project is any benefit here, but I came across this thread while searching for a way to deal with this.

[TahirAhmadov]

I ended up with something similar. The solution is "existential types". However, I have no idea how they are going to implement those, and when/whether that will ever happen.

[333fred]

@BlinD-HuNTeR, putting your nuget package on your own discussion is one thing, but you are not welcome to spam it across more discussions. Please refrain from doing so in the future.

[BlinD-HuNTeR]

No problem, though it doesn't have to do with the package being mine, whenever I know about a package that can solve someone's problem, I suggest it (have already done that in other discussions).