[Pitch] API to run a closure off of an actor (on the concurrent executor)

[FranzBusch]

I agree with @ktoso overall feedback that I don't think the pitched method pulls its weight to be included in the standard library. So far I personally haven't come across the need to write such a method but I understand that with SE-0461 this might change but I would suggest to wait a bit how that change plays out before we add such a method to the standard library. It is in the end a pretty trivial method that doesn't require any new language features.

@ktoso

The use-case I understand though, however I think this should be expressed as an executor "requirement" versus the "executor preference" which we have today already.

This effectively is a block of code that we require to execute on some specific (task) executor, in this case the global one but it could be any task executor;

@hborla

I think this is a good idea and we should totally do this. A withTaskExecutor API will also help with the feedback that SE-0461 makes task executor preferences less useful, because withTaskExecutor gives you a way to guarantee you're calling an async function that runs on the caller's actor on the specified executor, even if you're making the call from an actor with a custom executor.

I don't see how this is sound. If an actor specifies a custom executor and a method inherits the isolation of the caller's actor then that method must execute on the actor's custom executor. Otherwise invariants upheld by the custom executor may be broken by accessing isolated state from the wrong executor. It is a pretty common use-case to back an actor's custom executor by a single thread to guarantee that all isolated state is local to that thread.

Now I also don't think we need to differentiate between preferred and required task executors. In my opinion, there really can only be preferred task executors since custom actor executors always need to take priority over them. However, we can make the current withTaskExecutorPreference APIs more useful by providing a variant that takes a @execution(concurrent) closure instead. This way the closure won't inherit the isolation of the surrounding context right away and will eagerly hop off the actor. The tricky bit is how we would spell such an API without overloading withTaskExecutorPreference.