Semicolon can be left out after do-while

[Emil Madsen]

On 13 April 2011 16:17, Kai Meyer <kai at unixlords.com> wrote:

> On 04/13/2011 07:44 AM, Emil Madsen wrote:
>
>> On 13 April 2011 14:36, Steven Schveighoffer <schveiguy at yahoo.com
>> <mailto:schveiguy at yahoo.com>> wrote:
>>
>>    On Tue, 12 Apr 2011 18:00:40 -0400, spir <denis.spir at gmail.com
>>    <mailto: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 <mailto: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
>>
>
> I would argue that the more correct way to do this would be to separate the
> statements that are used in the condition from the statements that are not
> used in the condition.
>
> if(test())
>    test2();
>
> Since test2's return statement isn't used for anything means to me that it
> doesn't belong in the conditional statement.
>

Well I agree that its more correct for the case posted, but it can just get
somewhat messy, if your having a mix of conditionals say '&&' and '||'.
Even tho its not really good style, some of the people I study with use this
trick quite a lot converting functional programs, apparently (not my area of
expertise).

But surely I would go with your approach too, but if your having a deep
nesting of conditionals, I guess that could give some heavily nested code
too. (Atleast if you are to follow some specific coding standard).
-- 
// Yours sincerely
// Emil 'Skeen' Madsen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20110413/b6bc22ca/attachment.html>