On Tue, 18 Apr 2017 14:30:29 -0700 (PDT)
st ov <so.qu...@gmail.com> wrote:
> Wow! Thanks everyone!
>
> So if I got this right, Go always makes a copy but whats actually
> being copied differs by type.
>
> It seems that I don't need to worry about a lot of data being copied
> about with the larger data structures, but by passing the pointer
> value by default isn't that an implicit pass-by-reference?
Yes, and that's what Caleb talked about: the current language spec
appears to only clearly speak about the slices by saying a slice
"...is a descriptor to...".
In Go, the following things have reference semantics: functions,
slices, channels and maps. That is, they can be thought of as being
descriptors to the underlying "stuff". (Well, if you're into C, it's
probably easier to understand function values as being pointers.)
Note two things.
The first one is that it was probably possible to make all those values
have non-reference semantics.
The second is that you can easily create a type which has reference
semantics yourself -- by having a pointer value in some struct value:
type B struct {
PtrA *A
X int
}
b := B{PtrA: &a}
c := b
Note how c.X and b.X are different variables (with different addresses)
while both c and b refer to the same variable via their PtrA fields.
These two things combined actually represent a larger problem to
consider: there are types which have more sensible usage patterns when
made implement reference semantics than otherwise. Say, suppose the
channels would have made implement non-reference semantics. Then
assigning a value containing a channel to a variable would involve
actual copying of the whole channel -- locking it, allocating all the
underlying stuff for the new channel, initializing it, copying any
buffered data over etc. But now what would that really buy anyone?
The whole reason channels exist is that several concurrent goroutines
access *the same* channel value. So should the channels have
non-reference semantics, everyone would have to use pointers to them.
Consider slices. They explicitly were designed to serve as "views"
into underlying arrays, and that's why they can be though of as keeping
references to those arrays. Copying a function value by duplicating
the function's body has almost no sense in a compiled language (if at
all possible to implement given that on popular contemporary H/W
architectures the program's code segment is typically not writable and
data segments are not executable).
Maps it supposedly the only data type with reference semantics which
IMO is sort of in a grey area because non-reference semantics for it
would be sensible, too.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
