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
The upcoming bigint_helper_methods feature of core defines method names and type signatures which it would be good to adopt here as well where it makes sense.
I'd like to punt on this for the v0.6 release. We can always add the new names incrementally, deprecate the old ones, and remove them in a v0.7 release.
While I'm here though, I would also like to note some inconsistencies in modular inverse naming: we have inv, invert, and inv_mod, along with various inv_* and inv_*_mod names.
The *_mod is typically omitted when working with types that are implicitly modular like *Monty*, so that much seems okay, but the use of inv and invert seems a bit inconsistent at least.
Edit: hmm, I now notice this is used in a few places to make const fn inv unambiguous with an fn invert trait method, so I guess this is trickier to reconcile than I thought at first.
Edit again: these concerns probably apply to the Invert trait as well. I should perhaps split off a separate issue just for module inverse naming.
See also: #537
The upcoming
bigint_helper_methods
feature ofcore
defines method names and type signatures which it would be good to adopt here as well where it makes sense.Here's a name bikeshedding thread, if anyone has any opinions on these names: https://internals.rust-lang.org/t/naming-bigint-helper-methods-bike-shedding/21688
The text was updated successfully, but these errors were encountered: