Should generated IAsyncEnumerators clear current value when MoveNext is called?

[fabianoliver]

Problem

At the moment, compiler-generated async enumerators maintain their last yielded value in their state all the way until the next value is available (or terminate conditions are met I believe - eg exceptions, disposal).

Consider e.g. this (bad) example:

async IAsyncEnumerable<SomeVeryLargeObject> test()
{
    yield return new SomeVeryLargeObject();
    await Task.Delay(TimeSpan.FromHours(1));
    yield return new SomeVeryLargeObject();
}

When a caller fully consumes this IAsyncEnumerable, typically, the first yielded SomeVeryLargeObject will maintain in the async enumerator's state all the way until the second one is yielded, i.e. for at least an hour in this example.

await using var en = test().GetAsyncEnumerator();
await en.MoveNextAsync();
var secondMoveNextTask = en.MoveNextAsync();
var cur = en.Current; // Doing this is probably illegal? But right now, it works. You can still access the first yielded element here
await secondMoveNextTask;

This can be problematic:

• SomeVeryLargeObject might be, well .. large! And we (I think unnecessarily?) hold on to it in the enumerator's state for potentially quite a long time,
• Meaning our overall memory consumption might be significantly higher than it could be, if the object is particularly large, or many such sequences are enumerated
• Maybe even worse, unless I'm missing something: For any IAsyncEnumerable with some truly asynchronous source, surely typically, a non-trivial amount of time would pass before any MoveNext call returns. Not necessarily an hour like above, but long enough that it seems extremely likely that just about any item yielded by an async enumerate would almost always end up in gen2, no matter what?
• This problem might "compound", in the sense that applications may often have long linq-style sequences of transformations of a sequence, and all of those may then individually hold on to some potentially large resultset for potentially a long time, e.g.

  SomeStreamOfLargeObjects()  // Keeps holding on to the initial object
    .Select(x => SomeTransformedObject(x))  // Keeps holding on to yet another large, transformed object
   // ... potentially many more operators ...

If needed, I'm happy to provide a real world example where this behaviour has detrimental effects on system characteristics, but hopefully the problem description above is a sensible enough summary?

Suggestion

A few options come to mind; would any of them be feasible or worth considering?

• Changing existing behaviour. The generated enumerator could always clear out the current item when MoveNext is called (or possibly, it might want to check if MoveNext returns synchronously, and only clear out Current in case it does not)
• Offer some functionality to configure this on a case by case basis; possibly similar to WithCancellation and ConfigureAwait?
• Possibly add some way to hook into how the enumerator is generated; maybe somewhat akin to AsyncMethodBuilder? Though wary if this would be too complex to really be used in practice
• The generated enumerator could implement some new interface IClearableEnumerator that'd expose some ClearCurrent() method, allowing consumers to handle this themselves as needed

[huoyaoyuan]

This has already been discussed in dotnet/roslyn#74013 (comment)