Well, you do support only vector containers, by having the limitation of first++ as only iter increment.
Your name "array" clashes with the C++ array, which is a compile-time sized vector. And your array is unsafe sized, as last is the only size provision, even unsafer than C++ with its unsafe iterators. With C++ you can it least still bounds check against the vector size.
Your variant being static is indeed nice, the STL, CTL cannot do that, just MTL exists for that. Which supports all containers.
E.g. Non-vector types allow for much faster inserts.
You can only replace insitu, which is the opposite of functional. No backtracking. Manual copying needed. The spirit of the STL algorithms is to allocate, not overwrite.
Re hash-map: this is not even finished. For now it's just a pointer-stable unordered_map with optimizations for all types, primitives or strings. optimized Swisstable (string) and Stanford hashes (u64) are in work (no time for that), and are indeed multiple times faster.
> And your array is unsafe sized, as last is the only size provision, even unsafer than C++ with its unsafe iterators.
Can you explain more? C++ <algorithm> is intended to be used for C pointers as well. The iterator concept is an abstraction of pointer.
> You can only replace insitu
I'm not sure what you mean. The replace/remove/unique work just like the C++ versions. The STL recognizes there are cases when you want to work in-place, and others when you want to use a separate buffer. That's why it provides multiple versions.
> the spirit of the STL algorithms is to allocate, not overwrite.
I don't believe this is true. It's designed to separate memory allocation concerns from the algorithm. That's why a lot of them require you to provide a buffer satisfying some requirements.
Your variant being static is indeed nice, the STL, CTL cannot do that, just MTL exists for that. Which supports all containers. E.g. Non-vector types allow for much faster inserts.
You can only replace insitu, which is the opposite of functional. No backtracking. Manual copying needed. The spirit of the STL algorithms is to allocate, not overwrite.
Re hash-map: this is not even finished. For now it's just a pointer-stable unordered_map with optimizations for all types, primitives or strings. optimized Swisstable (string) and Stanford hashes (u64) are in work (no time for that), and are indeed multiple times faster.