Docs - type guarantees update by WiktorPrzetacznik · Pull Request #129822 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
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
[ Show hidden characters]({{ revealButtonHref }})
Content:
- Pin::map_unchecked | Safety section update
- String::reserve, String::reserve_exact | Panic section update
- Saturating | Introduce Layout section
- Fix typos
Questions:
- This proposes to update String reserve methods docs:
Panics if the new capacity overflows [
usize].
->
Panics if the new capacity exceeds [isize::MAX] bytes.
There are a few other types that are based on Vec and offer similar reserve API (like BinaryHeap).
Should they be updated, too?
ACP: rust-lang/libs-team#482 [not required]
Update safety section that was probably copy-pasted from _mut version
The previous version mentioned panicing when capacity exceeds usize, but that's unprecise. More accurate note mentions isize::MAX
Document layout of Saturating, similarly to Wrapping
r? @cuviper
rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.
Use r? to explicitly pick a reviewer
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
labels
Have these guarantees been discussed and approved somewhere? The String change is fine IMO, since that is a fundamental limitation of heap allocations (and object sizes in general), and we already state that in Vec docs. Saturating layout is probably fine -- it's transparent, but libs-api should sign off on guaranteeing that. I'm not sure about Pin stuff.
@rustbot author
I'll ping you when something happens here.
You can use @rustbot ready for that.
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
@alex-semenyuk
Unfortunately not at all, suffering from lack of time, I have some more free time in upcoming days though, so I'm planning on opening an ACP asking about those changes - if there's a better way to get official response from t-libs let me know.
Status: PR has an ACP and is waiting for the ACP to complete.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Relevant to the library API team, which will review and decide on the PR/issue.
label
We discussed this during today's libs-API meeting, it looks like there previously was no guarantee for the Saturating layout, so this would constitute an API change and will need an FCP.
Pin is subtle, so we weren't sure on the spot if this constitutes a new guarantee or a clarification, so we'd like input from a Pin expert on that.
Labels
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
Relevant to the library API team, which will review and decide on the PR/issue.