The other day I noticed that Wrapping only implements Shl and co. for usize, which contradicts that without Wrapping the shift amount can be any type. So, I think it may be useful to create tests which use macros to shove together all the types we expect to have impls for and check that we're consistent there.
What I've noticed:
- For every operation three extra impls are added, with the combinations of single-level references on both sides, e.g.
&T + T, T + &T, &T + &T for Add.
- Assignment ops do the same as the above, with only one extra impl, e.g.
T += &T for Add.
Add, Sub, Mul, Div, Rem exist for all int and float types with themselvesBitAnd, BitOr, BitXor exist for all int types and boolShl and Shr allow any integer type for both the left and the right sideNeg exists for all ints and floatsNot exists for all ints and boolWrapping should mimic all of the above, where references are of the form &Wrapping<T> and not Wrapping<&T>.
Like, I wouldn't be surprised if rearranging some macros might add or remove impls for these and adding comprehensive tests might help make sure we covered everything.
The other day I noticed that
Wrappingonly implementsShland co. forusize, which contradicts that withoutWrappingthe shift amount can be any type. So, I think it may be useful to create tests which use macros to shove together all the types we expect to have impls for and check that we're consistent there.What I've noticed:
&T + T,T + &T,&T + &TforAdd.T += &TforAdd.Add,Sub,Mul,Div,Remexist for all int and float types with themselvesBitAnd,BitOr,BitXorexist for all int types and boolShlandShrallow any integer type for both the left and the right sideNegexists for all ints and floatsNotexists for all ints and boolWrappingshould mimic all of the above, where references are of the form&Wrapping<T>and notWrapping<&T>.Like, I wouldn't be surprised if rearranging some macros might add or remove impls for these and adding comprehensive tests might help make sure we covered everything.