4 ms·

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 ass

by Mond_ 8mo ago

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.

ekimekim 8mo ago
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); Now imagine the definition of Option is in some library or other file and you don't realize how it works. You are thinking of the Option as its own structure and expect f to return Option<string | undefined>. But Option<string | undefined> = string | undefined | undefined = string | undefined = Option<string>. The mistake here is in how Option is defined, but it's a footgun you need to be aware of.
- int_19h 8mo ago
  The mistake here is that you assume that Option is a struct. For TypeScript, this is an idiomatic definition of something that is optional though.
JackYoustra 8mo ago
Hijacking your comment because this is a common point that's made on the superiority of Swift syntax against the union syntax. At least with |, you're attempting to model the state space. You're saying "this is one of these things." You might get the exhaustiveness wrong, but you're in the right ballpark. As it's normally done right now, the Swift developer with five optional properties is modeling state as "maybe this, maybe that, maybe both, who knows, good luck." which is just worse than a bar. If you need to discriminate explicitly, add a `__kind` field!
nielsbot 8mo ago
I guess I just want to be able to do something like this in Swift: let x: String | Int switch x { case let value as String: // handle String value here case let value as Int: // handle Int value here } There's one more thing about TypeScript-style union types: string literals. I think it's great to be able to do type Options = "option_1" | "option_2" ... "option_n" And subsequently I could use let t: Options switch t { case "option_1": // handle `"option_1"` case here ... case "option_n": // handle `"option_n"` case here } I think this is more programmer friendly than requiring an out-of-line definition of a new `enum`. Sometimes you just want to write some code, you know?
int_19h 8mo ago
So long as you have structurally typed structs (as TypeScript does), you can do stuff like {foo: string} | {bar: string} to the same effect as type constructors if and when you actually need it. At the same time, how often do you really need (Just (Just (Just ...)))?

by Mond_ 8mo ago

ekimekim 8mo ago

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); Now imagine the definition of Option is in some library or other file and you don't realize how it works. You are thinking of the Option as its own structure and expect f to return Option<string | undefined>. But Option<string | undefined> = string | undefined | undefined = string | undefined = Option<string>. The mistake here is in how Option is defined, but it's a footgun you need to be aware of.

int_19h 8mo ago
The mistake here is that you assume that Option is a struct. For TypeScript, this is an idiomatic definition of something that is optional though.

JackYoustra 8mo ago

Hijacking your comment because this is a common point that's made on the superiority of Swift syntax against the union syntax. At least with |, you're attempting to model the state space. You're saying "this is one of these things." You might get the exhaustiveness wrong, but you're in the right ballpark. As it's normally done right now, the Swift developer with five optional properties is modeling state as "maybe this, maybe that, maybe both, who knows, good luck." which is just worse than a bar. If you need to discriminate explicitly, add a `__kind` field!

nielsbot 8mo ago

I guess I just want to be able to do something like this in Swift: let x: String | Int switch x { case let value as String: // handle String value here case let value as Int: // handle Int value here } There's one more thing about TypeScript-style union types: string literals. I think it's great to be able to do type Options = "option_1" | "option_2" ... "option_n" And subsequently I could use let t: Options switch t { case "option_1": // handle `"option_1"` case here ... case "option_n": // handle `"option_n"` case here } I think this is more programmer friendly than requiring an out-of-line definition of a new `enum`. Sometimes you just want to write some code, you know?

int_19h 8mo ago

So long as you have structurally typed structs (as TypeScript does), you can do stuff like {foo: string} | {bar: string} to the same effect as type constructors if and when you actually need it. At the same time, how often do you really need (Just (Just (Just ...)))?