New str and String API

[bluss]

Proposed new str or String API

• String::insert_str(&mut self, index: usize, s: &str)
  Just like insert(&mut self, usize, char), but for a string piece. Insertion is inherently inefficient, but this impl will be better than the user having to create an entirely new String.
• String::splice<R>(&mut self, range: R, s: &str)
  Combine drain and insert_str, allow both removing a range and replacing it with a new string in one operation. Remove range, insert s at range.start.
• str::repeat(&self, n: usize) -> String
  Convenience to repeat a String. Will size the result correctly up front, so it's both simpler and faster than in-code iterator based solutions.

[Stebalien]

splice would be a good method to have on Vec as well.

[bluss]

Yep. I've started experimental implementations here for the moment, including Vec::splice. It doesn't compile perfectly though since it uses iterator input. But it's a nice real use of ExactSizeIterator.

[Gankra]

fwiw splice could be insert with Sufficient Generics.

[eefriedman]

Relevant motivating example: https://github.com/servo/rust-url/blob/2be081e5fad04efc321e51f795aa2b95d21f4c10/src/parser.rs#L563 uses unsafe code to emulate a special case of splice.

[Kimundi]

I'd like it if rather than adding new _str() variants, the existing ones taking char would just be made generic.

[bluss]

Ok. .push(char) and .push_str(&str) is the current precedent, but I agree.

[blaenk]

This sounds good to me bluss.

[cristicbz]

Isn't x.insert(index, y) equivalent to x.splice(index..index, y)? Do we need both?

[dbrodie]

Is there a reason not to have splice return an iterator over the removed values? That seems like a useful addition to have.

The implementation would just need to replace the items one at a time, as each one is taken from the returned iterator, and fallback to drain-like behavior otherwise.

[mbrubeck]

rust-lang/rust#34771 added insert_str.