Thank you for explicitly listing all reference semantics and more
importantly the considerations given for their use!
On Saturday, April 22, 2017 at 8:41:22 AM UTC-7, Konstantin Khomoutov wrote:
>
> On Tue, 18 Apr 2017 14:30:29 -0700 (PDT)
> st ov <so.q...@gmail.com <javascript:>> 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.
