On 17.01.2018 02:20, Steven Schveighoffer wrote:
On 1/12/18 5: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
Awesome! I can say I felt a lot more comfortable with the trailing-comma
syntax after our last discussion :)
Before going ahead with it, I'd like some preliminary community input:
- I'm not yet completely satisfied with the DIP.
(See section "Limitations".)
Please let me know suggestions or further concerns you might have.
In the section discussing the breaking changes with proposal 3, you say:
"The DIP author cannot see an obvious mitigation other than keeping
std.typecons.Tuple and core.object.__Tuple separate instead of aliasing
them."
Well, what if std.typecons.Tuple can detect whether it's being used in a
non-compatible way, and falls back on the original implementation? That
is, when it works, it's an alias to object.__Tuple/__tuple, when it
doesn't work, it's the old std.typecons.Tuple/tuple.
I would expect it not to be that difficult to detect, but you don't
specify exactly what the problems are so I'm not 100% sure I know what
you are talking about :) An example would help.
...
The example is:
auto t = tuple(1, 2, 3);
// auto t = (1, 2, 3); // after DIP, the same thing as above
writeln(t); // now: (1, 2, 3) before: Tuple!(int, int, int)(1, 2, 3)
-----
About proposal 2, you say it's inspired by the conversation we had in
the forums. I remember the discussion, but I'm not seeing the
relationship with Proposal 2.
...
Proposal 2 implements "these kind of allowances" in this post:
https://forum.dlang.org/post/orink2$2lpr$1...@digitalmars.com
(The DIP does not go further than that, because:
https://forum.dlang.org/post/or7sqd$dqg$1...@digitalmars.com )
I also am not sure about the example. It defines some function max, and
then never uses it.
Fixed. :) Thanks!
I'm assuming somewhere there's a typo? In fact, I
think the example would compile today as it doesn't use any tuples (I
think), so I don't see the reason for it.
-Steve
It uses tuples because it uses zip. The code does not compile today,
because the lambda I'm passing to "map" has two parameters:
auto a = [1, 2, 4, 7, 2];
auto b = [3, 5, 3, 2, 4];
// auto c = zip(a, b).map!((x, y) => x + y); // error
auto c = zip(a, b).map!(t => t[0] + t[1]); // ok
