Re:A rough proposal for sum types in Go (2018)
by Zababa on Tuesday November 16, 2021 @04:58AM
(#29238784)
The problem here is not the absence of pattern matching, it is the absence of the "tag" part of tagged unions. Union types like the one you presented (union result = user | Errors) are different from sum types, as they don't have a tag. Without the tag you need a way to know the type of the result at runtime. For example in TypeScript, you can use a type assertion and control-flow analysis to emulate sum types and pattern matching: https://www.typescriptlang.org/docs/handbook/2/everyday-type....
While sum types and union types are close, they are not exactly the same. Let's take an example:
union bools = bool | bool
enum Bools = A(bool) | B(bool)
I don't know enough about type theory to know if union types have a relationship with sum types. They can be used the same for most cases but they have differences around the edges.
Re:A rough proposal for sum types in Go (2018)
by Ciantic on Tuesday November 16, 2021 @05:20AM
(#29238911)
Yeah I was a bit sloppy when I wrote my answer. With GraphQL you can mimick tagged unions by giving each branch an object type.
I actully wrote just few days ago about how cool it would be if TypeScript-like language too had tags:
https://github.com/Ciantic/thoughts/blob/master/2021/dynamic...
This is the reason for instance in C# Hot Chocolate GraphQL library the newly proposed return type for fallible mutations is, e.g. for hypothethtical register function:
Instead of more type-correct way of: Precisely because using unions is gnarly in JS who are the main consumers of the API.Similarly if GO doesn't have a way to pattern match, the actually using sum types is very annoying and this "foo*, error" can be seen as more convinient.