3 ms·

That's right. This is about the language too, if Go doesn't have pattern matching, using sum types (or tagged unions) is a bit gnarly. This is the reason for i

That's right. This is about the language too, if Go doesn't have pattern matching, using sum types (or tagged unions) is a bit gnarly. 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: { user: Option<User>, errors: [Errors] } Instead of more type-correct way of: union result = user | Errors 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.

Zababa 5y ago
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-types.html#union-types 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) The example is a bit weird but shows an important point: bools has 2 values, true and false. Bools has 4 values, A(true), A(false), B(true), B(false). In bools (the union), true and true is always the same. In Bools (the sum/enum), A(true) is not the same as B(true). 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.
- Ciantic 5y ago
  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-language-with-tagged-unions.md https://github.com/Ciantic/thoughts/blob/master/2021/dynamic...

Zababa 5y ago

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-types.html#union-types 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) The example is a bit weird but shows an important point: bools has 2 values, true and false. Bools has 4 values, A(true), A(false), B(true), B(false). In bools (the union), true and true is always the same. In Bools (the sum/enum), A(true) is not the same as B(true). 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.

Ciantic 5y ago
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-language-with-tagged-unions.md https://github.com/Ciantic/thoughts/blob/master/2021/dynamic...