-
-
Notifications
You must be signed in to change notification settings - Fork 777
refactor(allocator/vec): access len and cap fields via getters/setters
#11081
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
Merged
graphite-app
merged 1 commit into
main
from
05-16-refactor_allocator_vec_access_len_and_cap_fields_via_getters_setters
May 20, 2025
Merged
refactor(allocator/vec): access len and cap fields via getters/setters
#11081
graphite-app
merged 1 commit into
main
from
05-16-refactor_allocator_vec_access_len_and_cap_fields_via_getters_setters
May 20, 2025
Conversation
This file contains hidden or 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
This was referenced May 16, 2025
Merged
Member
Author
CodSpeed Instrumentation Performance ReportMerging #11081 will improve performances by 14.32%Comparing Summary
Benchmarks breakdown
|
4aa658d to
565bde0
Compare
43a935e to
0b7da6b
Compare
565bde0 to
d12d30f
Compare
0b7da6b to
2798717
Compare
d12d30f to
aa76a16
Compare
2798717 to
29d7d91
Compare
29d7d91 to
99ad11f
Compare
Member
Merge activity
|
99ad11f to
bb936f8
Compare
…tters (#11081) Follow-on after #10884. Pure refactor. To make it explicit when we're converting `u32` to/from `usize`: * Make `RawVec`'s `len` field private. * Make all access to `len` and `cap` fields go via getter/setter methods. * Name those methods `*_u32` and `*_usize` so it's clear when a conversion is happening. I also renamed `cap_*` methods to `capacity_*` for consistency with `Vec::capacity`. I haven't used these methods in `RawVec` because there's some subtlety around when you want the "raw" `cap` value, and when you want the value `capacity` method returns, which is different when `T` is a ZST. Hopefully we can remove support for ZSTs, and remove this ambiguity.
bb936f8 to
8ec0c74
Compare
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.

Follow-on after #10884.
Pure refactor.
To make it explicit when we're converting
u32to/fromusize:RawVec'slenfield private.lenandcapfields go via getter/setter methods.*_u32and*_usizeso it's clear when a conversion is happening.I also renamed
cap_*methods tocapacity_*for consistency withVec::capacity.I haven't used these methods in
RawVecbecause there's some subtlety around when you want the "raw"capvalue, and when you want the valuecapacitymethod returns, which is different whenTis a ZST. Hopefully we can remove support for ZSTs, and remove this ambiguity.