5 ms·

Go's multiple return is in itself insane from my perspective. You cannot 'do' anything with a function that has multiple return types except assign them to a va

Go's multiple return is in itself insane from my perspective. You cannot 'do' anything with a function that has multiple return types except assign them to a variable.

masklinn 1y ago
The saddest part is that Go's designers decided to use MRV but pretty much just as bad tuples: as far as I can tell the only thing Go uses MRV for which tuple wouldn't be better as is post-updating named return values, and you could probably just update those via the container. Common Lisp actually does cool things (if a bit niche) things with MRVs, they're side-channels through which you can obtain additional information if you need it e.g. every common lisp rounding functions returns rounded value... and the remainder as an extra value. So if you call (let ((v (round 5 2))) (format t "~D" v)) you get 2, but if you (multiple-value-bind (q r) (round 5 2) (format t "~D ~D" q r)) you get 2 and 1.
- bravesoul2 1y ago
  You can at least in Go do this: r, err := f() r := f() _, err := f()
  - masklinn 1y ago
    No, you can not do the second one. The other two are completely routine and will work just fine with lists in JS or tuples in Python or Rust (barring a few syntactic alterations).
9rx 1y ago
What else would you want to do with them? Maybe in rare cases you'd want to structure them into an array or something, but the inverse isn't possible either [e.g. func f(a, b, c int) -> f(<destructure array into arguments>)] so it isn't like it is inconsistent. Perhaps what you are really trying to say is that multiple function arguments is insane full stop. You can pass in an array/tuple to the single input just the same. But pretty much every language has settled on them these days – so it would be utterly bizarre to not support them both in and out. We may not have known any better in the C days, but multiple input arguments with only one output argument is plain crazy in a modern language. You can't even write an identity function.
- throwawaymaths 1y ago
  have a single return value and if you really need MRV, return as a tuple type, which you could destructure. (this is what zig does)
  - 9rx 1y ago
    But then why accept multiple input arguments? Why not limit to a single argument, accepting a tuple where multiple arguments are necessary, for input too? Where multiple input arguments are present, not having multiple output arguments is just strange.
    - throwawaymaths 1y ago
      Exactly. Why not make multiple argument function call syntatic sugar over a ~single argument tuple call? https://ziglang.org/documentation/0.14.1/#call https://ziglang.org/documentation/0.14.1/#call
      - 9rx 1y ago
        What would you need syntax sugar for? If you are going to support multiple arguments you may as well do it properly or don't do it at all. A poor bandaid because you fucked up tuples is not a quality that is to strive for.
knutzui 1y ago
That's technically not true. You can pass multiple return values of a function as parameters to another function if they fit the signature. for example: func process[T any](value T, err error) { if err != nil { // handle error } // handle value } this can be used in cases such as control loops, to centralize error handling for multiple separate functions, instead of writing out the error handling separately for each function. for { process(fetchFoo(ctx)) process(fetchBar(ctx)) }
- prerok 1y ago
  Well, if fetchBar requires fetchFoo to complete successfully, you still somehow have to handle it. That said, there are libraries out there that implement Result as generic type and it's fine working with them, as well. I don't see what the hubbub is all about.

Go's multiple return is in itself insane from my perspective. You cannot 'do' anything with a function that has multiple return types except assign them to a variable.

masklinn 1y ago

The saddest part is that Go's designers decided to use MRV but pretty much just as bad tuples: as far as I can tell the only thing Go uses MRV for which tuple wouldn't be better as is post-updating named return values, and you could probably just update those via the container. Common Lisp actually does cool things (if a bit niche) things with MRVs, they're side-channels through which you can obtain additional information if you need it e.g. every common lisp rounding functions returns rounded value... and the remainder as an extra value. So if you call (let ((v (round 5 2))) (format t "~D" v)) you get 2, but if you (multiple-value-bind (q r) (round 5 2) (format t "~D ~D" q r)) you get 2 and 1.

bravesoul2 1y ago
You can at least in Go do this: r, err := f() r := f() _, err := f()
- masklinn 1y ago
  No, you can not do the second one. The other two are completely routine and will work just fine with lists in JS or tuples in Python or Rust (barring a few syntactic alterations).

9rx 1y ago

What else would you want to do with them? Maybe in rare cases you'd want to structure them into an array or something, but the inverse isn't possible either [e.g. func f(a, b, c int) -> f(<destructure array into arguments>)] so it isn't like it is inconsistent. Perhaps what you are really trying to say is that multiple function arguments is insane full stop. You can pass in an array/tuple to the single input just the same. But pretty much every language has settled on them these days – so it would be utterly bizarre to not support them both in and out. We may not have known any better in the C days, but multiple input arguments with only one output argument is plain crazy in a modern language. You can't even write an identity function.

throwawaymaths 1y ago
have a single return value and if you really need MRV, return as a tuple type, which you could destructure. (this is what zig does)
- 9rx 1y ago
  But then why accept multiple input arguments? Why not limit to a single argument, accepting a tuple where multiple arguments are necessary, for input too? Where multiple input arguments are present, not having multiple output arguments is just strange.
  - throwawaymaths 1y ago
    Exactly. Why not make multiple argument function call syntatic sugar over a ~single argument tuple call? https://ziglang.org/documentation/0.14.1/#call https://ziglang.org/documentation/0.14.1/#call
    - 9rx 1y ago
      What would you need syntax sugar for? If you are going to support multiple arguments you may as well do it properly or don't do it at all. A poor bandaid because you fucked up tuples is not a quality that is to strive for.

knutzui 1y ago

That's technically not true. You can pass multiple return values of a function as parameters to another function if they fit the signature. for example: func process[T any](value T, err error) { if err != nil { // handle error } // handle value } this can be used in cases such as control loops, to centralize error handling for multiple separate functions, instead of writing out the error handling separately for each function. for { process(fetchFoo(ctx)) process(fetchBar(ctx)) }

prerok 1y ago
Well, if fetchBar requires fetchFoo to complete successfully, you still somehow have to handle it. That said, there are libraries out there that implement Result as generic type and it's fine working with them, as well. I don't see what the hubbub is all about.