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