Rationale for Go's method syntax

Question

Ok, I have to admit, I don't really use Go very much at all, but I did just observe something that strikes me as odd for a language that strives for minimality and all that good stuff as Go does. I would be surprised if there isn't a legitimate rationale behind it, so that's what I'm looking for.

So when you have a method, you define it like this:

func (s *SomeStruct) Foo(x int) { }

but why have an extra parameter list just for the "receiver", as I think it's called? Would it not be a simpler and more elegant design to just do

func Foo(s *SomeStruct, x int) { }

and then have s.Foo(5) just be translated to a call to a function Foo(s, 5)?

Answer 1

Methods are fundamentally special and different from regular functions.

• Methods must live in the same package as the receiver type.
• Methods are used to satisfy interfaces.
• Receiver parameters are the only parameters which may be overloaded.
• When anonymous struct fields have methods, those methods are "inherited".

With your proposal, the line between a function and a method becomes very blurry and it's difficult to figure out how to resolve the above issues.

That said, I think it would be really interesting to design a language with multimethods and interfaces. However, that language would not be Go.