Should the comma operator be removed in D2?

[Bill Baxter]

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