Tuple DIP

[Timon Gehr]

On 16.02.2018 20:51, Martin Nowak wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 01/12/2018 11:44 PM, Timon Gehr wrote:
>> As promised [1], I have started setting up a DIP to improve tuple
>> ergonomics in D:
>>
>> https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md
> 
> Pardon me if things have been said already, can't really read through
> all the thread.
> 
> - - Regarding underscore as placeholder.
> 
> https://issues.dlang.org/show_bug.cgi?id=13522
> 

Thanks! I'll add a link to the enhancement to the DIP.

> - - Regarding the "limitation"
> 
> Maybe you want some auto-packing feature there? Doesn't seem too bad,
> we could come up with sth. when this turns out to become a common
> nuisance.
> Have you considered to lower (1, 2, 3)[0 .. 2] to tuple(tuple(1, 2,
> 3)[0 .. 2]) or using a non-std.typecons tuple where slicing does not
> expand?
> ...

I think this is technically a good idea, but there are drawbacks: (i) 
the language does not support this for user-defined types, ideally we 
avoid adding more built-in magic, and (ii) having two different types 
will be confusing to newcomers. ("Which of the two seemingly equivalent 
Tuple constructs should I use?")

> - - closed tuples?
> 
> The reference to std.typecons.tuple implies contiguous struct memory
> layout (closed tuples).
> This is a bit subtle for unpacking assignments which lower to
> 
> AliasSeq!(x, y) = tuple(y, x)[];
> 
> so on the left-hand side of an assignment, the syntax refers to a
> non-contiguous (open) tuple.
> ...

I don't think this is the best way to think about it. Syntactically, the 
left-hand side contains two non-contiguous variables x and y and uses 
their values to form a contiguous tuple, but as it is the left-hand side 
of an assignment, the operation is actually performed in the opposite 
direction. This is a bit as if D supported assignments of the form:

int a;
a + 1 = 3;
assert(a == 2); // computed using the inverse: a = 3 - 1

Of course, this is independent of the actual implementation strategy chosen.

> Declarations like
> 
> auto (a, b) = (1, 2);
> 
> also seem to declare an open tuple (non-contiguous memory).
> ...

Yes, the idea is that this would declare multiple independent variables.

> I assume that unpacking function arguments behaves similarly, i.e. on
> ABI level, each argument is passed separately.
> ...

I think the ABI should be unaffected in this case (it is just syntax 
sugar for unpacking the tuple argument immediately at the start of the 
called function, i.e. it is a callee-site construct that happens to 
sometimes make the signature prettier for the caller also). I will 
clarify this point.

> 
> Overall looks really good. I think that would make for a great
> addition to the language.
> ...

Thanks! I'll make sure to incorporate your points when I'll finally get 
around to updating the DIP based on the forum feedback.