Add .insert() and .insert_char() methods to ~str.

[SimonSapin]

I could not run the tests because of unrelated building issue, sorry about that.

[thestinger]

One of the design decisions made by the C++ standard is to avoid exposing inefficient convenience methods like this. I would expect these on a rope type but I'm not really sure they make sense on a string.

There's also the issue of extending the usage of fairly meaningless byte indices.

[SimonSapin]

str.unshift_char is already there, and just as inefficient. Sometimes O(N) behavior is really what one wants. Should every program just re-implement basic methods like this?

As to byte indices, this can be changed to what ever .slice() and related methods are changed to, when and if they are changed.

[thestinger]

A program needing this should probably be using a rope though. The motivation behind that C++ design choice is to encourage using the right type, by making inefficient code inconvenient.

Inserting text into a Unicode code string is not trivial to do correctly, and we're not really helping by pretending it's as easy as giving a byte or code point index. A code point doesn't correspond to the semantic characters most programmers expect them to, and we're not helping them.

[SimonSapin]

I thought I needed this for punycode decoding, but it turns out I really needed ~[char] which does have .insert().

I still disagree with your argument, though. Yes, proper text handling is hard. That doesn’t mean we should not provide any and leave everyone to implement it themselves, possibly even more wrong than what we could have provided.

In any case, if the answer is "use a rope instead" it would be nice to have a rope type in libextra. (Although that’s not really related to this bug.)

[ghost]

str::slow::insert()?

[lbonn]

@SimonSapin There used to be a rope type in extra (until #7629), if this can be of any help.

[thestinger]

A rewrite is necessary for a correct, useful rope.

[SimonSapin]

This only reinforce my point that "just use a rope" is not the answer to insert on ~str.

Anyway, I finished implementing punycode, using insert on ~[char]: https://github.com/SimonSapin/rust-url/blob/master/punycode.rs
I consider this good enough. I’m not worried about O(n²)-ish behavior since n is not bigger than 63 for domain name labels.

[brson]

I don't particularly have a problem with this, though the docs could indicate the performance pitfalls as well as the behavior when the position isn't on a codepoint boundary. Any other opinions?

[thestinger]

@SimonSapin: I don't understand why the poor state of the standard library would be an argument against ropes.

[SimonSapin]

@brson Yes. I will update the pull request to do so. (Though this applies to the rest of the standard library as well.)

@thestinger I mean that #7629 is a sign that ropes are complex and not obvious to get right, and thus are not always a good answer to "I need to insert".

[thestinger]

The effort required to implement a type like a hash table, rope or balanced binary search tree says nothing about their ease of use or suitability for a certain purpose. Vectors obviously aren't easy to get right either because Rust's vectors are full of overflow bugs and are slow.

[adrientetar]

+1

[brson]

I do notice that vecs insert method has a different signature: fn insert(&mut self, i: uint, x:T). If we do add a string insert method it should probably have the same signature as vec.

[SimonSapin]

@brson Do you mean the order of the parameters? I can change that.

[brson]

@SimonSapin yeah, the argument order is different for the two.

[SimonSapin]

@brson Rebased, and fixed the argument order.