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