Resurrecting this in the light of current discussions & language issues; we have
@rethrowspreventing abstraction ofAsyncSequence(we know statically whether a given sequence throws, but have no way to use that information generically)- a lengthy thread and at least one previous pitch for
reasync - missing stdlib functions for async maps, filters, etc.
- "keyword explosion" where you potentially need 4 versions of any generic function (vanilla,
async,rethrows,async rethrows) - proliferation of
XXXandThrowingXXXorAsyncXXXandAsyncThrowingXXXtypes in the stdlib - a soundness hole where
KeyPaths discard global actor annotations - a general problem for existing libraries like Combine/PromiseKit/RxSwift/... where types need to be generic over global actors to be concurrency-safe
- a need for finer-grained control over which actor async code runs on (every
awaitcurrently punts to the global pool, but many use cases need to inherit the actor from the caller) - "Generic value parameters" in the "maybe" section of the generics manifesto (which inevitably requires us to talk about compile-time evaluation)
- likely more I don't know of or haven't remembered…
All of which (AFAICT, not an expert!) can reasonably be solved by an effect system, and all of which otherwise require individual, custom solutions.
Since the last post to this thread, Rust has also made significant progress toward a scheme they call "keyword generics", for exactly these kinds of reasons. It seems to be less of an "effect system" than some of the research linked from this thread (in particular, "const" functions are an added keyword, rather than a removed effect), but it's still very much in keeping with the spirit of what this thread suggests.