IAsyncEnumerable<T> enumerator does not compile with net 40

[ig-sinicyn]

Example:

    public async IAsyncEnumerable<string?> EnumerateAsync()
    {
        await TaskEx.Yield();
        yield return "Hello!";
    }

produces CS1729 'ValueTask<bool>' does not contain a constructor that takes 2 arguments error.

The reason is, compilers calls ValueTask() ctor that requires IValueTaskSource and the ctor is not available under net40:

    [DebuggerHidden]
    ValueTask IAsyncDisposable.DisposeAsync()
    {
      // ...
      // fails here:
      return new ValueTask((IValueTaskSource) this, this.<>v__promiseOfValueOrEnd.Version);
    }

BTW, is the project alive now, or it was taken on hold? If the latter - its sad but thanks for the great library anyways!

[NN---]

I sent mails to the author but didn't get any response :( The only option I currently see here is to maintain a fork which is unfortunate.

[OwnageIsMagic]

@NN--- I'm currently maintaining private fork, but interested in making my contributions public. Seems like you have write permissions to this project, but doesn't have access to nuget, right?.

[OwnageIsMagic]

Based on GiHub activity @theraot is still active, but lost interest in .NET.

[OwnageIsMagic]

@theraot Are you interested in passing mainternership to @NN--- or someone else?

[theraot]

@NN--- is set as collaborator and call pull and merge.

But I still have the Nuget which is tied to my email account, and there is no release schedule or plans. I guess that answers https://github.com/theraot/Theraot/issues/194 too

I have an indie game studio, and that is taking my time. I cannot justify leaving my game project for this, as there is no income anyway.

Besides, if you asked me what would I do if I got a lot of money, I would answer that I put it on savings. That does not reveal anything about me beyond that money is not the motivation. On the other hand, if you ask me what I would do if I could even without income, that would be games.

So I don't know if income would get me back on this project. But I know that without income it makes no sense to publicize it or hire.

From time to time there is some articule about enabling C# features on old .NET, this project is never on there. Which makes me think not that many people know about it, or if they find it via Nuget search they discard it in favor of other alternatives (usually smaller libraries that backport a much smaller set of features). In fact, it seems this project has been more useful as repository of code examples for people who want to have control over the code that enable the aforementioned features.

At some point this project stopped being useful for old Unity projects - you know Unity is Unity and among of its failings you can count that they were behind in .NET for a good while, I don't know if they still are - and I don't know how to fix this project for that. I rather help improve Godot and people migrate.

I suppose there is still other people who need old .NET beyond Unity users, but as time passes there becomes less common. While I'm becoming convinced that won't ever be nobody, backporting every new thing in .NET does not seem worth it. So, per features?

Speaking of splitting the library, last thing I remember trying to tackle was Span et.al. and considering an unsafe build so it can be implemented with pointers. But those are big changes, and I never decided how to approach it, if at all... There is some value in having it all in the same package as code can be reused internally better. I imagine doing it per feature would be harder to manage.

In the time since I have last pushed this project, .NET got a source generation solution which would arguably have been a path for this project, which - if I'm not mistaken - is being deprecated in favor of "incremental generators" which I haven't look into. So if you ask me for a future for this project, I don't know what it is. However, I would think the clunky old way is better if the goal is for people with old .NET installations to use it, in fact, perhaps the issue with old Unity is in using newer build tools.

At least everybody can fork it, or take the parts of the code that they need, that remains true.

[NN---]

Hello, While I am able to merge I cannot push a NuGet update.

Probably we should open a new NuGet package.

Source generator / Interceptor is nice idea. There are already few packages doing that. The only issue with it is requiring a new C# compiler which is not always the case.

[OwnageIsMagic]

My primary use case is backporting modern core packages to netfx. Using Theraot.Core it usually means just adding a package reference and global replace some statics with Ex suffix until it compiles ok.

client (net 4.0) - multitarget lib - server (net7)
    |               /
backports          |
         \ Theraot.Core

So I'm interested in shared nuget package.

@theraot it would be rude to start messing with your project without asking your permission first. You can add owner on nuget.org https://devblogs.microsoft.com/nuget/managing-package-owners/ to allow us update package.

@NN--- I think source generators mentioned as a way to split library to mini packages, not about user side source generation.

[theraot]

I was unaware I can add owner to the nuget, it asks for user name, so what username I would be adding?

[OwnageIsMagic]

@NN--- since you have repo permission, could you create nuget account?

[NN---]

Sure. I have NuGet account.

https://www.nuget.org/profiles/N-N

[NN---]

Regarding source generators there is a concept library PolySharp