Comment by JackYoustra 8 hours ago
Adding on, its also a bit much to say that Swift has a good level of sugar and reference an enum of all things. Swift's union type story is so poor that, instead of properly modeling state, people to this day still use masses of optional types in their views rather than an enum because actually using swift enums and protocols is so painful.
I think Swift enums are really well designed, but SwiftData doesn't really support them unfortunately and Observable has problems with reactivity and enums (works on iOS not macOS I've found).
So lots of optionals might well be the better path here.
I don't think it's horrible, but I really do wish they would copy TypeScript here.
Let me do this:
const x: String | Int
enum MyEnum {
case string(String)
case int(Int)
}
https://forums.swift.org/t/re-proposal-type-only-unions/7270...
It's worth pointing out that the two examples that you're writing are actually strictly different, and not just "better syntax for the same thing". (This is assuming `String | Int` works as in Python, and the second example works as in Rust.)
To understand the difference, `String | String` is just `String`. It's a union, not a sum type. There's no tag or identifier, so you cannot distinguish whether it's the first or the second string.
If this sounds pedantic, this has pretty important ramifications, especially once generics get involved.
To provide a concrete example, this bit me in a typescript codebase:
type Option<T> = T | undefined
function f<T>(value: T): Option<T> { ... }
let thing: string | undefined = undefined;
let result = f(thing);
The mistake here is in how Option is defined, but it's a footgun you need to be aware of.
Note that union types are not the same thing as sum types, even if they're somewhat similar. https://viralinstruction.com/posts/uniontypes/
> actually using swift enums and protocols is so painful.
In what way? My understanding is they're widely used and encouraged.