Should the comma operator be removed in D2?

[Robert Jacques]

On Tue, 17 Nov 2009 11:38:19 -0500, Bill Baxter <wbaxter at gmail.com> wrote:

> On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques <sandford at jhu.edu> wrote:
>> On Tue, 17 Nov 2009 05:44:31 -0500, downs <default_357-line at yahoo.de>  
>> wrote:
>>
>>> Robert Jacques wrote:
>>>>
>>>> On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun <yigal100 at gmail.com>
>>>> wrote:
>>>>
>>>>> Robert Jacques wrote:
>>>>>>
>>>>>> On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
>>>>>> <smjg_1998 at yahoo.com> wrote:
>>>>>>
>>>>>>> dsimcha wrote:
>>>>>>> <snip>
>>>>>>>>
>>>>>>>> Axe.  Looks like the only things it's good for are making code
>>>>>>>> undreadable and
>>>>>>>> abusing for loop syntax to...
>>>>>>>>  Make code unreadable.
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>> Suppose you want the increment of a for loop to change two  
>>>>>>> variables
>>>>>>> in parallel.  I don't call that making code unreadable.
>>>>>>>
>>>>>>> Stewart.
>>>>>>
>>>>>>  Yes the classic use case of the comma operator is multi-variable
>>>>>> declarations/increments in a for loop.
>>>>>
>>>>> This was argued before and as I and others said before, this is *not*
>>>>> a use case for the comma separator.
>>>>>
>>>>> e.g.
>>>>> for (int a = 0, b = 1; condition(); a++, b++) {...}
>>>>>
>>>>> int a = 0, b = 1 // this is a declaration and not an expression
>>>>>
>>>>> a++, b++ // isn't assigned to any variable and can be treated as a  
>>>>> tuple
>>>>>
>>>>> the only use case that will break is if the two increments are
>>>>> dependent on the order (unless tuples are also evaluated from left to
>>>>> right):
>>>>> e.g.
>>>>> a + 5, b + a //
>>>>>
>>>>> I doubt it very much that anyone ever uses this, it's too unreadable
>>>>> to be useful.
>>>>
>>>> However, I imagine tuple(a++,b++) would have some overhead, which is
>>>> exactly what someone is trying to avoid by using custom for loops.
>>>>
>>>> Personally, I like using a..b => tuple(a,b), since it also solves the
>>>> multi-dimensional slicing and mixed indexing and slicing problems.
>>>
>>> Zero overhead. Tuples are flat compile-time entities.
>>
>> There are compile time tuples and runtime tuples. D already has a form  
>> of
>> compile-time tuples. This discussion seems to be about runtime tuples  
>> which
>> currently don't have a nice syntax: you have to use tuple(a,b). And
>> tuple(a,b) does have runtime overhead.
>
> I think the point is that in something like this:
>    auto foo = (a,b);
>    foo.a += 2;
>    foo.b += foo.a;
>    // etc
>
> The tuple foo is allocated on the stack and the compiler knows where
> the a part and b part are, so the code generated should be absolutely
> no different from the code generated for:
>
>    auto foo_a = a;
>    auto foo_b = b;
>    foo_a += 2;
>    foo_b += foo_a;
>    // etc
>
> So there doesn't need to be any "tuple overhead".
> --bb

But that isn't the expansion:
for (int a = 0, b = 1; condition(); a++, b++) =>

int a = 0;
int b = 0;
while(condition) {
     auto temp = tuple(a++,b++); // creation of a struct on the stack
}

Now the optimizer might get rid of that temporary struct. Then again it  
might not (or its presence interferes with other optimizations). At the  
very least, some amount of code profiling or disassembly needs to be done.