I intend to write 6 reasonably-general high-quality data structures that's complies with the standards of the std to submit it to the std.

Data structure summery(details on the github):
---

1. Ring array: an array with an access pattern that loops back on itself rather then overflowing
2. Opinionated list of lists: A array of nullable!T, where null is an end of a list.
3. Metadata: like nullable, but adds additional 7 bit int to round out the wasted space of nullable, and more flexible in usage pattern.
4. Member index arrays: A lighter version of SoA. Given a user defined T and a member of T, packs the designated members together for better cache usage for searches.
5. Fixed length string: When you want char[n] rather then the default char[].
6. Semi-static array: no gc, copy to larger array during overflow and custom allocator friendly array abstraction.

-----------

Month 1
----

* Get a dub package up and running.
* Get ring arrays to "feature complete".
* Make a *bodged* a-b fuzzy race testing/benchmarking framework that generates markdown test results.
  * Bodged: makeshift, slipshod, not intended to be stable.
* Make prototypes for the other 5 data structures.
* Learn d style and inline documentation system the community likes, adding it to ring array

Month 2
---

* Make/find a more robust testing system.
  * testing correctness of specific cases, as opposed to a fuzzer and benchmarker.
* Publish a-b test *results* on github inviting the community to criticize it in issues.
* Improve 3 more data structures to "feature complete".
  * The flexibility of which data structures is intended. To pace myself, or for interdependence, for example I will use metadata in opinionated list of list.

Month 3
---

* Improve remaining data structures to "feature complete".
* "Finalize" ring array.
* Respond to community feedback.

Month 4
---

* "Finalize" remaining data structures.
* Submit code to the std review process.

----

https://github.com/crazymonkyyy/datastuctureplayground
I primarily am in the discord.

So, what I'm worried about is making member indexed arrays in such a way that is standards complaint.

I have written a (semi-) functional aosoa, but my abstractions there where very much mine, and heavy template abuse *to the point it only worked on one compiler*.


```
struct cow{
  vec2 pos;
  vec2 vel;
  int milk;
  void update(){
    pos+=vel;
    milk++;
}}
memberindexedarray!(cow,pos) cows;
cows[0..100].map!update;
```

Making that work while deconstruction the cow into pieces is possible the abstraction I used in aosoa was "pointy" or roughly
```
struct pointy!cow{
  vec2* pos;
  partialcow* partialcow_;
  ... etc
}
```

with allot of really jank code that I was told repeatably was ugly.

While this is simpler then what I had, its still the same sort of problem and I expect to be playing with the edges of the compilers definition where the bugs are.

context:
https://www.youtube.com/watch?v=YGTZr6bmNmk - a lecture of what aosoa is, *in human*
https://www.dataorienteddesign.com/dodbook/node7.html#SECTION00720000000000000000 - the chapter of the "dod book" of the idea for this came form
https://github.com/crazymonkyyy/monkeydata - my aosoa lib
https://github.com/crazymonkyyy/datastuctureplayground/blob/master/planning/definetely%20doing/indexedarray.md -my current thoughts on member indexed arrays