## digitalmars.D.learn - T[][T] -> [(k1, v1), ..., (k1, vn), ..., (kn, v1), ..., (kn, vn)]

• Tobias Pankrath (16/16) Feb 13 2014 I've got a hash map T[][T] with keys of T and values of T[]. For
• Stanislav Blinov (10/23) Feb 13 2014 A byPair range has been proposed long ago:
• Tobias Pankrath (2/11) Feb 13 2014 That byKey and byValue adhere to the same order is not backed up
• bearophile (5/7) Feb 13 2014 Right. It's a bet (unlike in Python, that has this rule in the
• Stanislav Blinov (3/8) Feb 13 2014 Yup. And given how Walter and Andrei don't like breaking code, we
• bearophile (7/10) Feb 13 2014 That's not the rational way a language should be designed. Tester
• Stanislav Blinov (4/12) Feb 13 2014 I did put a smiley in there, right? My comment was a joke ;) It's
"Tobias Pankrath" <tobias pankrath.net> writes:
```I've got a hash map T[][T] with keys of T and values of T[]. For
some reason, I'll need a range of tuples (t1, t2), where t1 is a
key and t2 is an element of the array t1 maps to. To have them in
order would be great, but is not necessary.

I just wrote my own range type and it works. But I wonder how
would I do it with phobos utilities?

I came up with this:

int[][int] hash = [1 :[1,2,3,4], 2:[3,1,2,3], 4:[2,3,1,3]];
auto x = hash.keys.map!(x => tuple(x, hash[x]))
.map!(x => zip(repeat(x[0]), x[1]));

Is there any other way to create a range of simple (key,value)
pairs for the array, but needs to allocate (hash.keys return an
array of keys) and then again look up every key.

We can loop over (key,value) pairs of the AA with foreach, but I
guess there is no standard way to create a range from a
foreach-compatible delegate? Or even get a hand on this delegate?
```
Feb 13 2014
"Stanislav Blinov" <stanislav.blinov gmail.com> writes:
```On Thursday, 13 February 2014 at 11:00:17 UTC, Tobias Pankrath
wrote:
I've got a hash map T[][T] with keys of T and values of T[].
For some reason, I'll need a range of tuples (t1, t2), where t1
is a key and t2 is an element of the array t1 maps to. To have
them in order would be great, but is not necessary.

I just wrote my own range type and it works. But I wonder how
would I do it with phobos utilities?

A byPair range has been proposed long ago:

https://d.puremagic.com/issues/show_bug.cgi?id=5466

I came up with this:

int[][int] hash = [1 :[1,2,3,4], 2:[3,1,2,3], 4:[2,3,1,3]];
auto x = hash.keys.map!(x => tuple(x, hash[x]))
.map!(x => zip(repeat(x[0]), x[1]));

Is there any other way to create a range of simple (key,value)
pairs for the array, but needs to allocate (hash.keys return an
array of keys) and then again look up every key.

import std.algorithm : zip;
import std.traits    : isAssociativeArray;

auto byKeyValuePair(AA)(AA aa) if (isAssociativeArray!AA)
{
return zip(aa.byKey, aa.byValue);
}
```
Feb 13 2014
"Tobias Pankrath" <tobias pankrath.net> writes:
``` Is there any other way to create a range of simple (key,value)
pairs for the array, but needs to allocate (hash.keys return
an array of keys) and then again look up every key.

import std.algorithm : zip;
import std.traits    : isAssociativeArray;

auto byKeyValuePair(AA)(AA aa) if (isAssociativeArray!AA)
{
return zip(aa.byKey, aa.byValue);
}

That byKey and byValue adhere to the same order is not backed up
by the documenation, I suppose?
```
Feb 13 2014
"bearophile" <bearophileHUGS lycos.com> writes:
```Tobias Pankrath:

That byKey and byValue adhere to the same order is not backed
up by the documenation, I suppose?

Right. It's a bet (unlike in Python, that has this rule in the
docs).

Bye,
bearophile
```
Feb 13 2014
"Stanislav Blinov" <stanislav.blinov gmail.com> writes:
```On Thursday, 13 February 2014 at 12:30:29 UTC, bearophile wrote:
Tobias Pankrath:

That byKey and byValue adhere to the same order is not backed
up by the documenation, I suppose?

Right. It's a bet (unlike in Python, that has this rule in the
docs).

Yup. And given how Walter and Andrei don't like breaking code, we
should just previde enough usage so it would become a rule too :D
```
Feb 13 2014
"bearophile" <bearophileHUGS lycos.com> writes:
```Stanislav Blinov:

Yup. And given how Walter and Andrei don't like breaking code,
we should just previde enough usage so it would become a rule
too :D

That's not the rational way a language should be designed. Tester
Driven Development
(http://en.wikipedia.org/wiki/Tester_driven_development ) is bad

Bye,
bearophile
```
Feb 13 2014
"Stanislav Blinov" <stanislav.blinov gmail.com> writes:
```On Thursday, 13 February 2014 at 12:43:00 UTC, bearophile wrote:
Stanislav Blinov:

Yup. And given how Walter and Andrei don't like breaking code,
we should just previde enough usage so it would become a rule
too :D

That's not the rational way a language should be designed.
Tester Driven Development
(http://en.wikipedia.org/wiki/Tester_driven_development ) is