net: Expose return values of default implementations of net.Addr.Network() as constants rather than hardcoded strings

[srinathh]

Currently the default implementations of net.Addr.Network() functions in the net package return hard-coded strings representing the network type as below. This means that callers wanting to check the return value of these functions also have to hard-code these in their own code with the possibilities of typos leading to possibility of bugs.

• IPAddr.Network() : "ip"
• IPNet.Network() : "ip+net"
• TCPAddr.Network() : "tcp"
• UDPAddr.Network() : "udp"
• UnixAddr.Network() : "unix" or "unixgram" or "unixpacket"

If we expose these default return strings as package constants and have functions use the constants instead of hard-coded strings, callers can compare function return values against constants and be protected against these types of bugs. This would also be fully backwards-compatible.

A block of constants will also serve as a useful single point of reference in the documentation for these functions as currently we need to jump around the documentation to understand what each implementation returns.

Happy to work out a CL for this

[ianlancetaylor]

CC @mikioh

[srinathh]

@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

[mikioh]

@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".

[srinathh]

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?