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