[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/

[JackYoustra]

I agree that you should evaluate languages in their domains. At the end of the day, Swift is mainly used for systems and iOS apps. In this, it is inadequate, as you can tell by, again, most apps not using the type system to enumerate valid views but instead (because enums and union types more broadly are so clunky to use!) masses of uncoupled types in their views, allowing for many, many implicitly invalid states.