You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BoxedUint contains large amount of code copy-pasted from Uint, some of which has been rewritten to perform in-place operations to reduce heap allocations.
Before Rust 1.83 it just wasn't possible to share code between Uint and BoxedUint because Uint has been carefully written to maximally support const fn which precludes &mut [Limb], whereas with BoxedUint we always want to prefer in-place operations to reduce allocations and these require &mut [Limb]. The only way to "abstract" between the two was to use macros, which wasn't great.
As of Rust 1.83 we can now have &mut in const fn which makes it possible to share a common implementation.
One option might be to define a type like this:
pubstructLimbSlice([Limb]);
(it doesn't necessarily need to be pub but might potentially be useful as part of the public API)
Then various operations can be implemented on &mut self references to this type. However, we'd have to be careful that such functions are inlined to eliminate bounds checks on the size of the slice in the case of Uint where it's known statically.
Another option is simply to define the implementation in terms of free functions that operate on &mut [Limb] which is what we have now in a few places where macro-based abstractions were used previously. However, there are various algorithms that would benefit being implemented in terms of an abstraction between Uint/BoxedUint, and in such cases it might be nice to have a real type for that rather than having to import a bunch of free functions.
The text was updated successfully, but these errors were encountered:
BoxedUint
contains large amount of code copy-pasted fromUint
, some of which has been rewritten to perform in-place operations to reduce heap allocations.Before Rust 1.83 it just wasn't possible to share code between
Uint
andBoxedUint
becauseUint
has been carefully written to maximally supportconst fn
which precludes&mut [Limb]
, whereas withBoxedUint
we always want to prefer in-place operations to reduce allocations and these require&mut [Limb]
. The only way to "abstract" between the two was to use macros, which wasn't great.As of Rust 1.83 we can now have
&mut
inconst fn
which makes it possible to share a common implementation.One option might be to define a type like this:
(it doesn't necessarily need to be
pub
but might potentially be useful as part of the public API)Then various operations can be implemented on
&mut self
references to this type. However, we'd have to be careful that such functions are inlined to eliminate bounds checks on the size of the slice in the case ofUint
where it's known statically.Another option is simply to define the implementation in terms of free functions that operate on
&mut [Limb]
which is what we have now in a few places where macro-based abstractions were used previously. However, there are various algorithms that would benefit being implemented in terms of an abstraction betweenUint
/BoxedUint
, and in such cases it might be nice to have a real type for that rather than having to import a bunch of free functions.The text was updated successfully, but these errors were encountered: