As Axel points out this is not the case. This can be demonstrated by
trying to assign the struct to an interface that has the method you are
wanting to call. The following would compile under the rules you're
suggesting. It doesn't.

https://play.golang.org/p/qRYPaDOPYsl


On Mon, 2018-11-19 at 15:37 -0600, Robert Engels wrote:
> That is not really true though, as I can declare a method that take a
> pointer receiver and mutate through it, but the caller can pass a
> struct which it thinks can not be mutated.
>
> https://play.golang.org/p/Abf4VX9kUTR
>
> Go isn’t type safe by stating that methods cannot mutate structs. Any
> reader of the above code would think that couldn’t work, unless they
> inspected the source to find a pointer receiver.
>
> >
> > On Nov 19, 2018, at 3:28 PM, Axel Wagner <axel.wagner.hh@googlemail
> > .com> wrote:
> >
> > The restriction has nothing to do with heaps (in fact, the Go
> > language
> > (i.e. the spec) doesn't even have a concept of a "heap"). It's a
> > type-safety requirement. If you pass in a value, it can't be
> > mutated,
> > full-stop. Reflect shouldn't allow you to bypass type-safety - only
> > "unsafe" can do that, hence the name.
> > >
> > > On Mon, Nov 19, 2018 at 9:51 PM Robert Engels <rengels@ix.netcom.
> > > com> wrote:
> > >
> > > Interesting. I guess that makes sense. But you would think that
> > > if using a reflection call should force the compiler to heap
> > > allocate , then no reason for the restriction.
> > >
> > > >
> > > > On Nov 19, 2018, at 2:33 PM, Ian Denhardt <i...@zenhack.net>
> > > > wrote:
> > > >
> > > > Quoting Robert Engels (2018-11-19 15:13:53)
> > > > >
> > > > > But isn’t that just for safety. Meaning the unmarshall could
> > > > > use it as a pointer via reflection and mutate it (but that is
> > > > > probably not what the caller expects in Go) ?
> > > > No, see:
> > > >
> > > >   https://play.golang.org/p/MyF0Dx87-1j
> > > >
> > > > If you pass in &foo instead and insert the appropriate call to
> > > > value.Elem(), it works.
> > > >
> > > > --
> > > > 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.
> > > --
> > > 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.

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

Reply via email to