I just noticed a little oddity.
Why does this code compile? The equivalent C code is rejected:

import std.stdio;
//#include <stdio.h>

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)

Timon Gehr:

> I just noticed a little oddity.
> Why does this code compile? The equivalent C code is rejected:

I think Andrei wants (rightly) it to be fixed. So I think it is an implementation "bug" that will be fixed.

Bye,
bearophile

On Tue, 12 Apr 2011 14:57:26 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> I just noticed a little oddity.
> Why does this code compile? The equivalent C code is rejected:
>
> import std.stdio;
> //#include <stdio.h>
>
> 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)

That looks horrible, reformatted looks even worse:


int main()
{
    int a,b;
    do
    {
        scanf("%d %d",&a,&b);
    }

    // so here is a comment to separate things a bit
    //
    // do you think this makes sense?:
    while(a<b)
        return 0;
}

I think the grammar should be changed...  This is almost as bad as go's requirement for if statement opening block to be on the same line (would be as bad, but do..while doens't occur a lot).

-Steve

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")

denis
-- 
_________________
vita es estrany
spir.wikidot.com

On Tue, 12 Apr 2011 17:21:57 -0400, spir <denis.spir@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).

-Steve

On 04/12/2011 11:51 PM, Steven Schveighoffer wrote:
> On Tue, 12 Apr 2011 17:21:57 -0400, spir <denis.spir@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 '{').
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 ;-) Maybe, if not done already, a line starting with an opening brace should generate a parsing error.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On Tue, 12 Apr 2011 18:00:40 -0400, spir <denis.spir@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@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

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

> On Tue, 12 Apr 2011 18:00:40 -0400, spir <denis.spir@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@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

On Wed, 13 Apr 2011 09:44:54 -0400, Emil Madsen <sovende@gmail.com> wrote:

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

>>
>> 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.
>>
> 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?

if(condition1 && condition2); is an error.

However, an expression can be a statement:

condition1 && condition2;

Note, you can get around the limitation if that *really is* what you meant by doing:

if(expression) {}

An if statement is hard to justify for this, but I can see a while or for loop making sense here.

-Steve

On 4/13/11, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> 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.

I've been caught by DMD doing this a couple of times. It saved my butt. Thanks, Walter!