On 13 April 2011 14:36, Steven Schveighoffer <schvei...@yahoo.com> wrote:
> On Tue, 12 Apr 2011 18:00:40 -0400, spir <denis.s...@gmail.com> wrote: > > On 04/12/2011 11:51 PM, Steven Schveighoffer wrote: >> >>> On Tue, 12 Apr 2011 17:21:57 -0400, spir <denis.s...@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