digest: newtype support

[baloo]

This is an attempt at fixing #1069

example use:

digest::newtype!(
    "SHA-256 hasher",
    Sha256,
    CoreWrapper<CtVariableCoreWrapper<Sha256VarCore, U32, OidSha256>>
);

RustCrypto/hashes#659

[baloo]

I only implemented enough to make tests for sha2 pass. But I'd like your thoughts before going further.

Example doc output:

[newpavlov]

Sorry, but I still don't quite understand the relevance of this wrapper. Why can't the macro implement the struct as a direct thin wrapper around CoreCtWrapper and other wrapper types?

[baloo]

An isolated example is probably easier to showcase the purpose of the wrapper
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=2c559bf521cd586849fb5ffc8ba5850f

But this allows me to implement trait for the newtype only if the inner carries an implementation for it.
This is only meant as a hack until https://doc.rust-lang.org/beta/unstable-book/language-features/trivial-bounds.html lands.

The wrapper was a workaround found in this comment: taiki-e/pin-project#102 (comment)

[newpavlov]

Why do you need to deal with lifetimes here?

This snippet works just fine: https://play.rust-lang.org/?gist=9f86f1ec8c12cbb176cb8e1cce852e56

[baloo]

Yes, but this doesn't work anymore: https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=0c16e92508e7903da2d6099d956f57dd

This is what the lifetime gives me: a bound on the trait implementation of the wrapper.

[newpavlov]

I do not understand. Why do you expect for wrapper!(String => Email); to work in you snippet?

[baloo]

Because the inner type may or may not implement Foo, and I want the wrapper to implement Foo only if the inner implements it.

This is what the lifetime hack gives me.

[newpavlov]

Ah, I see. It's certainly a neat trick, but it's a bit too much magic for my taste. The macro itself already obscures the implementation a bit, so I would prefer to have something more straightforward.

We can either have macros for common scenarious (e.g. impl_fixed_digest!) or explicitly list traits which we want to implement by delegation to the wrapped type. I am not sure which solution would be better, so I will need to experiment and think about it a bit.

[baloo]

alright well I'll pause a bit then :)

[tarcieri]

I think it'd be nice to get rid of all of the current complexity we have around this trait (which is really just a hack around the fact that the digest crates couldn't define their own types, i.e. that we didn't have newtypes before) and just simply impl AssociatedOid for the newtype. Then the newtype macro doesn't need to concern itself with OIDs at all, and indeed we could remove everything related to OIDs from the digest crate.

[baloo]

Ha good point, I just used the same pattern mechanically.