Open dsyme opened 2 years ago
This would mean bringing a CancellableTask into this library from IcedTasks, which may be a good thing.
Hmm, yes. But then the top lib name of TaskSeq
should be reconsidered, as the namespace will be hosting tasks and task sequences.
Maybe just FSharp.Control.Tasks
and turn it into a collection of all of our wishlist in one place? I.e., cancellable task, parallel task and delayed tasks from IcedTasks
and TaskSeq
, perhaps later AsyncSeq
as well? And then should we include the extremely useful FsToolkit
taskResult
and taskOption
and the like?
Many questions and strategies possible... Though the idea of a "single stop shop" for all (or most) of task/async related stuff is appealing.
Yes for the project and nuget something like FSharp.Control.TaskExtras may make sense
We can think it over a bit more but I guess it's OK to go for task/cancellableTask/taskSeq for now.
I'll think about whether it's possible to do an overall revamp for F#8, tailcalls etc too. If we did there would be no harm in a rename then.
@dsyme, see linked issue by @bartelink, #128. It's now a good time as any to discuss the scope of Task
extensions and landing it. It appears that other libraries also yearn for a small, useful extension library.
Not exactly the same as what we discussed here, but this could be a precursor to unifying these efforts at some point.
While writing #77 I realised it would be logical to allow this TaskSeq thing to interoperate with a standard CancellableTask, that is
which would pass the CancellationToken governing the iteration of the TaskSeq to the Cancellable task. This would give robust cancellation token passing through the overall computation.
Under the alternative long term strategy in #77 this would be the same as
because F#
cancellableTask
andasync2
are more or less the same thing.This would mean bringing a CancellableTask into this library from IcedTasks, which may be a good thing.