Add for! (for-bang) keyword to computation expressions

[Lanayx]

I propose we extend the computation expression syntax with a new keyword, for!, that simplifies processing of IAsyncEnumerable<'T>.

task {
    for! item in agent.RunStreamingAsync("What is the weather today?") do
        printf "%O" item
}

Which should be desugared to this (similar to C#)

task {
    use e = agent.RunStreamingAsync("What is the weather today?").GetAsyncEnumerator()
    while! e.MoveNextAsync() do
        printf "%O" e.Current
}

The existing way of approaching this problem in F# is using the desugared version
or with FSharp.Control.TaskSeq package:

open FSharp.Control
task {
    for item in agent.RunStreamingAsync("What is the weather today?") do
        printf "%O" item
}

Former option is rather verbose and latter is confusing, since nothing tells user that there is "await" on each iteration.

Fable

This will also help Fable to implement support for AsyncEnumerable analogues:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncGenerator
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for-await...of
https://docs.python.org/3/reference/compound_stmts.html#async-for

promise{
    for! value in generate() do
        printfn "%O" value
}

// javacript
for await (const value of generate()) {
  console.log(value);
}

# python
async for value in generate():
    print(value )

Pros and Cons

The advantage of making this adjustment to F# is improved user experience when working with IAsyncEnumerable<>, which is already widespread

The disadvantages of making this adjustment to F# is that it's unclear whether new method will be applicable to other cases except IAsyncEnumerable<>

Extra information

Estimated cost (XS, S, M, L, XL, XXL): M

Related suggestions: (put links to related suggestions here)

While-bang
If-bang
AsyncSeq builder

Affidavit (please submit!)

Please tick these items by placing a cross in the box:

• This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
• This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to the compiler and tooling repository
• This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it
• I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

• This is not a breaking change to the F# language design
• I or my company would be willing to help implement and/or test this

For Readers

If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.

[jwosty]

Also related to (and would be superseded by if implemented): #1070

[Tarmil]

Yeah, as shown by the TaskSeq example, it's not technically necessary to have new syntax for this; we could just add a For overload that takes an IAsyncEnumerable instead of an IEnumerable. But it would probably be clearer when reading code like this if awaiting for loops are visually distinct in the same way as every other awaiting construct.

[jl0pd]

There's definitely should be different syntax for asynchronous enumerating since same instance may implement both IEnumerable and IAsyncEnumerable and compiler would have to either fail to resolve overload (worst scenario since code will just break without workarounds) or prefer one overload over another (may pick sync overload in async method or wise-versa which is still bad). Also type doesn't have to implement I{Async}Enumerable since C# supports duck typing for some constructs and F# should support consuming them

Following example compiles in C#

using System;
using System.Threading.Tasks;

public class MyEnumerable {
    public Enumerator GetEnumerator() => new();
    public Enumerator GetAsyncEnumerator() => new();
    
    public class Enumerator
    {
         public int Current => 0;
         public bool MoveNext() => false;
         public ValueTask<bool> MoveNextAsync() => ValueTask.FromResult(false);
    }
}

public class C {
    public void Iter() {
        foreach (var item in new MyEnumerable()) {}
    }
    
    public async Task IterAsync() {
        await foreach (var item in new MyEnumerable()) {}
    }
}

[T-Gro]

Could you please include full de-sugaring process incl. resource management+disposal?

[Lanayx]

@T-Gro Good catch, after adding desugared version to the description I've realized that this feature is required to be implemented first.
UPDATE: I've actually realized that even though binding in finally block is not available for users, it is already implemented for IAsyncDisposable<> with regular use in task CE.

[Lanayx]

@jl0pd Actually while digging into it I've found that we already have use supporting both IDisposable and IAsyncDisposable, so as we are in the same situation with IEnumerable<> and IAsyncEnumerable<> - it's unclear what to do when both are supported. So we can either claim that the decision to reuse the same operator with different disposables was wrong (and separate them to use and use!), or stick to it for enumerables as well. Which means - to choose IAsyncEnumerable if it's available, otherwise choose IEnumerable

[TheAngryByrd]

Yeah, as shown by the TaskSeq example, it's not technically necessary to have new syntax for this; we could just add a For overload that takes an IAsyncEnumerable instead of an IEnumerable.

We already have support for this in IcedTasks with the current for keyword

IcedTask Implementation: https://github.com/TheAngryByrd/IcedTasks/blob/863bf91cdee93d8c4c875bb5d321dd92eb20d5a9/src/IcedTasks/TaskBuilderBase.fs#L342-L357

Use: https://github.com/TheAngryByrd/IcedTasks/blob/863bf91cdee93d8c4c875bb5d321dd92eb20d5a9/tests/IcedTasks.Tests/TaskTests.fs#L586-L614

[Lanayx]

Added Fable cases