Static arrays are the best vectors

As many (or most) of C++ features, std::array is a logical idea with terrible ergonomics, bordering to unusable. While they are potentially a little safer to use than plain C arrays (but compilers could easily add runtime checking for plain C arrays too), they are much less ergonomic, both in verbosity of declaration and errors.

They can't replace an init-allocated std::vector either, because they have a size fixed at compile time.

And unique_ptr itself is TERRIBLE to use too. If RAII is your thing, then still very often, it's totally worth the boilerplate to wrap individual objects in type-specific explicit "Holder classes", instead of relying on std::unique_ptr which has terrible ergonomics too, again both for declaration and use.

Oh, and if you're using a free-standing destructor function for the managed object (which is often a very good idea because exposing the class definition in typical C++ style leads to TERRIBLE TERRIBLE compile times), you'll have to bake in a function pointer that is carried by unique_ptr at runtime (I suspect that is because they couldn't make the function a templated parameter because in C++, this leads to ambiguitiy if it is a static inline function declared in a header (terrible!)). So you're paying for all the all the drawbacks of the templated type and get none of the benefits (except for saving a few lines of boilerplate).

TERRIBLE.

And now you propose combining these two terrible things? How would you use this?

    #include <memory>
    #include <array>

    struct Foo
    {
        ~Foo()
        {
            printf("Bye!\n");
        }
    };

    int main()
    {
        // std::unique_ptr<std::array<Foo, 42>> foo = std::make_unique<std::array<Foo, 42>>();  // my fingers hurt and my eyes bleed
        auto foo = std::make_unique<std::array<Foo, 42>>();  // fingers hurt a little less but my brain will melt on next compiler error
        foo->at(0);  // valid
        foo[0];  // error. TERRIBLE!
        return 0;
    }