4 ms·
That's no different from having a C++ function that takes a std::string, or overloads for const std::string& and std::string&&, instead of only accepting one.
by SamReidHughes 11y ago
That's no different from having a C++ function that takes a std::string, or overloads for const std::string& and std::string&&, instead of only accepting one. Only you have to go out of your way to have Into<String> to do it. And we're talking about an API to make queries to send remotely.
- jblow 11y agoYeah, and this is one of the many reasons why performance programmers usually do not touch std::string.
- SamReidHughes 11y agoYeah, they might want some sort of string type that you can't implicitly copy, like Rust's.
- steveklabnik 11y agoRust's String does not implement Copy. &str does. (That means Strings aren't ever implicitly copied.)
- SamReidHughes 11y agoThat's what I said.
- steveklabnik 11y agoAh, now that you say that, I see that my brain produced a _very_ poor parse. Sorry :(
- SamReidHughes 11y agoI was speaking in TI-85 and you were reading in TI-83 :)
- Manishearth 11y agoOverloading 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.
- SamReidHughes 11y agoInto<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.)