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
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
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=5466I 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
That byKey and byValue adhere to the same order is not backed up by the documenation, I suppose?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: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
On Thursday, 13 February 2014 at 12:30:29 UTC, bearophile wrote:Tobias Pankrath: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 :DThat 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).
Feb 13 2014
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 :DThat's not the rational way a language should be designed. Tester Driven Development (http://en.wikipedia.org/wiki/Tester_driven_development ) is bad enough already. Bye, bearophile
Feb 13 2014
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 :DThat's not the rational way a language should be designed. Tester Driven Development (http://en.wikipedia.org/wiki/Tester_driven_development ) is bad enough already.I did put a smiley in there, right? My comment was a joke ;) It's just that often the desire to "not break code" adheres to that very pattern :(
Feb 13 2014