Re: Semicolon can be left out after do-while
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(ab) //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
Re: Semicolon can be left out after do-while
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(ab) //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
Re: Semicolon can be left out after do-while
On 4/13/11, Steven Schveighoffer schvei...@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!
Re: Semicolon can be left out after do-while
On Wed, 13 Apr 2011 09:44:54 -0400, Emil Madsen sove...@gmail.com wrote:
On 13 April 2011 14:36, Steven Schveighoffer schvei...@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
Re: Semicolon can be left out after do-while
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(ab) //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.
Re: Semicolon can be left out after do-while
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(ab) //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
Re: Semicolon can be left out after do-while
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
Re: Semicolon can be left out after do-while
On Tue, 12 Apr 2011 14:57:26 -0400, Timon Gehr timon.g...@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(ab) //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(ab)
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
Re: Semicolon can be left out after do-while
On 04/12/2011 09:21 PM, Steven Schveighoffer wrote:
int main(){
int a,b;
do{
scanf(%d %d,a,b);
}while(ab) //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
Re: Semicolon can be left out after do-while
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(ab) //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
Re: Semicolon can be left out after do-while
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(ab) //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
Re: Semicolon can be left out after do-while
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. IIRC, TDPL says that the semicolon is required, even though it isn't, and when that was brought to Andrei's attention, he asked Walter to change it so that it is required like TDPL says. But as far as I know, nothing has happened. I don't recall Walter saying anything about it on the list either. So, I have no idea what the state of this is. I susupect that it was completely forgetten. An bug stating that this needs to be fixed to match TDPL is probably in order. - Jonathan M Davis
