<div class="gmail_quote">On 13 April 2011 16:17, Kai Meyer <span dir="ltr"><<a href="mailto:kai@unixlords.com">kai@unixlords.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 04/13/2011 07:44 AM, Emil Madsen wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 13 April 2011 14:36, Steven Schveighoffer <<a href="mailto:schveiguy@yahoo.com" target="_blank">schveiguy@yahoo.com</a><br></div><div class="im">
<mailto:<a href="mailto:schveiguy@yahoo.com" target="_blank">schveiguy@yahoo.com</a>>> wrote:<br>
<br>
On Tue, 12 Apr 2011 18:00:40 -0400, spir <<a href="mailto:denis.spir@gmail.com" target="_blank">denis.spir@gmail.com</a><br></div><div class="im">
<mailto:<a href="mailto:denis.spir@gmail.com" target="_blank">denis.spir@gmail.com</a>>> wrote:<br>
<br>
On 04/12/2011 11:51 PM, Steven Schveighoffer wrote:<br>
<br>
On Tue, 12 Apr 2011 17:21:57 -0400, spir<br></div><div><div></div><div class="h5">
<<a href="mailto:denis.spir@gmail.com" target="_blank">denis.spir@gmail.com</a> <mailto:<a href="mailto:denis.spir@gmail.com" target="_blank">denis.spir@gmail.com</a>>> wrote:<br>
<br>
On 04/12/2011 09:21 PM, Steven Schveighoffer wrote:<br>
<br>
int main(){<br>
int a,b;<br>
do{<br>
scanf("%d %d",&a,&b);<br>
}while(a<b) //note missing semicolon here<br>
return 0;<br>
}<br>
<br>
The grammar specifies this correctly, but then<br>
again, the example uses the<br>
semicolon.<br>
(<a href="http://www.digitalmars.com/d/2.0/statement.html#DoStatement" target="_blank">http://www.digitalmars.com/d/2.0/statement.html#DoStatement</a>)<br>
[...]<br>
I think the grammar should be changed...<br>
<br>
<br>
yop!<br>
<br>
This is almost as bad as go's<br>
requirement for if statement opening block to be on<br>
the same line...<br>
<br>
<br>
why? I like Go's syntactuc diffs. (except for its<br>
"multi-for")<br>
<br>
<br>
in Go, this:<br>
<br>
if(x)<br>
{<br>
gosWriteRoutineThatIDontKnowTheSyntaxOf("hello")<br>
}<br>
<br>
is equivalent to this in D:<br>
<br>
if(x)<br>
{<br>
}<br>
<br>
writeln("hello");<br>
<br>
This is frankly unforgivable IMO.<br>
<br>
Of course it's fixable, but the attitude that "the coder<br>
should know better"<br>
doesn't really make me comfortable with it. And I hate the<br>
"brace on the same<br>
line" format (but this of course is not a real argument<br>
against it).<br>
<br>
<br>
Oh, that's what you meant! I find this a Good Thing, in that it<br>
enforces one bracing style (the right one, that does not eats<br>
one more line for just a '{').<br>
<br>
<br>
No, it doesn't enforce anything. The above compiles and runs. What<br>
it does is introduce subtle bugs.<br>
<br>
The way to fix it is to make the above an error.<br>
<br>
<br>
About knowing or not about this (non/mis/-)feature, it's written<br>
down, and clearly, in all Go docs I've read. And one cannot miss<br>
it for very long anyway ;-)<br>
<br>
<br>
I know that if(xyz); is not *ever* what I meant, but in C it<br>
compiles. However, in D, it tells me I shouldn't do that. What<br>
results is less bugs because I can't make that mistake without the<br>
compiler complaining.<br>
<br>
I'm not saying that the spec isn't well defined, or the manual isn't<br>
clear, what I'm saying is, the attitude reflected in the rule is<br>
that greater burden is put on the developer to make sure they follow<br>
the rules without compiler enforcement. It makes me want to not use<br>
Go. And in fact, I will probably never use it as long as this rule<br>
is in place.<br>
<br>
<br>
Maybe, if not done already, a line starting with an opening<br>
brace should generate a parsing error.<br>
<br>
<br>
Typically this is used to create a new scope in C/D/Java/C#. This<br>
allows declaring temporary variables, not sure how it is in Go, but<br>
I'd assume something similar.<br>
<br>
-Steve<br>
<br>
<br>
<br></div></div><div class="im">
Does D throw an error at; if(expression && expression)*; *or only at<br>
if(expression);<br>
Because you could actually use the first one, alike this:<br>
<code><br>
#include <stdio.h><br>
<br>
bool test()<br>
{<br>
printf("test\n");<br>
return false;<br>
}<br>
<br>
bool test2()<br>
{<br>
printf("test2\n");<br>
return true;<br>
}<br>
<br>
int main()<br>
{<br>
if(test() && test2());<br>
}<br>
</code><br>
Output = "test"<br>
if test returns true, then: Output = "test" + "test2"<br>
<br>
Simply because its conditional, and if the first one fails, why bother<br>
evaluating the rest?<br>
<br></div>
--<div class="im"><br>
// Yours sincerely<br>
// Emil 'Skeen' 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>
test2();<br>
<br>
Since test2's return statement isn't used for anything means to me that it doesn't belong in the conditional statement.<br>
</blockquote></div><br>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 '||'.<div>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).</div>
<div><br></div><div>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). </div>
<div>-- <br>// Yours sincerely<br>// Emil 'Skeen' Madsen<br>
</div>