Should the comma operator be removed in D2?

Robert Jacques sandford at jhu.edu
Tue Nov 17 07:09:13 PST 2009


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.



More information about the Digitalmars-d mailing list