3 ms·

Okay, it is some reasonable if the operator is viewed as a behavior operator. But it is not, it is a type set operator.

by tapirl 2y ago

jerf 2y ago
And the real point I'm making here is that "the type set operator" is not "a sum type". A sum type with, say, three branches is either the first, or the second, or the third, and to do anything with any of them, you have to deconstruct it, at which point you have full access to the deconstructed branch you are in. The | operator in a Go generic is more a declaration of "I want to operate on all of these at once", so, you can put multiple numeric types into it because you can do a + or a - on any of them, but while the syntax permits you to put three struct types into it, and it'll compile, it does not produce a "sum type". Instead you get "I can operate on this value with the intersection of all the operations they can do", which is more or less "nothing". ("Methods" aren't "operations"; methods you can already declare in interfaces.) Some people particularly fool themselves because you can still take that type, cast it into an "any", and then type switch on it, but it turns out you can always do that, the | operator isn't helping you in any particular way, and if you want to have a closed set of types, a closed interface is a much better way to do it, on many levels. It also doesn't currently do anything else people may want it to do, like, accept three structs that each have a field "A" of type "int" and allow the generic to operate on at least that field because they all share it. There's a proposal I've seen to enable that, as the current syntax would at least support that, but I don't know what its status is.
- tapirl 2y ago
  There is actually a proposal to make type constraints act as sum types: https://github.com/golang/go/issues/57644 https://github.com/golang/go/issues/57644 But I doubt sum types will be supported perfectly in Go. The current poor-men's sum type mechanism (type-switch syntax) might be still useful in future Go custom generic age.
  - jerf 2y ago
    I've pondered the utility of just proposing some syntax sugar around the current methodology, mostly for the reason of getting it rejected for being an unnecessary redundancy to what we already have, so we can point at the rejection.

Okay, it is some reasonable if the operator is viewed as a behavior operator. But it is not, it is a type set operator.

by tapirl 2y ago

Okay, it is some reasonable if the operator is viewed as a behavior operator. But it is not, it is a type set operator.

jerf 2y ago

And the real point I'm making here is that "the type set operator" is not "a sum type". A sum type with, say, three branches is either the first, or the second, or the third, and to do anything with any of them, you have to deconstruct it, at which point you have full access to the deconstructed branch you are in. The | operator in a Go generic is more a declaration of "I want to operate on all of these at once", so, you can put multiple numeric types into it because you can do a + or a - on any of them, but while the syntax permits you to put three struct types into it, and it'll compile, it does not produce a "sum type". Instead you get "I can operate on this value with the intersection of all the operations they can do", which is more or less "nothing". ("Methods" aren't "operations"; methods you can already declare in interfaces.) Some people particularly fool themselves because you can still take that type, cast it into an "any", and then type switch on it, but it turns out you can always do that, the | operator isn't helping you in any particular way, and if you want to have a closed set of types, a closed interface is a much better way to do it, on many levels. It also doesn't currently do anything else people may want it to do, like, accept three structs that each have a field "A" of type "int" and allow the generic to operate on at least that field because they all share it. There's a proposal I've seen to enable that, as the current syntax would at least support that, but I don't know what its status is.

tapirl 2y ago
There is actually a proposal to make type constraints act as sum types: https://github.com/golang/go/issues/57644 https://github.com/golang/go/issues/57644 But I doubt sum types will be supported perfectly in Go. The current poor-men's sum type mechanism (type-switch syntax) might be still useful in future Go custom generic age.
- jerf 2y ago
  I've pondered the utility of just proposing some syntax sugar around the current methodology, mostly for the reason of getting it rejected for being an unnecessary redundancy to what we already have, so we can point at the rejection.