str module allocates too much; proposal for improvement

[Kimundi]

I was looking over the str module and noticed that a lot of the functions there do unnecessary allocations. I counted ~20 functions that return either an ~str or ~[~str] where a &str or a bunch of &str would do. (they're mostly search / trim functions)

I'd like to change them, however I'm not sure if that would be the best way in regards to API design.

My proposal is:

• Every function that returns ~str but could also return an &str will get changed to do so. If users want to have an explicit copy, they have to call to_uniqe() or similar.
• Every function that returns an ~[~str] but could also return return a list of &str will get rewritten under an other name to work as an iterator that takes an fn(&str) -> bool closure. The original name still remains, and will just wrap that iterator in an ~[~str].
• Remove the view functions, make the slice ones return &str (mirrors recent change to vec)

[catamorphism]

Agreed. Function argument types should be as general as possible (but no more general).

[pcwalton]

+1

[huonw]

I started doing something along these lines without seeing this issue. So far I've basically just done the first point (WIP, str.rs), I'm happy to continue with the rest of your proposal @Kimundi, or let you do it, either is fine. What do you think? (edit: this is resolved, Kimundi and I had a discussion on IRC: he's almost done and will continue with the work.)

[huonw]

#5422 seems to fit into this issue too.

[Kimundi]

The view <-> slice change is done now, now working on the cases that return ~str

[Kimundi]

All changes listed here have been implemented, closing issue.