-
Notifications
You must be signed in to change notification settings - Fork 55
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
[EDIT: rq. impl isNumberMatch] Equivalent PhoneNumber
s are not equal if the source of their country code is different
#28
Comments
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 |
The way this phone numbers differ is in the encoding of the country code. The fully parsed one uses the "plus"
The other one used the country code passed in to the parsing function as default to determine it is a |
PhoneNumber
s are not equal if the source of their country code is differentPhoneNumber
s are not equal if the source of their country code is different
I turned this into an enhancement request 😉. While I'm not sure we need to keep track of |
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. |
Because
Eq
is derived forPhoneNumber
, this happens:phonenumber::country::Code
stores theu16
as well as thephonenumber::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 normalizedPhoneNumber
s 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".The text was updated successfully, but these errors were encountered: