Add SplitByteSlice::split_at_unchecked
#1071
Conversation
jswrenn
force-pushed
the
try_split
branch
2 times, most recently
from
748ec27
to
4bac39f
Compare
There was a problem hiding this comment.
I worry that this commits us to an API - try_split_at - that we're not 100% sure we want long-term. The only use of it in this PR is internal to the crate, so maybe we could just make it a private bare function? We'd keep the introduction of split_at_unchecked, and we'd keep split_at as a method with a default impl. Those changes need to go in now (before 0.8) since they're breaking changes. But making try_split_at a private function accomplishes the same goals as this PR but commits us to fewer APIs long-term.
jswrenn
changed the title
SplitByteSlice::{try_split_at, split_at_unchecked}SplitByteSlice::split_at_unchecked
Done. |
jswrenn
force-pushed
the
try_split
branch
2 times, most recently
from
ade377a
to
b2e4740
Compare
src/lib.rs
Outdated
| // `l_ptr` is non-null, because `self` is non-null, by invariant on | ||
| // `&mut [u8]`. | ||
| let l_ptr = self.as_mut_ptr(); | ||
|
|
||
| // `l_ptr` is non-null, because `self` is non-null, by invariant on | ||
| // `&mut [u8]`. |
There was a problem hiding this comment.
Maybe only say this (in comments) once?
Given the importance of avoiding panic paths to some of our customers, we should, as a rule, avoid only offering (or relying upon) APIs with panic paths. Related to #202
|
The Kani breakage is tracked upstream: model-checking/kani#3138 |
Given the importance of avoiding panic paths to some of our customers, we should, as a rule, avoid only offering (or relying upon) APIs with panic paths.
Related to #202