Semicolon can be left out after do-while

Emil Madsen sovende at gmail.com
Wed Apr 13 06:44:54 PDT 2011


On 13 April 2011 14:36, Steven Schveighoffer <schveiguy at yahoo.com> wrote:

> On Tue, 12 Apr 2011 18:00:40 -0400, spir <denis.spir at gmail.com> wrote:
>
>  On 04/12/2011 11:51 PM, Steven Schveighoffer wrote:
>>
>>> On Tue, 12 Apr 2011 17:21:57 -0400, spir <denis.spir at gmail.com> wrote:
>>>
>>>  On 04/12/2011 09:21 PM, Steven Schveighoffer wrote:
>>>>
>>>>  int main(){
>>>>> int a,b;
>>>>> do{
>>>>> scanf("%d %d",&a,&b);
>>>>> }while(a<b) //note missing semicolon here
>>>>> return 0;
>>>>> }
>>>>>
>>>>> The grammar specifies this correctly, but then again, the example uses
>>>>> the
>>>>> semicolon. (
>>>>> http://www.digitalmars.com/d/2.0/statement.html#DoStatement)
>>>>> [...]
>>>>> I think the grammar should be changed...
>>>>>
>>>>
>>>> yop!
>>>>
>>>>  This is almost as bad as go's
>>>>> requirement for if statement opening block to be on the same line...
>>>>>
>>>>
>>>> why? I like Go's syntactuc diffs. (except for its "multi-for")
>>>>
>>>
>>> in Go, this:
>>>
>>> if(x)
>>> {
>>> gosWriteRoutineThatIDontKnowTheSyntaxOf("hello")
>>> }
>>>
>>> is equivalent to this in D:
>>>
>>> if(x)
>>> {
>>> }
>>>
>>> writeln("hello");
>>>
>>> This is frankly unforgivable IMO.
>>>
>>> Of course it's fixable, but the attitude that "the coder should know
>>> better"
>>> doesn't really make me comfortable with it. And I hate the "brace on the
>>> same
>>> line" format (but this of course is not a real argument against it).
>>>
>>
>> Oh, that's what you meant! I find this a Good Thing, in that it enforces
>> one bracing style (the right one, that does not eats one more line for just
>> a '{').
>>
>
> No, it doesn't enforce anything.  The above compiles and runs.  What it
> does is introduce subtle bugs.
>
> The way to fix it is to make the above an error.
>
>
>  About knowing or not about this (non/mis/-)feature, it's written down, and
>> clearly, in all Go docs I've read. And one cannot miss it for very long
>> anyway ;-)
>>
>
> I know that if(xyz); is not *ever* what I meant, but in C it compiles.
>  However, in D, it tells me I shouldn't do that.  What results is less bugs
> because I can't make that mistake without the compiler complaining.
>
> I'm not saying that the spec isn't well defined, or the manual isn't clear,
> what I'm saying is, the attitude reflected in the rule is that greater
> burden is put on the developer to make sure they follow the rules without
> compiler enforcement.  It makes me want to not use Go.  And in fact, I will
> probably never use it as long as this rule is in place.
>
>
>  Maybe, if not done already, a line starting with an opening brace should
>> generate a parsing error.
>>
>
> Typically this is used to create a new scope in C/D/Java/C#.  This allows
> declaring temporary variables, not sure how it is in Go, but I'd assume
> something similar.
>
> -Steve
>


Does D throw an error at; if(expression && expression)*; *or only at
if(expression);
Because you could actually use the first one, alike this:
<code>
#include <stdio.h>

bool test()
{
    printf("test\n");
    return false;
}

bool test2()
{
    printf("test2\n");
    return true;
}

int main()
{
    if(test() && test2());
}
</code>
Output = "test"
if test returns true, then: Output = "test" + "test2"

Simply because its conditional, and if the first one fails, why bother
evaluating the rest?

-- 
// Yours sincerely
// Emil 'Skeen' Madsen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20110413/56ed66dd/attachment.html>


More information about the Digitalmars-d-learn mailing list