On Mon, 15 Dec 2014 18:42:11 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> 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.
this is a VERY BAD idea, but nothing else works. anything other will be either rejected with random reason or talked to death.

> One possible solution:

Another idea is to make "byPair" and "pairs" templates that by default return 2-structs and use a Tuple on request (so you have to import Phobos Tuple if you want them, so byPair doesn't depend on Phobos and you can put in druntime):

int[string] aa;
assert(aa.byPair.array == aa.pairs);

byPair yields something like:
struct Pair { string key; value int; }

Now this yields tuples:
assert(aa.byPair!Tuple.array == aa.pairs!Tuple);

Bye,
bearophile

> Now this yields tuples:
> assert(aa.byPair!Tuple.array == aa.pairs!Tuple);

But I'd really like tuples as built-ins for D -.- This is a work-around that cements the ugly Phobos tuples in the language... -.-

Bye,
bearophile

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

> 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.
maybe after five years of talking and after alot of people will relay on the current behavior, it will be documented.

On Mon, Dec 15, 2014 at 06:46:20PM +0000, bearophile via Digitalmars-d-learn wrote:
> 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).
[...]

That's exactly what I plan to do. :-)


T

-- 
Let's call it an accidental feature. -- Larry Wall

On Monday, 15 December 2014 at 18:55:13 UTC, bearophile wrote:
>> Now this yields tuples:
>> assert(aa.byPair!Tuple.array == aa.pairs!Tuple);
>
> But I'd really like tuples as built-ins for D -.- This is a work-around that cements the ugly Phobos tuples in the language... -.-
>
> Bye,
> bearophile

Kenji has had a pull for full built-in Tuple support sitting in Github for years now (https://github.com/D-Programming-Language/dmd/pull/341). The syntax obviously won't work as it is, but that aside there's very little stopping built-in tuples in D.

Don't forget, he also made a DIP about it as well: http://forum.dlang.org/thread/mailman.372.1364547485.4724.digitalmars-d@puremagic.com

On Mon, 15 Dec 2014 21:32:23 +0000
Meta via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:

> On Monday, 15 December 2014 at 18:55:13 UTC, bearophile wrote:
> >> Now this yields tuples:
> >> assert(aa.byPair!Tuple.array == aa.pairs!Tuple);
> >
> > But I'd really like tuples as built-ins for D -.- This is a work-around that cements the ugly Phobos tuples in the language... -.-
> >
> > Bye,
> > bearophile
> 
> Kenji has had a pull for full built-in Tuple support sitting in Github for years now (https://github.com/D-Programming-Language/dmd/pull/341). The syntax obviously won't work as it is, but that aside there's very little stopping built-in tuples in D.
> 
> Don't forget, he also made a DIP about it as well: http://forum.dlang.org/thread/mailman.372.1364547485.4724.digitalmars-d@puremagic.com

wow, thank you. i missed that PR and i really like it. will try to add it to my patchset. ;-)

On Monday, 15 December 2014 at 14:41:43 UTC, bearophile wrote:
> 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

Ok. Thanks.

Is

Tuple!(Key,Value)[] pairs(Key,Value)(Value[Key] aa);

a suitable contender for now?

I especially wonder about the mutability of parameter aa.

BTW: Why doesn't aa.byKey.map work?

On Monday, 15 December 2014 at 22:58:43 UTC, Nordlöw wrote:
> Tuple!(Key,Value)[] pairs(Key,Value)(Value[Key] aa);
>
> a suitable contender for now?
>
> I especially wonder about the mutability of parameter aa.

More specifically is

https://github.com/nordlow/justd/blob/master/range_ex.d#L545

ok?

Nordlöw:

> BTW: Why doesn't aa.byKey.map work?

It currently works.

Bye,
bearophile