5 ms·

Basically, anything that makes it possible to do an Etiher/Result type blows the whole damn thing up. It calls everything into question, e.g. whether multiple r

by jchw 1y ago

Basically, anything that makes it possible to do an Etiher/Result type blows the whole damn thing up. It calls everything into question, e.g. whether multiple returns really makes sense. It's kind of a shame, because I would really like to be able to model things better (and ideally more efficiently too) when working in Go.

eru 1y ago
The 'multiple return values' thing is really stupid in any case, even without sum-types: it's like "we have tuples, but only for this one special case." Just add first-class tuples to the language.
- dontlaugh 1y ago
  It’s an actual liability, since you can’t uniformly compose the results of functions with different numbers of return values.
  - aatd86 1y ago
    I think it could be retroffited but would require a syntax to have a variable marked as being a tuple. If we look behind the curtains, go functions somehow return tuples that are automatically unrolled into respective variables, sometimes. That's why if you have f(a, b, c){} and g() (b,c){} you can't do f(a, g()) currently. It does not unroll it automatically for some reason here. The result remains in "tuple" form ? I think it may leave some space to have tuples if needed. In any case, I don't see it as technically infeasible.
    - dontlaugh 1y ago
      Go functions don’t actually semantically return tuples, multiple return is part of the calling convention. It can be changed more easily than in other languages because everyone statically links, but it’s not trivial.
      - aatd86 1y ago
        They are not first class in the language but I think I remember the compiler having them as a representation for some language objects. Maybe https://go.dev/src/go/types/tuple.go https://go.dev/src/go/types/tuple.go
      - pjmlp 1y ago
        While it is the default, dynamic linking has been supported in Go for quite a while.
    - eru 1y ago
      > I think it could be retroffited but would require a syntax to have a variable marked as a being tuple. Like Perl's sigils? Or PHP's distinction between 'normal' variables with a $ and variables of function type which have no marking but are case insensitive?

by jchw 1y ago

eru 1y ago

The 'multiple return values' thing is really stupid in any case, even without sum-types: it's like "we have tuples, but only for this one special case." Just add first-class tuples to the language.

dontlaugh 1y ago
It’s an actual liability, since you can’t uniformly compose the results of functions with different numbers of return values.
- aatd86 1y ago
  I think it could be retroffited but would require a syntax to have a variable marked as being a tuple. If we look behind the curtains, go functions somehow return tuples that are automatically unrolled into respective variables, sometimes. That's why if you have f(a, b, c){} and g() (b,c){} you can't do f(a, g()) currently. It does not unroll it automatically for some reason here. The result remains in "tuple" form ? I think it may leave some space to have tuples if needed. In any case, I don't see it as technically infeasible.
  - dontlaugh 1y ago
    Go functions don’t actually semantically return tuples, multiple return is part of the calling convention. It can be changed more easily than in other languages because everyone statically links, but it’s not trivial.
    - aatd86 1y ago
      They are not first class in the language but I think I remember the compiler having them as a representation for some language objects. Maybe https://go.dev/src/go/types/tuple.go https://go.dev/src/go/types/tuple.go
    - pjmlp 1y ago
      While it is the default, dynamic linking has been supported in Go for quite a while.
  - eru 1y ago
    > I think it could be retroffited but would require a syntax to have a variable marked as a being tuple. Like Perl's sigils? Or PHP's distinction between 'normal' variables with a $ and variables of function type which have no marking but are case insensitive?