Tracking Issue for split_at_checked

Feature gate: #![feature(split_at_checked)].

This is a tracking issue for the addition of split_at_checked and split_at_mut_checked methods to [T] and str types which are non-panicking versions of split_at and split_at_mut methods. Rather than panicking when spit index is out of range (like split_at does), the methods return None.

Public API

impl<T> [T] {
    pub fn split_at_checked(&self, mid: usize) -> Option<(&[T], &[T])>;
    pub fn split_at_mut_checked(&self, mid: usize) -> Option<(&[T], &[T])>;
}

impl str {
    pub fn split_at_checked(&self, mid: usize) -> Option<(&str, &str)>;
    pub fn split_at_mut_checked(&mut self, mid: usize) -> Option<(&str, &str)>;
}

Steps / History

ACP: ACP: Introduce checked_split_at{,_mut} methods libs-team#308
Implementation: core: introduce split_at{,_mut}_checked #118578
Final comment period (FCP)¹
Stabilization PR

Unresolved Questions

Name of the methods. Some possibilities (suggested in ACP discussion):

split_at_checked and split_at_mut_checked — follows naming of split_at_unchecked and split_at_mut_unchecked. Using suffix makes the names sort nicely together.
checked_split_at and checked_split_at_mut — follows naming convention of arithmetic types (e.g. checked_add). Those new functions serve similar purpose as checked arithmetic operations.
try_split_at and try_split_at_mut — follows naming of various fallible methods such as try_from, try_new, try_for_each etc. Shortest of the three suggestions.

https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

I wonder if the str method should return a Result since they have two failure modes - invalid char boundary and OOB of the string.

Personally I’d rather not complicate the interface and have the methods on slice and on str return the same kind of value. No strong feelings though.

Auto merge of rust-lang#118578 - mina86:c, r=dtolnay

Rollup merge of rust-lang#118578 - mina86:c, r=dtolnay

Unrolled build for rust-lang#118578

@mina86

Thanks for pushing for this feature ❤️ I really want this to land! Panic free handling of byte slices has been in a pretty bad state a long time. I came here just now because I was trying out the new split_first_chunk just to realize I could not make the code improvements I have been wanting a long time without also having panic free slice splitting with a runtime mid. split_first_chunk and split_at_checked do the same thing really, but one of them have the splitting index as a const generic.

I just tried slice::split_first_chunk and it does wonders to my code. Both in terms of code simplicity/readability but also to amount of potentially panic locations.

@mina86 You can check the implementation PR step in your initial comment. That's merged 🥳

@m-ou-se

@m-ou-se Can we get a fcp for this? slice::split_at_{mut}_unchecked is getting stabilized on 1.79.0 and I think is going to be kinda akward to not also provide the safe non-panic option as well on the same release.

Thanks in advance.

Name of the methods. Some possibilities

For consistency with the existing methods on slice and str, it probably should be called split_at_{mut}_checked.

I wonder if the str method should return a Result since they have two failure modes - invalid char boundary and OOB of the string.

IMO returning option here should be fine. But t-libs might have something else to say about this?

@rfcbot

We discussed this in the libs-api meeting and are happy to merge this as it is. The _checked suffix is consistent with the already stabilized _unchecked methods, and returning an Option is consistent with the .get() method.

@rfcbot fcp merge

@Amanieu

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

Rollup merge of rust-lang#124678 - UserIsntAvailable:feat/stabilize-s…

Unrolled build for rust-lang#124678

this was duplicate of #90410. I would have prefer Result.

This become stable very fast Oo. (nice)

rust: transmute: simplify code with Rust 1.80.0 `split_at_*checked()`

Navigation Menu

Repository navigation

Tracking Issue for split_at_checked #119128

Public API

Steps / History

Unresolved Questions

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for split_at_checked #119128

Description

Public API

Steps / History

Unresolved Questions

Footnotes

Activity

tgross35 commented on Jan 10, 2024

mina86 commented on Jan 10, 2024

faern commented on Feb 20, 2024

UserIsntAvailable commented on Apr 22, 2024

Amanieu commented on Apr 23, 2024

rfcbot commented on Apr 23, 2024

7 remaining items

rfcbot commented on May 3, 2024

Stargateur commented on Oct 11, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions