Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

srinathh opened this issue Jul 16, 2015 · 4 comments


Copy link

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

Copy link

CC @mikioh

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Jul 16, 2015
Copy link
Contributor Author

@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

Copy link

mikioh commented Jul 17, 2015


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

Copy link
Contributor Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

3 participants