Default Methods in Go(mcyoung.xyz)
mcyoung.xyz
Default Methods in Go
https://mcyoung.xyz/2025/08/25/go-default-methods/
7 comments
> and there is no canonical way to document that A satisfies B
Surely that is wrong:
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)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.
TBH, anything that can make interface casting faster/more efficient in go would be a welcome improvement.
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);mama_mia9(1)
I do agree all of this can be quite painful, but I'm not so sure that default methods are the right solution.