Thanks for sharing. I have implemented a very similar data structure for another purpose: editing large files (text) using some tricks with `mmap` / `memfiles` to minimize RAM requirements (& time to load a file); which I have called a PSeq for "partitioned" seq (constant partitions/chunk size to reduce latency for editing ops; i.e. insertions/deletions). My `PSeq` implementation is currently using a `seq` to hold the partitions with a set capacity (to ensure it doesn't realloc, i.e. I am using a seq as a "FixedSizeSeq"). I'll try out this or a variant of this implementation when I get the time.
Thoughts: 1. "Pinned" is a nice name to describe the concept of not reallocating the underlying memory. 2. Should `seq` be a concept & that way might be able to reduce the "The cost is that it's not convertible to an openArray"? 3. `delete` and `del` (for `delete` you could use `moveMem`; although with the exponential growth of each chunks this may be quite expensive) 4. Surprised you don't have an `=destroy` proc and have a manual `destroy` proc; why? 5. (low priority): `extend` method (using `moveMem`) > The cost is that it's not convertible to an openArray Maybe this speaks more > to a hole in the design of the standard library (& maybe nim's iterators > too?), e.g. for libs like sequtils, algorithm: when I first saw these > libraries, I was surprised concepts were not utilized here. e.g. for algorithms compare C++'s [lower_bound](https://en.cppreference.com/w/cpp/algorithm/lower_bound) to Nim's [lowerBound](https://nim-lang.org/docs/algorithm.html#lowerBound%2CopenArray%5BT%5D%2CK%2Cproc%28T%2CK%29); C++'s works on a [ForwardIt](https://en.cppreference.com/w/cpp/named_req/ForwardIterator); Nim's only works on an `openArray` (or anything convertible to this). As I think more deeply about it this is not a trivial problem to solve as details matter here as you can't just define a "ForwardIterator" concept on any `T` defining an `items` iterator or `[]` proc (as I first thoiught), e.g. for `lower_bound` you need to know the range (`begin`/`end`) & number of elements between them (`n`) you can't get this information on an `items` iterator trivially (you'd need a "Range"/"Slice" concept for this example?) Is there any relevant RFCs/work being done with respect to this?
