A Discussion of Tuple Syntax
Kenji Hara
k.hara.pg at gmail.com
Tue Aug 20 09:03:42 PDT 2013
2013/8/20 bearophile <bearophileHUGS at lycos.com>
> So, std.typecons.Tuple _is not special_. You can define another Tuple
>> struct in the same way.
>> We should not define new syntax for the library utility
>> std.typecons.Tuple.
>>
>
> With your idea is there a way to unpack a short array into variables? This
> is an handy operation I do often in Python:
>
> s = "red blue"
>>>> (a, b) = s.split()
>>>> a
>>>>
>>> 'red'
>
>> b
>>>>
>>> 'blue'
>
My position to such a feature is constant. We should not conflate tuple
unpacking and array unpacking.
But, extending unpacking syntax mentioned in DIP32 might help it.
// Just an idea: extending DIP32 unpacking syntax
import std.typecons : tuple;
auto tup = tuple(1, tuple(2,3), [4,5]);
{ auto a, {b, c}, [d, e] } = tup;
//{ auto a, [b, c], {d, e} } = tup; // cause compile-time error
assert(a == 1);
assert(b == 2 && c == 3);
assert(d == 4 && e == 5);
However, array unpacking would require *hidden* runtime boundary check.
In above example code,
assert(tup[2].length == 2);
// or
if (tup[2].length != 2) throw Error("Runtime mismatch of unpacking
pattern");
// or similar
should be implicitly inserted by compiler, even in @system code.
I'm not sure that is acceptable cost or not.
Kenji Hara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130821/5b536545/attachment-0001.html>
More information about the Digitalmars-d
mailing list