Shane F. Carr

Note that I don't want to put in work and change APIs to be fallible if we eventually are going to do the auto-sizing approach. So we should keep this...

> We can stop on the way at a const generic approach but note that we can't currently do `struct VZV` since defaults on consts are unstable, so I'd prefer...

An algorithm for expanding or contracting the index array can be written in O(N) time, with N = length of the byte buffer. 1. When contracting, say from 4 bytes...

Another question is how exactly we define the boundary. I see two ways to define it: 1. When the length of the entire buffer exceeds the capacity of the integer...

Hmm. I wonder if we should have two width parameters: one for the width of the length field, and the other for the width of the index fields. There is...

> I don't think it's worth attempting to save the 1-3 bytes we can save by optimizing for the length field having a different length Let's answer [this question](https://github.com/unicode-org/icu4x/issues/1410#issuecomment-998217578) first....

Another option would be to keep the number of elements fixed at 2^32 but allow the data array to scale in length. But then we still need to add fallible...

I think the fallibility question is the big crux. Vec is not fallible, because it grows to however big it needs, which is as big as `usize` supports. In order...

If VZV is fallible, then we should make ZeroMap fallible, too. I'm not comfortable making VZV fallible but not ZeroMap. I don't know how concerned I am with OOMs. That's...

I don't understand what you're suggesting about the OOM. If we're deserializing zero-copy, the memory has already been allocated, and we are just pointing to it. There is no memory...