D with experimental features like tuple unpacking

John Colvin john.loughran.colvin at gmail.com
Fri Mar 22 04:16:05 PDT 2013


On Friday, 22 March 2013 at 07:05:03 UTC, Denis Shelomovskij 
wrote:
> 22.03.2013 1:13, bearophile пишет:
>> And in foreach:
>>
>> foreach ((c, ref e); loa)
>
>
> D already have undocumented[1] front tuple expansion in foreach 
> over range:
> ---
> import std.algorithm;
> import std.stdio;
>
> void main() {
>     enum s = "this is an example for huffman encoding"d;
>     foreach (c, n; s.dup.sort().release().group())
>         writefln("'%s'  %s", c, n);
> }
> ---
>
> [1] http://d.puremagic.com/issues/show_bug.cgi?id=7361

I've run in to this a few times and it's very irritating. The 
lack of an explicit syntax introduces an ambiguity:

foreach (c, n; s.dup.sort().release().group())
     writefln("'%s'  %s", c, n);

should c be the index, or should the tuple be unpacked? Currently 
the tuple is unpacked. In the general case, there is no easy way 
of having n be the tuple and c be the size_t index.

Sure, you could write

foreach (size_t c, n; s.dup.sort().release().group())
     writefln("'%s'  %s", c, n);

forcing n to be a tuple, which I think should work ( but doesn't, 
with a lot of irrelevant error messages: 
http://dpaste.dzfl.pl/7589a472 ), but if the first element of the 
tuple is also type size_t then you have a true ambiguity.


tldr: If we're going to have tuple unpacking, we need some way of 
controlling it.


More information about the Digitalmars-d mailing list