if (int x=..) but no while(int x=..) ?

Oskar Linde oskar.lindeREM at OVEgmail.com
Fri Mar 17 05:10:20 PST 2006


Jari-Matti Mäkelä wrote:
> Lionello Lunesu wrote:
>>> The grammar for D does not allow a
>>>
>>> "Declarator = Expression"
>>>
>>> inside the braces of a while statement. The "IfCondition" rule does allow 
>>> this
>>> for the if statements, however. Now, can the grammar be modified to accept 
>>> the
>>> "Declarator = Expression" rule? Yes, I just modified my grammar and it 
>>> works
>>> without conflicts. As for any deeper questions about the
>>> validity/usability/maintainability of this...well that is for Walter to 
>>> decide,
>>> I guess.
>> Nice test, thanks. So with no grammatical conflicts and the added symmetry, 
>> it should be easy to get Walter's backing on this : )
>>
> 
> Yes, an easy-to-use grammar checker would probably reduce the amount of
> totally pointless syntax proposals.
> 
> One other thing I don't understand is the "Expression -> Expression |
> AssignExpression , Expression" -rule. C++ seems to support this, but
> Java doesn't. The comma-operator is mostly used inside the if
> -->(...)<-- {} -part of if/while -loops. There can be a lot of uses for
> commas inside other statements, e.g. multidimensional arrays:
> 
> int[][] a
> a.length = 4,5;
> 
> or
> 
> return 1,2,3;
> 
> Currently these operations don't work as expected, thus causing code
> obfuscation. I'm not saying these examples are well designed, but I
> cannot see why we should prevent potential future extensions. What do
> you think?

This has been discussed several times, and I believe* most people are if 
favor of depreciating and removing the , operator in preparation for a 
future tuple syntax. With foreach, he for-syntax is much less common in 
D code than in C code. Perhaps , in the for syntax should be made a 
special case, as it is in Java.

/Oskar

*) based on responses to previous occurrences of the same suggestion.



More information about the Digitalmars-d mailing list