Feature Request: ref struct iterator

[UniqeId6542]

In C#, I can write an iterator (yield return). This compiles into a private class.
I can also write a ref struct enumerable. (It can be used in a foreach loop as long as the struct has Current, MoveNext, and GetEnumerator)
I'm requesting that iterators support spans (ref-struct). Any iterator with a span used across yield return statements will itself compile into a ref struct enumerable.

A complication is how try-finally and other cleanup would work. Some form of Dispose or Finalize would probably be necessary.
#1110

[CyrusNajmabadi]

This specification needs more information. As yield return is only valid for methods that are IEnumerable<T> or IEnumerator<T> returning. And there is no way to ahve that be the return type, while also being a ref-struct.

[HaloFour]

Yup, I did mean to include that in "state", it's everything that the iterator needs to capture and lift into the generated class. All of it is now subject to being copied.

[TahirAhmadov]

Copying is one thing - and that's a problem - but how can the method return a struct of a variable size depending on what the implementation is? Unless we do something like:

struct iterator int Foo() { ... }

Here, we invent new syntax, struct iterator, which means the actual return type is synthesized at compile time; it's only guaranteed to have MoveNext and Current members.

[HaloFour]

but how can the method return a struct of a variable size depending on what the implementation is?

It couldn't. The iterator would have to be emitted into a value type, which would be different per iterator implementation, not unlike how each iterator emits a bespoke class today.

Here, we invent new syntax, struct iterator, which means the actual return type is synthesized at compile time; it's only guaranteed to have MoveNext and Current members.

That's an option. Personally I'm not a fan of auto-generated names. I'd rather a mechanism to explicitly name the value type that is returned.

[TahirAhmadov]

Yeah too much trouble for what it's worth, to be honest.

[RikkiGibson]

It's way harder when the generated names appear in signatures.

What if we just let you say:

public partial ref struct FooEnumerable : IEnumerable<ElementType>;
public FooEnumerable GetValues()
{
    yield return 1;
    // ...
    // compiler implements a state machine by adding members to 'FooEnumerable',
    // perhaps a mix of well-specified, public speakable ones, and implementation-defined unspeakable ones.
}

It doesn't seem that bad to me?

[HaloFour]

Probably falls under #982

[UniqeId6542]

I had missed that in my search. They're certainly related. Mine more has to do with ref-struct support for data in the iterator. The other's main post didn't mention 'ref' but just normal structs. I could see them being done at the same time, or the other one first followed by this request later.