Tuple DIP

[Steven Schveighoffer]

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