ValueTask, taskSeq computation expressions based on TaskBuilderBase

[En3Tho]

Now, TaskBuilderBase ctor is not exposed in corresponding fsi file, basically it's internal to F# core
Is there a way to extend TaskBuilderBase to return ValueTask/IAsyncEnumerable (eg. not allocate a Task object if it not needed) other than full copy?

Are there more intricate implications with ValueTasks which prevent them to be included in FSharp.Core? I know they can't be awaited multiple time etc but I don't really see this as the reason of their absence.

And what about taskSeq? Is it planned for F# 7 or will there be a minor version introducing those?

[dsyme]

Are there more intricate implications with ValueTasks which prevent them to be included in FSharp.Core? I know they can't be awaited multiple time etc but I don't really see this as the reason of their absence.

I did talk about this with @NinoFloris . My conclusion was that ValueTask authoring using CEs wouldn't immediately reduce any allocations over task { ... } with a conversion to ValueTask, or else returning ValueTask objects created in other ways. So it didn't feel necesssary to include it in FSharp.Core. But we can reassess and add something in F# 7.

And what about taskSeq? Is it planned for F# 7 or will there be a minor version introducing those?

Initially we will do this as a separate community nuget package built on the resumable code feature (similar to FSharp.Control.AsyncSeq - indeed we will likely revise that). We won't add directly to FSharp.Core though I can see a world where we move some community packages to .NET Foundation and start adding references to them by default in standard F# templates. Though that begins to mean F# has a framework of its own

[abelbraaksma]

I've made the taskSeq library available on NuGet since 2022, where it has gotten some traction, see: https://www.nuget.org/packages/FSharp.Control.TaskSeq/. Contributions welcome :).

[En3Tho]

@dsyme Thanks. You've mentioned Community package - will it be based on existing TaskBuilderBase or will it use another builder? Is there a plan to "open" TaskBuilderBase or to let it stay internal only? I'm asking because I want to expreriment with ValueTask based Result builders so any info is welcome.

[dsyme]

@dsyme Thanks. You've mentioned Community package - will it be based on existing TaskBuilderBase or will it use another builder? Is there a plan to "open" TaskBuilderBase or to let it stay internal only?

It will stay as internal only. It's not a complicated thing and can be duplicated out as needed

[Xyncgas]

ValueTask.ToTask is painful to use in System.IO.PipeLine when everything is returning a ValueTask in high performance IO

[En3Tho]

After all this time (and having implemented different stuff based on TaskBuilder like SynchronizationContextTask for ui apps, ActivityTask for automatic activity creatinon, SemaphoreTask, LazyTask, RepeatableTask, TaskSeq, TaskResult, ValueTask etc. It was really fun to play with.) I still think that ValueTask and TaskSeq builders should be included in the corelib.

There are many cases where you'd want to just simply implement some core types without resorting to additional packages.
E.g. even a simple DisposeAsync now is a "do it yourself or get a package". This is not really cool.
Same with IAsyncEnumerable. I believe people should be able to make these right out of the box. They are a part of corelib and should be a part of FSharp.Core.

In the list above most of task builders I've made are special cased or are a convinience. But these 2 are basic ones.

[abelbraaksma]

I still think that ValueTask and TaskSeq builders should be included in the corelib.

• TaskSeq CE using resumable code is available here: https://github.com/fsprojects/FSharp.Control.TaskSeq and as a NuGet lib and is pretty stable by now (by me).
• ValueTask CE using resumable code is available here: https://github.com/TheAngryByrd/IcedTasks and as a NuGet lib, which is also rather stable by now (by @TheAngryByrd).

@En3Tho Both ValueTask and TaskSeq depend on classes that are only available in NetStandard 2.1. Since FSharp.Core.dll must support both NetStandard 2.0 and 2.1, it's unlikely this will be added there any time soon. This is why those libs exist :).

E.g. even a simple DisposeAsync now is a "do it yourself or get a package". This is not really cool.

No. This is presently supported out of the box using the task CE with use or use!. IAsyncDisposable is NS20, so we can properly support it.

They are a part of corelib

No. At least not the version we must support.

I've made are special cased or are a convinience. But these 2 are basic ones.

It seems like you have a lot of experience with resumable code then. I could always use an extra hand with TaskSeq. Would you mind take a look if things are up to spec?

[abelbraaksma]

In addition, have a look here: #14755 and here: fsharp/fslang-suggestions#1244.