-
Notifications
You must be signed in to change notification settings - Fork 39
De-emphasize IPv4-mapped IPv6 handling, relegate it to stdlib compat. #108
Conversation
Closes #64. Signed-off-by: David Anderson <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
// address. | ||
func IPv6Raw(addr [16]byte) IP { | ||
// IPFrom16 returns the IPv6 address given by the bytes in addr. | ||
func IPFrom16(addr [16]byte) IP { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This violates the "new behavior, new name" adage. It's better to break existing callers than silently break them with a change in behavior.
If this will only return IPv6 now, maybe a better name is just IPv6
to match https://godoc.org/inet.af/netaddr#IPv4.
@@ -1289,6 +1280,10 @@ func (u uint128) or(m uint128) uint128 { | |||
return uint128{u.hi | m.hi, u.lo | m.lo} | |||
} | |||
|
|||
func (u uint128) not() uint128 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the other three above have docs, even if internal
}, | ||
{ | ||
name: "4in6-unmap", | ||
fn: FromStdIP, | ||
std: net.ParseIP("1.2.3.4"), | ||
std: net.ParseIP("1.2.3.4").To16(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this change shouldn't be doing anything, right? I'd prefer you keep the old line alone and add a second test, even if it's currently redundant. It'd be interesting if it one of the cases failed in a future Go release.
Proposal implementation for #64, to de-emphasize auto-unmapping. Keep it for stdlib because stdlib makes ambiguous types, but otherwise constructors don't do unobvious things.