3 ms·

A common suggestion for this seems to be to use the stdlib GC mechanism (refcounting) for those cases, is that too limiting?

pjmlp 5y ago
Too boilerplaty. While other languages with RC based GC mechanisms take care of managing the references automatically, even the C++ std ones do it, in Rust you have to manually increment the references with calls to clone().
- ncmncm 5y ago
  Yes. Rust probably should have a built-in pimpl-y construct, in lieu of user-codable moves. (Maybe it does, by now? Dunno.)
  - pjmlp 5y ago
    It doesn't and I guess it will never get one, as it is apparently considered good practice that clone() calls are explicit, as in the developer is painfully made aware of the performance cost of reference counting. So then we land in Rust code golf, where one tries to make the code as much as possible with bare bones borrow checker.
    - ncmncm 5y ago
      Not real clear on this... In C++, pimpl types almost always have a std::unique_ptr<Impl> in them, and they get moved, not copied. The compiler generates the move constructor implicitly, and move cannot fail. Maybe in Rust this just a struct with a ref in it? And what would be member functions borrow from it?
      - pjmlp 5y ago
        Ah, sorry. I misunderstood your point, so went into another path. I don't see how this would work, Rust is already move by default, the problem is how to get std::shared_ptr() like convenience where copy member functions are called by the compiler, with the side effect of taking care of the counters implicitly. In Rust, copying is explicit, thus manually typing the copy()/clone() calls.
        ncmncm 5y ago
        Sorry, don't see how this touches on my question at all. I don't use shared_ptr in C++, and don't know any reason to make Arc nicer in Rust. My question was specifically about a Rust analog of the common idiom struct X { std::unique_ptr<XImpl> p; };
        pjmlp 5y ago
        You don't need that at all in Rust, all pointers are unique by default. My initial remark was regarding the ergonomics of reference counting, naturally for values greater than 1. The reason is exactly that, ergonomics and developer productivity. A reason usually taken into account when picking programming languages for a project, if multiple options are available.

pjmlp 5y ago

Too boilerplaty. While other languages with RC based GC mechanisms take care of managing the references automatically, even the C++ std ones do it, in Rust you have to manually increment the references with calls to clone().

ncmncm 5y ago
Yes. Rust probably should have a built-in pimpl-y construct, in lieu of user-codable moves. (Maybe it does, by now? Dunno.)
- pjmlp 5y ago
  It doesn't and I guess it will never get one, as it is apparently considered good practice that clone() calls are explicit, as in the developer is painfully made aware of the performance cost of reference counting. So then we land in Rust code golf, where one tries to make the code as much as possible with bare bones borrow checker.
  - ncmncm 5y ago
    Not real clear on this... In C++, pimpl types almost always have a std::unique_ptr<Impl> in them, and they get moved, not copied. The compiler generates the move constructor implicitly, and move cannot fail. Maybe in Rust this just a struct with a ref in it? And what would be member functions borrow from it?
    - pjmlp 5y ago
      Ah, sorry. I misunderstood your point, so went into another path. I don't see how this would work, Rust is already move by default, the problem is how to get std::shared_ptr() like convenience where copy member functions are called by the compiler, with the side effect of taking care of the counters implicitly. In Rust, copying is explicit, thus manually typing the copy()/clone() calls.
      - ncmncm 5y ago
        Sorry, don't see how this touches on my question at all. I don't use shared_ptr in C++, and don't know any reason to make Arc nicer in Rust. My question was specifically about a Rust analog of the common idiom struct X { std::unique_ptr<XImpl> p; };
        pjmlp 5y ago
        You don't need that at all in Rust, all pointers are unique by default. My initial remark was regarding the ergonomics of reference counting, naturally for values greater than 1. The reason is exactly that, ergonomics and developer productivity. A reason usually taken into account when picking programming languages for a project, if multiple options are available.