4 ms·

1.18 shaping up to be a great release! My only remaining desired features: * sum types (would be really nice) * some equivalent of ? in Rust (can live without

by qaq 5y ago

1.18 shaping up to be a great release! My only remaining desired features: * sum types (would be really nice) * some equivalent of ? in Rust (can live without but would be nice) After playing with a ton of languages have settled on Go for most projects.

masklinn 5y ago
> * sum types (would be really nice) That seems really difficult to retrofit, and to not really fit the language either. I've been thinking something like sealed interfaces would fit better: Go already has fallible downcasts (and RTTI which takes the role of discriminant), and type switches can play the role of your `case` statement: func do[T any](i option[T]) { switch v := i.(type) { case T: fmt.Printf("Got a %v", v) case nothing: // or `nil` could be a (pseudo)-type fmt.Printf("was empty!") // no default necessary because the check is complete } } The only pieces missing are a way to "seal in" a set of types, and add completeness check to type switches for those.
- Zababa 5y ago
  This with exhaustiveness checking and a way to apply that to errors would be great.
- nicoburns 5y ago
  Why would it be difficult to retrofit? It’s just a new set of types. Is it that existing APIs wouldn’t be using them?
  - masklinn 5y ago
    > Why would it be difficult to retrofit? It’s just a new set of types. Is it that existing APIs wouldn’t be using them? It's a brand new kind which wouldn't necessarily work the way existing types do, and it's a whole lot of extra syntax. Plus previous retrofits have not exactly panned out great, C++ and Java's native "type safe enumerations" are pretty crummy as they're closer to enumerated sets of constants than sum types. Sealed classes/interfaces/traits/… fit well in the machinery and aesthetics of RTTI-heavy products-types-based languages and slot nicely into the "niche" of sum types.
  - tialaramex 5y ago
    One problem beyond the technical "How" is that culturally Go didn't have Sum types, so there are existing APIs where, if a Sum type was possible that's what you'd do, but it wasn't, so they didn't. This isn't so different from the problem Generics introduce (why isn't this API generic, oh, it pre-dates that feature). And it might similarly be worth it for Sum types, but it's certainly an extra consideration. On the technical side, Sum types kinda suck unless you have niches. If your Optional sum type is always actually bigger than the Some type it is wrapping then why even bother? So then you're also adding promises about niches in your implementation.
- jerf 5y ago
  "I've been thinking something like sealed interfaces would fit better:" You can have "sealed interfaces" today; you put an unexportable method name in the interface. Then no legal external implementation can exist. (Not even if someone "guesses" the method name; the compiler will not consider them to have the same name.) What you still don't get is completeness checking even so. In theory a linter could do it even without compiler support, I don't know if one exists. You can use this in Go today to get, oh, say, 1/3rd of the feature of 'sum types' today. But you don't get much of the "sum types" bang for that 1/3rd of the buck. Basically, you can use them, and you don't need to do the fully manual type of thing you need to do in C with unions and tags, you can lean on the interfaces carrying type information around to handle that, but you get no additional compiler or syntax support, nor any sort of pattern matching on them.
  - tjalfi 5y ago
    go-sumtype[0] has completeness checking for sealed interfaces. [0] https://github.com/BurntSushi/go-sumtype https://github.com/BurntSushi/go-sumtype
  - masklinn 5y ago
    I'm not quite sure what you're trying to express, because all I'm reading in your comment is "you can get none of the benefits today with no changes", which doesn't seem like a very interesting statement? I don't understand why you insist on quoting "sum types" when literally just mentioning them.
    - jerf 5y ago
      "I'm not quite sure what you're trying to express, because all I'm reading in your comment is "you can get none of the benefits today with no changes", which doesn't seem like a very interesting statement?" You can get some of the benefits today with no changes to Go. You can create a package-level sealed interface: http://www.jerf.org/iri/post/2917 http://www.jerf.org/iri/post/2917 "I don't understand why you insist on quoting "sum types" when literally just mentioning them." Because they aren't literally sum types, in that they have every feature that everyone associates with sum types, and people are very sensitive about that. So I don't need anyone replying with "but those aren't really sum types", either for my previous HN post or the blog post I just linked. Yes, I know they don't check every check box. But they do check a few of them, and, arguably the most essential one which is that you can indeed implement type ASumType interface { unexportedMethod() } func SomeFunction(thing ASumType) { ... } and ASumType can be any of several types, closed and limited at compile time to only be things defined in this particular package in a way that can not be extended by any other external package.

by qaq 5y ago

masklinn 5y ago

> * sum types (would be really nice) That seems really difficult to retrofit, and to not really fit the language either. I've been thinking something like sealed interfaces would fit better: Go already has fallible downcasts (and RTTI which takes the role of discriminant), and type switches can play the role of your `case` statement: func do[T any](i option[T]) { switch v := i.(type) { case T: fmt.Printf("Got a %v", v) case nothing: // or `nil` could be a (pseudo)-type fmt.Printf("was empty!") // no default necessary because the check is complete } } The only pieces missing are a way to "seal in" a set of types, and add completeness check to type switches for those.

Zababa 5y ago
This with exhaustiveness checking and a way to apply that to errors would be great.
nicoburns 5y ago
Why would it be difficult to retrofit? It’s just a new set of types. Is it that existing APIs wouldn’t be using them?
- masklinn 5y ago
  > Why would it be difficult to retrofit? It’s just a new set of types. Is it that existing APIs wouldn’t be using them? It's a brand new kind which wouldn't necessarily work the way existing types do, and it's a whole lot of extra syntax. Plus previous retrofits have not exactly panned out great, C++ and Java's native "type safe enumerations" are pretty crummy as they're closer to enumerated sets of constants than sum types. Sealed classes/interfaces/traits/… fit well in the machinery and aesthetics of RTTI-heavy products-types-based languages and slot nicely into the "niche" of sum types.
- tialaramex 5y ago
  One problem beyond the technical "How" is that culturally Go didn't have Sum types, so there are existing APIs where, if a Sum type was possible that's what you'd do, but it wasn't, so they didn't. This isn't so different from the problem Generics introduce (why isn't this API generic, oh, it pre-dates that feature). And it might similarly be worth it for Sum types, but it's certainly an extra consideration. On the technical side, Sum types kinda suck unless you have niches. If your Optional sum type is always actually bigger than the Some type it is wrapping then why even bother? So then you're also adding promises about niches in your implementation.
jerf 5y ago
"I've been thinking something like sealed interfaces would fit better:" You can have "sealed interfaces" today; you put an unexportable method name in the interface. Then no legal external implementation can exist. (Not even if someone "guesses" the method name; the compiler will not consider them to have the same name.) What you still don't get is completeness checking even so. In theory a linter could do it even without compiler support, I don't know if one exists. You can use this in Go today to get, oh, say, 1/3rd of the feature of 'sum types' today. But you don't get much of the "sum types" bang for that 1/3rd of the buck. Basically, you can use them, and you don't need to do the fully manual type of thing you need to do in C with unions and tags, you can lean on the interfaces carrying type information around to handle that, but you get no additional compiler or syntax support, nor any sort of pattern matching on them.
- tjalfi 5y ago
  go-sumtype[0] has completeness checking for sealed interfaces. [0] https://github.com/BurntSushi/go-sumtype https://github.com/BurntSushi/go-sumtype
- masklinn 5y ago
  I'm not quite sure what you're trying to express, because all I'm reading in your comment is "you can get none of the benefits today with no changes", which doesn't seem like a very interesting statement? I don't understand why you insist on quoting "sum types" when literally just mentioning them.
  - jerf 5y ago
    "I'm not quite sure what you're trying to express, because all I'm reading in your comment is "you can get none of the benefits today with no changes", which doesn't seem like a very interesting statement?" You can get some of the benefits today with no changes to Go. You can create a package-level sealed interface: http://www.jerf.org/iri/post/2917 http://www.jerf.org/iri/post/2917 "I don't understand why you insist on quoting "sum types" when literally just mentioning them." Because they aren't literally sum types, in that they have every feature that everyone associates with sum types, and people are very sensitive about that. So I don't need anyone replying with "but those aren't really sum types", either for my previous HN post or the blog post I just linked. Yes, I know they don't check every check box. But they do check a few of them, and, arguably the most essential one which is that you can indeed implement type ASumType interface { unexportedMethod() } func SomeFunction(thing ASumType) { ... } and ASumType can be any of several types, closed and limited at compile time to only be things defined in this particular package in a way that can not be extended by any other external package.