It happens all the time because e.g. third party developers follow the same patterns in the standard lib. And it was designed that way. Another example: logging libs are frequently quite similar. Even though the stdlib didn’t define that interface, you can still make your own that works for lots of libs. But even if you don’t use that part of it, it’s still great to limit the scope of your dependency. Less to mock, more flexible code. You obviously don’t like this and I’m not going to convince you, I think. But this is really one of the best features of Go.
This library (and some 3rd parties) have a lot of implementations of image types. But without any inheritence or interface declaration on their part I can make something that will do image size calculations by defining an interface that only contains
Bounds() Rectangle
Now, any of those types can be passed into my function to do checking.
Another example. The stdlib log package didn't define an interface (they should have) and the stdlib logger looks like this: https://pkg.go.dev/log
However, lots of people have made drop in replacements that implement the same method signature. By defining an interface you can swap in the stdlib logger or a 3rd party without the stdlib implementing that interface.
So yeah, the stdlib implemented the interface I defined in my code "by accident" and that's a great thing.
