Introduce <&[_]>::split_off and <&str>::split_off

[nox]

No description provided.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @withoutboats (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[Centril]

This seems nice to have 👍
I'm kinda saddened that libcore can't use these (and existing methods in the same impl..) -- hopefully we can fix that someday.

[cramertj]

+1-- I've written these a handful of times.

I'd also like split_off_front and split_off_front_mut.

[nox]

@cramertj I plan to make a separate PR for a more general "cutting" concept, with "anchored ranges". I'll probably do that at the end of the week.

https://play.rust-lang.org/?gist=54e0077190f33596d9f8fa705bed0a66&version=nightly

[Centril]

This is trivially safe since an empty string slice is UTF-8 by definition, but a comment to that effect would be nice here ;)
(Generally I think all uses of unsafe elimination blocks should come with a comment explaining the reason why it is safe.)

[nox]

I finally added the damn comment. :3

[cramertj]

ping @withoutboats

[nox]

@withoutboats Ping.

[SimonSapin]

The implementation looks fine to me but the self: &mut &'a Self parameter is unusual. @rust-lang/libs what do you think?

[alexcrichton]

The method name here could be shadowed by Vec::split_off so we may want to rename?

We've also got methods like <[_]>::split_{first,last}, so I wonder if we'd want to provide similar treatment to those methods as well? (aka have all the split_* methods with a &mut &mut [T] version)

[bors]

☔ The latest upstream changes (presumably #49698) made this pull request unmergeable. Please resolve the merge conflicts.

[emilyalbini]

Ping from triage! Can @withoutboats (or someone else from @rust-lang/libs) review this?

[withoutboats]

Code looks good, I agree with Alex that the potential shadowing with the Vec API seems bad and it would be good to rename.

In regard to @SimonSapin's point about the return type, I think this is just an example of the kinds of new APIs arbitrary_self_types enables.

[nox]

What should I rename them to?

[Centril]

@nox How about: steal_from or take_from? This hints at the fact that the return value "steals" or takes something from the receiver starting fromat and leaves the rest in place.

[nox]

I would expect such a method to set self to the rest of the slice, not the beginning.

[TimNN]

@nox / @alexcrichton: It looks like the main blocker here is deciding on names for the new methods. How do you want to move forward with this?

---

If this does essentially the same as existing split_off methods, I think it should be named similarly. If shadowing with Vec is a concern, maybe split_off_slice? Or keep split_off for now and discuss again prior to stabilization?

[alexcrichton]

I don't have a particular personal preference on name, but I do think it just needs to be different

[emilyalbini]

Ping from triage! What's the status of this? S-waiting-on-bikeshed?

[alexcrichton]

Indeed!

[emilyalbini]

Sure.

[cramertj]

How about split_tail or take_tail?

[emilyalbini]

Ping from triage @nox@alexcrichton! What we should do with this PR?

[Centril]

I propose that we just pick one of the suboptimal names proposed for now and optimize it during stabilization; maybe we'll have better ideas by then?

[Centril]

Also; I noticed that impl Default for &'_ mut str so the unsafe block can/should be replaced with a call to default.

[shepmaster]

pick one of the suboptimal names proposed for now and optimize it during stabilization; maybe we'll have better ideas by then

Can we say that explicitly in the docs somehow? "If you don't like this name, pop on over to #XXXXX and paint the bikeshed"

[Centril]

@shepmaster SGTM 👍

[alexcrichton]

Looks like this hasn't been updated in awhile so I'm going to close, but feel free to resubmit of course! I think @Centril's idea above makes sense to me too!

[nox]

I completely forgot this PR. I'm currently doing a crate for slices represented as a pair of start and end pointers (like slice::Iter) and I'm thinking that split_off should rather live on slice::Iter, given its representation fits the use case better.

[cramertj]

@nox I started on a revival of it in #62282