On Thu, 25 Dec 2008 15:09:59 +0100, Frits van Bommel <[email protected]> wrote:
>Jarrett Billingsley wrote: >> On Wed, Dec 24, 2008 at 5:24 PM, Yigal Chripun <[email protected]> wrote: >>> why not replace the current comma operator with tuple support? >>> the comma op needs to be higher than assingment in precedence and instead of >>> evaluating the expressions left to right and returning the value of the >>> _last_ expression as the return value of the op, return _all_ expressions' >>> return values as a value tuple. the current behavior that is really used >>> only in for loops can be implemented with tuples as well. >>> >>> insted of: >>> for (int i = 0, long j = 0; ...; ...) {...} >> >> Actually that's not legal syntax. You're thinking of "int i = 0, j = >> 0", which is parsed as a single declaration statement which declares >> two variables. This does not use the comma operator. >> >> The place where the comma operator is used is in the increment: >> >> for(..; ..; i++, j++) >> >> All that has to be done here is the comma has to be added to the >> increment grammar of the for loop. (MiniD does this.) > >Actually, that isn't even needed. Since the return value of the >increment is never used, and it can be any type at all, there would be >no reason to change that line of code at all. >So the increment clause is suddenly a tuple? Who cares; it still >increments just fine, doesn't it? :) > >The only potential problem (which I just now thought of) would be >increments with type void (e.g. ++i, iter.step()). Do tuple values allow >void elements? If not, would it do any harm to allow them? I wish void values would be legal. One more inconsistency hindering generic programming would probably go from the type system. Now almost any place when void is used as a type needs to be special-cased. For example, I don't see why the following should be illegal: T foo(T = void)() { return T.init; } foo(); // error
