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.
