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
proposal: net/netip: add To6 to wrap an IPv4 address into an IPv6 one #51833
Comments
It doesn't seem to me that |
Yeah, it's a bit unusual. I don't really have an opinion on names. 🙂 |
How about:
|
@ianlancetaylor How about |
I rewrote the proposal with a better method name |
|
This proposal has been added to the active column of the proposals project |
@rsc Thank you. I tried to play with the compiler and could not prove the allocation (not being familiar with the Go Assembler). I also agree that |
At the moment we have very little evidence that this comes up often. |
No, but I don't think we can reach a conclusion now because |
It sounds like we should likely decline this, but we can always revisit if we get new information about how often this comes up. |
Based on the discussion above, this proposal seems like a likely decline. |
No change in consensus, so declined. |
For people who are interested, #54365 is the new incarnation of this proposal, and there is new information about efficiency and usage there (which are the two main reasons for the declination of this PR). I think we could consider revisiting it. |
Currently, there is no efficient way to wrap an IPv4 address into an IPv6 one. The most sensible way is to do the following:
But this is slow and not allocation-free.But this seems to be unnecessarily involved. I wish there would be a new methodTo6
that implements the same functionality but without allocation: (Note: I originally proposedMap
here, but that name did not gain wide support.)Here is a possible implementation of the proposed
To6
method:As an invariant, for any valid IPv4 address ip,
ip.To6().Unmap()
is always equal toip
.EDIT: Following @rsc's comment, I removed the unsubstantiated claim that
As16
is allocating.The text was updated successfully, but these errors were encountered: