(I started a conversation on Twitter but @adg suggested it would be a good time to try out this forum.)
@adg has advised in the past that it isn’t a good idea to use interface types as map keys because if an implementation is provided which has an incomparable type (map, slice, func), it will result in a runtime panic.
This is of course sensible and I agree in general, but I’ve also found cases where I’m not easily able to avoid using an interface in a map key. The one that comes to mind at the moment is when making use of http.ConnState callback. Sometimes I’ve used that to get statistics on the number of connections in various states, and in that case I’ve used c.RemoteAddr() as my map key. But at other times, it’s more natural to use net.Conn itself as the key. See, for example, @bradfitz’s recent CL for net/http/httptest:
In my point of view, there is always a chance you have runtime panic even if you’re writing code that you feel most comfortable with. Also, things can be worked around to reduce the probabilities of runtime panic such as do a type check before using it to access value in the map.
This is really a matter of context. Who will be using the map? How will the map be accessible? What might you be using as a key (concrete types)? Where are those types coming from (are you writing them, 3rd party lib)? Who else will be working with this code (will they recognize the same concerns when making changes)?
If the surface area is really small, I wouldn’t fret over it. Otherwise, why risk it.