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
