> 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.

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?

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.

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

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();
        }
    }

Using the container's iterator to move allows the container to enforce those invariants.

> * It restricted the type of range/container passed to it

Yes, it did, but as I mentioned before, it's overengineering to make everything generic that could possibly be generic.

> * It had unnatural ownership semantics (borrowing a box of unique things without saying you're borrowing those things is weird).

No, it's not, it's quite natural. `&[&Drawable]` is not a subtype of `&[~Drawable]`, so if your caller has an array of `&[~Drawable]`, then they would have to recreate the array to pass it to that function.

> * The implementation, as was, required further borrows which were only implied. In C++ you take everything straight away.

I don't understand what this means, but in any case C++ and Rust don't differ substantially on ownership/reference/move semantics.

Why is it a problem to "require further borrows which are only implied"? Borrows are compile-time only, and they conceptually happen anyway in your C++ implementation. It's just enforcing the correct ownership pattern in the compiler.