-
Notifications
You must be signed in to change notification settings - Fork 198
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
elliptic-curve: remove ToString
and FromStr
impls
#1600
Conversation
I would prefer to keep the |
Personally, I find it strange that Unfortunately, the docs are not clear enough about when Overall, I don't have a strong opinion here, so feel free to close this PR if you disagree with the position above. |
PEM encoding is the main string encoding of these types humans are used to interacting with, IMO. To me the reasons to prefer There's an explicitness argument to be made for purpose-dedicated APIs, but |
But I don't think we commonly use it to display keys to humans. It's just the traditional serialization format. And users certainly do not input PEM-encoded keys manually.
I think it's a misuse of the My personal rule of thumb for whether an Since I was not able to find good enough docs about it, I will try to ask for additional opinions about |
I think of PEM as the most common method of printing keys themselves, especially SPKI encoded public keys. Yes, it's a serialization format, but it's also pretty much the only game in town for providing a compact way of representing a key to the user as a string.
Sure, that's fine |
The URLO thread has only two replies, but I guess my opinion about the traits is comparatively on a more extreme side. I still think that we do not need the impls in this case and that users should use the explicit methods, but I am not strongly opposed to having the either, so I will close this PR. |
As discussed in #1598 users probably should prefer explicit serialization/deserialziation methods instead of using
FromStr
/ToString
trait implementations.FromStr
implementations forScalarPrimitive
andNonZeroScalar
are left unchanged since they have a symmetricDisplay
impl. But note that the currentFromStr
impls for these types may be potentially confusing, since they decodes from hex, whileFromStr
impls for primitive numeric types decode from decimal encoding.