On 13 April 2011 16:17, Kai Meyer <k...@unixlords.com> wrote: > On 04/13/2011 07:44 AM, Emil Madsen wrote: > >> On 13 April 2011 14:36, Steven Schveighoffer <schvei...@yahoo.com >> <mailto:schvei...@yahoo.com>> wrote: >> >> On Tue, 12 Apr 2011 18:00:40 -0400, spir <denis.s...@gmail.com >> <mailto: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 <mailto: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 >> > > 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
