On 1/17/18 1:44 AM, Timon Gehr wrote:
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)
OK, so writeln isn't going to show the type any more. This seems like a
small difference, but possibly could affect code.
I thought there was more of an issue with the actual construction of a
tuple that wouldn't work with the new version.
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'll have to re-read that whole discussion...
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
Ah, ok, I see that now. I thought it worked because of the alias this :)
Definitely, we need something like this.
-Steve
