So first I thought it was just going to be that you had a signed vs unsigned mismatch and that switching your a and b variables from i32 to u32, to match the unsignedness of your Into constraint.
But then I realized that actually, Into is not implemented for most integers at all. See
https://doc.rust-lang.org/std/convert/trait.From.html and note that only u8 has that conversion built in. My understanding is that that is because T -> usize could be lossy for any types greater than 8 bit, if you are running on an 8 bit platform (so that usize is 8 bits). Having that conversion be built in for u8 makes sense since it can’t be lossy on any platform architecture that is intended to be supported by rust. That cannot be said for the other types.
Looking at the documentation for pow, in the num crate, it looks like it takes T for the base, but usize for the exponent, whereas you are trying to use a T for the exponent as well, which would require a conversion that could wraparound, given above.
But once you fix those issues, you are still left with some issues that I don’t know how you would want to solve.
Notably, with a revised type signature of
pub fn nth_root<T>(value: T, n: usize) -> Option<T>
The compiler is now all sorts of grumpy about this line: (simplified from yours)
x = (nm1 * x + value / ::num::pow(x, nm1)) / n;
because even though we’ve made the arguments to pow be correct, the Add, Mul, Div operators are also not defined for usize and a generic Integer.
Note that all of this is because the compiler is trying to protect us from ourselves. In this case, no version of your original type signature (nor mine in the link above) can be remotely safe without a lot of run-time checking for overflows, etc.
So you could go in various directions. You could create a version that output Option (or i128), and explicitly upconvert to larger internal variables than your arguments. You could do a run-time check to make sure that usize is less than T, and be more conservative about your output type, etc, etc. Or if you were intent on maximizing performance, you might skip trying to make a single implementation, be ideal, and instead use specialization to create multiple versions.