Sure, you can use it like that, but it's not considered good practice. I think the context missing here is that most modern C# applications are going to be async all of the way down. The entry point can be async. Background service abstractions are async. Your API endpoints in ASP.NET Core are typically async as you're going to be calling some async I/O anyways (database queries, HTTP clients). There's no benefit to writing something in the old callback model when the rest of your code is async/await anyways.

> So does C# not have map yet?

Have you heard the word of our lord and savior, LINQ?

Of course.

In the article linked above: > ContinueWith allocates more than using async await

Does LINQ not carry a similar overhead?

You said, "So does C# not have map yet?", knowing full well that it did, and are now moving the goalposts.

I'll rephrase.

Does LINQ's map come with a plethora of problems like I'm told Task's map does above?

Should you avoid mapping because 'it's the old callback model' which doesn't belong in modern code?

Is map fit for purpose, or has it been disavowed?

Mapping (spelt "Select" quite often in LINQ) is entirely normal and promoted going forwards. It can optimize extremely well for simple cases. By default it is not parallel and compiles to an underlying for loop.

Or you can use it with Tasks. https://itnext.io/fun-csharp-doing-linq-to-tasks-because-tas...

(caution: contains the M word)

More from Microsoft: https://devblogs.microsoft.com/pfxteam/tasks-monads-and-linq... ; referencing Lippert https://ericlippert.com/category/monads/

ContinueWith is not a broken "map". What people usually want is Select. https://learn.microsoft.com/en-us/dotnet/csharp/linq/standar...