www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Semicolon can be left out after do-while

reply Timon Gehr <timon.gehr gmx.ch> writes:
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)
Apr 12 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Apr 12 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 12 2011
next sibling parent reply spir <denis.spir gmail.com> writes:
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
Apr 12 2011
parent Kai Meyer <kai unixlords.com> writes:
On 04/13/2011 07:44 AM, Emil Madsen wrote:
 On 13 April 2011 14:36, Steven Schveighoffer <schveiguy yahoo.com
 <mailto:schveiguy yahoo.com>> wrote:

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

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.
Apr 13 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 12 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 13 2011
prev sibling next sibling parent Emil Madsen <sovende gmail.com> writes:
--001636e1f77f8ad22f04a0cd0310
Content-Type: text/plain; charset=ISO-8859-1

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 --001636e1f77f8ad22f04a0cd0310 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 13 April 2011 14:36, Steven Schveighoffer <sp= an dir=3D"ltr">&lt;<a href=3D"mailto:schveiguy yahoo.com">schveiguy yahoo.c= om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On Tue, 12 Apr 2011 18:00:40 -0400, spir &lt;<a href=3D"m= ailto:denis.spir gmail.com" target=3D"_blank">denis.spir gmail.com</a>&gt; = wrote:<br> <br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 04/12/2011 11:51 PM, Steven Schveighoffer wrote:<br> </div><div><div></div><div class=3D"h5"><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Tue, 12 Apr 2011 17:21:57 -0400, spir &lt;<a href=3D"mailto:denis.spir g= mail.com" target=3D"_blank">denis.spir gmail.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 04/12/2011 09:21 PM, Steven Schveighoffer wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> int main(){<br> int a,b;<br> do{<br> scanf(&quot;%d %d&quot;,&amp;a,&amp;b);<br> }while(a&lt;b) //note missing semicolon here<br> return 0;<br> }<br> <br> The grammar specifies this correctly, but then again, the example uses the<= br> semicolon. (<a href=3D"http://www.digitalmars.com/d/2.0/statement.html#DoSt= atement" target=3D"_blank">http://www.digitalmars.com/d/2.0/statement.html#= DoStatement</a>)<br> [...]<br> I think the grammar should be changed...<br> </blockquote> <br> yop!<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> This is almost as bad as go&#39;s<br> requirement for if statement opening block to be on the same line...<br> </blockquote> <br> why? I like Go&#39;s syntactuc diffs. (except for its &quot;multi-for&quot;= )<br> </blockquote> <br> in Go, this:<br> <br> if(x)<br> {<br> gosWriteRoutineThatIDontKnowTheSyntaxOf(&quot;hello&quot;)<br> }<br> <br> is equivalent to this in D:<br> <br> if(x)<br> {<br> }<br> <br> writeln(&quot;hello&quot;);<br> <br> This is frankly unforgivable IMO.<br> <br> Of course it&#39;s fixable, but the attitude that &quot;the coder should kn= ow better&quot;<br> doesn&#39;t really make me comfortable with it. And I hate the &quot;brace = on the same<br> line&quot; format (but this of course is not a real argument against it).<b= r> </blockquote> <br></div></div><div class=3D"im"> Oh, that&#39;s what you meant! I find this a Good Thing, in that it enforce= s one bracing style (the right one, that does not eats one more line for ju= st a &#39;{&#39;).<br> </div></blockquote> <br> No, it doesn&#39;t enforce anything. =A0The above compiles and runs. =A0Wha= t it does is introduce subtle bugs.<br> <br> The way to fix it is to make the above an error.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> About knowing or not about this (non/mis/-)feature, it&#39;s written down, = and clearly, in all Go docs I&#39;ve read. And one cannot miss it for very = long anyway ;-)<br> </blockquote> <br></div> I know that if(xyz); is not *ever* what I meant, but in C it compiles. =A0H= owever, in D, it tells me I shouldn&#39;t do that. =A0What results is less = bugs because I can&#39;t make that mistake without the compiler complaining= .<br> <br> I&#39;m not saying that the spec isn&#39;t well defined, or the manual isn&= #39;t clear, what I&#39;m saying is, the attitude reflected in the rule is = that greater burden is put on the developer to make sure they follow the ru= les without compiler enforcement. =A0It makes me want to not use Go. =A0And= in fact, I will probably never use it as long as this rule is in place.<di= v class=3D"im"> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Maybe, if not done already, a line starting with an opening brace should ge= nerate a parsing error.<br> </blockquote> <br></div> Typically this is used to create a new scope in C/D/Java/C#. =A0This allows= declaring temporary variables, not sure how it is in Go, but I&#39;d assum= e something similar.<br> <br> -Steve<br> </blockquote></div><br><br><div>Does D throw an error at; if(expression &am= p;&amp; expression)<b>; </b>or only at if(expression);</div><div>Because yo= u could actually use the first one, alike this:</div><div><div>&lt;code&gt;= </div> <div>#include &lt;stdio.h&gt;</div><div><br></div><div>bool test()</div><di= v>{</div><div>=A0 =A0 printf(&quot;test\n&quot;);</div><div>=A0 =A0 return = false;</div><div>}</div><div><br></div><div>bool test2()</div><div>{</div><= div> =A0 =A0 printf(&quot;test2\n&quot;);</div><div>=A0 =A0 return true;</div><d= iv>}</div><div><br></div><div>int main()</div><div>{</div><div>=A0 =A0 if(t= est() &amp;&amp; test2());</div><div>}</div></div><div>&lt;/code&gt;</div><= div>Output =3D &quot;test&quot;</div> <div>if test returns true, then: Output =3D &quot;test&quot; + &quot;test2&= quot;</div><div><div><br></div><div>Simply because its conditional, and if = the first one fails, why bother evaluating the rest?<br clear=3D"all"><br>-= - <br> // Yours sincerely<br>// Emil &#39;Skeen&#39; Madsen<br> </div></div> --001636e1f77f8ad22f04a0cd0310--
Apr 13 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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.

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
Apr 13 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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!
Apr 13 2011
prev sibling parent Emil Madsen <sovende gmail.com> writes:
--000e0cd14f886d0aa304a0cf578c
Content-Type: text/plain; charset=ISO-8859-1

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

 On 04/13/2011 07:44 AM, Emil Madsen wrote:

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

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

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 --000e0cd14f886d0aa304a0cf578c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 13 April 2011 16:17, Kai Meyer <span dir=3D"l= tr">&lt;<a href=3D"mailto:kai unixlords.com">kai unixlords.com</a>&gt;</spa= n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On 04/13/2011 07:44 AM, Emil Madsen wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 13 April 2011 14:36, Steven Schveighoffer &lt;<a href=3D"mailto:schveigu= y yahoo.com" target=3D"_blank">schveiguy yahoo.com</a><br></div><div class= =3D"im"> &lt;mailto:<a href=3D"mailto:schveiguy yahoo.com" target=3D"_blank">schveig= uy yahoo.com</a>&gt;&gt; wrote:<br> <br> =A0 =A0On Tue, 12 Apr 2011 18:00:40 -0400, spir &lt;<a href=3D"mailto:deni= s.spir gmail.com" target=3D"_blank">denis.spir gmail.com</a><br></div><div = class=3D"im"> =A0 =A0&lt;mailto:<a href=3D"mailto:denis.spir gmail.com" target=3D"_blank= ">denis.spir gmail.com</a>&gt;&gt; wrote:<br> <br> =A0 =A0 =A0 =A0On 04/12/2011 11:51 PM, Steven Schveighoffer wrote:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0On Tue, 12 Apr 2011 17:21:57 -0400, spir<br></div><= div><div></div><div class=3D"h5"> =A0 =A0 =A0 =A0 =A0 =A0&lt;<a href=3D"mailto:denis.spir gmail.com" target= =3D"_blank">denis.spir gmail.com</a> &lt;mailto:<a href=3D"mailto:denis.spi= r gmail.com" target=3D"_blank">denis.spir gmail.com</a>&gt;&gt; wrote:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On 04/12/2011 09:21 PM, Steven Schveighoffe= r wrote:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int main(){<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int a,b;<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0do{<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0scanf(&quot;%d %d&quot;,&amp;a,&amp= ;b);<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}while(a&lt;b) //note missing semic= olon here<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0;<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The grammar specifies this correctl= y, but then<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0again, the example uses the<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0semicolon.<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(<a href=3D"http://www.digitalmars.= com/d/2.0/statement.html#DoStatement" target=3D"_blank">http://www.digitalm= ars.com/d/2.0/statement.html#DoStatement</a>)<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[...]<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I think the grammar should be chang= ed...<br> <br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0yop!<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This is almost as bad as go&#39;s<b= r> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0requirement for if statement openin= g block to be on<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the same line...<br> <br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0why? I like Go&#39;s syntactuc diffs. (exce= pt for its<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;multi-for&quot;)<br> <br> <br> =A0 =A0 =A0 =A0 =A0 =A0in Go, this:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0if(x)<br> =A0 =A0 =A0 =A0 =A0 =A0{<br> =A0 =A0 =A0 =A0 =A0 =A0gosWriteRoutineThatIDontKnowTheSyntaxOf(&quot;hello= &quot;)<br> =A0 =A0 =A0 =A0 =A0 =A0}<br> <br> =A0 =A0 =A0 =A0 =A0 =A0is equivalent to this in D:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0if(x)<br> =A0 =A0 =A0 =A0 =A0 =A0{<br> =A0 =A0 =A0 =A0 =A0 =A0}<br> <br> =A0 =A0 =A0 =A0 =A0 =A0writeln(&quot;hello&quot;);<br> <br> =A0 =A0 =A0 =A0 =A0 =A0This is frankly unforgivable IMO.<br> <br> =A0 =A0 =A0 =A0 =A0 =A0Of course it&#39;s fixable, but the attitude that &= quot;the coder<br> =A0 =A0 =A0 =A0 =A0 =A0should know better&quot;<br> =A0 =A0 =A0 =A0 =A0 =A0doesn&#39;t really make me comfortable with it. And= I hate the<br> =A0 =A0 =A0 =A0 =A0 =A0&quot;brace on the same<br> =A0 =A0 =A0 =A0 =A0 =A0line&quot; format (but this of course is not a real= argument<br> =A0 =A0 =A0 =A0 =A0 =A0against it).<br> <br> <br> =A0 =A0 =A0 =A0Oh, that&#39;s what you meant! I find this a Good Thing, in= that it<br> =A0 =A0 =A0 =A0enforces one bracing style (the right one, that does not ea= ts<br> =A0 =A0 =A0 =A0one more line for just a &#39;{&#39;).<br> <br> <br> =A0 =A0No, it doesn&#39;t enforce anything. =A0The above compiles and runs= . =A0What<br> =A0 =A0it does is introduce subtle bugs.<br> <br> =A0 =A0The way to fix it is to make the above an error.<br> <br> <br> =A0 =A0 =A0 =A0About knowing or not about this (non/mis/-)feature, it&#39;= s written<br> =A0 =A0 =A0 =A0down, and clearly, in all Go docs I&#39;ve read. And one ca= nnot miss<br> =A0 =A0 =A0 =A0it for very long anyway ;-)<br> <br> <br> =A0 =A0I know that if(xyz); is not *ever* what I meant, but in C it<br> =A0 =A0compiles. =A0However, in D, it tells me I shouldn&#39;t do that. = =A0What<br> =A0 =A0results is less bugs because I can&#39;t make that mistake without = the<br> =A0 =A0compiler complaining.<br> <br> =A0 =A0I&#39;m not saying that the spec isn&#39;t well defined, or the man= ual isn&#39;t<br> =A0 =A0clear, what I&#39;m saying is, the attitude reflected in the rule i= s<br> =A0 =A0that greater burden is put on the developer to make sure they follo= w<br> =A0 =A0the rules without compiler enforcement. =A0It makes me want to not = use<br> =A0 =A0Go. =A0And in fact, I will probably never use it as long as this ru= le<br> =A0 =A0is in place.<br> <br> <br> =A0 =A0 =A0 =A0Maybe, if not done already, a line starting with an opening= <br> =A0 =A0 =A0 =A0brace should generate a parsing error.<br> <br> <br> =A0 =A0Typically this is used to create a new scope in C/D/Java/C#. =A0Thi= s<br> =A0 =A0allows declaring temporary variables, not sure how it is in Go, but= <br> =A0 =A0I&#39;d assume something similar.<br> <br> =A0 =A0-Steve<br> <br> <br> <br></div></div><div class=3D"im"> Does D throw an error at; if(expression &amp;&amp; expression)*; *or only a= t<br> if(expression);<br> Because you could actually use the first one, alike this:<br> &lt;code&gt;<br> #include &lt;stdio.h&gt;<br> <br> bool test()<br> {<br> =A0 =A0 printf(&quot;test\n&quot;);<br> =A0 =A0 return false;<br> }<br> <br> bool test2()<br> {<br> =A0 =A0 printf(&quot;test2\n&quot;);<br> =A0 =A0 return true;<br> }<br> <br> int main()<br> {<br> =A0 =A0 if(test() &amp;&amp; test2());<br> }<br> &lt;/code&gt;<br> Output =3D &quot;test&quot;<br> if test returns true, then: Output =3D &quot;test&quot; + &quot;test2&quot;= <br> <br> Simply because its conditional, and if the first one fails, why bother<br> evaluating the rest?<br> <br></div> --<div class=3D"im"><br> // Yours sincerely<br> // Emil &#39;Skeen&#39; Madsen<br> </div></blockquote> <br> 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.<br> <br> if(test())<br> =A0 =A0test2();<br> <br> Since test2&#39;s return statement isn&#39;t used for anything means to me = that it doesn&#39;t belong in the conditional statement.<br> </blockquote></div><br>Well I agree that its more correct for the case post= ed, but it can just get somewhat messy, if your having a mix of conditional= s say &#39;&amp;&amp;&#39; and &#39;||&#39;.<div>Even tho its not really go= od style, some of the people I study with use this trick quite a lot conver= ting functional programs,=A0apparently=A0(not my area of expertise).</div> <div><br></div><div>But surely I would go with your approach too, but if yo= ur having a deep nesting of conditionals, I guess that could give some heav= ily nested code too. (Atleast if you are to follow some specific coding sta= ndard).=A0</div> <div>--=A0<br>// Yours sincerely<br>// Emil &#39;Skeen&#39; Madsen<br> </div> --000e0cd14f886d0aa304a0cf578c--
Apr 13 2011
prev sibling parent spir <denis.spir gmail.com> writes:
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
Apr 12 2011