[grey-area]

I'd contend that code in places 2 and 3 shouldn't care about the interface except insofar as they violate it (for which they'll get a compile error and be able to fix the problem).

The only place that really cares about the interface is place 1 - where it is used, where it defines a contract for the types passed to a function which they must conform to.

Re your examples, if you want a slice to be used in a read-only manner, pass in a copy of the slice, it's the only way to be sure in future too - those use-sites might be modified later anyway so one check doesn't really help. Interfaces are not intended to limit this sort of use, nor are they a good mechanism to do so. Re the existing implementation, I can't imagine losing track of types such that they'd be a good fit for a given problem, but I wouldn't know about them, interfaces are usually small so it's just a question of one or two functions...

While it's of academic interest to see which types conform to which interface (and people have written little tools to do this), I don't find it's really a limitation in real-world go code, it just doesn't really come up, and I like that interfaces are explicitly one-way, you don't declare them on the implementation side for good reasons.

[tsimionescu]

In my own real world code, this problem comes up daily or more - I have a concrete class, but is it through an interface for mocking purposes. When I am trying to follow the code which uses the interface, I want to follow what galena to the values passed into the interface, through the real (or sometimes mock) implementation. Hopefully gopls will some day be able to do this, but it is a constant annoyance at the moment that I have to break my flow and search for the implementation class by hand.

I am honestly considering just getting rid of the interface and finding some other hackish way to mock the code, just because of the improvement in ease of following the code.