Were multiple return values Go's biggest mistake?

Re:Were multiple return values Go's biggest mistake? by MichaelMoser123 on Saturday March 15, 2025 @02:22PM (#43374282)

Another 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.

- arrays: depends if it is a slice then copy cost is small (again, similar to maps), however an array is fully copied.

... complicated.

[ Parent | on HN ]

Re:Were multiple return values Go's biggest mistake? by porridgeraisin on Saturday March 15, 2025 @03:11PM (#43374551)

This is fairly standard and expected behaviour. Embedded pointers get copied only when you explicitly do a deep copy.

[ Parent | on HN ]

Re:Were multiple return values Go's biggest mistake? by MichaelMoser123 on Saturday March 15, 2025 @11:40PM (#43376808)

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.

[ Parent | on HN ]

Re:Were multiple return values Go's biggest mistake? by porridgeraisin on Sunday March 16, 2025 @04:44AM (#43377677)

> 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.

[ Parent | on HN ]