Don't panic in ceil_char_boundary by clarfonthey · Pull Request #112387 · 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
Conversation10 Commits3 Checks0 Files changed
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 }})
Implementing the alternative mentioned in this comment: #93743 (comment)
Since floor_char_boundary will always work (rounding down to the length of the string is possible), it feels best for ceil_char_boundary to not panic either. However, the semantics of "rounding up" past the length of the string aren't very great, which is why the method originally panicked in these cases.
Taking into account how people are using this method, it feels best to simply return the end of the string in these cases, so that the result is still a valid char boundary.
r? @cuviper
(rustbot has picked a reviewer for you, use r? to override)
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
This comment has been minimized.
I think this needs to be an API question, even though it's not stable yet. It seems surprising to me that it would return something less than index when it is stated up front, "not below index", so panicking is the only choice. But I also kind of think that floor should not paper over out-of-bounds index either.
@bors label -T-libs +T-libs-api
r? libs-api
For a more direct link to what I was searching: https://github.com/search?utf8=%E2%9C%93&q=ceil_char_boundary+language%3ARust&type=code&l=Rust
Essentially, I saw a few uses of ceil_char_boundary(index + 1) or something to that effect, and while I didn't scrutinise the exact usages to make sure they were using it properly, that alongside the combination of people asking for a non-panicking version made me feel that it would make the most sense for this to not panic.
My (flimsy) logic is to think of it like climbing a ladder, and if you climb past the last rung on the ladder you just stay at the last rung.
Co-authored-by: Josh Stone cuviper@gmail.com
We discussed this in the libs-api meeting last week. While we felt it was a bit odd for this method to return a value lower than its input, we agree that one of its main use cases is basically to sanitize input to e.g. s.split_at(x), s[..x], etc. The guarantee that any return value from floor_char_boundary and ceil_char_boundary is always a valid index to give to split_at is a very useful one.
Since this is still unstable, this PR doesn't require an FCP. (The behavior of this method will be part of the FCP that will happen when stabilizing it.)
@bors r+
📌 Commit 2f75dd4 has been approved by m-ou-se
It is now in the queue for this repository.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Finished benchmarking commit (4f4dae0): comparison URL.
Overall result: no relevant changes - no action needed
@rustbot label: -perf-regression
Instruction count
This benchmark run did not return any relevant results for this metric.
Max RSS (memory usage)
Results
This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 2.5% | [2.1%, 2.8%] | 3 |
| Regressions ❌ (secondary) | - | - | 0 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | - | - | 0 |
| All ❌✅ (primary) | 2.5% | [2.1%, 2.8%] | 3 |
Cycles
This benchmark run did not return any relevant results for this metric.
Binary size
This benchmark run did not return any relevant results for this metric.
Bootstrap: 633.856s -> 632.472s (-0.22%)
Artifact size: 346.73 MiB -> 346.76 MiB (0.01%)
Labels
This PR was explicitly merged by bors.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the library team, which will review and decide on the PR/issue.