* jlforr...@berkeley.edu <jlforr...@berkeley.edu> [171217 15:33]:
> Here's what I believe is the explanation. The book says (slightly
> edited) "If the receiver p is a variable of type Path but the method
> requires a *Path receiver, we can use this shorthand:
>
> p.pr1()
>
> and the compiler will perform an implicit &p on the variable.". This
> explains what happens when pr1() is called.
>
> I'm surprised that Go would include this implicit behavior because type
> conversions are generally required to be explicit.
>
> type Path []byte
>
> func (p *Path) pr1() {
> fmt.Printf("%s\n", *p)
> }
>
> func (p Path) pr2() {
> fmt.Printf("%s\n", p)
> }
>
> func main() {
> var p Path
>
> p = Path("abc")
> p.pr1()
>
> p = Path("abc")
> p.pr2()
> }
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.
...Marvin
--
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.
