Remove big_digit::* from the public API #38
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The *idea* of `big_digit` and its type aliases is that we may someday use something other than `u32` in the representation, perhaps even different sizes for different targets. That's still a possibility, but I think it's not really feasible to expose this variation in the public API. Calling `BigUint::from_slice([1, 2, 3])` is only meaningful if you know what that size is, and users can't really alternate this kind of thing based on a type definition. So for now, we just commit to `u32` units in the public API, no matter what we may do internally. This removal is a breaking change, part of the 0.2 semver bump. If I'm wrong and somebody can show a compelling use case for `big_digit`, we can always add things back into the public API later.
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
May 1, 2018
38: Remove big_digit::* from the public API r=cuviper a=cuviper The *idea* of `big_digit` and its type aliases is that we may someday use something other than `u32` in the representation, perhaps even different sizes for different targets. That's still a possibility, but I think it's not really feasible to expose this variation in the public API. Calling `BigUint::from_slice([1, 2, 3])` is only meaningful if you know what that size is, and users can't really alternate this kind of thing based on a type definition. So for now, we just commit to `u32` units in the public API, no matter what we may do internally. This removal is a breaking change, part of the 0.2 semver bump. If I'm wrong and somebody can show a compelling use case for `big_digit`, we can always add things back into the public API later. Co-authored-by: Josh Stone <cuviper@gmail.com>
Build succeeded |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The idea of
big_digitand its type aliases is that we may somedayuse something other than
u32in the representation, perhaps evendifferent sizes for different targets. That's still a possibility, but
I think it's not really feasible to expose this variation in the public
API. Calling
BigUint::from_slice([1, 2, 3])is only meaningful if youknow what that size is, and users can't really alternate this kind of
thing based on a type definition. So for now, we just commit to
u32units in the public API, no matter what we may do internally.
This removal is a breaking change, part of the 0.2 semver bump. If I'm
wrong and somebody can show a compelling use case for
big_digit, wecan always add things back into the public API later.