Implement Vec::splice and String::splice

[SimonSapin]

RFC: rust-lang/rfcs#1432, tracking issue: #32310

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (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.

[SimonSapin]

I’d like some other opinions here. Getting this guess wrong either way causes the tail to be moved twice.

• If we over-estimate (which it the moment only happens if size_hint is incorrect) we reserve more space than necessary in the vector. But that space can still be used later (with further calls to Vec::push and friends). Vec::reserve often over-allocates anyway.
• If we under-estimate, we allocate a temporary vector and soon drop it.

Maybe over-estimating is better, and this should use the upper bound when it’s Some? (And fall back to the lower bound otherwise.)

[bluss]

Maybe if the optimistic route is only used if Some(lower) == upper, i.e the iterator claims to know its exact size?

[SimonSapin]

If Some(lower) == upper we already use that. If they’re accurate the Vec we then collect is zero-length. The question is what to do when the two bounds are not equal?

[bluss]

This condition lower_bound > 0 could be replaced by lower_bound > 0 && Some(lower_bound) == _upper_bound. Just to clarify what I mean.

[SimonSapin]

Ok, I see. In that case we’d avoid moving "tail" elements twice, but we’d allocate a temporary Vec in more cases.

[SimonSapin]

It may also make sense to rewrite drain to be based on splice (and std::iter::empty) rather than the reverse. In that case, could Drain be a pub type Drain<'a, T> = Splice<'a, Empty<T>> type alias or would it have to be a wrapper struct?

[apasel422]

s/Create/Creates/

[SimonSapin]

All three fixed, thanks.

[SimonSapin]

While we’re talking API (#32355 (comment)), should the replace_with argument of String::splice be I: Iterator<Item=char> rather than &str?

[alexcrichton]

Hm for consistency it seems like you may want that but on the other hand it seems like most of the time you'd want to splice in another slice. It's also arguably less performant as splicing a slice would require decoding and re-encoding utf-8, although perhaps we could recover the performance through specialization?

This may be a good question to have open for stabilization (and the tracking issue), but doesn't necessarily seem like an immediately blocker for landing the PR.

[SimonSapin]

There is indeed the UTF-8 round-trip overhead, and also the accuracy loss of size_hint. The lower bound of str:Chars::size_hint is utf8_len / 4.

[alexcrichton]

Hm the loss of size_hint may be killer for now, perhaps &str can be favored?

[SimonSapin]

I’m fine with sticking to &str.

[bors]

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

[alexcrichton]

ping @SimonSapin, any update on this?

[SimonSapin]

I still need to write more tests and haven’t taken the time to do it yet. If someone wants to do so before I do, feel free.

[alexcrichton]

Ok, in that case I'm gonna close this out of inactivity, but feel free to reopen/resubmit once the tests are there!

[solson]

@alexcrichton Is there some way we can advertise this to see if someone wants to work on it? I hate to see merged RFCs go unimplemented for so long.

[alexcrichton]

@solson an interesting idea! @rust-lang/libs, thoughts?

[glaebhoerl]

There is (or used to be?) a "help wanted" section in TWiR...

[aturon]

I added a comment to the tracking issue and marked it "help wanted", which (I think?) will lead it to TWiR (@brson?).

We ultimately should do something more persistent and general, maybe on the roadmap tracker.