Array focused iterators

monkyyy crazymonkyyy at gmail.com
Thu Apr 11 18:19:00 UTC 2024


With D3 either from phoboes or open d I was hoping there be the 
will to update the range api to be just better, from my half 
dozen posts trying to get something started; thats clearly not 
the case.

A brief history of how d's iterators came about as I understand 
it is: stepov wanted to make the bestest data structure and 
algorithm lib ever, he tried several languages before 
compromising and choosing c++ and the inadvertently turing 
complete templates; *before c++ made any real usability 
decisions, before anyone had any practice with these things*. Stl 
is successful, aa takes the "slices > pointers" idea, looks at 
stl iterators being based on pointers and makes a quick edit 
making "ranges" looks around find walter and makes some template 
api requests that he largely got. **Again** *before anyone had 
practice or theory with d templates or the full feature set was 
in place.* Theres no reason to believe ranges have the best 
possible api for d with a full feature set and a decade of 
practice with template metaprogramming with d's features.

I highly suggest that changing the range api design to be post- 
everyone practice and knowledge of templates and not based on 
some essays for c++ in the 90's

---

I made this proof of concept for a different api I thought would 
be better 
https://gist.github.com/crazymonkyyy/308bf3387ceec5c84883678d0fc097a7

To summarize I believe iteration and "shaping" should be 
separated; while ranges are "views of data" they should get a 
"key" from an array reference that should be a "smart reference" 
to real data. Rather then the stl concept of random access 
iterators being a subset of bi-directional iterators.

For the simplest possible version id suggest

```
range:
   front
   pop
   empty
   //optional
   key
   length

array:
   opIndex(typeof(opSlice()).key)
   opIndex(typeof(opDollar))
   opSlice() (returns a range)
   opDollar
   //optional
   opSlice(typeof(opSlice[].key),typeof(opDollar)) (returns an 
array)
```

For a phoboes version probably keep bidirectional for backward 
compatibility and whatever computer science theory that loves 
doubly linked lists, while deprecating "random access ranges".

To clarify the difference, sorting a range in this paradigm is 
incoherent, reducing an array without an opSlice is incorrect.

----

On fundamental vs composite algorithms; if you look at my code 
theres several extremely small blocks of code, my original notes 
where 10 fundamental algorithms and 34 composite algorithms, I 
still believe that phoboes is held back by refusing "to simple" 
"not optimized" code that can be an unituitive combination of the 
more fundamental algorithms(you can easily make max with reduce, 
you cant make reduce with max) however my plan of 1:3 was to 
greedy and I would suggest 1:2.5




More information about the Digitalmars-d mailing list