Overloading doesn't scale when there are tons of ways of making a `String`. I don't see why `Into<String>` is "out of your way"; it's actually less verbose than overloading.

Into<String> is "out of your way" compared to having a String parameter in Rust. (Thus the person writing the code is expressly asking for the interface to allow implicit copying.) It is not being compared to C++ overloading. (The point is, this is more "out of your way" than you have to go in C++, where using an unoverloaded argument type of std::string will get you copying with opportunistic moving, and where a const std::string& will get you copying somewhere on the inside of the function. Thus Rust protects you from accidental expensive copies.)

Yeah, and this is one of the many reasons why performance programmers usually do not touch std::string.

Yeah, they might want some sort of string type that you can't implicitly copy, like Rust's.

Rust's String does not implement Copy. &str does. (That means Strings aren't ever implicitly copied.)

That's what I said.

Ah, now that you say that, I see that my brain produced a _very_ poor parse. Sorry :(

I was speaking in TI-85 and you were reading in TI-83 :)