It's true it is an exception, it's one of the few cases where the language adds a pinch of syntactic sugar to make the experience more pleasurable.
I can imagine without this the number one oft repeated feature request would be to _not_ have to write (&t).m() all the time when you just wanted to write t.m(). Compared to the subtle footguns of for range capturing loop variables, the compiler harmonizing method dispatch has always felt to me to be the right compromise of a small amount of magic--the illusion is only broken by map addressablity--in pursuit of Go's other goals of readability and productivity. On Tuesday, 19 December 2017 02:30:52 UTC+11, jlfo...@berkeley.edu wrote: > > > > On Monday, December 18, 2017 at 7:21:14 AM UTC-8, Marvin Renich wrote: > >> >> I think you are looking for this statement in the Go spec: >> >> A method call x.m() is valid if the method set of (the type of) x >> contains m and the argument list can be assigned to the parameter list >> of m. If x is addressable and &x's method set contains m, x.m() is >> shorthand for (&x).m() >> >> This can be found at https://golang.org/ref/spec#Calls near the bottom >> of that section. This was clearly an intentional design decision. >> > > No doubt, but for someone coming to Go from C, it seems like a step > backwards. I like the "What You See Is What You Get" style of programming > language, which mostly describes Go very well. This is an exception. > > Jon > > > -- 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.
