Add borrowed-only versions of data structs in ZeroVec

[sffc]

Part of #1082

Depends on #1078

zerovec is capable of supporting no_std, including no heap allocations. To achieve this, we should make public versions of ZeroVec, VarZeroVec, and ZeroMap that are borrow-only.

Some caveats:

• Can we make ICU4X data structs no_std at the same time?
• How to avoid code duplication?

CC @Manishearth

[Manishearth]

Work items involved here, as an inverted dependency tree:

old list

• Support infinite nesting in VZV (VZVOwned) , WIP in Support for infinitely nesting VarZeroVecs #1065
  • make VZVOwned/Borrowed public
    • Add ZeroMapBorrowed (needed by @sffc for Migrate BlobProvider to ZeroMap #1056), fixes this issue
  • restrcuture AsVarULE to move as_unaligned (needed by @zbraniecki for PluralRuleStringsV1 should be parsed at data load time #615)
    • custom derive for AsVarULE and friends (not currently needed, probably won't work on just yet)
  • improve VZV's mutation ops

list moved to #1082

[sffc]

Writing down some of my thoughts:

I feel that the AsVarULE trait is fraught. I think a lot of operations would be easier to reason about if VarZeroVec were parameterized by the VarULE type directly, rather than the AsVarULE type.

For example:

• VarZeroVec<str> is a vector of strings.
• VarZeroVec<[u8]> is a vector of blobs.
• VarZeroVec<FooULE> is a vector of FooULEs, which must be a VarULE type.

Nesting:

• VarZeroVec<ZeroVecULE<u16>> is a vector of u16 vectors.
• VarZeroVec<VarZeroVecULE<ZeroVecULE<u16>>> is a 3D vector of u16.

The contract for VarZeroVec is simply that the type in the vector must be #[repr] with a variable-length byte slice.

The other advantage is that by making the VarULE type front and center, we encourage developers to think in terms of the VarULE throughout their program, rather than in some other abstraction that may be less efficient or require conversions to/from the VarULE.

[Manishearth]

Some things to make requirements of the VarULE and ULE trait

• no padding bytes, all bytes are initialized (allows us to treat them as u8 slices safely)
• equality is byte equality (should AsVarULE require Eq?)

[sffc]

• no padding bytes, all bytes are initialized (allows us to treat them as u8 slices safely)

+1

• equality is byte equality (should AsVarULE require Eq?)

Yes, and we should also require that the parser reject any input that is not in canonical form. For example, "1.00e3" and "10.0e2" are semantically equal, but only the former is in canonical form.

With these new constraints, can people implement ULE/VarULE without any unsafe code? (Maybe except for a single "unsafe" on the trait impl to assert that all the constraints are satisfied.)

[Manishearth]

With these new constraints, can people implement ULE/VarULE without any unsafe code? (Maybe except for a single "unsafe" on the trait impl to assert that all the constraints are satisfied.)

No because they both expose unsafe fns as well. I don't think this is a useful metric to optimize for.

[Manishearth]

Another potential improvement might be to get rid of AsVarULE entirely and have people directly use ULE types

[sffc]

Related: type structure for ZeroMap. Removing AsVarULE requires making changes to the ZeroMap traits. (Follow-up to #1057 (comment))

[Manishearth]

I moved the list of work items to #1082. "Get rid of AsVarULE" is #615

[Manishearth]

As a part of this we should make make_mut() public on ZeroVec (and perhaps rename both to to_mut())