I understand that. I was stating that the syntactic sugar of automatic pointer creation to call a method should be removed. Having an A become a *A in one instance but not in others just causes confusion, let alone makes things not obviously mutable, mutable, causing a developer to determine that the method actually have a pointer receiver. I know it won’t because of backwards compatibility, but it was a very bad choice IMO.
> On Nov 19, 2018, at 5:41 PM, Dan Kortschak <dan.kortsc...@adelaide.edu.au> > wrote: > > 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.
