extending foreach for keyed ranges and other usage of datastructures

[monkyyy]

On Thursday, 16 May 2024 at 20:59:26 UTC, Quirin Schroll wrote:
> Why would you want it to have `int` indices?

cause id rather write 1 cast then 10 when im iterating over data 
that depends on the index for some math; I find size_t style 
indexs insane and would happily change slices to int, I cant and 
theres that deprecation coming

Im far from alone, see a rant thread about the deprecation

>> and range.enumerate has problems with strings;
>
> I have zero clue what you mean.

imagine a comma seperated value list with unicode
you enumerate and filter by comma than map the tuple to the 
"index", the indexs that are returned will be wrong

enumerate can only react to the fronts as if they are one at a 
time, unicode skips ahead; fundamental unsolvable problem with 
the current range api

>
>> if you have key,value pairs you must always use it in all 
>> foreaches even if you only use value while slices get special 
>> treatment
>
> That’s definitely wrong. You can overload `opApply` just fine:
> ```d
> struct Range
> {
>     import std.stdio;
>     int opApply(int delegate(ref int) callback)
>     {
>         writeln("no key");
>         return 0;
>     }
>     int opApply(int delegate(size_t, ref int) callback)
>     {
>         writeln("with key");
>         return 0;
>     }
> }
>
> void main()
> {
>     foreach (ref value; Range()) {} // writes "no key"
>     foreach (key, ref value; Range()) {} // writes "with key"
> }
> ```

ok, I was wrong (still on team 3 function ranges and not single 
function iterators)