I'm not trying to complicate or block the review of this proposal. On the contrary, I'm suggesting that we make it more compact and focused, with a clear, well-argued motivation.
The motivation for typed throws is crystal clear:
- For embedded Swift, error composition is essential.
- For regular Swift, it provides a more convenient syntax for composing errors.
typed throws is about error handling — something we write a lot of and deal with daily.
As for the other scenarios:
- "Codable round-trip across mixed-shape JSON" – I very rarely encounter situations where a single JSON field contains values of two different types. In the few cases I have seen,
Either/OneOfsolved the problem just fine. - "SwiftUI's _ConditionalContent" – This type is an implementation detail of SwiftUI. As a library user, I don't have composition problems with it, and I never need to work with
_ConditionalContentdirectly. - "Container extensions: extension Array where Element == Int | String" – Personally, I've never needed this. Every example I've seen in pull requests where developers used
Eitherto store a collection of values of two types turned out to be the result of poorly thought-out design. There may be real-world use cases whereArray<Int | String>is genuinely necessary, but in my experience, such suggestions have come from people with a background in other languages who don't yet have a strong grasp of Swift idioms.
I'm concerned that as soon as this feature is added to Swift, we'll be flooded with ill‑considered APIs that return things like String | Int .
Take Result as an example: it could theoretically be expressed as (T | E: Error) , yet I don't see any benefit in using that syntax – on the contrary, I see strong reasons to stick with Result .
My worry is that introducing union types will encourage a style of coding that feels more like JavaScript than idiomatic Swift, leading to poorly designed code.