No, it’s explicitly not what I’m after. Sometimes just logging to stderr and not crashing is the desired behavior, but you still want to be sure that the task is run to completion or cancelled.
Semantics like this are closer to those people already expect with the concurrent.futures apis, while still maintaining structured concurrency benefits of no task outliving it’s intended scope (in this case, the application lifetime), and errors being handled prompty, it’s just in this case, a convienient api for log and move on at failure.
This other thread is more relevant to possible designs for that