Considering there is a ParseMAC corresponding to ParseIP which is basically what the Unmarshaller for IP does, this seems like a reasonable request.

There are backwards compatibility concerns with adding MarshalText/UnmarshalText where they did not exist before. Was it possible to marshal these to JSON/Gob/XML before and then decode them back? If so, we can't break the old encoding. Or even if it was only possible to marshal, if that was a form other languages/tools knew, we can't change that either.

While we're on the topic, do we need to think about net.IPMask too?

Waiting for someone to dig into whether there are compatibility issues here.

/cc @mikioh

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

Just FYI.

As far as I can see/remember;

• textual representation for link- or below-layer identifiers varies,
• the existing net.ParseMAC accepts only a few well-known representations, IEEE and some vendors, for the sake of convenience,
• the existing net.HardwareAddr.String method returns the form described in IEEE Std 802-2001, Section 3.1.8 hexadecimal representation with the pick of "colons" instead of "hyphens",
• though, MAC-48 is now obsolete. IEEE RA states that "... octets separated by hyphens; the IEEE RA refers to this as the hexadecimal (hex) representation." in https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf

While we're on the topic, do we need to think about net.IPMask too?

Also net.IPNet? I don't think so. As shown in #30264, there is a need for flexible IP address printer but simple, single-form text marshaler and unmarshaler might not fit for the actual needs, not only for classical telco sectors but tech sectors.

Still looking for comments on compatibility issues.

@rsc I've dug through the git history of the go repo and I can't seem to find anything that would indicate any backwards compatibility issues. If there are specific things you'd like me to look for, I'm more than happy to, but at this point, I don't see any harm in adding this function.

Change https://golang.org/cl/196817 mentions this issue: net: add text marshalling and unmarshalling for HardwareAddr

@klnusbaum The backward compatibility issue is that someone could have marshaled net.HardwareAddr values to JSON using Go 1.13, and might try to unmarshal them using Go 1.14. The unmarshaling would fail because the format would be different.

Is there some reason that that is impossible?

@ianlancetaylor I'm a little confused here. If someone marshaled a hardware address on their own into JSON, why would Go be on the hook for being able to unmarshal that value with this newly introduced code? That seems somewhat unreasonable to me.

In general, it seems reasonable that if you marshal a net.HardwareAddr into JSON with one Go release, you should be unmarshal that JSON into a net.HardwareAddr in a subsequent release. As far as I know that works today--you can marshal and unmarshal a net.HardwareAddr.

As far as I know that works today--you can marshal and unmarshal a net.HardwareAddr.

Ah, ok. So this I think is the source of my confusion. I'm unaware of any way to marshal or unmarshal a net.HardwareAddr to JSON (for example) using the existing Go or any other previous version of Go. Can you point me to where this is possible?

unless you're talking about a developer manually calling String and then writing that out to JSON. And then later, getting the string back and manually calling ParseMAC on it. In which case, the solution I've proposed in my PR would indeed be backwards compatible.

Can you point me to where this is possible?

net.HardwareAddr has a underlying type of []byte and is therefore marshaled/unmarshaled as a base64 string (default behavior of encoding/json for byte slices).

Since that is an unusual format for MAC addresses, I guess it wasn't widely used, so there shouldn't be many compatibility issues.

In general, it seems reasonable that if you marshal a net.HardwareAddr into JSON with one Go release, you should be unmarshal that JSON into a net.HardwareAddr in a subsequent release.

If that's an issue, the UnmarshalText method can use base64.Decode as a fallback in case net.ParseMAC fails.

Ah, so in other words, we're saying that we must remain backwards compatible with the raw marshaling of bytes? i.e. the behavior of this (which will marshal using the default marshal behavior of []byte) should continue to work?

	addr, _ := net.ParseMAC("aa:bb:cc:dd:ee:ff")

	marshaledBytes, _ := json.Marshal(addr)
	
	var unmarshaled net.HardwareAddr
	json.Unmarshal(marshaledBytes, &unmarshaled)
	
	fmt.Printf("Unmarshalled Addr: %s", unmarshaled)

If that's the case, then yea, I think we can do as @zigazeljko suggested, fallback to raw byte unmarshaling in the case of ParseMAC failing. @ianlancetaylor do you think that would work?

It's worth a try. Make sure to include a test with a net.HardwareAddr pre-encoded as if by an earlier release.

@ianlancetaylor @zigazeljko I've added the ability to unmarshal the mac address in the case that it was originally encoded as a raw byte slice. I've also added a test to ensure such functionality actually works. I believe this should assuage any backwards compatibility fears. IMHO, it feels pretty silly and doesn't actually result in a better product. But if that is the will of the Go community so be it.

Why is backward compatibility silly?

Oh, I'm not saying that backwards compatibility is silly over all. It's great overall. It just always comes with a cost. In my own projects, I would say the extra code here adds confusion and it's not worth supporting what I perceive to be an edge case from previous versions. That said, this seems to be the kind of tradeoff where, at least for the go project, the benefits outweigh the costs and so we do want to add the extra code.

Hey Folks,
I think the PR is in pretty good shape at the moment. Is there anything left for me to do? If not that's fine. Just want to make sure there aren't any further actions I need to take on my end at the moment.

Just clarifying if it's okay to extend the policy defined in go/build/deps_test.go to allow net to import base64.

The main thing the PR is missing is consensus on this proposal that we want to do this.
That in turn is blocked on understanding the compatibility issues.

On hold for understanding the compatibility issues. I will try to do that at some point if no one else beats me to it.