I read and avoided talking because I haven't carefully read your pitch, but here I want to voice a concern.
I agree that SE-0338 has provided a convenient way to address a need, which is to "write a function that does not block the main thread no matter what". It is natural to look for new conveniences.
But to me, @concurrent synchronous functions is a bad idea that looks like a good one.
When writing a CPU-intensive function, developers will always balance between marking it @concurrent or not.
Library developers will not declare them as @concurrent. For example: JSONDecoder.decode. Even though most GUI applications avoid decoding server payload on the main thread, the actual scheduling of this method should remain the client's concern. Nobody here would start questioning the declaration of JSONDecoder.decode.
Application developers will declare CPU-intensive methods as @concurrent, because it is so handy. It solves the problem at hand.
But now it becomes impossible to call this function synchronously, even outside of the main thread. For no good reason.
Tests that call this function must be made async, for no good reason.
When the developer decides to wrap the function into a library, there are only two bad options:
- Keeping
@concurrent. Now this function is an outsider in the landscape of libraries (which do not use@concurrenteven for CPU-intensive functions, because the actual scheduling of these methods should remain the client's concern. Being an outsider is not good. - Removing
@concurrent. Now all call sites have to be refactored. This is not good.
I do not see any good outcomes from @concurrent synchronous functions.