Closed obskyr closed 7 months ago
so this is only a breaking change if it's in scope for the API to implement
PrimInt
(which I wouldn't guessed it is based on the name, but I suppose it might be?).
Yes it is, and there are real implementations in the wild, e.g. bnum
. That example does also implement Hash
, and probably most do, but we can't really assume that.
Slightly less boilerplate is to create your own extended trait with a blanket implementation:
trait MyPrimInt: PrimInt + Hash {}
impl<T: PrimInt + Hash> MyPrimInt for T {}
Great to know! Alright, now that it's on your radar, I'll close this issue – I suppose it should be added to #47 “Tracking issue for potential breaking changes”, right?
Currently, generic integers can't be used with hashmaps (which by extension means that they can't either be used with, for example,
.unique()
fromitertools
). Give the following code a whirl:It raises the following compiler error:
All of the standard types that
PrimInt
is implemented for implementHash
(which is why it makes sense for it to be a part ofPrimInt
), so this is only a breaking change if it's in scope for the API to implementPrimInt
(which I wouldn't guessed it is based on the name, but I suppose it might be?).It's possible to work around this issue by manually adding the trait bound:
But that's highly boilerplatitudinous, and bubbles up through anything that wants to call the function. It'd be wonderful to be able to comfortably write generic code for different number types in this area as well!