I just removed the use of
detachedhere […] it doesn't really have any affect.
I thought detached guaranteed a global executor (though I'm not finding this in the documentation now). Or are you saying that using a global executor is irrelevant in this case since the only operation being performed is already isolated to itself (and will therefore immediately switch again)?
…there is yet another proposal pending that could influence this further
Also very much looking forward to that implementation. Implicit isolation inheritance has been one of the rougher topics to follow, and I've only recently even come to be aware of it. (Anecdote: I had a Task {} that I expected would inherit the main actor and it didn't, but if it did I would have had a deadlock.)
With that in place, you could remove only isolation. […] I'm not sure this is actually useful for async functions, but I think it could be for synchronous ones.
Could you elaborate on what you mean for synchronous functions here?
Now, in my opinion, using
Taskhere is the best option. First, users of concurrency have to understand it regardless.
I actually think that Task is so simple to use that learners can easily avoid understanding it. I certainly did (see prior anecdote). But that's poor justification for giving them something else that's just as simple to use, I know.
Finally, the concurrency system is already complex. Introducing a new keyword here would need a lot of justification.
For sure. And I expected the history (if there was any) would boil down to this. I think if there was some way that the keyword/feature could be implemented to help learners adhere to (or at least be aware of) strict concurrency sooner, that could make it more appealing. But I have no ideas there right now (since my intent was to avoid it).