Associative Ranges

[Freddy via Digitalmars-d]

On Monday, 4 August 2014 at 09:21:40 UTC, Marc Schütz wrote:
> On Sunday, 3 August 2014 at 18:38:51 UTC, Freddy wrote:
>> On Sunday, 3 August 2014 at 08:50:47 UTC, Marc Schütz wrote:
>>> 3) For the value and key ranges, there should be a guarantee 
>>> that they can be zipped through, i.e. that the elements in 
>>> them are in the same order so keys and values correspond to 
>>> each other. The built-in associative arrays provide `byKey` 
>>> and `byValue`, which satisfy this condition.
>> Also won't the implicit range make it hard to implement 
>> function
>> like map (should you map to whole range or to the value)
>
> I guess when you iterate over it, you just get tuples. So, 
> `map` would return a normal range of tuples, not an associative 
> range. There could then be a method to convert such a range to 
> an associative range (although it would need to assume that the 
> first tuple elements = keys are unique).
>
> I'm not sure whether this is the right thing to do. In any case 
> I don't think it's good to map the keys, because they mustn't 
> be modified, or otherwise you could get duplicate keys.
>
> An alternative would be that `map` takes both a the key and the 
> value, but returns only the new value. The same goes for the 
> other range operations (e.g. reduce). But on the other hand, 
> this doesn't seem to scale, because all range algorithms would 
> then have to be specialized for associative ranges...
I have come up with a new interface:
----
R r=void;
auto v=r.front;//r is an input range
auto k=r.byKey.front;//byKey is an input range
v=r[k];//opIndex of k
v=*(k in r);//opBinearyRight!"in" of k
----
The allows function like map to not alter key(similar to how map
can't alter the postioning of random access ranges), and it
shouldn't conflit with the build-in associative array's opApply