Implement derives for generic wrapper types

[oli-cosmian]

fixes #19

[cuviper]

This is cool -- Generics::split_for_impl makes this a lot easier than I thought it would be.

Could you rebase for the conflicts from #35? Mostly just need to change _num_traits to a dynamic #import.

[oli-cosmian]

Rebased

[cuviper]

Just missed a couple spots.

[oli-cosmian]

Just missed a couple spots.

oops, resolved and grepped to see if there are any others (there weren't).

[oli-cosmian]

Oh. I just realized that

#[derive(
    Debug,
    Clone,
    Copy,
    PartialEq,
    PartialOrd,
    ToPrimitive,
    FromPrimitive,
    NumOps,
    NumCast,
    One,
    Zero,
    Num,
)]
struct MyThing<T>(Wrapping<T>);

does not work, because there's no T: Num bound on the Num impl, causing rustc to fail to infer that Wrapping<T>: Num holds. If we add T: Num bounds, that makes struct MyThing<T, U>(SomeTypeImplingNumEvenIfTDoesNot<T>); not work anymore.

[oli-cosmian]

Since Num requires PartialEq, and the libstd derive causes PartialEq to get a T: PartialEq bound instead of a Wrapping<T>: PartialEq bound, this workaround is required to use the new num derives from this PR with such types.

[cuviper]

Is there a meaningful difference? The std implementation looks like this:

impl<T> PartialEq<Wrapping<T>> for Wrapping<T>
where
    T: PartialEq<T>,

You can't impl PartialEq for Wrapping<LocalType>, so it seem like T: PartialEq and Wrapping<T>: PartialEq should be equivalent.

[oli-cosmian]

I'm not sure why there's a difference, but there definitely is one. I'll look into it

[cuviper]

because there's no T: Num bound on the Num impl, causing rustc to fail to infer that Wrapping<T>: Num holds. If we add T: Num bounds, that makes struct MyThing<T, U>(SomeTypeImplingNumEvenIfTDoesNot<T>); not work anymore.

Hmm, now it seems like we're in that gray area of rust-lang/rust#26925, where it's not really obvious whether you should want bounds on the generic parameters or on the structural types. By adding #inner_ty: Trait, we're leaking that private type in a way that may not be desirable. I think we should probably only constrain the generic parameters, as the compiler does.

So far we've avoided this question because the newtype derivations are unconditional.