Things that may be removed

[Max Samukha]

On Thu, 25 Dec 2008 15:09:59 +0100, Frits van Bommel
<fvbommel at REMwOVExCAPSs.nl> wrote:

>Jarrett Billingsley wrote:
>> On Wed, Dec 24, 2008 at 5:24 PM, Yigal Chripun <yigal100 at gmail.com> 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