9 ms·

Those are very lightweight abstractions as the compiler will generate optimized code for each variant separately. That's the entire point of Rust Trait abstract

Those are very lightweight abstractions as the compiler will generate optimized code for each variant separately. That's the entire point of Rust Trait abstractions.

jblow 11y ago
I am talking about the actual conversion of an unowned object to an owned object, which as nearly as I can tell involves copying the object? Implicitly? All the time?
- MichaelGG 11y ago
  Only if the user is providing borrowed strings in the first place, in which case, there's not much choice. If the user can provide an owned string, it'll just use that, no copy.
- 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 ago
    Yeah, and this is one of the many reasons why performance programmers usually do not touch std::string.
    - SamReidHughes 11y ago
      Yeah, they might want some sort of string type that you can't implicitly copy, like Rust's.
      - steveklabnik 11y ago
        Rust's String does not implement Copy. &str does. (That means Strings aren't ever implicitly copied.)
        SamReidHughes 11y ago
        That's what I said.
        steveklabnik 11y ago
        Ah, now that you say that, I see that my brain produced a _very_ poor parse. Sorry :(
        SamReidHughes 11y ago
        I was speaking in TI-85 and you were reading in TI-83 :)
  - Manishearth 11y ago
    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.
    - SamReidHughes 11y ago
      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.)
- pcwalton 11y ago
  Well, it's not implicit. It's explicit both inside the function body (".into()") and in the function signature (where "into" alerts the user that something may be going on). You can also avoid the copy by just supplying String in the first place, in which case it gets moved (avoiding the allocation), not copied.
  - jblow 11y ago
    I see. Having to say .into() makes me feel a little better about it. But it does make it clear there is a runtime performance cost to insisting on a strict ownership model.
    - pcwalton 11y ago
      If the API has to hang onto the string, sure. But not all APIs have to do that. The only reason why the Elasticsearch API requires owned strings in this case is that the JSON API does, and this is a trait that many JSON APIs share, regardless of language. (For example, the first Google result for "c json api" pulls up this API [1], which also copies strings.) You could write a JSON API that doesn't insist on a strict ownership model, if you wanted. There is even a type, MaybeOwned [2], in the standard library to support this kind of API. In such a library, the JSON type would have a lifetime parameter, which could be 'static for owned strings, but which could be non-static for JSON types that contain references to strings. [1]: https://jansson.readthedocs.org/en/2.7/apiref.html#string https://jansson.readthedocs.org/en/2.7/apiref.html#string [2]: http://doc.rust-lang.org/0.11.0/collections/str/type.MaybeOwned.html http://doc.rust-lang.org/0.11.0/collections/str/type.MaybeOw...
      - dbaupp 11y ago
        Incidentally, MaybeOwned is now written `Cow<str>`. http://doc.rust-lang.org/std/borrow/enum.Cow.html http://doc.rust-lang.org/std/borrow/enum.Cow.html
    - deleted 11y ago
      [deleted]
    - 11y ago
- tatterdemalion 11y ago
  Rust also has the AsRef<T> trait, which converts to a reference, hopefully without copying. Functions which do not need to take ownership of the object should take an AsRef<T> instead of an Into<T>.
- deleted 11y ago
  [deleted]

Those are very lightweight abstractions as the compiler will generate optimized code for each variant separately. That's the entire point of Rust Trait abstractions.

jblow 11y ago

I am talking about the actual conversion of an unowned object to an owned object, which as nearly as I can tell involves copying the object? Implicitly? All the time?

MichaelGG 11y ago
Only if the user is providing borrowed strings in the first place, in which case, there's not much choice. If the user can provide an owned string, it'll just use that, no copy.
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 ago
  Yeah, and this is one of the many reasons why performance programmers usually do not touch std::string.
  - SamReidHughes 11y ago
    Yeah, they might want some sort of string type that you can't implicitly copy, like Rust's.
    - steveklabnik 11y ago
      Rust's String does not implement Copy. &str does. (That means Strings aren't ever implicitly copied.)
      - SamReidHughes 11y ago
        That's what I said.
        steveklabnik 11y ago
        Ah, now that you say that, I see that my brain produced a _very_ poor parse. Sorry :(
        SamReidHughes 11y ago
        I was speaking in TI-85 and you were reading in TI-83 :)
- Manishearth 11y ago
  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.
  - SamReidHughes 11y ago
    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.)
pcwalton 11y ago
Well, it's not implicit. It's explicit both inside the function body (".into()") and in the function signature (where "into" alerts the user that something may be going on). You can also avoid the copy by just supplying String in the first place, in which case it gets moved (avoiding the allocation), not copied.
- jblow 11y ago
  I see. Having to say .into() makes me feel a little better about it. But it does make it clear there is a runtime performance cost to insisting on a strict ownership model.
  - pcwalton 11y ago
    If the API has to hang onto the string, sure. But not all APIs have to do that. The only reason why the Elasticsearch API requires owned strings in this case is that the JSON API does, and this is a trait that many JSON APIs share, regardless of language. (For example, the first Google result for "c json api" pulls up this API [1], which also copies strings.) You could write a JSON API that doesn't insist on a strict ownership model, if you wanted. There is even a type, MaybeOwned [2], in the standard library to support this kind of API. In such a library, the JSON type would have a lifetime parameter, which could be 'static for owned strings, but which could be non-static for JSON types that contain references to strings. [1]: https://jansson.readthedocs.org/en/2.7/apiref.html#string https://jansson.readthedocs.org/en/2.7/apiref.html#string [2]: http://doc.rust-lang.org/0.11.0/collections/str/type.MaybeOwned.html http://doc.rust-lang.org/0.11.0/collections/str/type.MaybeOw...
    - dbaupp 11y ago
      Incidentally, MaybeOwned is now written `Cow<str>`. http://doc.rust-lang.org/std/borrow/enum.Cow.html http://doc.rust-lang.org/std/borrow/enum.Cow.html
  - deleted 11y ago
    [deleted]
  - 11y ago
tatterdemalion 11y ago
Rust also has the AsRef<T> trait, which converts to a reference, hopefully without copying. Functions which do not need to take ownership of the object should take an AsRef<T> instead of an Into<T>.
deleted 11y ago
[deleted]