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