Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

confusion could be elaborated on #67

Open
tommyjcarpenter opened this issue Jan 30, 2020 · 1 comment
Open

confusion could be elaborated on #67

tommyjcarpenter opened this issue Jan 30, 2020 · 1 comment

Comments

@tommyjcarpenter
Copy link

I found your post here: https://nathanleclaire.com/blog/2014/08/09/dont-get-bitten-by-pointer-vs-non-pointer-method-receivers-in-golang/

after reading this page: https://gobyexample.com/methods

my question is: why does go not seem to care that you pass the correct type (pointer or not) into a method?
Specifically, at the end you have a code block:

func main() {
    m := &Mutatable{0, 0} // line * below seems to work even without the & here
    fmt.Println(m)
    m.StayTheSame()
    fmt.Println(m)
    m.Mutate() . //*
    fmt.Println(m)
}

however, if you just did m := Mutatable{0, 0}, then m.Mutate() still works. Why? What is the effect of this? Why doesn't the compiler complain about m not being a pointer?

@shunkica
Copy link

shunkica commented Apr 26, 2021

If x is addressable and &x's method set contains m, x.m() is shorthand for (&x).m():

https://golang.org/ref/spec#Calls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants