The thing with default methods is that while the code may not "break" in the sense of "will not compile", it may very well break in the sense of "issues runtime panic", or even worse: "does the wrong thing".

I do agree all of this can be quite painful, but I'm not so sure that default methods are the right solution.

I think the one really useful suggestion here is at the end of the article. Having some way for the compiler to know that a struct satisfies a particular interface, and thereby create a fast path that sidesteps reflection would be marked performance improvement (and avoid the need for caching).

TBH, anything that can make interface casting faster/more efficient in go would be a welcome improvement.

> and there is no canonical way to document that A satisfies B

Surely that is wrong:

    package satisfy
    type I interface { foo(); }
    type S1 struct { a int; }
    type S2 struct { a int; }
    func (s *S1) foo() { s.a = 1; }
    var _ I = (*S1)(nil);
    var _ I = (*S2)(nil);

Then we get:

    $ go build ./satisfy.go 
    # command-line-arguments
    ./satisfy.go:7:11: cannot use (*S2)(nil) (value of type *S2) as type I in variable declaration:
         *S2 does not implement I (missing foo method)

Also doesn't this disprove his default methods claim, or have I misunderstood?

    package defmeth
    type I interface { foo(); }
    type defs struct { }
    func (s *defs) foo() { }
    var _ I = (*defs)(nil);
    
    type usage struct { defs; a int; }
    
    var _ I = (*usage)(nil);