Associative Ranges

[Freddy via Digitalmars-d]

On Tuesday, 5 August 2014 at 00:11:21 UTC, Freddy wrote:
> 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...
> The way I have it now is that type doesn't matter when you
> iterate over a assciative range, all that matters is that that
> type has a .key and .value. This allow custom opAssign and  
> other
> bonuses.
>
> Should I switch to use type tuples.
>
> A lot of the functions that take Input/Forward ranges don't need
> specialization because you could use byValue and zip with
> byKey(however then we might need to add a default .key and 
> .value
> to type tuples if we go with my original idea).
Wait, the build-in associative arrays already a opApply with a
single element, this makes them unable to be an associate range
(depending on priority we would break backwards compatabily or be
unable to use them as a range) unless we change the associtive
range interface to be an input/forward range of the value type
and ask users to zip byKeys and the range