I propose we implement a task {} workflow, similar to async {} which can execute and unwrap a Task, Task<'T> and ValueTask<'T> without having to convert the task into an async workflow first.
Given that most .NET libraries (almost everything if not everything) implements asynchronous methods which work with Task and Task<'T> it doesn't make sense to constantly have to convert back and forth between async workflows and tasks with the static Async.{...} methods if F# could just natively work with tasks instead.
My proposal is to add a task {} workflow which can exist side by side to the already existing async {} workflow. It would be a non-breaking addition to the F# language and probably (over time) supersede async {} altogether (I think async would only be used for backwards compatibility at some point).
Pros and Cons
The advantages of making this adjustment to F# would be better performance (as I understand that Tasks are slightly faster than Async and it will cut down the additional overhead cost of converting from Task to Async and from Async back to Task in every application. For example this is typical overhead in a standard .NET web application written in F#).
There are no disadvantages, because Async will still exist.
Extra information
FSharpX has a task computation expression and someone else has further improved it in this GitHub repository, which claims to be a lot faster.
Estimated cost (XS, S, M, L, XL, XXL):
S-M
Related suggestions:
The difference between #559 and this suggestion is that I don't propose to add more conversions between Task and Async, but to add native support for Tasks instead.
Affidavit (must be submitted)
Please tick this by placing a cross in the box:
Please tick all that apply:
I propose we implement a
task {}workflow, similar toasync {}which can execute and unwrap aTask,Task<'T>andValueTask<'T>without having to convert the task into an async workflow first.Given that most .NET libraries (almost everything if not everything) implements asynchronous methods which work with
TaskandTask<'T>it doesn't make sense to constantly have to convert back and forth between async workflows and tasks with the staticAsync.{...}methods if F# could just natively work with tasks instead.My proposal is to add a
task {}workflow which can exist side by side to the already existingasync {}workflow. It would be a non-breaking addition to the F# languageand probably (over time) supersede.async {}altogether (I think async would only be used for backwards compatibility at some point)Pros and Cons
The advantages of making this adjustment to F# would be better performance (as I understand that Tasks are slightly faster than Async and it will cut down the additional overhead cost of converting from Task to Async and from Async back to Task in every application. For example this is typical overhead in a standard .NET web application written in F#).
There are no disadvantages, because Async will still exist.
Extra information
FSharpX has a task computation expression and someone else has further improved it in this GitHub repository, which claims to be a lot faster.
Estimated cost (XS, S, M, L, XL, XXL):
S-M
Related suggestions:
structural awaitersThe difference between #559 and this suggestion is that I don't propose to add more conversions between Task and Async, but to add native support for Tasks instead.
Affidavit (must be submitted)
Please tick this by placing a cross in the box:
Please tick all that apply: