Description
See also: #5523, for the holistic design for helper ULE abstractions
The original design of ZeroVec and VarZeroVec was for them to be Cow-like types that fully supported mutation. In practice; the mutation isn't that useful, and if we really wanted to we could expose MutableZeroVec, etc that is a safe wrapper around ZeroSlice/Vec. The current VarZeroVec in-format mutation code is unsafe and complex and also overall unused except by ZeroMap construction, and we want to remove it too #5582.
The goals of "a vector I can mutate" vs "a vector that serializes and deserializes easily" seem to be overall separate: for ser/de stuff you want a potentially-Cow-like type where the owned and borrowed variants both deref to the same buffer format ([Var]ZeroSlice), but for mutation it's better to have Cow<[Var]ZeroSlice> with a Vec<T> or Vec<Box<T>> owned side.
@sffc and I discussed this a bunch and a path we think is promising is:
ZeroVec/VarZeroVec become immutable. If you wish to mutate them, you should convert to a vector and mutate that, and convert back. We can also add MutableZeroVec/MutableVarZeroVec that is a simple enum between Vec<T> and the slice type.
They then get represented using something like ZeroCow (first proposed in #5561), which we can start off as an internal abstraction. We don't need to bitpack the discriminant and introduce an additional operation in the length check; rather we can restrict lengths to being 32 bits (we need to anyway for things to work cross platform) and have an additional owned/borrowed discriminant after that.