Tuple DIP

[Timon Gehr]

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