Implement ToImmutable*Async extension methods

[bash]

Resolves #1540.

I copied most of the XML documentation and tests of the non-immutable equivalents (with adjustments of course).

b667720 contains a bit of a refactoring, but I'm not sure if it's a big improvement.

Working with AsyncOverloads.tt was a bit unpleasant, especially since the generated code has diverged from the generated code (nullability and XML documentation) which meant I had to be careful of what to commit and what to discard.
Wouldn't a source generator be a better fit, because it knows about nullability and generic constraints?

[dnfadmin]

All CLA requirements met.

[dnfadmin]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

❌ bash sign now
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[bartdesmet]

LGTM modulo a cosmetic nit around a namespace.

[bartdesmet]

A source generator could be a viable option to replace the T4. We've had these T4 files for years but as you've observed sometimes manual changes to the .cs files made their way in and slipped through the cracks in code reviews, so we should either do a pass to refresh them, or replace them. In the latter case, we need to make we end up generating the exact same code of course.

[bartdesmet]

@bash I've merged the PR for the source generators (thanks!), so could you go ahead and rebase this PR (due to the delete/edit conflicts for the T4 files which are now obsolete)?

[bash]

@bartdesmet Hurray! I'm really happy how the source generators turned out. This PR is all rebased and ready for another review. 😃

[bartdesmet]

Functionally, everything looks good. But I do have a concern around the symmetry with the .NET libraries which put all of these ToImmutable* extension methods in System.Collections.Immutable instead (e.g. see here). It'd be unexpected if a user currently has using System.Collections.Immutable; (but no using System.Linq;) and is unable to discover the Async variants of these ToImmutable* methods.

My suggestion is to move all of these to System.Collections.Immutable and organize them in classes named as Immutable[<collection type here>]AsyncEnumerableExtensions, so the discoverability story is consistent.

A potential follow-up question is whether we want to put all of these in the current assembly or keep them in a separate assembly, but that always stirs heated debates (there's a history of flip-flopping between coarse-grained and fine-grained organization). So I'm fine keeping it here, and just focus on the logical namespace organization. The physical organization in terms of assemblies could be scrutinized down the road, but it seems like the conditional dependency on System.Collections.Immutable is only conditional for 1 target platform, so it's okay to always have the reference when the BCL assembly is available in the box anyway.

[bash]

Yess I finally got around to address your comment 🥳 (and fix my source generator ^^)

Oh, I haven't thought about this! I applied your suggestion for the namespace change and class name change. I also moved the files to match the new namespace.

There's not much that I know about how to best divide up assemblies, but it seems ok to me too to depend on System.Collections.Immutable conditionally, if it's only for one target platform.

[Romfos]

one year later -_-

[stijnherreman]

one year later -_-

Looks like there are no active maintainers currently :(

[akarnokd]

Does this have to live in dotnet/reactive? C# has extension methods so unlike other Rx incarnations, there is no loss of convenience having it in a 3rd party library.

[Romfos]

Does this have to live in dotnet/reactive? C# has extension methods so unlike other Rx incarnations, there is no loss of convenience having it in a 3rd party library.

I think yes, .NET 6 have this method out of the box for linq

[bash]

I always assumed that the goal of System.Linq.Async is to provide everything for async enumerables that Linq provides for enumerables (Although technically the ToImmutable* extension methods are part of System.Collections.Immutable).

I'd be willing to move this to a separate project if this should not be part of System.Linq.Async and someone has a good name suggestion for the package :)

[bash]

I'm no longer interested in updating this PR should a maintainer against all odds choose to review it.
Anyone is free to adopt the PR though in that case :)

[idg10]

/AzurePipelines run

[azure-pipelines]

Pull request contains merge conflicts.

[idg10]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

[idg10]

Hi,

Sorry this got neglected for so long. My employer (endjin.com) took over maintenance of all of Rx at the start of last year. Our priority was around Rx itself, and the fact that we inherited the Ix and System.Linq.Async projects as well was just a consequence of the history of this project. The BCL team has made noises about moving the System.Linq.Async functionality into .NET itself, with a strong suggestion that they might need to chuck a lot of code away because it doesn't really conform to their current design guidelines. So we've not been putting much attention into this.

However, since that seems to have stalled, we're starting to look at this again.

Since all the changes were made 3 years ago, this PR is no longer really usable, so what I'm intending to do is merge it into a separate branch, and then I will merge main into that branch, and then try to bring all of this up to date, with the hope of finally getting it merged into main.