On Friday, 15 March 2024 at 09:03:25 UTC, rkompass wrote:
@Monkyyy: I adopted your solution, it is perfect.
I only have one problem left:
The foreach loop with associative arrays has two cases:
`foreach(key, val; arr)` and `foreach(x; arr)`.
In the second case only the values are iterated.
With the present solution the iteration delivers (key, val)
tuples.
That will not be fixed in d2 ranges and has no good solutions;
and my affect over d3 seems to be none. You could ask around for
the "opApply" solution but I dont know it well (and prefer ranges)
d2 Ranges are based on a simplification of stl's ideas and stl
doesn't support arrays-like iteration well, I wish to change that
and working on a proof of concept algorthims lib... but well,
this is unlikely to work.
For d3 if changing the range interface fails, expect to see style
guides say "prefer explict range starters" string.byUnicode and
string.byAscii will probably be how they kill `autodecoding` and
your data stucture having 2 range functions as `byKey` and
`byKeyValue` will look the same.
Should I do an improvement request somewhere?
I think its been kinda of piecemeal and D1 1D(repetition
intentional) opSlice is in limbo(it was deprecated, and then
slightly undepercated in some random chats, its a mess)
for completeness I believe the current state of 1d op overloads
are:
opIndex(int)
opIndex(key)
opSlice()
opSlice(int, int)
int opDollar()
dollar opDollar()
opSlice(int, dollar)
opBinararyRight("in",K)(key) (opIn was deprecated and shouldn't
have been)
If your confident in your writing ability id suggest a clean
slate article based on this list and what the compiler actually
does(maybe ask around for any I missed) rather than trying to
untangle this mess
Or write a dip thread "undeperacate d1 opOverloads that are still
wanted by everyone") and try to bring back opIn at the same time
and get the limboness of old technically deprecated 1d array
opOverloads officially gone
