CC @mikioh

@mikioh @ianlancetaylor
As i'm going into the net package sources in detail, there's a LOT of usage of hardcoded strings for network address names in the code and implementing a fix for this issue will mean probably 150+ small changes throughout the package sources - essentially replacing many uses of strings like "ip", "ip+net" or "unixgram" with constants like possibly IPAddrName, IPNetAddrName or UnixGramAddrName (perhaps we could come up with better names).

The question i have is might it adversely impact maintainability of the package to make such changes in so many places? The alternative would be to simply define an exported constant block in src/net/net.go for external use but not use the constants internally

@srinathh,

I think the returned values of Addr.Network are just for fault localization, and are not designed for the case such as "callers can compare values against constants." Please remember that we can use type assertions. So I don't see any benefit from exposing such network names as constants. Instead, from fault localization point of view, I'd like to make Addr.Network return more accurate network names like OpError; e.g., "tcp4" or "tcp6" rather than "tcp".

Yup - I understand that we can use type assertions or type switches and for what i was developing, i ended up going that route ultimately. However, I did spend some time trying to figure out how to use Addr.Network() since that seemed easier & possibly faster. If the interface is meant more for internal use/debugging, it might be better to document that explicitly in the Addr interface and ask people to use type assertions instead.

Wouldn't changing what Addr.Network returns break compatibility?