Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
17: Derive various num traits for newtypes r=cuviper a=asayers This PR adds deriving macros for the following traits: * FromPrimitive * ToPrimitive * NumOps<Self, Self> * NumCast * Zero * One * Num * Float These macros only work when applied to a newtype where the inner type already implements the trait in question. They produce the obvious "unwrap-call-rewrap" implementation. The `FromPrimative` and `ToPrimative` macros now handle both newtypes and the enums that they used to handle. The odd one out is `NumOps`, for two reasons. First, `NumOps` is just a trait alias for `Add + Sub + Mul + Div + Rem`, so those are the traits which the macro generates impls for. I suppose it's not a great user experience to say `#[derive(Foo)]` and end up with `impl Bar`, but I think in this case it's just about OK. After all, the user needs only to look at the definition of `NumOps` to know that this is only possible behaviour - there's no other way to get an impl for `NumOps`. The other reason this one is strange is that when the user says `#[derive(NumOps)]`, the macro decides that what they want is an impl for `NumOps<Rhs=Self, Output=Self>`. I think this makes sense though; these are the default type parameters, so when you say `NumOps` unqualified this is what it means. As you can probably tell, my objective here was to get to `Float`. That's why this PR only provides macros for a subset of the traits in `num_traits`. Our codebase has a bunch of newtyped `f64`s, and I don't want people unwrapping them all the time to work with them. ### To-do - [x] docs - [x] tests - [x] RELEASES entry Co-authored-by: Alex Sayers <[email protected]> Co-authored-by: Josh Stone <[email protected]>
- Loading branch information