Ix.Async Select with selector returning Task<TResult>

[fubar-coder]

It would be very convenient to have a Select(Func<TInput, Task<TResult>>) out of the box.

The only way to do this is by creating your own Select function or by using .SelectMany(x => ConvertItemAsync(x).ToAsyncEnumerable()), which probably isn't as optimized as it could've been?

[aelij]

This is missing for ALL of the operators. This entire Async library should be revisited and implemented much more simply using async/await (see SelectAsync and WhereAsync in this Gist for example.)

[oliverjanik]

I was just looking for a ForEach version of this where the callback should be Func<TInput,Task>and not Action<TInput>.

[bartdesmet]

We'll sync up with the C# team on future directions for IAsyncEnumerable<T> and LINQ. See dotnet/roslyn#261 for a discussion on that end. The observation that we'd need sync and async overloads for operators is quite right; for operators that take in 2 or more functions that need async variants, this starts to add up quite a bit in terms of API surface though.

[aelij]

@bartdesmet For operators that take in 2 or more functions, can't we have just Task-returning functions and use Task.FromResult if needed (possibly at the cost of an allocation)? I may be wrong but I think this use-case is fairly rare (needing a sync and async functions together in the same call).

Must you really wait for C# to implement this feature? It could take a while. As I mentioned in my PR (#170) there's currently a real need for this library in Service Fabric, which only exposes an async enumerable over Reliable Collections. And the async versions of the operators are needed for cross-collection queries.

[clairernovotny]

These are now available in the 4.0 preview

[softlion]

"These are now available in the 4.0 preview"

What is "these" ?