Status check: Typed throws

[tcldr]

@John_McCall

So it's really down to who's capable of carrying that work out and how that should be prioritized vs other work they could be doing.

IIUC the decision on this does seem to be backing up progress on other work.

The particular one I have in my mind is the definition of Primary Associated Types for AsyncSequence. The original pitch document explicitly marks out a decision on typed throws as preventing further progress:

AsyncSequence and AsyncIteratorProtocol logically ought to have Element as their primary associated type. However, we have ongoing evolution discussions about adding a precise error type to these. If those discussions bear fruit, then the new Error associated type would need to also be marked primary. To prevent source compatibility complications, adding primary associated types to these two protocols is deferred to a future proposal.

If – as it would seem – adding typed throws seems likely, then perhaps adding a Failure associated type to AsyncSequence/AsyncIteratorProtocol would permit some forward progress. For example, it seems to me that this change would finally allow AsyncSequence to be useful as an opaque type by facilitating a route for the compiler to determine whether or not a rethrowing asynchronous sequence definitively throws or not from the value of its generic Failure parameter.