Ah the old nil values boxed into non-nil interfaces. Even after 8 years writing go code almost every day this still bites me occasionally. I've never seen code that actually uses this. I understand why it is the way it is but I hate it.
replies(4):
Loudest arguments against returning concrete types were on the terraform core team and the excuse was it makes testing easier. I disagree.
net.Dial (Conn, error)
image.Decode(r io.Reader) (Image, string, error)
sha256.NewXXX() hash.Hash
flate.NewReader(r io.Reader) io.ReadCloser
http.NewFileTransport(fs FileSystem) RoundTripper
That’s why Go added abstractions later like fs.FS and fs.File.
embed/fs.Open again deliberately breaks this.
If you will always only ever have one implementation in absolute permanence and no mocking/fake/alternative implementation is ever required in eternity, return a concrete type. Otherwise, consider whether returning an interface makes more sense.
The advice of returning concrete types is paired with defining interfaces when you need them on the consumer side.
It's returning interfaces that prevents good evolution, since the standard library will not add methods to interfaces, it can only document things like: all current standard library implementations additionally satisfy XXX interfaces.
Due to lack of native support of defaults for optional methods , many interfaces in Go are using hacks for optional methods added by evolution.
The Value interface has a `IsBoolFlag()` optional method not part of the interface signature
The other way for evolution is just add sub-interfaces. Like `io.WriterTo` and `io.ReaderFrom` which are effectively just extensions of `io.Writer` and `io.Reader` with `WriteTo` and `ReadFrom` methods - which are checked for in consumers like `io.Copy`.
Anyways, my point was specifically about generic interfaces and alternative implementations, so it appears you agree.
Go's standard library interfaces (like net.Conn) earned their place.
Premature interfaces calcify mistakes and that's what the guideline pushes back on.