3 ms·

If &[T] is somewhat generic already, why even have 'Drawable' in the signature? Also, doesn't having a borrowed array of unique references to Drawables mean th

• pcwalton 13y ago
  > If &[T] is somewhat generic already, why even have 'Drawable' in the signature? `&[T]` isn't generic: it's a bounds-checked slice. Two pointers: start and end. Presumably `Drawable` is in the signature so that methods specific to `Drawable` can be called. > Also, doesn't having a borrowed array of unique references to Drawables mean the elements of the array are either now implicitly borrowed, or I have to borrow each of them before they're accessed? They work like anything else: if you want to take a reference to a Drawable, you borrow it. > Just knowing the symbols don't make the semantics clear. Yes. Also true for C++'s symbols; e.g. `&`. > In C++ all smart pointers are values in their own right. Same in Rust. > In my example I have a reference to an array of smart pointers, and there's no magic. Same in that example.
  • nly 13y ago
    A good test for me is whether the simplest possible implementation works: template <typename Range> void draw_all (Range r) { for (e : r) { draw(e); } } There are no magical symbols here at all. It's not efficient, but it's completely memory safe... breaks with unique_ptr though, which is a good indication for me that unique_ptr is the wrong choice. Here's the less safe 'borrowing' version: template <typename Range> void draw_all (Range const& r) { for (e const& : r) { draw(e); } } and a sane compromise: template <typename Range> void draw_all (Range r) { for (e const& : r) { draw(e); } } How would you write all of these in Rust?
    • pcwalton 13y ago
      The reason for use of a unique pointer is that if the caller had an array of unique pointers to Drawables, then you want the caller to be able to call draw_all() without recreating the array. You could come up with a generic function that doesn't require unique ownership (for example, one that takes an Iterator<&Drawable>), but the function in that example wasn't generic because making everything generic just in case is overengineering. You seem pretty confused about how borrowing works. Borrowing is tangential to that function.
      • nly 13y ago
        I'm not confused about borrowing, what I'm saying is is that borrowing, plain refs in C++, are a performance hack in both languages. In my final version above, I have assumed copying a range is cheap, and copying a Drawable is expensive and unnecessary... seems perfect to me, and it will not compile passing a vector of unique_ptr's, which is what I would want
        • pcwalton 13y ago
          References are not a performance hack; they're a fundamental way to avoid lots of moves, which obscure algorithms and cause a lot of mutation. (In Rust they are memory safe.) Anyway, if you wanted a generic reference-taking version: fn draw_all<I:Iterator<&Drawable>>(iterator: I) { for drawable in iterator { drawable.draw(); } } And a generic move version: fn draw_all<I:Iterator<Drawable>>(iterator: I) { for drawable in iterator { drawable.draw(); } }
          • nly 13y ago
            Internal moves make no sense. You can't move an object out of a container that has invariants, like an ordered map. This is why it only makes sense for the caller to move a container in to the function. This is efficient. I've edited my 3rd version appropriately, as moving from a const& was clearly bogus. template <typename Range> void draw_all (Range r) { for (e const& : r) { draw(e); } }