• bearophile (26/26) Jan 06 2015 I strongly suggest to "burn with fire", I mean, warn and then
• Vlad Levenfeld (7/7) Jan 06 2015 I loved this feature when I first found out about it but after
• deadalnix (2/2) Jan 06 2015 Tuple unpacking is necessary for things like bypair. Why not
• bearophile (10/12) Jan 06 2015 I'm all for unpacking consistently, but to reach consistency you

"bearophile" <bearophileHUGS lycos.com> writes:

I strongly suggest to "burn with fire", I mean, warn and then 
deprecate the special case of automatic tuple unpacking in 
foreach loops in dmd 2.067:


void main() {
     import std.typecons, std.range;

     auto data1 = [tuple("red", 10), tuple("blue", 20)];
     foreach (x, y; data1) {
         pragma(msg, typeof(x), " ", typeof(y));
     }

     auto data2 = only(tuple("red", 10), tuple("blue", 20));
     foreach (x, y; data2) {
         pragma(msg, typeof(x), " ", typeof(y));
     }
}



Output:

uint Tuple!(string, int)
string int


See issues:

https://issues.dlang.org/show_bug.cgi?id=9817
https://issues.dlang.org/show_bug.cgi?id=7361

It causes troubles today because it's a special-cased trap. And 
it will cause even more troubles in future if/when we add 
built-in tuple unpacking to D. So please remove this wart, thank 
you.

Bye,
bearophile

"Vlad Levenfeld" <vlevenfeld gmail.com> writes:

I loved this feature when I first found out about it but after 
reading your arguments against on the bug tracker I have to agree 
with your position. It would be much nicer if it worked with 
uniform tuple syntax like

   foreach (i, {x,y}; [tuple('a',`b`),tuple('c',`d`)])

where i is size_t and x,y is char, string

which is I think what you were proposing.

"deadalnix" <deadalnix gmail.com> writes:

Tuple unpacking is necessary for things like bypair. Why not 
unpack consistently ?

"bearophile" <bearophileHUGS lycos.com> writes:

deadalnix:

 Tuple unpacking is necessary for things like bypair. Why not 
 unpack consistently ?

I'm all for unpacking consistently, but to reach consistency you 
first have to break something, the iteration on arrays or the 
iteration on ranges of tuples. The first is documented and it's 
present since D1, the second is recent and undocumented and it 
causes evolution troubles for D toward possible implementations 
of tuples. What do you want to kill? I prefer to kill the second, 
and do it yesterday.

Bye,
bearophile