-
Notifications
You must be signed in to change notification settings - Fork 212
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
digest: type name readability regression #1069
Comments
It will involve a quite significant amount of boilerplate in every hash crate. |
I think with some experimentation we can find a solution which allows newtypes for each hash type while minimizing per-crate boilerplate. |
Alternatively perhaps we could find more meaningful names for the generic types which make the generic types more readable. Or a combination thereof. |
In RustCrypto/RSA#179 we ran into a somewhat related issue: It would be nice to be able to use the Unfortunately this isn't possible because these types are actually Something I think is worth noting is the orphan rules would probably permit such an impl if the inner generic type were defined in the current crate (leveraging the same exemption |
I think |
Potentially relevant issue: rust-lang/rust#66751 |
Re: newtypes, using macros for delegation is one option as mentioned here: #1098 (comment) FWIW I don't think it's a terrible option. Macros are best used as stopgaps for missing language features, and I think the lack of first-class delegation support (especially in a composition-over-inheritance language) is a reasonable use case for macros. I also think lack of first-class delegation is somewhat widely recognized as a deficiency in Rust which should eventually get addressed somehow. See rust-lang/rfcs#2393 We use them for solving a similar problem related to Alternatively |
Along these same lines, the error messages for when a digest type fails to impl the #1098 approach to
...and for me this error continues (possibly unrelated):
|
A note re: above: it becomes very very hard to tell what's happening when dealing with errors like above but trying to figure out e.g. SHA-256CoreWrapper<CtVariableCoreWrapper<Sha256VarCore, signature::digest::typenum::UInt<signature::digest::typenum::UInt<signature::digest::typenum::UInt<signature::digest::typenum::UInt<signature::digest::typenum::UInt<signature::digest::typenum::UInt<UTerm, B1>, B0>, B0>, B0>, B0>, B0>>> SHA-512CoreWrapper<CtVariableCoreWrapper<Sha512VarCore, signature::digest::typenum::UInt<signature::digest::typenum::UInt<signature::digest::typenum::UInt<signature::digest::typenum::UInt<signature::digest::typenum::UInt<signature::digest::typenum::UInt<signature::digest::typenum::UInt<UTerm, B1>, B0>, B0>, B0>, B0>, B0>, B0>>>> There is just so much syntactic noise the actual important parts become very difficult to find/compare. |
The solution to all of the above was to enable the For now we're going to need to make all of this very clear in the documentation, with examples of the error messages and suggested resolutions. |
Most of the noise comes from Regardless of the horrible error messages, maybe we should make the |
Digest now makes use of several vaguely-named generic wrapper structs and type aliases to give them human-readable names.
This makes both the type names emitted by rustc and the resulting rustdoc harder to read, as they render the canonical type name rather than the type alias.
For example, what used to render in rustdoc as:
now renders as:
e.g. https://docs.rs/k256/0.11.3/k256/schnorr/struct.Signature.html#impl-PrehashSignature
I think this usability issue and various others (e.g. confusing error messages relating to blanket impls of sealed traits) could be fixed by using newtypes around the generic core, rather than just type aliases.
The text was updated successfully, but these errors were encountered: