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