Migration to .NET 10 is unclear

[Leon99]

I feel like I'm missing something obvious here but couldn't find an explanation anywhere, and MS documentation on this is rather brief...

await Enumerable.Range(1, 10)
                .ToAsyncEnumerable()
                .SelectAwait(async i => await Task.FromResult(i))
                .FirstAsync()

returns int, but SelectAwait is now obsolete with explanation "Use Select", however

await Enumerable.Range(1, 10)
                .ToAsyncEnumerable()
                .Select(async i => await Task.FromResult(i))
                .FirstAsync()

returns Task<int>, so Select is not a direct replacement as it'd need to be wrapped in something like await Task.WhenAll(...ToArrayAsync()) to get the same result. What am I missing?

[julealgon]

@Leon99 what are you attempting to do with this line?

.Select(async i => await Task.FromResult(i))

What is your real Select expression that you are trying to convert?

Here is an example that works just fine, where I'm simulating some sort of async logic on the projection. All you need to do is make sure you are using the correct overload ValueTask + CancellationToken here:

// `x` is `int` here, not `Task<int>`
var x = await Enumerable
    .Range(1, 10)
    .ToAsyncEnumerable()
    .Select(DoSomethingAsync)
    .FirstAsync();

ValueTask<int> DoSomethingAsync(int i, CancellationToken cancellationToken)
{
    return ValueTask.FromResult(i * 2);
}

The inline equivalent on your example would be something like:

var x = await Enumerable
    .Range(1, 10)
    .ToAsyncEnumerable()
    .Select(async (int i, CancellationToken ct) => await ValueTask.FromResult(i))
    .FirstAsync();

Or even this alternative version that disambiguates a different way:

var x = await Enumerable
    .Range(1, 10)
    .ToAsyncEnumerable()
    .Select<int, int>((i, _) => ValueTask.FromResult(i))
    .FirstAsync();

[idg10]

I think the crucial part of @julealgon's example is that the callbacks take a CancellationToken.

The .NET runtime library team elected to require all async callbacks to accept a CancellationToken. In effect, they only offer the forms that System.Linq.Async supplied with names that include WithCancellation.

There's no loss of functionality here: you are free to ignore the CancellationToken, at which point the behaviour is the same as if you'd used the old System.Linq.Async methods that let you supply a callback that didn't take that token.

I'll see if I can make this more clear by changing the Obsolete text.

[Leon99]

Thanks, using the CancellationToken overload is the missing piece I was looking for.
And yes, a few words in documentation would definitely help as using a particular overload to achieve different behavior is not obvious at all.

[alexdresko]

So the new Select doesn't work with anonymous types. You can't use the Select overload that takes a cancellation token, because you can't specify the first parameter.

[idg10]

So the new Select doesn't work with anonymous types. You can't use the Select overload that takes a cancellation token, because you can't specify the first parameter.

Since the new Select comes from the .NET runtime's new System.Linq.AsyncEnumerable you should consider creating an issue in the dotnet/runtime repo. The maintainers of this dotnet/reactive repo (e.g. me) are not in a position to do anything about the point you've raised.

(This repo is not really anything to do with the .NET team. It's under their org only for historical reasons.)

That said, I am now wondering if System.Interactive.Async (which I am responsible for maintaining) could usefully offer a solution to this.

For example, instead of just making this particular WithCancellation method obsolete, we could just move it into System.Interactive.Async, along with the other features that .NET's System.Linq.AsyncEnumerable chose not to replicate, and which we wanted to continue to offer. I hadn't done that with these WithCancellation overloads because the new library supports cancellable callbacks, so this seemed like an area where the new library fully covered what we used to supply. But usability with anonymous types hadn't occurred to me.

I'm wondering if @stephentoub has any suggestions for you. Ix.NET's use of this non-standard WithCancellation naming convention was one of the reasons for not simply taking over ownership of the existing System.Linq.Async library. His knowledge of the subtleties of .NET library design goes far deeper than mine, so he might be able to suggest a way to deal with this scenario that doesn't involve Ix.NET reintroducing this non-standard naming convention.

[stephentoub]

So the new Select doesn't work with anonymous types. You can't use the Select overload that takes a cancellation token, because you can't specify the first parameter.

If you have an anonymous type, you can use the overload that takes the value, the int, and the CancellationToken, and just ignore the int.

var valuesNamed = AsyncEnumerable.Range(1, 10).Select(i => i.ToString());
_ = valuesNamed.Select(x => x.Length);
_ = valuesNamed.Select((x, i) => x.Length);
_ = valuesNamed.Select(async (string x, CancellationToken ct) => x.Length);
_ = valuesNamed.Select(async (x, _, ct) => x.Length);

var valuesAnonymous = AsyncEnumerable.Range(1, 10).Select(i => new { Value = i });
_ = valuesAnonymous.Select(x => x.Value * 2);
_ = valuesAnonymous.Select((x, i) => x.Value * 2);
_ = valuesAnonymous.Select(async (x, _, ct) => x.Value * 2);

[stephentoub]

@333fred, if we wanted to improve that, seems like ORPA would fit the bill. Any downsides to putting ORPA(1) on https://github.com/dotnet/runtime/blob/eccb92811b68de151bdbcb9e472df31cf03ed487/src/libraries/System.Linq.AsyncEnumerable/ref/System.Linq.AsyncEnumerable.cs#L132 ?

[333fred]

Only in the particularly weird case of a type with conversions to both int and CT. Hopefully such a type doesn't exist.

[alexdresko]

@stephentoub @idg10

Stephen's suggestion to user the overload with three parameters got my code working again. Please let me know if you would still like for me to create an issue in the correct repo.

This is a contrived example, but this compiles:

	var result = await new[] { new { Age = 45 }}
		.ToAsyncEnumerable()
		.Select(async (p, _, _) => { // Using the overload with 3 parameters
			return await ValueTask.FromResult(p);
		})
		.ToListAsync();

...and this does not...

	var result = await new[] { new { Age = 45 }}
		.ToAsyncEnumerable()
		.Select(async (p, _) => { // CS0121
			return await ValueTask.FromResult(p);
		})
		.ToListAsync();

[idg10]

Assuming you're happy with the this solution, I think it's probably unnecessary.