spec: embedded interfaces should include interface type literals

[TutiFrouti]

What is the URL of the page with the issue?

https://go.dev/ref/spec#Embedded_interfaces

What is your user agent?

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36

Screenshot

No response

What did you do?

Specification for embedded interfaces states (I bolded myself):

In a slightly more general form an interface T may use a (possibly qualified) interface type name E as an interface element. This is called embedding interface E in T [Go 1.14].

It requires interface type name, but implementation currently accepts interface type literal as well.

The notes for GO 1.18 at the end of the specification also imply that it was only intended for interface type names, not interface type literals (I bolded myself):

Interface types may embed arbitrary types (not just type names of interfaces) as well as union and ~T type elements.

What did you see happen?

type InterfaceX interface {
	interface {
		Print1()
		Print2()
	}
}

It compiles successfully.

What did you expect to see?

I expect the implementation to remain as it is currently and just to update the specification.

That is, to change the following:

In a slightly more general form an interface T may use a (possibly qualified) interface type name E as an interface element.

to:

In a slightly more general form an interface T may use a interface type (name or literal) E as an interface element.

or:

In a slightly more general form an interface T may use a interface type E as an interface element.

It doesn't need to be an interface type name, just interface type.

[gabyhelp]

Related Issues and Documentation

• cmd/go2go: embedded types ignored in interface implementation #40199 (closed)
• gccgo: does not accept a legal interface declaration #1811 (closed)
• spec: disallow recursive embedded interfaces #1814 (closed)
• spec: incorrect requirement for the embedded field #69460 (closed)
• spec: Interface Types defines embedding as method enumeration, but private methods are treated differently #7886 (closed)
• go/types: new embedded interface behavior (possible regression) #29029 (closed)
• spec: document interface satisfaction more explicitly #5570 (closed)
• proposal: Go 2: #63948 (closed)
• cmd/go2go: misleading error for embedded struct field of type parameter #39774 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

CC @griesemer

[griesemer]

Thanks for raising the issue, but the spec is correct as is. As you cite yourself, the spec says:

In a slightly more general form an interface T may use a (possibly qualified) interface type name E as an interface element.

The emphasis here is on the word may. It doesn't say that that's the only choice. In fact, the section on general interfaces allows the "embedding" of interface literals (and other types).

The reason that the spec groups interfaces into 3 categories (basic interfaces, interfaces with embedding, general interfaces) is purely for didactic and historical reasons. Before Go 1.18, we just had basic interfaces and embedding of other interfaces. This is covered by the first two sub-sections on interface types. Then, with Go 1.18, interfaces were generalized and now represent type sets (rather than just method sets). In the spec, we could probably just describe general interfaces, but it would be a) harder to grasp the concept, and b) remove the connection to pre-Go 1.18 interfaces. It may be fine for a spec, but the current organization was deliberate to help bringing people along. Also, many Go programmers never need the most general interface definition.

In short, "embedding" an interface literal is clearly permitted by the spec even though we do not traditionally call that an embedded interface.

Closing.