That's definitely a thing. A whole lot of the features added since C++11 have been specifically intended to enable library writers to do very complex things under the hood so they can present powerful yet simple interfaces to users.

Users of coroutine-friendly libraries will have to adopt the async function coloring (co_await, co_yield, co_return, Task<T>).

So saying that coroutines are low-level / not application code is misguided.

Not necessarily. Coroutines are invisible at the ABI level (that is coroutines are just functions).

It's pretty easy to write a library with them (using your own executor) and not reveal their use to the user.

Obviously sharing an executor between application and library is another matter.

> sharing an executor between application and library is another matter.

Especially when there is not one, but several libraries, and the application itself doesn't actually has or uses any executors, now that's a fun challenge.

Good point.

Although doesn't that defeat the purpose of structured concurrency?

i.e. creating tasks that are plumbed to some background thread/executor.

By directly invoking the coroutine, lifetime issues become much easier to avoid.

They serve both to a great extent, as long as code owners are willing to refactor their codebases. The changes do actually make code significantly safer and more pleasant to work with. My favourite ones are the concepts and class template argument deductions.

I believe this is correct. Anecdotally, at FB, there was quite a push to get coroutine-supporting-features into the standard because we had a C++ coroutine library built through non-standard means, which meant that compilers didn't fully support them (leading to a bunch of annoying things for all of those writing code on top of the library).

Now the folly/experimental/coro library can be compiled by anything that claims to support C++20, which is a pretty big win for FB if nothing else.

I can't speak to modern C++ specifically, but in many, many languages, more complex features are often for library writers than application writers.