TaskEx: ignore

[bartelink]

Replaces #128. TaskEx top level issue: #139

Async.Ignore has always been ugly and undiscoverable. While I tend to make ignoring explicit by using let! _ = <async stuff I want to ignore result of>, it's commonly the last expression in a function, and having to do let! _ = <thing I'm wrapping> in () is too much.

It is proposed that the module associated with any given builder should by convention have an ignore function that correctly observes completion of the work, dropping the result, but propagating exceptions, if any

Current proposed APIs that are not currently in FSharp.Core (will be updated inline based on discussion below):

module Async =
    let inline ignore (a : Async<'t>) = Async.Ignore
module Task =
    let inline ignore (t : Task<'t>) = ...
module ValueTask =
    let inline ignore (t : ValueTask<'t>) = ...

NOTES:

1. Currently, TaskSeq (and other libs such as IcedTasks contain various bespoke implementations
2. While this could live in a TaskEx lib, it could be argued that FSharp.Core is the obvious home for them. (However that would raise the issue of whether they need to go into the 6.x release line in order to align with minimal dependencies for various common libraries)

[github-actions]

🤖 This is an automated response from Repo Assist.

Good news — the ignore functions this issue proposes are already implemented in the library! They live in Utils.fs and are exported via Utils.fsi:

module ValueTask =
    /// Convert a ValueTask<'T> into a non-generic ValueTask, ignoring the result
    val inline ignore: valueTask: ValueTask<'T> -> ValueTask

module Task =
    /// Convert a Task<'T> into a non-generic Task, ignoring the result
    val inline ignore: task: Task<'T> -> Task

module Async =
    /// Convert an Async<'T> into an Async(unit), ignoring the result
    val inline ignore: async: Async<'T> -> Async(unit)

The ValueTask.ignore implementation follows Stephen Toub's advice to avoid unnecessary task allocation when the value task has already completed successfully.

If you feel these should be noted more prominently in the README or docs, that could be a useful follow-up. Otherwise this issue might be ready to close.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f

[bartelink]

Good news — the ignore functions this issue proposes are already implemented in the library! They live in Utils.fs and are exported via Utils.fsi

I guess these nudges are slowly shuffling me toward getting AwaitTaskCorrect into FSharp.Core

@T-Gro (or anyone else) Do you have a stance on getting these sorts of helpers into core? (ideally the overall picture of #139 is taken into account in any answer)

[T-Gro]

The suggestion is approved in principle, fsharp/fslang-suggestions#840 (comment) .

I do not like the name and usage, but I do agree with what it does internally.
Let me refresh the discussion and wait for proposals.

[bartelink]

@T-Gro thanks for the response

I'm well aware of the AwaitTaskCorrect suggestion and it's state - it's my pet hate but it's not like I couldn't fix it; I just haven't gotten around to it

I was asking about your/a stance on things like providing a Task.ignore and ancillary functions as mapped out in #139.

Summarizing the relevant points:

• this lib and many others have these sorts of helpers
• apps should not really be having to take dependencies on libs like this (esp if they don't use IAsyncEnumerable) to cover basic needs (or doing stuff like let! _ = taskThing in () that should really be something like do! taskThing |> Task.ignore).
• Obviously we need to be sane about the amount of one-liners admitted into FSharp.Core

For some the answer is FsToolkit and/or IcedTasks.

My workaround hack is (as in the case in this library) to sprinkle them around in Internal modules like this: https://github.com/jet/propulsion/blob/master/src/Propulsion/Internal.fs#L160

The bottom line is that the helpers that live in FSharp.Control.TaskSeq nuget are pretty close to what I'd want/recommend, but they dilute the focus of this library, and don't solve the problem that we have N copies of these throughout the ecosystem that don't provide any useful variation - they just mean newcomers spend ages working out where all the little incidental helpers come from and/or why they exist.

Do you see a potential for any of these helpers to go live in FSharp.Core ? Does having a FSharp.TaskEx make more sense from your perspective (I'm not convinced personally as such a thing has huge potential to become a junk drawer unless it has a very strong maintainer group, along with general diamond dependency structure concerns)?

The current state of play is bad news for day to day real world F# consumption in writing/maintaining apps unless you:

• pull in Equinox+Propulsion, TaskSeq and/or FsToolkit (FSharpPlus and many others probably provide similar - these are just ones I've had lots of day to day experience with)
• are an experienced/senior dev that's bootstrapped on lots of nuances of Async/Task interop and tradeoffs that can reliably work out the one liner shims appropriate/necessary in the context of a given application suite.

[T-Gro]

Let me collect some data on the redefinitions and usage (under multiple names, possibly), to have a better understanding of what is needed by most.

Those can live in FSharp.Core, we should just better understand the real usage for each (i.e. not hide less significant API additons under the same umbrella).

I will transitively process all issues linked from your comment and see what I find at least in public GH repos.

[T-Gro]

Proposed F# Task/Async API Additions — Verified GitHub Usage

Date: 2026-03-18
Sources: TaskSeq#139, #140, #141, #142, #143, fslang-suggestions#840, jet/propulsion Internal.fs, IcedTasks AsyncEx.fs, FsToolkit Async.fs+Task.fs
Methodology: 7 subagents opened actual source code on GitHub, verified declarations vs usages, deduplicated forks, classified each hit

Results

#	Proposed API	Signature	Hits	Decl Repos	Use Repos	TaskSeq	IcedTasks	FsToolkit	F#+	Source
1	Async.map	('T→'U) → Async<'T> → Async<'U>	720	25	25	✅	uses	✅	✅	Utils
2	Async.parallelLimit/Throttled	int → Async<'T> seq → Async<'T[]>	113	17	26	❌	❌	inline	❌	#143
3	Async.bind	('T→Async<'U>) → Async<'T> → Async<'U>	432	13	24	✅	❌	✅	❌	Utils
4	Task.ignore	Task<'T> → Task / Task<unit>	140	8	22	✅	❌	✅	✅†	#140
5	Task.map	('T→'U) → Task<'T> → Task<'U>	330	11	17	✅	❌	✅	✅	Utils
6	Task.fromResult/singleton	'T → Task<'T>	148	7	21	✅	❌	✅	❌	Utils
7	Async.ofTask (AwaitTaskCorrect)	Task<'T> → Async<'T>	90	10	14	✅‡	✅	❌	✅	#141/#840
8	Task.bind	('T→Task<'U>) → Task<'T> → Task<'U>	83	10	11	✅	❌	✅	✅	Utils
9	Async.singleton	'T → Async<'T>	88	5	16	❌	❌	✅	❌	FsToolkit
10	Task.ofAsync/Async.toTask	Async<'T> → Task<'T>	11	8	2	✅	❌	❌	❌	Utils
11	Task.ofUnitTask/ofUnit	Task → Task<unit>	15	4	5	✅	❌	✅	❌	Utils
12	Task.catch	Task<'T> → Task<Choice<'T,exn>>	14	3	5	❌	❌	✅	❌	FsToolkit
13	ValueTask.ignore	ValueTask<'T> → ValueTask	6	2	3	✅	❌	❌	✅†	#140
14	Task.toAsync	Task<'T> → Async<'T>	6	2	2	✅	❌	❌	❌	#141
15	Async.call	(CT→Task<'T>) → Async<'T>	10	2	2	❌	❌	❌	❌	Propulsion
16	Async.ofUnitTask	Task → Async<unit>	4	1	2	✅	✅	❌	❌	#141
17	Async.startImmediateAsTask	CT → Async<'T> → Task<'T>	17	2	1	❌	❌	❌	❌	#142
18	Async.ignore (lowercase)	Async<'T> → Async<unit>	0	0	0	✅	❌	❌	❌	#140

Legend

Symbol	Meaning
Hits	GitHub code search file matches across ALL of GitHub (forks excluded)
Decl Repos	Unique non-fork repos that define the helper (verified by reading source)
Use Repos	Unique non-fork repos that call it (consuming, not defining)
✅‡	TaskSeq wraps Async.AwaitTask without AggregateException fix
✅†	Present but different semantics (F#+: Task.ignore = Task→Task<unit>; ValueTask.ignore = ValueTask→ValueTask<unit>)
inline	Uses Async.Parallel(…, maxDegreeOfParallelism=N) inline, no named helper
uses	IcedTasks calls Async.map internally but does not declare it

Library Coverage Summary

Library	Coverage	Notes
TaskSeq	15/18	Most comprehensive. Async.ofTask wraps Async.AwaitTask without AggregateException fix. Missing: parallelLimit, Async.singleton, Task.catch
FsToolkit	9/18	Dominant NuGet source for downstream usage. Missing: AwaitTaskCorrect, conversions, parallelLimit
FSharpPlus	6/18	Has AwaitTaskCorrect (as Async.Await). Task.ignore/ValueTask.ignore have inverted signatures
IcedTasks	2/18	Focused on CEs (asyncEx, cancellableTask), not utility module functions

Notable Findings

• Async.map (25 declaring repos) — the F# compiler itself (dotnet/fsharp) declares and uses this in lib.fs. The single most duplicated helper in the ecosystem.
• Async.parallelLimit (17 declaring repos) — two implementation patterns observed: simple Async.Parallel wrapper vs SemaphoreSlim-based throttling. Names vary: parallelLimit, parallelThrottled, ParallelWithThrottle.
• AwaitTaskCorrect (10 declaring repos) — approved-in-principle since 2022 but unimplemented. The canonical fssnip is still copy-pasted. 6 additional repos wrap Async.AwaitTask under the Async.ofTask name without the AggregateException fix.
• Task.ignore — two semantic variants in the wild: Task<'T> → Task<unit> (FsToolkit, most common) vs Task<'T> → Task (simple upcast, less common).
• Async.ignore (lowercase) has zero independent implementations outside TaskSeq. Nobody wraps Async.Ignore in lowercase. Drop from proposal.
• Async.startImmediateAsTask pipeable wrapper — only 2 repos: jet/propulsion and ionide/FsAutoComplete.
• No single library covers all 18 APIs. TaskSeq comes closest (15/18) but its Async.ofTask lacks the AggregateException fix.

Top Declaring Repos

Repo	APIs declared
fsprojects/FSharp.Control.TaskSeq	Task.ignore, Task.map, Task.bind, Task.fromResult, Task.ofAsync, Task.toAsync, Task.ofUnitTask, ValueTask.ignore, Async.ofTask‡, Async.ofUnitTask, Async.toTask, Async.ignore, Async.map, Async.bind
jet/propulsion	Task.ignore, Async.ofTask✅, Async.ofUnitTask, Async.call, Async.startImmediateAsTask, Async.executeAsTask, Async.parallelLimit, Task.parallelLimit, Task.catch, Task.ofUnitTask
demystifyfp/FsToolkit.ErrorHandling	Task.map, Task.bind, Task.ignore, Task.singleton, Task.ofUnit, Task.catch, Async.map, Async.bind, Async.singleton
fsprojects/FSharpPlus	Task.map, Task.bind, Task.ignore†, Async.map, Async.ofTask (as Async.Await), ValueTask.ignore†

[bartelink]

Hm; general thoughts re the above:

• (unsurprisingly) plenty hallucinations in the summary, but (also not unsurprisingly) it's not useless
• I'd exclude .map. Just because it's common doesn't make it a good thing to have in the box IMO
• Task.ofAsync and some related ones are questionable as it makes it too easy not to flow cancellation etc
• the ofUnit* specialization to cover Task vs Task<'T> feels icky so should be deferred/handled separately
• Async.ignore (with that casing) is not something to pooh-pooh - the fact that prod code uses Async.Ignore, Async.Catch, Async.StartAsTask/StartImmediateAsTask (with and without threading cancellation, with or without actually meaning StartImmediateAsTask but using StartAsTask as it sounded like the right thing) was understandable 10 years ago but the myriad inconsistencies and pitfalls are why all these helpers have spawned and/or continue to proliferate in various ways with useless variation clouding things.

Before this can be converted into something for broader discussion, some high level stances would help:

• a stance on whether we err on the side of keeping warts in the interest of avoiding confusing duplication (e.g. add a Task.ignore but trust people will discover/understand that Async.Ignore is cased that way for reasons and that's just the way it is)
• a stance on whether we put things with pitfalls into the mix or not (Task.ofAsync without some way to surface that you probably want to flow CT in most cases)
• a stance on long excluded things like Async.map (I think that's one to keep off the table; its definitely highly improbable that it's not a deliberate omission that's had eons of airtime)

The elephant in the room re all of the above is that fleshing out an Async.Await that does not egregiously introduce AggregateExceptions probably will answer a lot of the above indirectly as a side-effect of getting it done.

[T-Gro]

1. Avoid confusing duplication. If current state is really bad, I would rather do Obsolete + better thing, but has to be justified. Mere casing does not meet the bar I am afraid.
2. Correctness by default, make pitfalls explicit (e.g. via CancellationToken.None). Humans as well as agents will try to take shortcuts for sure, but at least it makes them visible.
3. If something is difficult to get right/has many tradeoffs, but people still reimplement their own versions - we are not winning anything by excluding it. If it is needed and used a lot more then the others, we should ship a sensible default for it IMO.