A minor remark: I find it remarkable how closely the proposed API mirrors the one of the BatArray.Cap interface, an Array submodule doing essentially the same thing contributed by David Teller in 2008. (Many details are different as
vec offers dynamically-resizable arrays, while
Array.Cap is fixed-size arrays, but this is orthogonal to the static control over mutability.)
To me this suggests that the
vec API is not actually specific to Rust, or at least that the inspiration arrived at the same point as the long tradition of “phantom types” in ML-family languages. (In this space I think the key idea popularized by Rust would be ownership (possibly with borrowing), and in particular the idea that by default mutable values should be uniquely-owned, while immutable values can easily be shared.)
This is not a criticism of the library itslef! I very much like the idea of having small modules that cover simple needs, rather than large monolithic libraries.
Question: in Batteries, my impression is that
Array.Cap was never used much. I would guess that the reason was that, for most users, the static guarantees of the interface did not offset the (mild) cost of the more complex types to manage. What is/are your use-case(s) where reasoning about mutation is important?