It is an unfortunate historical difference, but I think the{integer} inference loss is probably not worth it when the more flexiblePow<RHS> already exists. Do you need an equivalentCheckedPow?

Thank you for taking a look.

I think the{integer} inference loss is probably not worth it when the more flexiblePow<RHS> already exists.

I am sorry that my English ability is not sufficient, but am I right in interpreting you think it is too much to changeexp: usize to general one and therefore are not in favor of the change of the pull request? What I give more importance here is actually not the fact that the user can implement their ownpow withPow<RHS>, but the reusability of the library's existing code and mitigating the concern about type size. After implementingClone (and preferablyCopy for the case I am describing at the moment considering the cost) +One for their own struct, the user will be able to just callnum_traits::pow without writing their ownpow. Also for example, forWrapping<T> or something similar, the user can reasonably take exp >= 2^32, but always having to takeusize's actual size into account leads to implementing their ownpow and in the end the user cannot benefit much frompub pow.

Do you need an equivalentCheckedPow?

I know others may have a interest in one (ref#254) and I am not against the idea to add one. I consider making a pull request once the idea of generalizing exp is accepted, for I do not want to yield another FIXME.

Maybe I should have created an issue first. I apologize if discussing the idea here is quite inappropriate.