What is the state & future of Ix?

[Ilia-Kosenkov]

Linq over IAsyncEnumerable is a core part of the services that I work on, yet I am growing more and more concerned with the fact that there are no updates & the repository looks abandoned. It is good to have some progress in the Rx domain, but what about Ix?

[HowardvanRooijen]

What needs to happen to Ix? I don't see any critical bugs, and the versions of .NET it targets are still supported?

[HowardvanRooijen]

BTW see #2102 - Proposal for moving async LINQ to BCL

[Ilia-Kosenkov]

It certainly would be nice to have it in BCL -- even with some breaking changes, but until the executive decision is made, is there a room for improvement here? By maintainers or other contributors? Or is it a no-go?

[idg10]

So...in an ideal world I'd be on top of all Ix issues. But the fact is we took over the repo in order to maintain Rx (and we do this as a contribution to the .NET community—nobody is paying us) and given that Microsoft occasionally suggests they would like to build the IAsyncEnumerable support into .NET, we haven't been prioritising that work. If it's all going to become moot because Microsoft writes their own replacement, it would be a waste of the limited amount of time we can spend on this project.

That said, since no real progress seems to be happening on the "Microsoft takes this over" front, I have been looking recently at some Ix issues.

[Ilia-Kosenkov]

Hi @idg10 , thanks for the update. I originally raised this topic not to blame or force someone to maintain Ix but rather to discuss if you could collaborate with people like myself and provide some support for Ix.
For instance, we (the users) could take a look at some simple PRs and perhaps tackle easy tasks like reaching feature parity with regular Linq without heavy optimizations, for starters
But I don't want to just blindly open PRs if they will remain unchecked.

I see no problem in doing this even if MS decides to overtake it -- I use this project right here right now and I am interested in its development alongside BCL.

[idg10]

We certainly aim to look at all PRs, and accept them if they are in alignment with Rx/Ix goals and design approach. But it is taking us a while even to get through the backlog that had built up before we took over the project.

In general it is best to open an issue first and propose a change so we can avoid situations where someone does some work that we wouldn't want to incorporate. (For example, people sometimes propose extending some of the non-core functionality in these libraries, such as the IDisposable implementations, or the async locking primitives. We don't always want to do that because these features exist to serve the purpose of these libraries, and are not intended to be fully capable features in their own right.)