Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adopt core naming conventions for bigint methods #693

Open
Tracked by #681
tarcieri opened this issue Oct 12, 2024 · 1 comment
Open
Tracked by #681

Adopt core naming conventions for bigint methods #693

tarcieri opened this issue Oct 12, 2024 · 1 comment

Comments

@tarcieri
Copy link
Member

See also: #537

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.

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

@tarcieri
Copy link
Member Author

tarcieri commented Jan 9, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant