[EDIT: rq. impl isNumberMatch] Equivalent `PhoneNumber`s are not equal if the source of their country code is different

[EndilWayfare]

Because Eq is derived for PhoneNumber, this happens:

let full = "+1-800-555-1234".parse().unwrap();
let equivalent = `phonenumber::parse(Some(phonenumber::country::US), "800-555-1234").unwrap();

// false
full == equivalent;

phonenumber::country::Code stores the u16 as well as the phonenumber::country::Source that indicates where it came from. I can see how this may be useful for some aspects of a program's logic, but it makes straightforward equality checks of normalized PhoneNumbers awkward (requiring a helper function or a newtype).

I just wanted to draw attention to this. Maybe it's the desired behavior? Maybe this is how libphonenumber works? From my perspective, though, it violates the "Principle of Least Surprise".

[yannleretaille]

As with everything else about phone numbers, matching is not trivial and has different levels of certainty and equivalence, therefore it can't be done by direct comparison. The original libphonenumber provides isNumberMatch for this purpose but we do not have a matching implementation in rust-phonenumber at the moment.

[rustonaut]

The way this phone numbers differ is in the encoding of the country code.

The fully parsed one uses the "plus" +1 in the country code

~The the other one uses the default encoding which depending on the context might or might not be +1.~

The other one used the country code passed in to the parsing function as default to determine it is a US number.

[rustonaut]

I turned this into an enhancement request :wink:.

While I'm not sure we need to keep track of source in country code, which could fix your given example there are other examples which it would not fix.

[henriquecolini]

Just ran into this, and it's really annoying. I have a bunch of manually written phone numbers, and my goal was to parse all of them and remove duplicates. As it turns out, some of them have the plus code, some don't... and despite being actually the same number, they are considered different.

This makes no sense; I see no reason at all why a type that describes a phone number should contain information regarding how it was parsed. If at least there were functions that would allow me to modify phone numbers this wouldn't be too much of an issue. too bad there are none.