Re:Were multiple return values Go's biggest mistake?
by UncleEntity on Saturday March 15, 2025 @02:38PM
(#43374377)
> The parameters of a function are passed on the stack and the return values are returned immediately after on the stack. That's why naming your return values is just like naming your parameters - they are both local stack based variables.
Why should the user of a language need to know anything about how values are passed to/returned from a function? Passing them on the stack, in registers, on the heap are definitely in the 'implementation detail' camp.
And named return values seems to me to be just bookkeeping and (admittedly a good form of) user convenience.
That being said, I do like the way python does it with tuples and automagic tuple unpacking. Even the C-API makes it super easy to do multiple return values.
The C ABI is quite capable of it provided you dress it up into a struct, you just can't do it without defining that useless one off struct.
IMHO Go fixed that C wart.
If you look at the Go calling convention, multiple return values look perfectly natural. The parameters of a function are passed on the stack and the return values are returned immediately after on the stack . That's why naming your return values is just like naming your parameters - they are both local stack based variables.
So I would argue that multiple return values are great.
Maybe you should be able to treat all the return arguments as a tuple (eg Python). That would make certain things neater, but I think it is a different argument.