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.
