www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - for loop parens

reply "ixid" <nuaccount gmail.com> writes:
Go and Rust seem to have been able to dispense with the parens in 
for loops, is this something that would be possible to do in D or 
are there parsing and grammatical reasons not to do this?
Jul 12 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
ixid:


 Go and Rust seem to have been able to dispense with the parens 
 in for loops, is this something that would be possible to do in 
 D or are there parsing and grammatical reasons not to do this?


Go has chosen a different syntax. I don't think D syntax of for 
loops can change now...

Bye,
bearophile
Jul 12 2013
parent reply "ixid" <nuaccount gmail.com> writes:
On Friday, 12 July 2013 at 19:44:43 UTC, bearophile wrote:

 ixid:


 Go and Rust seem to have been able to dispense with the parens 
 in for loops, is this something that would be possible to do 
 in D or are there parsing and grammatical reasons not to do 
 this?


 Go has chosen a different syntax. I don't think D syntax of for 
 loops can change now...

 Bye,
 bearophile


Humour me. =) Perhaps as a discussion over a D3 language. If 
curly brackets were required where parens were omitted what would 
prevent such a syntax in D?
Jul 12 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
ixid:


 If curly brackets were required where parens were omitted
 what would prevent such a syntax in D?


Maybe nothing, beside lot of programmers that want the "freedom" 
to omit curly brackets :-)

Bye,
bearophile
Jul 12 2013
parent reply "ixid" <nuaccount gmail.com> writes:
On Friday, 12 July 2013 at 20:02:46 UTC, bearophile wrote:

 ixid:


 If curly brackets were required where parens were omitted
 what would prevent such a syntax in D?


 Maybe nothing, beside lot of programmers that want the 
 "freedom" to omit curly brackets :-)

 Bye,
 bearophile


Similarly what are D user's potential issues with Go-like 
semi-colon rules? And would this be possible as a subset of 
current D code?
Jul 12 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
ixid:


 Similarly what are D user's potential issues with Go-like 
 semi-colon rules? And would this be possible as a subset of 
 current D code?


Such changes will not happen even in D4. Walter is strongly 
against the idea of optional semicolons, on the base that 
semicolons help the parser, so they allow better error recovery 
and error messages.

Bye,
bearophile
Jul 12 2013
parent reply "ixid" <nuaccount gmail.com> writes:
On Friday, 12 July 2013 at 20:30:59 UTC, bearophile wrote:

 ixid:


 Similarly what are D user's potential issues with Go-like 
 semi-colon rules? And would this be possible as a subset of 
 current D code?


 Such changes will not happen even in D4. Walter is strongly 
 against the idea of optional semicolons, on the base that 
 semicolons help the parser, so they allow better error recovery 
 and error messages.

 Bye,
 bearophile


Is there any evidence that these are issues in Go? That sounds 
like a theoretical objection that isn't attackable when no one 
has done it but turns out not to be terribly important when 
someone actually does it.
Jul 12 2013
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 7/12/13 5:38 PM, ixid wrote:

 On Friday, 12 July 2013 at 20:30:59 UTC, bearophile wrote:

 ixid:


 Similarly what are D user's potential issues with Go-like semi-colon
 rules? And would this be possible as a subset of current D code?


 Such changes will not happen even in D4. Walter is strongly against
 the idea of optional semicolons, on the base that semicolons help the
 parser, so they allow better error recovery and error messages.

 Bye,
 bearophile


 Is there any evidence that these are issues in Go? That sounds like a
 theoretical objection that isn't attackable when no one has done it but
 turns out not to be terribly important when someone actually does it.


They are not issues in Go, but Walter is strongly against optional 
semicolons, as bearophile said. Me and others (like you) like optional 
semicolons, but since Walter doesn't and it's his language, that will 
not change.

I personally understand much better the code without semicolons, like in 
Ruby and Python. And making a parser that way isn't that much difficult, 
and error recovery is as powerful.
Jul 12 2013
parent reply "ixid" <nuaccount gmail.com> writes:
 They are not issues in Go, but Walter is strongly against 
 optional semicolons, as bearophile said. Me and others (like 
 you) like optional semicolons, but since Walter doesn't and 
 it's his language, that will not change.

 I personally understand much better the code without 
 semicolons, like in Ruby and Python. And making a parser that 
 way isn't that much difficult, and error recovery is as 
 powerful.


Yes, I don't expect anyone to change their opinion though frankly 
the anti-groups opinions feel more like attachment to the status 
quo than something that's evidently and demonstrably superior.

It seems a pity that D is achieving such power and elegance in 
some areas while failing to take on some of the syntactic beauty 
that is within reach. The ultimate language would look something 
like D crossed with Go in my eyes. It would be interesting if 
someone were able to make a D subset that showed what it could 
look like. There is significant value to being easy to read and 
write, making the language naturally more appealing for users 
just as speed makes applications much more attractive to users.
Jul 12 2013
next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 7/12/13 1:46 PM, ixid wrote:

 They are not issues in Go, but Walter is strongly against optional semicolons,
as bearophile said.
 Me and others (like you) like optional semicolons, but since Walter doesn't
and it's his language,
 that will not change.

 I personally understand much better the code without semicolons, like in Ruby
and Python. And
 making a parser that way isn't that much difficult, and error recovery is as
powerful.


 Yes, I don't expect anyone to change their opinion though frankly the
anti-groups opinions feel more
 like attachment to the status quo than something that's evidently and
demonstrably superior.

 It seems a pity that D is achieving such power and elegance in some areas
while failing to take on
 some of the syntactic beauty that is within reach. The ultimate language would
look something like D
 crossed with Go in my eyes. It would be interesting if someone were able to
make a D subset that
 showed what it could look like. There is significant value to being easy to
read and write, making
 the language naturally more appealing for users just as speed makes
applications much more
 attractive to users.


One person's beauty is another person's ugly.  This is an area that reasonable
people are going to 
disagree on.  You're feeling on their reasons is rather dismissive.
Jul 12 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 12, 2013 at 05:51:21PM -0700, Brad Roberts wrote:

 On 7/12/13 1:46 PM, ixid wrote:


[...]

It seems a pity that D is achieving such power and elegance in some
areas while failing to take on some of the syntactic beauty that is
within reach. The ultimate language would look something like D
crossed with Go in my eyes. It would be interesting if someone were
able to make a D subset that showed what it could look like. There is
significant value to being easy to read and write, making the
language naturally more appealing for users just as speed makes
applications much more attractive to users.


 
 One person's beauty is another person's ugly.  This is an area that
 reasonable people are going to disagree on.  You're feeling on their
 reasons is rather dismissive.


I find this fixation on syntax rather strange. As long as the syntax is
not *too* ugly (*cough*C++ templates*cough*) isn't the *semantics* more
important? A pretty language that has limited expressiveness is useless;
a powerful language that's a bit ugly in syntax isn't any less powerful
because of it.


T

-- 
There are two ways to write error-free programs; only the third one works.
Jul 12 2013
next sibling parent reply "ixid" <nuaccount gmail.com> writes:
 As long as the syntax is
 not *too* ugly (*cough*C++ templates*cough*) isn't the 
 *semantics* more
 important? A pretty language that has limited expressiveness is 
 useless;
 a powerful language that's a bit ugly in syntax isn't any less 
 powerful
 because of it.


 T


What is the cost of expressiveness in these cases? I don't think 
expressiveness should be limited and often prettiness lends 
itself to expressiveness. People find D templates much easier to 
use than C++ ones and in part that's because they're much easier 
for humans to parse.
Jul 12 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Jul 13, 2013 at 03:19:04AM +0200, ixid wrote:

As long as the syntax is not *too* ugly (*cough*C++ templates*cough*)
isn't the *semantics* more important? A pretty language that has
limited expressiveness is useless; a powerful language that's a bit
ugly in syntax isn't any less powerful because of it.




[...]

 What is the cost of expressiveness in these cases?


But that's the issue, this is just a cosmetic change that doesn't really
add expressiveness to the language.



 I don't think expressiveness should be limited and often prettiness
 lends itself to expressiveness. People find D templates much easier to
 use than C++ ones and in part that's because they're much easier for
 humans to parse.


But I find C's for-loop syntax easier to parse, because what's in the
preamble is clearly distinguished from what's in the loop body. Omitting
the parens would make it visually more similar to the loop body, and
thus more liable to be confused with it.

I think comparing this to D vs. C++ template syntax is a bit unfair. C++
templates made a bad choice of using angle brackets, which are already
being used for comparison operators, thus things like func<a<b>(x)>y are
ambiguous: is it func<(a<b)>(x) > y, or is it func<(a<b>(x))> y? Not to
mention func<a<b>> is actually syntactically invalid until C++11 (how
many years did it take for them to fix that one!). D templates are so
much better, in part because they use normal parentheses, which *don't*
suffer from ambiguity with existing operators.

In the case of optional parens in for-loops, there are no such ambiguity
issues involved. It's more a matter of personal preference than anything
else, IMO.


T

-- 
To err is human; to forgive is not our policy. -- Samuel Adler
Jul 12 2013
prev sibling parent reply "JS" <js.mdnq gmail.com> writes:
On Saturday, 13 July 2013 at 01:06:09 UTC, H. S. Teoh wrote:

 On Fri, Jul 12, 2013 at 05:51:21PM -0700, Brad Roberts wrote:

 On 7/12/13 1:46 PM, ixid wrote:


 [...]

It seems a pity that D is achieving such power and elegance 
in some
areas while failing to take on some of the syntactic beauty 
that is
within reach. The ultimate language would look something like 
D
crossed with Go in my eyes. It would be interesting if 
someone were
able to make a D subset that showed what it could look like. 
There is
significant value to being easy to read and write, making the
language naturally more appealing for users just as speed 
makes
applications much more attractive to users.


 
 One person's beauty is another person's ugly.  This is an area 
 that
 reasonable people are going to disagree on.  You're feeling on 
 their
 reasons is rather dismissive.


 I find this fixation on syntax rather strange. As long as the 
 syntax is
 not *too* ugly (*cough*C++ templates*cough*) isn't the 
 *semantics* more
 important? A pretty language that has limited expressiveness is 
 useless;
 a powerful language that's a bit ugly in syntax isn't any less 
 powerful
 because of it.


Of course, .net demonstrates this very well... but do you really 
expect most people to really be able to think that abstractly? 
Syntax is meaningless but necessary... see 
http://en.wikipedia.org/wiki/Malbolge.
Jul 13 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Jul 13, 2013 at 05:08:11PM +0200, JS wrote:

 On Saturday, 13 July 2013 at 01:06:09 UTC, H. S. Teoh wrote:


[...]

I find this fixation on syntax rather strange. As long as the syntax
is not *too* ugly (*cough*C++ templates*cough*) isn't the *semantics*
more important? A pretty language that has limited expressiveness is
useless; a powerful language that's a bit ugly in syntax isn't any
less powerful because of it.


 
 Of course, .net demonstrates this very well... but do you really
 expect most people to really be able to think that abstractly?
 Syntax is meaningless but necessary... see
 http://en.wikipedia.org/wiki/Malbolge.


That's not a fair example. I *did* say, as long as the syntax is not
*too* ugly. Malbolge doesn't qualify. :)  I mean, if you really want to
push this to the extreme, you could say we should all just write lambda
expressions, since it's all Turing-complete anyway.

The difference between D and Malbolge is on a totally different scale
than the difference between for(...){...} and for ...{...}. Just because
the difference between walking to a destination vs. driving there is a
big difference, doesn't mean that the difference between whether you
wear a red shirt vs. a white shirt while travelling is an important
issue.


T

-- 
Windows 95 was a joke, and Windows 98 was the punchline.
Jul 13 2013
prev sibling parent reply "QAston" <qaston gmail.com> writes:
On Friday, 12 July 2013 at 20:46:21 UTC, ixid wrote:

 Yes, I don't expect anyone to change their opinion though 
 frankly the anti-groups opinions feel more like attachment to 
 the status quo than something that's evidently and demonstrably 
 superior.


I think that Python has syntax evidently and demonstrably 
superior to D. Why not Python?

 It seems a pity that D is achieving such power and elegance in 
 some areas while failing to take on some of the syntactic 
 beauty that is within reach. The ultimate language would look 
 something like D crossed with Go in my eyes. It would be 
 interesting if someone were able to make a D subset that showed 
 what it could look like. There is significant value to being 
 easy to read and write, making the language naturally more 
 appealing for users just as speed makes applications much more 
 attractive to users.


There won't be an ultimate language - ever. People haven't 
settled up even on tabs vs spaces or braces issues yet.

Please keep in mind that every change made to the langage has 
costs that have to be paid for the benefits. Sometimes costs are 
not worth paying for the potential benefits. Status quo has this 
wonderful feature - it has 0 cost, so the benefit/cost ratio 
approaches infinity :).

Also, i don't know what's wrong with parens - 2 additional 
keystrokes? I didn't see a for loop i a long time - ranges + 
foreach are everywhere. And foreach is 4 chars more to type than 
for :P.
Jul 12 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, July 13, 2013 06:42:57 QAston wrote:

 On Friday, 12 July 2013 at 20:46:21 UTC, ixid wrote:

 Yes, I don't expect anyone to change their opinion though
 frankly the anti-groups opinions feel more like attachment to
 the status quo than something that's evidently and demonstrably
 superior.


 
 I think that Python has syntax evidently and demonstrably
 superior to D. Why not Python?


I think that that's very disputable. In general, which syntax is better than 
another syntax is very subjective. Personally, I hate Python's syntax and find 
it far harder to deal with than that of languages like C/C++ or D. The lack of 
braces alone is a huge annoyance for editing code (being able to hop between 
braces in an editor is invaluable for getting to the beginning and end of 
functions, scopes, classes, etc.), and it's easy enough to find rants where 
people have had bugs in their python code due to spacing issues and how it 
cost them hours to find them.

Yes. Some people prefer python's syntax, but I don't see how anyone could 
possibly claim that it was demonstratably superior. It's primarily a 
subjective issue, and from what I've seen, the objective portions of the 
argument are very much against python as having braces and semicolons and the 
like makes the code more explicit and therefore less prone to scoping issues. 
So while that tradeoff may very well be worth it for some people, it's 
certainly not an objective advantage for python's syntax.

- Jonathan M Davis
Jul 12 2013
parent reply "QAston" <qaston gmail.com> writes:
On Saturday, 13 July 2013 at 04:56:19 UTC, Jonathan M Davis wrote:

 On Saturday, July 13, 2013 06:42:57 QAston wrote:

 On Friday, 12 July 2013 at 20:46:21 UTC, ixid wrote:

 Yes, I don't expect anyone to change their opinion though
 frankly the anti-groups opinions feel more like attachment to
 the status quo than something that's evidently and 
 demonstrably
 superior.


 
 I think that Python has syntax evidently and demonstrably
 superior to D. Why not Python?


 I think that that's very disputable. In general, which syntax 
 is better than
 another syntax is very subjective. Personally, I hate Python's 
 syntax and find
 it far harder to deal with than that of languages like C/C++ or 
 D. The lack of
 braces alone is a huge annoyance for editing code (being able 
 to hop between
 braces in an editor is invaluable for getting to the beginning 
 and end of
 functions, scopes, classes, etc.), and it's easy enough to find 
 rants where
 people have had bugs in their python code due to spacing issues 
 and how it
 cost them hours to find them.

 Yes. Some people prefer python's syntax, but I don't see how 
 anyone could
 possibly claim that it was demonstratably superior. It's 
 primarily a
 subjective issue, and from what I've seen, the objective 
 portions of the
 argument are very much against python as having braces and 
 semicolons and the
 like makes the code more explicit and therefore less prone to 
 scoping issues.
 So while that tradeoff may very well be worth it for some 
 people, it's
 certainly not an objective advantage for python's syntax.

 - Jonathan M Davis


I agree, I was just playing games with ixid.
Jul 12 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, July 13, 2013 07:03:28 QAston wrote:

 On Saturday, 13 July 2013 at 04:56:19 UTC, Jonathan M Davis wrote:

 On Saturday, July 13, 2013 06:42:57 QAston wrote:

 On Friday, 12 July 2013 at 20:46:21 UTC, ixid wrote:

 Yes, I don't expect anyone to change their opinion though
 frankly the anti-groups opinions feel more like attachment to
 the status quo than something that's evidently and
 demonstrably
 superior.


 
 I think that Python has syntax evidently and demonstrably
 superior to D. Why not Python?


 
 I think that that's very disputable. In general, which syntax
 is better than
 another syntax is very subjective. Personally, I hate Python's
 syntax and find
 it far harder to deal with than that of languages like C/C++ or
 D. The lack of
 braces alone is a huge annoyance for editing code (being able
 to hop between
 braces in an editor is invaluable for getting to the beginning
 and end of
 functions, scopes, classes, etc.), and it's easy enough to find
 rants where
 people have had bugs in their python code due to spacing issues
 and how it
 cost them hours to find them.
 
 Yes. Some people prefer python's syntax, but I don't see how
 anyone could
 possibly claim that it was demonstratably superior. It's
 primarily a
 subjective issue, and from what I've seen, the objective
 portions of the
 argument are very much against python as having braces and
 semicolons and the
 like makes the code more explicit and therefore less prone to
 scoping issues.
 So while that tradeoff may very well be worth it for some
 people, it's
 certainly not an objective advantage for python's syntax.
 
 - Jonathan M Davis


 
 I agree, I was just playing games with ixid.


Ah. Clearly I read through the posts too quickly.

I should probably add though that the problems that the lack of braces cause 
in python with regards to moving around in the code in an editor also apply to 
parens, which would be an objective reason why getting rid of parens on for 
loops would cause problems. Obviously, it could be argued that how the code 
looks without parens would be better than with parens and worth the problems 
it would cause with text editors, but that would be a completely subjective 
argument.

- Jonathan M Davis
Jul 12 2013
prev sibling next sibling parent reply "QAston" <qaston gmail.com> writes:
On Saturday, 13 July 2013 at 04:42:58 UTC, QAston wrote:

 Also, i don't know what's wrong with parens - 2 additional 
 keystrokes? I didn't see a for loop i a long time - ranges + 
 foreach are everywhere. And foreach is 4 chars more to type 
 than for :P.


Replying to myself, but well, this is flawed, foreach is ususally 
shorter than for.
Jul 12 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/12/2013 10:34 PM, QAston wrote:> On Saturday, 13 July 2013 at 
04:42:58 UTC, QAston wrote:

 Also, i don't know what's wrong with parens - 2 additional keystrokes?
 I didn't see a for loop i a long time - ranges + foreach are
 everywhere. And foreach is 4 chars more to type than for :P.


 Replying to myself, but well, this is flawed, foreach is ususally
 shorter than for.


Especially when for loops can be infinitely long. :) I think the actual 
syntax of 'for' may be surprising to most:

   http://dlang.org/statement.html#ForStatement

import std.stdio;

void main()
{
     for ( {
             int i = 0;
             double d = 0.5;

             struct S
             {
                 string s;
             }

             auto s = S("hello");

             writeln("I am in the initialization clause of a for loop!");
         } i < 10; ++i) {

         writeln("i: ", i, ", d: ", d);
         d /= s.s.length;
     }
}

Ali
Jul 12 2013
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 13 July 2013 at 06:56:46 UTC, Ali Çehreli wrote:

 On 07/12/2013 10:34 PM, QAston wrote:> On Saturday, 13 July 
 2013 at 04:42:58 UTC, QAston wrote:

 Also, i don't know what's wrong with parens - 2 additional




 keystrokes?

 I didn't see a for loop i a long time - ranges + foreach are
 everywhere. And foreach is 4 chars more to type than for :P.


 Replying to myself, but well, this is flawed, foreach is


 ususally

 shorter than for.


 Especially when for loops can be infinitely long. :) I think 
 the actual syntax of 'for' may be surprising to most:

   http://dlang.org/statement.html#ForStatement

 import std.stdio;

 void main()
 {
     for ( {
             int i = 0;
             double d = 0.5;

             struct S
             {
                 string s;
             }

             auto s = S("hello");

             writeln("I am in the initialization clause of a for 
 loop!");
         } i < 10; ++i) {

         writeln("i: ", i, ", d: ", d);
         d /= s.s.length;
     }
 }

 Ali


I love this feature so much ^^
Jul 13 2013
prev sibling parent reply "ixid" <nuaccount gmail.com> writes:
 I think that Python has syntax evidently and demonstrably 
 superior to D. Why not Python?


White spaces with meaning cause hard to find bugs, the Python 
syntax is not appropriate for large projects and this is well 
known. That is not the case for the small changes Go has made.
Jul 13 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
ixid:


 White spaces with meaning cause hard to find bugs, the Python 
 syntax is not appropriate for large projects and this is well 
 known.


Well known by who? What's your evidence? My experience says 
otherwise :-)

Bye,
bearophile
Jul 13 2013
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Sat, 2013-07-13 at 12:43 +0200, ixid wrote:

 I think that Python has syntax evidently and demonstrably=20
 superior to D. Why not Python?


=20
 White spaces with meaning cause hard to find bugs, the Python=20
 syntax is not appropriate for large projects and this is well=20
 known. That is not the case for the small changes Go has made.


Who says Python is not appropriate for large projects? What is their
authority for saying this?

This claim is certainly not well known, nor is it understood or believed
by anyone undertaking serious software projects that involve Python.

Some of the enforced syntactic constraints of Go due to the deduced
semi-colon insertion, are awful and ugly, in my opinion. To hide the
issues by trying to make a benefit from there being "one and only one
allowable style of Go code" enforced by gofmt is actually running away
from the real problem.=20

Personally I think parentheses enclosing the control expressions in for
statements and end of statement semi-colons are anachronisms. C++ and D
choose to keep them, which is irritating. Go always has end of statement
semi-colons even if the source code appears not to.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jul 13 2013
prev sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-07-12, 22:38, ixid wrote:


 On Friday, 12 July 2013 at 20:30:59 UTC, bearophile wrote:

 ixid:


 Similarly what are D user's potential issues with Go-like semi-colon  
 rules? And would this be possible as a subset of current D code?


 Such changes will not happen even in D4. Walter is strongly against the  
 idea of optional semicolons, on the base that semicolons help the  
 parser, so they allow better error recovery and error messages.

 Bye,
 bearophile


 Is there any evidence that these are issues in Go?


I'm not sure how much of a problem it is, especially given that Go has a
strict style guide, but the objection has come up that these two are
very different:

   if i < f() {
       g()
   }

and

   if i < f()
   {
       g()
   }

In the second case, a semicolon is inserted on the same line as the if.

However, like I said, in idiomatic Go, this is simply not a done thing.

-- 
Simen
Jul 12 2013
parent "ixid" <nuaccount gmail.com> writes:
 I'm not sure how much of a problem it is, especially given that 
 Go has a
 strict style guide, but the objection has come up that these 
 two are
 very different:

   if i < f() {
       g()
   }

 and

   if i < f()
   {
       g()
   }

 In the second case, a semicolon is inserted on the same line as 
 the if.

 However, like I said, in idiomatic Go, this is simply not a 
 done thing.


Why would:

     if i < f()

gain a semi-colon? I thought the Go rules require that a line 
would compile to add the semi-colon. In D at least wouldn't the 
line have to be:

     if i < f() {}

before the compiler would add a semi-colon to it?
Jul 12 2013