Proposal: yield => <expression>; as supplement to yield return <value>; for ref struct etc. support

[nietras]

The following program or similar programs with an IEnumerable<T> where T is a ref struct will either compile fine, crash the compiler or crash at runtime. The issue is of course the state machine trying to store the ref struct as a member.

foreach (var span in EnumerateSpans())
{
    Console.WriteLine(span.ToString());
}

static IEnumerable<ReadOnlySpan<char>> EnumerateSpans()
{
    yield return "Hello".AsSpan();
    yield return "World".AsSpan();
}

Sharplab below will show a compiler error or similar.
https://sharplab.io/#v2:D4AQTAjAsAUCAMACEEAsBuWsBmB7ATgKYCGAxgBaIAUAbsfogM4AOxAdogJYcCibArgFtC+YgBdCAZVZtGVAJTzYAb1iJ1yCAE4qLdgDoAKrklj83AOYL5mGAF8scCADZNAZgA8AJRIATAPJsADYAntLsHhT0AHzRiHxCIuJSMnJKMKowGpoQyADsiABEABKEQUG4hfoAgozhbAq22Si5IAWFAOoEQb5VtfWNsA4wQA=

I would like to propose the idea to add syntax support for yielding "expressions", that is Current of the enumerator/async enumerator will be Current => <expression>; and whatever is used in expression not part of other members be added to members of state machine.

foreach (var span in EnumerateSpans())
{
    Console.WriteLine(span.ToString());
}

static IEnumerable<ReadOnlySpan<char>> EnumerateSpans()
{
    yield => "Hello".AsSpan();
    yield => "World".AsSpan();
}

Above is just an example to show usage. A motivational example for code in BCL that might be more easily possible with this could be EnumerateLines() method on TextReader like:

public class TextReader
{
    public IEnumerable<ReadOnlySpan<char>> EnumerateLines()
}

The point of the idea is to open up C# for defining ref struct iterators, there are many use cases all it takes is a bit of imagination.

[huoyaoyuan]

The expression under Current is compiled down and the same for each iteration. The syntax can't really guarantee that.

For usages that need to produce ref struct, it's often necessary to also capture a ref struct, which doesn't work with yield because the iterator type must be speakable. Producing a ref struct (span) from other type (string) is really a niche case.

[nietras]

Sure, if you have different yield expressions you need to switch on that, not that complicated...

[HaloFour]

I wouldn't expect yield return <expr> to behave so differently from yield => <expr>.

How do you expect the compiler to emit the iterator state machine in this case?

[timcassell]

How do you expect the compiler to emit the iterator state machine in this case?

I would expect it to compile each <expr> to a method, and Current switches on the state to call the method. This means any side-effects of the <expr> will be observable (calling Current twice before MoveNext could return different results).

[nietras]

if => was just a short hand for return it would have little value, the whole point is as mentioned to let get_Current execute an expression instead of just point to a field. Whether this be with => or yield { return _array.AsSpan().Slice(0, _pos); }; or whatever.

yes, if the <expr> has side effect Current would change, there examples of same in BCL already. Reusable custom Task etc. Cannot await twice. If I recall correctly.

[HaloFour]

if => was just a short hand for return it would have little value

That's pretty much what is it for the rest of C#, which is why I feel that it's out of place for it to mean something so drastically here.

[TahirAhmadov]

I'm not sure i understand why the => is needed.

Will this not become possible when ref struct can implement interfaces, allowing the compiler to create a ref struct state machine?

[HaloFour]

Isn't that only to be permitted with use with constrained generics so that it can be guaranteed that the ref struct can never be boxed onto the heap?

I do agree, though. This feels like a language feature to hack around a larger limitation in an incredibly narrow way. How often would an iterator have a ref struct return but require no ref struct state?

[nietras]

See EnumerateLines example, lots of similar use cases or definitions. ref struct specifically opens up returning internal reusable state that is NOT in it self a ref struct. Aka span over internal array where a line is, a row is, some other state we are continuously iterating over but where we do not want to allocate for every return. This is what this opens up. :)

[HaloFour]

Those feel like niche cases and they can already be solved by defining a custom iterator adhering to the foreach pattern, which would only have to be done once.

[TahirAhmadov]

@nietras can you show exactly how the desired code in your OP gets transpiled to a state machine?