On Tue, 17 Nov 2009 05:44:31 -0500, downs <default_357-l...@yahoo.de>
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun <yigal...@gmail.com>
wrote:
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
<smjg_1...@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.
