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