Thoughts on possible tuple semantics

Dicebot public at dicebot.lv
Wed Aug 21 09:19:26 PDT 2013


On Wednesday, 21 August 2013 at 15:55:01 UTC, deadalnix wrote:
> Good let's drop tuple for sequence, that is much, much better. 
> However, as sequence works now, it won't fit for the type of a 
> tuple, as it auto expand.

My attitude is as follows "either we unify them even at cost of 
major breakage or is better to not touch it at all and just focus 
on some usability features, abandoning the hope to remove 
confusion". Creating new entities while keeping old ones as-is 
will make situation even worse :(

>> As Andrei has stated clearly that he does not like 
>> auto-expansion and considers
>> it a major mistake, I was trying to imagine how that idea can 
>> be incorporated
>> into idiomatic D code.
>>
>
> That is the hard point, clearly. This has advantages, but 
> difficult to make everything fit together.

Yes and I actually favor current auto-expansion despite all the 
issues - it is just easier to define what expansion is in terms 
of special tuple type semantics then some sort of action.

But Andrei seems to be pretty convinced about this and I have 
accepted this as a given starting point.

>>
>> // existing syntax
>>
>> // args can't be single entity and use normal parameter 
>> passing ABI at the same
>> // time.
>>
>> void foo(T...)(T args) // following normal ABI implies 
>> unpacking
>> {
>> }
>>
>> foo(1, 2, 3); // automatic packing
>>
>
> Which mean that I can call foo with a tuple directly ? What 
> about :
> auto a = tuple(1, 2);
> foo(a, 3);
>
> I guess this is the pack/unpack issue again.

Hm, the wording feels wrong now. No, here is the idea:
auto a = tuple(1, 2);
foo(a, 3); // rejected
foo(a.expand, 3); // works

"T..." here simply says, "work with T as it is a tuple but it is 
a normal function argument list in fact".

so no packing actually happens here: "foo(1, 2, 3)", my mistake


More information about the Digitalmars-d mailing list