Is there a combined property of AAs that combine keys and values typically

.pairs()

or

.byPairs()

I need to sort the elements of an AA by value and then retrieved corresponding keys in the order sorted.

Nordlöw:

> Is there a combined property of AAs that combine keys and values typically
>
> .pairs()
>
> or
>
> .byPairs()
>
> I need to sort the elements of an AA by value and then retrieved corresponding keys in the order sorted.

You can add an eager pairs() function to Phobos that returns an array of tuples.

byPairs can't be done in object.d for the dependency from tuples that aren't yet (and perhaps never) built-in in D, and it can't be done in Phobos because it needs access to unspecified runtime functions.

Bye,
bearophile

>
> You can add an eager pairs() function to Phobos that returns an array of tuples.
>
> byPairs can't be done in object.d for the dependency from tuples that aren't yet (and perhaps never) built-in in D, and it can't be done in Phobos because it needs access to unspecified runtime functions.
>
> Bye,
> bearophile

I think we should require byKeys and byValues to iterate the elements in the same order. Than we can just zip them for the pairwise iteration.

Would this impose a performance problem with the current implementation?

On Mon, 15 Dec 2014 17:37:13 +0000
Tobias Pankrath via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:

> I think we should require byKeys and byValues to iterate the elements in the same order. Than we can just zip them for the pairwise iteration.
> 
> Would this impose a performance problem with the current implementation?
i was always sure that they doing that in the same order. at least this was true some time ago, but i see that runtime AA changed since, so i don't sure if it works like this now. but i agree that this requirement should be documented. and i bet it will not, 'cause this will support principle of least astonishment, which is completely alien for D.

the only way to get it into the specs is to write the useful library that relies on that behavior and then scream "don't break our code, it's regression!" then it eventually may be turned to requirement and documented.

On 12/15/14 12:52 PM, ketmar via Digitalmars-d-learn wrote:
> On Mon, 15 Dec 2014 17:37:13 +0000
> Tobias Pankrath via Digitalmars-d-learn
> <digitalmars-d-learn@puremagic.com> wrote:
>
>> I think we should require byKeys and byValues to iterate the
>> elements in the same order. Than we can just zip them for the
>> pairwise iteration.
>>
>> Would this impose a performance problem with the current
>> implementation?
> i was always sure that they doing that in the same order. at least this
> was true some time ago, but i see that runtime AA changed since, so i
> don't sure if it works like this now.

It does work this way, the same structure and functions are used to do both byKey and byValue.

> but i agree that this
> requirement should be documented. and i bet it will not, 'cause this
> will support principle of least astonishment, which is completely alien
> for D.

Really? You done filling up that man with straw?

-Steve

On Mon, Dec 15, 2014 at 02:27:52PM +0000, "Nordlöw" via Digitalmars-d-learn wrote:
> Is there a combined property of AAs that combine keys and values typically
> 
> .pairs()
> 
> or
> 
> .byPairs()
> 
> I need to sort the elements of an AA by value and then retrieved corresponding keys in the order sorted.

I implemented this before, but it got rejected because people insisted that it must return a range of Tuple, but Tuple is defined in Phobos and druntime can't have dependencies on Phobos. :-(

Maybe I'll take another shot at this, since this question keeps coming up.


T

-- 
LINUX = Lousy Interface for Nefarious Unix Xenophobes.

On Mon, 15 Dec 2014 13:01:10 -0500
Steven Schveighoffer via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:

> > but i agree that this
> > requirement should be documented. and i bet it will not, 'cause this
> > will support principle of least astonishment, which is completely alien
> > for D.
> 
> Really? You done filling up that man with straw?

so it will be documented? that was the rhetorical question.

ketmar:

> the only way to get it into the specs is to write the useful library that relies on that behavior and then scream "don't
> break our code, it's regression!" then it eventually may be
> turned to requirement and documented.

This is a bad idea.

Bye,
bearophile

H. S. Teoh:

> I implemented this before, but it got rejected because people insisted
> that it must return a range of Tuple, but Tuple is defined in Phobos and
> druntime can't have dependencies on Phobos. :-(
>
> Maybe I'll take another shot at this, since this question keeps coming up.

One possible solution: have a hidden but documented runtime function that yields 2-item structs, and add a "std.range.byPairs" range and a "std.range.pairs" function to Phobos that yield the tuples (byPairs could use a cast to convert the runtime struct to the Phobos tuple).

Bye,
bearophile

On 12/15/14 1:10 PM, ketmar via Digitalmars-d-learn wrote:
> On Mon, 15 Dec 2014 13:01:10 -0500
> Steven Schveighoffer via Digitalmars-d-learn
> <digitalmars-d-learn@puremagic.com> wrote:
>
>>> but i agree that this
>>> requirement should be documented. and i bet it will not, 'cause this
>>> will support principle of least astonishment, which is completely alien
>>> for D.
>>
>> Really? You done filling up that man with straw?
>
> so it will be documented? that was the rhetorical question.

Does it need to be? I don't see a reason for anyone to go out of their way to make the implementation inconsistent. Do you? The principal of least astonishment means that the least astonishing path is chosen. In this case, the least astonishing path has been chosen. Does it need documenting for you to believe it?

But my larger beef with your statement is that you assume D opts never to take that path, which is absolutely untrue.

-Steve