[deleted]
Were multiple return values Go's biggest mistake?
21–25 of 25 posts
Re: Were multiple return values Go's biggest mistake?
#22This article seems to break down into 3 parts - why multiple return values are bad, why go error handling is bad, and opinions about what to do about it.
The part that feels wrong to me is their issue with multiple return values. They argue that multiple return values are a special case in the type system, so they don't compose well. But, as far as I can figure, function arguments are also a special case, in the exact same way. I think if the author wants to argue go should only have one return value, then use tuple destructuring to simulate multiple return values, they should also argue functions should only take one argument, and use tuple destructuring to break it apart within the function.
I don't think having a special case for either the input or output of a function is particularly weird, and I can't think of any language (except haskell?) that limits you to one argument.
I don't know. I don't think they're particularly wrong about multiple return types being ugly, but it also doesn't feel like some great tragedy to me the way it does to the author.
Re: Were multiple return values Go's biggest mistake?
#23This article seems to break down into 3 parts - why multiple return values are bad, why go error handling is bad, and opinions about what to do about it. The part that feels wrong to me is their issue with multiple return values. They argue that multiple return values are a special case in the type system, so they don't compose well. But, as far as I can figure, function arguments are also a special case, in the exac…
> they should also argue functions should only take one argument, and use tuple destructuring to break it apart within the function
You say that as an hypothetical, but that's exactly how code is written in Standard ML; and the rest of the ML language family supports it to some degree, although they lean more on currying, like Haskell.
Re: Were multiple return values Go's biggest mistake?
#24Another thing that bugs me: if you have a function argument then it is copied by value, right? But it is hard to tell if the whole value is copied or not. - structures argument: the whole structure is copied (unless you passed a pointer to the struct) - interface? depends if the implementation is structure or pointer. - maps: it copies just a small internal struct that is pointing to the implementation of the map. -…
This is fairly standard and expected behaviour. Embedded pointers get copied only when you explicitly do a deep copy.
yes, however if you look at the function definition then you can't tell if the caller is passing a slice vs an array, or an interface that is implemented on a pointer vs a struct.
The semantics of the function parameter should not depend on how the function is being called.
Re: Were multiple return values Go's biggest mistake?
#25Earlier quoted context omitted.
This is fairly standard and expected behaviour. Embedded pointers get copied only when you explicitly do a deep copy.
yes, however if you look at the function definition then you can't tell if the caller is passing a slice vs an array, or an interface that is implemented on a pointer vs a struct. The semantics of the function parameter should not depend on how the function is being called.
> if you look at the function definition then you can't tell if the caller is passing a slice vs an array
You certainly can. If a function is `f(x []int)` it is illegal to pass a `[3]int` to it. And vice versa, if a parameter is `[3]int` you cannot pass in an `[]int` there.
> or an interface that is implemented on a pointer vs a struct. The semantics of the function parameter should not depend on how the function is being called.
In this case, the semantics of the parameter is the semantics of the interface in question. Whether that interface is implemented by a value or implemented by a pointer inside a particular user of the function is not relevant. This is good -- the decision of using pointer or value receivers on the user's struct, of course, should rest with the user.