aim: * [1]to make using 32 (or fewer) bit indices more ergonomic in rust 64bit builds (which currently requires continuous manual casting); * [2] To avoid signed vs unsigned friction (often indices do require interaction with signed values, eg offsets in convolutions etc) * [3] To allow strongly typed indices, e.g. differentiate between a Index32, Index32 etc to give more compile time checks on the correct use of index data.

There is hardware vectorized 32bit index support, and on a 16gb machine,pervasive 64bit indices are overkill: 2^30 * 16byte objects will fill memory,yet 32bit mode is insufficient;

Most applications will never fill memory with a single array.

Graphical applications often reason about explicit sizes e.g. with knowledge of what fits in GPU memory, optimal chunk sizes for rendering, etc. It is common to cluster/subdivide scenes with certain maximums for individual elements, giving the opportunity to leverage bit-reduction in both indexing and spatial precision within chunks.

approach:-

• 'Vec' is wrapped in Array
• there is an IndexTrait which must be implemented for indexable types, which must provide conversion to and from usize , for interop with the underlying rust vector implementation
• There are small 'Array2,Array3, Array4' types to replace [T;2],[T;3],[T;4] with similar support (WIP)

Unresolved Issues:- * no solution yet for slices (TODO!) * what to do about the .enumerate() adapter, which is incredibly useful and important for indexed reasoning; perhaps we have to implement a workalike to deal with this.

Possible future work:- It would be best to re-implement Vec itself with custom Length,Capacity fields, e.g. 'a 32bit indexed vector/64bit build' would take 16bytes for the struct instead of 24. This is lower priority, and it's possible the larger vec gives useful space for a SmallVec optimization later.