Some times one only needs an array of four elements and feel that bound checks might be overkill for the initial use case, but as complexity grows and it does not feel safe anymore, one either encapsulate the dangerous array in an object that slowly reimplements every feature in List, or slap on SafePointer on top of the dangerous array, where one can forget to multiply the safe region's size by element size or forget to change which element type you take the size of when copying code.
The framework should not force one to choose between optimal performance and safety checks, so more collection types are needed.
If the Array, Field and List collections can inherit statically from more generic collections that are independent of storage, one can use the same collection interfaces for both heap allocations and fixed size collections with an upper limit decided in compile time. Then an array can still be allocated with 3 elements even if 4 are reserved, to avoid depending on Variable Length Array extensions.
Then each will contain an allocator directly by value, which must define allocation methods for elements for the interfaces to call. The allocator should contain either a handle to a heap allocation, a DestructibleVirtualStackAllocation pointing to virtual stack memory, or a fixed size array for allocating directly in a structure or regular stack memory.
Define List as ListInterface<T, HeapAllocator>.
Define StackList as ListInterface<T, VirtualStackAllocator>.
Define FixedList<T, MAX_LENGTH> as ListInterface<T, FixedAllocator<T, MAX_LENGTH>>.
The same can be done for Array and Field.
Can start by refactoring the existing types to separate allocation from collection interfaces. Then introduce fixed and virtual stack allocators.
Some times one only needs an array of four elements and feel that bound checks might be overkill for the initial use case, but as complexity grows and it does not feel safe anymore, one either encapsulate the dangerous array in an object that slowly reimplements every feature in List, or slap on SafePointer on top of the dangerous array, where one can forget to multiply the safe region's size by element size or forget to change which element type you take the size of when copying code.
The framework should not force one to choose between optimal performance and safety checks, so more collection types are needed.
If the Array, Field and List collections can inherit statically from more generic collections that are independent of storage, one can use the same collection interfaces for both heap allocations and fixed size collections with an upper limit decided in compile time. Then an array can still be allocated with 3 elements even if 4 are reserved, to avoid depending on Variable Length Array extensions.
Then each will contain an allocator directly by value, which must define allocation methods for elements for the interfaces to call. The allocator should contain either a handle to a heap allocation, a DestructibleVirtualStackAllocation pointing to virtual stack memory, or a fixed size array for allocating directly in a structure or regular stack memory.
Define List as ListInterface<T, HeapAllocator>.
Define StackList as ListInterface<T, VirtualStackAllocator>.
Define FixedList<T, MAX_LENGTH> as ListInterface<T, FixedAllocator<T, MAX_LENGTH>>.
The same can be done for Array and Field.
Can start by refactoring the existing types to separate allocation from collection interfaces. Then introduce fixed and virtual stack allocators.