[Pitch N+1] Typed Throws

Protocol conformance and refinements

Protocols should have the possibility to conform and refine other protocols containing throwing functions based on the subtype relationship of their functions. This way it would be possible to throw a more specialised error or don't throw an error at all.

All this discussion of parity between Result, Task, and typed throws, alongside the minor source-breaking changes we're willing to incur in Swift 6 to deliver on the overall feature (all of which I vehemently agree with), makes me sad that it's likely not in scope here to have the same subtyping niceties when it comes to protocol requirements and that other error handling mechanism we have: optional return values.

My pet use case has the same rationale as expressed here: if I have an infinite sequence, it would be more expressive if I could implement the iterator requirement as next() -> Element instead of next() -> Element?, but alas this is not regarded as kosher in present-day Swift. It does seem of-a-kind to what we're dealing with here, though, since returning an optional Element? is notionally isomorphic to throws(Void) -> Element, for which this proposal would accommodate subtyping the relationship...

5 Likes