> The compiler accepts it just fine, though.

I've never seen a concrete type in an interface before, so I decided to try it:

    package main

    type A interface {
        int
        M()
    }

    func f(x A) { // line 8
        x.M()
    }

It is indeed accepted if it's there by itself, but it is rejected if you try to use the interface, which is what function f does:

   ./main.go:8:10: interface contains type constraints

I think this ends up being a very boring reason for rejection and is somewhat irrelevant to the post that you can't actually put concrete types in interface{} definitions. It looked weird to me so I had to try it.

Since this is in the context of generics, I think the author might have been thinking about embedding types like comparable, which are interfaces (comparable is interestingly defined as `type comparable interface { comparable }`). You can, of course, put interfaces in interfaces in general (see io.ReadCloser and friends).

For the comparable case:

    type A interface {
        comparable
        M()
    }

    func p(x A) {
        x.M()
    }

This gets its own error:

    ./main.go:8:10: interface is (or embeds) comparable

Very clever, because yeah, there is nothing stopping you from writing `func f(x comparable) {}`. Except this explicit check.

I don't know what the point of this comment is, since 99% of the article is not about this code block, but I guess I found it interesting.