[tizio13]

I think you’re conflating 'conciseness' with 'correctness.' The 'clutter' you're describing in Swift like, having to explicitly define an Enum instead of using a vertical bar |, is exactly what makes it more robust than TS for large-scale systems.

In TypeScript a union like string | number is structural and convenient, but it lacks semantic meaning. In Swift, by defining an Enum, you give those states a name and a purpose. This forces you to handle cases exhaustively and intentionally. When you're dealing with a massive codebase 'easy' type bridging is often how you end up back in 'id' or 'any' hell. Swift’s compiler yelling at you is usually it trying to tell you that your logic is too ambiguous to be safely compiled which, in a safety first language, is the compiler doing its job.

[JackYoustra]

I mean there should be _some_ sugar in a language like swift, no? It has sugar in many parts of the language, being able to define a simple type union should not require custom declaration of every forwarding accessor, a protocol, an enum, bridging back and forth between them, etc.

It would be one thing to say that the vertical bar is a shortcut for these more exhaustive constructs (setting aside whether these constructs are actually exhaustive - they're not really for the purposes they're used for in practice), but as it is right now, you have no bar! If it were simple and easy to use you'd have enums dictate the state of every app which, as any app developer knows, is not how its currently done! Swift enums are so hard to use you have just a mess of optionals on view state instead of how it should formally be done, where almost every non-trivial view has a single state that's an enum of all possible configurations of valid states.

Indeed, if you put in a ton of effort to try and go down this route defining views "properly" with something like Swift TCA, you're not going to be able to get there even if you break up your app into 40 different targets because incremental recompilation will take a few minutes for something as simple as a color change.

[tizio13]

I think we are talking past each other because we are optimizing for different domains.

You seem to want the ergonomics of a structural type system like TypeScript where data shapes are fluid but explicitly unsound [1]. In that paradigm requiring a named Enum feels like clutter because it forces you to pause and define a relationship that you just want to infer.

But Swift is a nominal static language designed for long lived binary compiled applications [2]. In this context that clutter is actually architectural definition. The friction is a feature not a bug because it discourages passing around anonymous bags of data and forces you to model what that data represents.

Swift actually has plenty of sugar but it puts it in places that don't compromise static analysis. It is designed to be expressive without being loose.

Complaining that Swift doesn't handle anonymous unions as easily as TS is like complaining that a tank handles worse than an F1 car. It is true but the tank is built to survive a direct hit whereas the F1 car trades that safety for raw speed.

[1] https://www.typescriptlang.org/docs/handbook/type-compatibil... [2] https://www.swift.org/about/

[llmslave2]

This is just cope. Swift's compiler doesn't choke because your logic is too ambiguous, it chokes because it's simply too slow at inferring types in certain cases, including a very common case where you write a normal Swift UI view. There is nothing ambiguous about that.

Secondly, I'm not sure why you think the mountains of boilerplate to replace | leads to semantic meaning. The type identifier itself is sufficient.

[lmm]

| is a massive footgun because it's usually exclusive in practice and occasionally silently inclusive. Having it in a language is a mistake, even if it superficially seems to make things easier, just like e.g. null.