Tracking Issue for split_inclusive

[golddranks]

This is a tracking issue for split_inclusive APIs for slice and str.
The feature gate for the issue is #![feature(split_inclusive)].

API overview

• Implement split_inclusive for slice and str and split_inclusive_mut for slice
• split_inclusive is a substring/subslice splitting iterator that includes the matched part in the iterated substrings as a terminator.
• Two examples below:

    let data = "\nMäry häd ä little lämb\nLittle lämb\n";
    let split: Vec<&str> = data.split_inclusive('\n').collect();
    assert_eq!(split, ["\n", "Märy häd ä little lämb\n", "Little lämb\n"]);

    let uppercase_separated = "SheePSharKTurtlECaT";
    let mut first_char = true;
    let split: Vec<&str> = uppercase_separated.split_inclusive(|c: char| {
        let split = !first_char && c.is_uppercase();
        first_char = split;
        split
    }).collect();
    assert_eq!(split, ["SheeP", "SharK", "TurtlE", "CaT"]);

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC
• Adjust documentation
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

No known unresolved questions at the moment.

Implementation history

Implementation: #67330

[matklad]

We also need str::lines_inclusive -- like .lines(), but keeps line endings. We can stabilize/implement these separately, but we must make sure that the naming is consistent.

EDIT: wait, I guess lines_inclusive is just .split_inclusive('\n')? By happy accident, it will magically handle both \r\n and optional trailing newline correctly? Then we might get by without dedicated method, and just call out this pattern in the docs.

[golddranks]

@matklad I planned using it also for lines_inclusive -like functionality, but didn't thought about it exhaustively. Indeed, it's a nice plus that \r\n seems to work. I guess that \r (and especially the others https://en.wikipedia.org/wiki/Newline#Representation) is such a rarity these days that another method is not warranted.

I'll send a doc PR for that use case!

Also, I think that a stabilization would be warranted soonish. What ya'll think?