When we first wrote the method set definition, we had long
discussions about whether method sets applied to all types
or just named types, and we (or at least I) concluded that it
didn't matter: the two were equivalent points of view, because
the only way to introduce a new method was to write a method
function, which requires a named receiver type.
However, the addition of embedded types changed this.
Embedding can introduce a method without writing an explicit
method function, as in:
var x struct {
sync.Mutex
}
var px *struct {
sync.Mutex
}
var _, _ sync.Locker = &x, px
The edits in this CL make clear that both &x and px satisfy
sync.Locker. Today, gccgo already works this way; 6g does not.
R=golang-dev, gri, iant, r
CC=golang-dev
https://golang.org/cl/
5702062
A type may have a <i>method set</i> associated with it
(§<a href="#Interface_types">Interface types</a>, §<a href="#Method_declarations">Method declarations</a>).
The method set of an <a href="#Interface_types">interface type</a> is its interface.
-The method set of any other named type <code>T</code>
+The method set of any other type <code>T</code>
consists of all methods with receiver type <code>T</code>.
The method set of the corresponding pointer type <code>*T</code>
is the set of all methods with receiver <code>*T</code> or <code>T</code>
<p>
Fields and methods (§<a href="#Method_declarations">Method declarations</a>) of an anonymous field are
promoted to be ordinary fields and methods of the struct (§<a href="#Selectors">Selectors</a>).
-The following rules apply for a struct type named <code>S</code> and
+The following rules apply for a struct type <code>S</code> and
a type named <code>T</code>:
</p>
<ul>