www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Parenthesis around if/for/while condition is not necessary

reply aedt <adnansignsup gmail.com> writes:
for line in stdin.lines() {}

if condition {}

while condition {}

for init; condition; op {}


What's the rationale of keeping the requirement that the 
condition of if/for/while must be wrapped with a parenthesis 
(other than keeping parser simple)? Modern languages have already 
dropped this requirement (i.e. Rust, Nim) and I don't see any 
reason not to do so.
Jun 22 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, June 23, 2018 01:27:30 aedt via Digitalmars-d wrote:

 for line in stdin.lines() {}

 if condition {}

 while condition {}

 for init; condition; op {}


 What's the rationale of keeping the requirement that the
 condition of if/for/while must be wrapped with a parenthesis
 (other than keeping parser simple)? Modern languages have already
 dropped this requirement (i.e. Rust, Nim) and I don't see any
 reason not to do so.


I expect that it's in keeping with why D also has semicolons. The added
redundancy and separation between statements makes it easier for the
compiler to give intelligent error messages and makes it easier for the
reader of the code to see what's going on. This is particularly true for
parens when you consider that single statement bodies without braces are
allowed for if statements and loops. Not having parens in such cases would
be akin to not having a semicolon at the end of a statement, and in the case
of the for loop, it actually creates an ambiguity problem. When does the
statement in the third portion end and the statement in the body begin?

Another consideration is that it's an unnecessary difference from C/C++
code. In general, C code is supposed to be either valid D code or not
compile in order to making porting it easier. Getting rid of the parens
wouldn't break that, but it _would_ make it so that it's more work to port C
code to D when doing so is supposed to be straightforward in most cases.

And of course, the counter question to why the parens shouldn't be removed
would be the question of why they should be. What about having parens makes
the code worse? Many of us would consider the code easier to read with
parens.

Ultimately, by having these delimiters, the intent of the code tends to be
clearer when mistakes are made, and the compiler can give better error
messages, because it's easier for the compiler to accurately guess what the
programmer intended.

Yes, on some level, it's a subjective design decision, but it's also not at
all the true that programmers in general are going to agree that removing
stuff like parens or semicolons from the language is a good idea. Some will
and some won't. And D follows very much in the tradition of C and C++ with
decisions like this. Syntax was changed from those languages when the syntax
actually caused problems (e.g. C function pointers tend to be problematic,
so D has a different syntax for them), but if the C/C++ syntax was not
considered to be a problem, it was largely left as-is in D. That makes code
porting easier, and it makes it easier for programmers to transition to the
language.

- Jonathan M Davis
Jun 22 2018
parent reply Dennis <dkorpel gmail.com> writes:
On Saturday, 23 June 2018 at 02:14:04 UTC, Jonathan M Davis wrote:

 In general, C code is supposed to be either valid D code or not 
 compile in order to making porting it easier. Getting rid of 
 the parens wouldn't break that, but it _would_ make it so that 
 it's more work to port C code to D when doing so is supposed to 
 be straightforward in most cases.

 And of course, the counter question to why the parens shouldn't 
 be removed would be the question of why they should be. What 
 about having parens makes the code worse? Many of us would 
 consider the code easier to read with parens.


I don't see why allowing one to omit the parens makes porting C 
code harder. The fact that D allows `printf = "hello world";` 
doesn't mean you have to write it like that, you can still use 
the C notation. The same applies to parens.

I would be in favor for allowing this. It's not that I encourage 
omitting them, it's similar to curly braces around the statement: 
You want them most of the time, but in certain scenarios you like 
to be able to leave them out. In particular:

if (!("key" in dict)) {...}
if (!(flags & 0x40)) {...}

These are annoying to type and read. There are more than 100 
instances of this in the dmd source code. Aren't these just much 
nicer? :)

if !("key" in dict) {...}
if !(flags & 0x40) {...}

It gets worse as expressions get larger. Parens may be easy to 
read around small expressions, but can you tell quickly whether 
the parens below are balanced?

if (!(t1.ty == Tarray && t2.ty == Tarray && needsDirectEq(t1, t2))

How about this one?

if (!(i1 && i2 && (i1.mod == i2.mod || (!i1.parent.isImport() && 
!i2.parent.isImport() && i1.ident.equals(i2.ident)))))

The compiler will easily output 5+ error messages pointing to the 
wrong place when a closing paren is missing ("missing { ... } for 
function literal", "unrecognized declaration"). So I'm not 
convinced that error message quality is at stake here.

To avoid ambiguity of where the expression ends and body starts, 
it can be enforced that either () around the expression or {} 
around the statement must be present.
Jun 24 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, June 24, 2018 22:03:13 Dennis via Digitalmars-d wrote:

 On Saturday, 23 June 2018 at 02:14:04 UTC, Jonathan M Davis wrote:

 In general, C code is supposed to be either valid D code or not
 compile in order to making porting it easier. Getting rid of
 the parens wouldn't break that, but it _would_ make it so that
 it's more work to port C code to D when doing so is supposed to
 be straightforward in most cases.

 And of course, the counter question to why the parens shouldn't
 be removed would be the question of why they should be. What
 about having parens makes the code worse? Many of us would
 consider the code easier to read with parens.


 I don't see why allowing one to omit the parens makes porting C
 code harder.


It makes it harder if the language does not have parens on if statements,
while loops, etc., because then you have to remove them from all of the code
that you're porting. Having them be optional shouldn't make porting harder.
The OP's post said nothing about making them optional, just complained that
they were in the language, so I posted based on the assumption that they
were arguing for their removal from the language. However, optional parens
would make it more confusing when reading code (since then you have to
figure out whether parens go with the if or the expression in the
conditional), and it's the sort of thing that's just going to start style
wars.

Also, usually, I hear about how folks _like_ D's syntax and find it easy to
learn, whereas many complain about the syntax in languages such as Rust
(it's my understanding that folks tend to like Rust in spite of its syntax,
not because of it). So, it seems a bit odd to try and emulate them.

Regardless, personally, I don't want to have to deal with reading code that
omits parens on if statements and loops. It just makes the language less
consistent and makes it more work to read code (as well as opening the door
for yet more arguments about the style guidelines on projects). Obviously,
others can disagree, but I'd vote strongly against any attempt to change D
in this regard.

- Jonathan M Davis
Jun 24 2018
parent aliak <something something.com> writes:
On Sunday, 24 June 2018 at 22:25:43 UTC, Jonathan M Davis wrote:

 On Sunday, June 24, 2018 22:03:13 Dennis via Digitalmars-d 
 wrote:

 On Saturday, 23 June 2018 at 02:14:04 UTC, Jonathan M Davis 
 wrote:

 [...]


 I don't see why allowing one to omit the parens makes porting 
 C code harder.


 It makes it harder if the language does not have parens on if 
 statements, while loops, etc., because then you have to remove 
 them from all of the code that you're porting. Having them be 
 optional shouldn't make porting harder. The OP's post said 
 nothing about making them optional, just complained that they 
 were in the language, so I posted based on the assumption that 
 they were arguing for their removal from the language. However, 
 optional parens would make it more confusing when reading code 
 (since then you have to figure out whether parens go with the 
 if or the expression in the conditional), and it's the sort of 
 thing that's just going to start style wars.

 Also, usually, I hear about how folks _like_ D's syntax and 
 find it easy to learn, whereas many complain about the syntax 
 in languages such as Rust (it's my understanding that folks 
 tend to like Rust in spite of its syntax, not because of it). 
 So, it seems a bit odd to try and emulate them.

 Regardless, personally, I don't want to have to deal with 
 reading code that omits parens on if statements and loops. It 
 just makes the language less consistent and makes it more work 
 to read code (as well as opening the door for yet more 
 arguments about the style guidelines on projects). Obviously, 
 others can disagree, but I'd vote strongly against any attempt 
 to change D in this regard.

 - Jonathan M Davis


FWIW, a lot of people I try and get in to D complain about the 
template syntax. "What're all those exclamation marks 
everywhere??!!" - Every. Single. Time. And as soon as you see 
__traits code anywhere you can say good bye to any aesthetic 
pleasures. There're things in every language you just have to get 
used to looking at and at some point things just start to look 
nice. After a while I didn't even think objective-c bracket hell 
was too bad :p

Cheers,
- Ali
Jun 24 2018
prev sibling parent reply Timoses <timosesu gmail.com> writes:
On Sunday, 24 June 2018 at 22:03:13 UTC, Dennis wrote:

 if (!("key" in dict)) {...}


if ("key" !in dict) {...}

At least that one has a shorter form. The others may be rewritten 
to not have a leading "!" as well, e.g.


 if (!(t1.ty == Tarray && t2.ty == Tarray && needsDirectEq(t1, 
 t2))


if (t1.ty != Tarray || t2.ty != Tarray || ...)

Plus, for counting brackets a text editor that highlights 
enclosing opposite brackets really helps.
Jun 24 2018
parent reply Nick Treleaven <nick geany.org> writes:
On Sunday, 24 June 2018 at 23:40:56 UTC, Timoses wrote:

 The others may be rewritten to not have a leading "!" as well, 
 e.g.


 if (!(t1.ty == Tarray && t2.ty == Tarray && needsDirectEq(t1, 
 t2))


 if (t1.ty != Tarray || t2.ty != Tarray || ...)


Yes, but you might make a mistake, and sometimes it makes more 
intuitive sense to read it in a non-minimized form. This type of 
change is also much harder to review. Consider why the change got 
checked into dmd, without it being minimized at the time or in a 
later pull.
Jul 01 2018
parent reply Seb <seb wilzba.ch> writes:
On Sunday, 1 July 2018 at 12:02:03 UTC, Nick Treleaven wrote:

 On Sunday, 24 June 2018 at 23:40:56 UTC, Timoses wrote:

 The others may be rewritten to not have a leading "!" as well, 
 e.g.


 if (!(t1.ty == Tarray && t2.ty == Tarray && needsDirectEq(t1, 
 t2))


 if (t1.ty != Tarray || t2.ty != Tarray || ...)


 Yes, but you might make a mistake, and sometimes it makes more 
 intuitive sense to read it in a non-minimized form. This type 
 of change is also much harder to review. Consider why the 
 change got checked into dmd, without it being minimized at the 
 time or in a later pull.




and it wouldn't be hard for D to support it too: 
https://github.com/dlang/dmd/pull/8440
It just requires someone to step up and write the DIP.
Jul 02 2018
parent Daniel N <no public.email> writes:
On Monday, 2 July 2018 at 20:28:06 UTC, Seb wrote:

 On Sunday, 1 July 2018 at 12:02:03 UTC, Nick Treleaven wrote:

 On Sunday, 24 June 2018 at 23:40:56 UTC, Timoses wrote:

 The others may be rewritten to not have a leading "!" as 
 well, e.g.


 if (!(t1.ty == Tarray && t2.ty == Tarray && 
 needsDirectEq(t1, t2))


 if (t1.ty != Tarray || t2.ty != Tarray || ...)


 Yes, but you might make a mistake, and sometimes it makes more 
 intuitive sense to read it in a non-minimized form. This type 
 of change is also much harder to review. Consider why the 
 change got checked into dmd, without it being minimized at the 
 time or in a later pull.




 and it wouldn't be hard for D to support it too: 
 https://github.com/dlang/dmd/pull/8440
 It just requires someone to step up and write the DIP.


Since ! is used to pass template params... I'd rather use it for 
parameterized keywords in the same way, for instance:

if!likely(...)
if!unlikely(...)

It would standardize the existing practice of "__builtin_expect".
Also it you really wanted, you could add something like:

if!not(...)
Jul 04 2018
prev sibling next sibling parent reply user1234 <user1234 12.nl> writes:
On Saturday, 23 June 2018 at 01:27:30 UTC, aedt wrote:

 for line in stdin.lines() {}

 if condition {}

 while condition {}

 for init; condition; op {}


 What's the rationale of keeping the requirement that the 
 condition of if/for/while must be wrapped with a parenthesis 
 (other than keeping parser simple)? Modern languages have 
 already dropped this requirement (i.e. Rust, Nim) and I don't 
 see any reason not to do so.


There is this case that requires parens:

     if a && b c;

Is there a missing && or not ? It seems obvious for a human but 
compiler parsers are "apparatchiks", i.e rules are rules. That 
being said this would work by allowing parens for disambiguation.
Jun 22 2018
next sibling parent reply aedt <adnansignsup gmail.com> writes:
On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:

 On Saturday, 23 June 2018 at 01:27:30 UTC, aedt wrote:

 for line in stdin.lines() {}

 if condition {}

 while condition {}

 for init; condition; op {}


 What's the rationale of keeping the requirement that the 
 condition of if/for/while must be wrapped with a parenthesis 
 (other than keeping parser simple)? Modern languages have 
 already dropped this requirement (i.e. Rust, Nim) and I don't 
 see any reason not to do so.


 There is this case that requires parens:

     if a && b c;

 Is there a missing && or not ? It seems obvious for a human but 
 compiler parsers are "apparatchiks", i.e rules are rules. That 
 being said this would work by allowing parens for 
 disambiguation.


Same thing as the following"
return a && b;

I'm not saying to drop parens completely, I'm saying why is it 
not optional. D seems to have no problem with x.to!string or 
std.lines
Jun 22 2018
parent reply user1234 <user1234 12.nl> writes:
On Saturday, 23 June 2018 at 05:09:13 UTC, aedt wrote:

 On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:

 On Saturday, 23 June 2018 at 01:27:30 UTC, aedt wrote:

 for line in stdin.lines() {}

 if condition {}

 while condition {}

 for init; condition; op {}


 What's the rationale of keeping the requirement that the 
 condition of if/for/while must be wrapped with a parenthesis 
 (other than keeping parser simple)? Modern languages have 
 already dropped this requirement (i.e. Rust, Nim) and I don't 
 see any reason not to do so.


 There is this case that requires parens:

     if a && b c;

 Is there a missing && or not ? It seems obvious for a human 
 but compiler parsers are "apparatchiks", i.e rules are rules. 
 That being said this would work by allowing parens for 
 disambiguation.


 Same thing as the following"
 return a && b;

 I'm not saying to drop parens completely, I'm saying why is it 
 not optional. D seems to have no problem with x.to!string or 
 std.lines


I agree that this would be in adequation with certain stuff of 
the D syntax, such as parens-less single template parameter. 
Someone has to make a DIP for this otherwise we're good for one 
of this sterile NG discussion leading to nothing, i.e 
intellectual mast... well guess the word.
Jun 22 2018
parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 23 June 2018 at 06:18:53 UTC, user1234 wrote:

 On Saturday, 23 June 2018 at 05:09:13 UTC, aedt wrote:

 On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:

 On Saturday, 23 June 2018 at 01:27:30 UTC, aedt wrote:

 for line in stdin.lines() {}

 if condition {}

 while condition {}

 for init; condition; op {}


 What's the rationale of keeping the requirement that the 
 condition of if/for/while must be wrapped with a parenthesis 
 (other than keeping parser simple)? Modern languages have 
 already dropped this requirement (i.e. Rust, Nim) and I 
 don't see any reason not to do so.


 There is this case that requires parens:

     if a && b c;

 Is there a missing && or not ? It seems obvious for a human 
 but compiler parsers are "apparatchiks", i.e rules are rules. 
 That being said this would work by allowing parens for 
 disambiguation.


 Same thing as the following"
 return a && b;

 I'm not saying to drop parens completely, I'm saying why is it 
 not optional. D seems to have no problem with x.to!string or 
 std.lines


 I agree that this would be in adequation with certain stuff of 
 the D syntax, such as parens-less single template parameter. 
 Someone has to make a DIP for this


Maybe but this is a simple parser thing. For example after 
reading the discussion here i have tested the idea in my toy 
programming language 
(https://github.com/BBasile/styx/commit/83c96d8a789aa82f9bed2
4ab342ffc4aed4fd88) and i believe that for D this would be as simple ( < 20
SLOC, w/o the tests).


 otherwise we're good for one of this sterile NG discussion 
 leading to nothing, i.e intellectual mast... well guess the 
 word.


I'm tempted to try this in DMDFE. Change is simple enough so that 
if it get rejected no much time is lost.
Jun 22 2018
parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 23 June 2018 at 06:24:29 UTC, Basile B. wrote:

 On Saturday, 23 June 2018 at 06:18:53 UTC, user1234 wrote:

 On Saturday, 23 June 2018 at 05:09:13 UTC, aedt wrote:

 On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:

 On Saturday, 23 June 2018 at 01:27:30 UTC, aedt wrote:

 for line in stdin.lines() {}

 if condition {}

 while condition {}

 for init; condition; op {}


 What's the rationale of keeping the requirement that the 
 condition of if/for/while must be wrapped with a 
 parenthesis (other than keeping parser simple)? Modern 
 languages have already dropped this requirement (i.e. Rust, 
 Nim) and I don't see any reason not to do so.


 There is this case that requires parens:

     if a && b c;

 Is there a missing && or not ? It seems obvious for a human 
 but compiler parsers are "apparatchiks", i.e rules are 
 rules. That being said this would work by allowing parens 
 for disambiguation.


 Same thing as the following"
 return a && b;

 I'm not saying to drop parens completely, I'm saying why is 
 it not optional. D seems to have no problem with x.to!string 
 or std.lines


 I agree that this would be in adequation with certain stuff of 
 the D syntax, such as parens-less single template parameter. 
 Someone has to make a DIP for this


 Maybe but this is a simple parser thing. For example after 
 reading the discussion here i have tested the idea in my toy 
 programming language 
 (https://github.com/BBasile/styx/commit/83c96d8a789aa82f9bed2
4ab342ffc4aed4fd88) and i believe that for D this would be as simple ( < 20
SLOC, w/o the tests).


 otherwise we're good for one of this sterile NG discussion 
 leading to nothing, i.e intellectual mast... well guess the 
 word.


 I'm tempted to try this in DMDFE. Change is simple enough so 
 that if it get rejected no much time is lost.


FYI this works fine, as expected it's just some small parser 
changes.
I didn't touch to for and foreach for now. I think that 
SwitchStatement is a candidate too.

https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d

However note that there's a nice thing with the phobos style that 
won't be that nice anymore:

if (condition)
     action();
----^

if condition)
     action();
---^
----^

It's not nicely aligned anymore !
Jun 24 2018
next sibling parent reply aliak <something something.com> writes:
On Sunday, 24 June 2018 at 11:27:12 UTC, Basile B. wrote:

 On Saturday, 23 June 2018 at 06:24:29 UTC, Basile B. wrote:

 On Saturday, 23 June 2018 at 06:18:53 UTC, user1234 wrote:

 On Saturday, 23 June 2018 at 05:09:13 UTC, aedt wrote:

 On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:

 [...]


 Same thing as the following"
 return a && b;

 I'm not saying to drop parens completely, I'm saying why is 
 it not optional. D seems to have no problem with x.to!string 
 or std.lines


 I agree that this would be in adequation with certain stuff 
 of the D syntax, such as parens-less single template 
 parameter. Someone has to make a DIP for this


 Maybe but this is a simple parser thing. For example after 
 reading the discussion here i have tested the idea in my toy 
 programming language 
 (https://github.com/BBasile/styx/commit/83c96d8a789aa82f9bed2
4ab342ffc4aed4fd88) and i believe that for D this would be as simple ( < 20
SLOC, w/o the tests).


 otherwise we're good for one of this sterile NG discussion 
 leading to nothing, i.e intellectual mast... well guess the 
 word.


 I'm tempted to try this in DMDFE. Change is simple enough so 
 that if it get rejected no much time is lost.


 FYI this works fine, as expected it's just some small parser 
 changes.
 I didn't touch to for and foreach for now. I think that 
 SwitchStatement is a candidate too.

 https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d

 However note that there's a nice thing with the phobos style 
 that won't be that nice anymore:

 if (condition)
     action();
 ----^

 if condition)
     action();
 ---^
 ----^

 It's not nicely aligned anymore !


Wow nice, that was quick, would it be much more to make it so 
that braces are required with if statements that do not start 
with an open paren? Then you avoid the ambiguity I guess ... It'd 
be awesome if D allowed it optionally though.

Not that I have a strong opinion here but I have found that being 
able to omit the parens makes the code look A Lot cleaner. And 
forcing braces I've also come to apprecaite with a bonus of 
avoiding this bug:

if (a)
   b;
   c;

Though forcing braces in D may make phobos quite sparse since it 
uses allman braces so we'll get 4 line if statements everywhere :p

Cheers,
- Ali
Jun 24 2018
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 24 June 2018 at 23:08:15 UTC, aliak wrote:

 On Sunday, 24 June 2018 at 11:27:12 UTC, Basile B. wrote:

 On Saturday, 23 June 2018 at 06:24:29 UTC, Basile B. wrote:

 On Saturday, 23 June 2018 at 06:18:53 UTC, user1234 wrote:

 On Saturday, 23 June 2018 at 05:09:13 UTC, aedt wrote:

 On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:

 [...]


 Same thing as the following"
 return a && b;

 I'm not saying to drop parens completely, I'm saying why is 
 it not optional. D seems to have no problem with 
 x.to!string or std.lines


 I agree that this would be in adequation with certain stuff 
 of the D syntax, such as parens-less single template 
 parameter. Someone has to make a DIP for this


 Maybe but this is a simple parser thing. For example after 
 reading the discussion here i have tested the idea in my toy 
 programming language 
 (https://github.com/BBasile/styx/commit/83c96d8a789aa82f9bed2
4ab342ffc4aed4fd88) and i believe that for D this would be as simple ( < 20
SLOC, w/o the tests).


 otherwise we're good for one of this sterile NG discussion 
 leading to nothing, i.e intellectual mast... well guess the 
 word.


 I'm tempted to try this in DMDFE. Change is simple enough so 
 that if it get rejected no much time is lost.


 FYI this works fine, as expected it's just some small parser 
 changes.
 I didn't touch to for and foreach for now. I think that 
 SwitchStatement is a candidate too.

 https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d

 However note that there's a nice thing with the phobos style 
 that won't be that nice anymore:

 if (condition)
     action();
 ----^

 if condition)
     action();
 ---^
 ----^

 It's not nicely aligned anymore !


 Wow nice, that was quick, would it be much more to make it so 
 that braces are required with if statements that do not start 
 with an open paren?


It's in the commit.
Jun 25 2018
parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 25 June 2018 at 10:36:46 UTC, Basile B. wrote:

 On Sunday, 24 June 2018 at 23:08:15 UTC, aliak wrote:

 On Sunday, 24 June 2018 at 11:27:12 UTC, Basile B. wrote:

 On Saturday, 23 June 2018 at 06:24:29 UTC, Basile B. wrote:

 On Saturday, 23 June 2018 at 06:18:53 UTC, user1234 wrote:

 On Saturday, 23 June 2018 at 05:09:13 UTC, aedt wrote:

 On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:

 [...]


 Same thing as the following"
 return a && b;

 I'm not saying to drop parens completely, I'm saying why 
 is it not optional. D seems to have no problem with 
 x.to!string or std.lines


 I agree that this would be in adequation with certain stuff 
 of the D syntax, such as parens-less single template 
 parameter. Someone has to make a DIP for this


 Maybe but this is a simple parser thing. For example after 
 reading the discussion here i have tested the idea in my toy 
 programming language 
 (https://github.com/BBasile/styx/commit/83c96d8a789aa82f9bed2
4ab342ffc4aed4fd88) and i believe that for D this would be as simple ( < 20
SLOC, w/o the tests).


 otherwise we're good for one of this sterile NG discussion 
 leading to nothing, i.e intellectual mast... well guess the 
 word.


 I'm tempted to try this in DMDFE. Change is simple enough so 
 that if it get rejected no much time is lost.


 FYI this works fine, as expected it's just some small parser 
 changes.
 I didn't touch to for and foreach for now. I think that 
 SwitchStatement is a candidate too.

 https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d

 However note that there's a nice thing with the phobos style 
 that won't be that nice anymore:

 if (condition)
     action();
 ----^

 if condition)
     action();
 ---^
 ----^

 It's not nicely aligned anymore !


 Wow nice, that was quick, would it be much more to make it so 
 that braces are required with if statements that do not start 
 with an open paren?


 It's in the commit.


https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d#diff-cd066d37445cac534313c0137c2d4bbeR5599
Jun 25 2018
parent reply aliak <something something.com> writes:
On Monday, 25 June 2018 at 10:38:49 UTC, Basile B. wrote:

 On Monday, 25 June 2018 at 10:36:46 UTC, Basile B. wrote:

 On Sunday, 24 June 2018 at 23:08:15 UTC, aliak wrote:

 Wow nice, that was quick, would it be much more to make it so 
 that braces are required with if statements that do not start 
 with an open paren?


 It's in the commit.


 https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d#diff-cd066d37445cac534313c0137c2d4bbeR5599


Indeed! Totally missed that! PR Itttt!!! :D
Jun 25 2018
parent Basile B. <b2.temp gmx.com> writes:
On Monday, 25 June 2018 at 12:19:15 UTC, aliak wrote:

 On Monday, 25 June 2018 at 10:38:49 UTC, Basile B. wrote:

 On Monday, 25 June 2018 at 10:36:46 UTC, Basile B. wrote:

 On Sunday, 24 June 2018 at 23:08:15 UTC, aliak wrote:

 Wow nice, that was quick, would it be much more to make it 
 so that braces are required with if statements that do not 
 start with an open paren?


 It's in the commit.


 https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d#diff-cd066d37445cac534313c0137c2d4bbeR5599


 Indeed! Totally missed that! PR Itttt!!! :D


What i would make if i was a new comer. Language changes must be 
formally specified with a DIP. I don't especially want to write 
it but if one of the of the paren-less statements 'partisan' 
wants to then you can count on me if at a time an  implementation 
is required (even as demo in a first time).
Jul 02 2018
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 24.06.2018 13:27, Basile B. wrote:

 
 FYI this works fine, as expected it's just some small parser changes.
 I didn't touch to for and foreach for now. I think that SwitchStatement 
 is a candidate too.
 
 https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d


if (a+b)*c == d { ... }
Jul 04 2018
next sibling parent Nick Treleaven <nick geany.org> writes:
On Wednesday, 4 July 2018 at 14:37:49 UTC, Timon Gehr wrote:

 if (a+b)*c == d { ... }


Error: found `{` when expecting `;` following statement

Adding the semi-colon, `*c == d;` would likely cause:
Error: `*c == d` has no effect

Also multiplying (a+b) by a pointer is illegal, and c is probably 
a pointer if it can be dereferenced. In theory a UDT could define 
opUnary!"*" and opBinary!"*", is that likely?
Jul 05 2018
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 4 July 2018 at 14:37:49 UTC, Timon Gehr wrote:

 On 24.06.2018 13:27, Basile B. wrote:

 
 FYI this works fine, as expected it's just some small parser 
 changes.
 I didn't touch to for and foreach for now. I think that 
 SwitchStatement is a candidate too.
 
 https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d


 if (a+b)*c == d { ... }


right, maybe logic to apply here is : if the expression parses 
and no closing paren is found then it's not nececessary.
Jul 05 2018
parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 5 July 2018 at 09:45:44 UTC, Basile B. wrote:

 On Wednesday, 4 July 2018 at 14:37:49 UTC, Timon Gehr wrote:

 On 24.06.2018 13:27, Basile B. wrote:

 
 FYI this works fine, as expected it's just some small parser 
 changes.
 I didn't touch to for and foreach for now. I think that 
 SwitchStatement is a candidate too.
 
 https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d


 if (a+b)*c == d { ... }


 right, maybe logic to apply here is : if the expression parses 
 and no closing paren is found then it's not nececessary.


Actually with the change the example doesn't parse and without it 
didn't either.
The program meaning is not altered so it's fine.
Jul 05 2018
prev sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:

 There is this case that requires parens:

     if a && b c;

 Is there a missing && or not ? It seems obvious for a human but 
 compiler parsers are "apparatchiks", i.e rules are rules. That 
 being said this would work by allowing parens for 
 disambiguation.


Why not just require either parens or brackets?
Jul 04 2018
prev sibling next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 06/22/2018 09:27 PM, aedt wrote:

 for line in stdin.lines() {}
 
 if condition {}
 
 while condition {}
 
 for init; condition; op {}
 
 
 What's the rationale of keeping the requirement that the condition of 
 if/for/while must be wrapped with a parenthesis (other than keeping 
 parser simple)? Modern languages have already dropped this requirement 
 (i.e. Rust, Nim) and I don't see any reason not to do so.
 


Mainly because of D's C-family lineage. D was designed to use syntax 
that would be familiar to programmers of the other popular C-derived 

in a C-ish (more or less) language was largely popularized by Go, but at 
the time, Go didn't exist yet.

Whatever the reasons, I'm personally glad it worked out this way: I find 
it very difficult to visually parse loops and conditionals that omit the 
parens. Without them, there just isn't enough visual "landmarks" for my 
brain's visual center to lock-on and pattern-recognize a standard loop 
or conditional.
Jun 22 2018
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2018-06-23 03:27, aedt wrote:

 for line in stdin.lines() {}

 if condition {}

 while condition {}

 for init; condition; op {}


 What's the rationale of keeping the requirement that the condition of
 if/for/while must be wrapped with a parenthesis (other than keeping
 parser simple)? Modern languages have already dropped this requirement
 (i.e. Rust, Nim) and I don't see any reason not to do so.


For the parentheses to be optional I think the curly brace need to be 
mandatory, or perhaps force a newline after the condition. I don't see 
how this would be any better. You're trading one set of required 
punctuational characters for another set. This would also take D one 
step further away from the C family of languages.

-- 
/Jacob Carlborg
Jun 23 2018
parent reply user1234 <user1234 12.nl> writes:
On Saturday, 23 June 2018 at 08:07:23 UTC, Jacob Carlborg wrote:

 On 2018-06-23 03:27, aedt wrote:

 for line in stdin.lines() {}

 if condition {}

 while condition {}

 for init; condition; op {}


 What's the rationale of keeping the requirement that the 
 condition of
 if/for/while must be wrapped with a parenthesis (other than 
 keeping
 parser simple)? Modern languages have already dropped this 
 requirement
 (i.e. Rust, Nim) and I don't see any reason not to do so.


 For the parentheses to be optional I think the curly brace need 
 to be mandatory, or perhaps force a newline after the 
 condition. I don't see how this would be any better. You're 
 trading one set of required punctuational characters for 
 another set. This would also take D one step further away from 
 the C family of languages.


I wouldn't like the new line constraint. Forcing Curly braces is 
nice, logic and natural imo.
Jun 23 2018
next sibling parent user1234 <user1234 12.nl> writes:
On Saturday, 23 June 2018 at 09:19:45 UTC, user1234 wrote:

 On Saturday, 23 June 2018 at 08:07:23 UTC, Jacob Carlborg wrote:

 On 2018-06-23 03:27, aedt wrote:

 for line in stdin.lines() {}

 if condition {}

 while condition {}

 for init; condition; op {}


 What's the rationale of keeping the requirement that the 
 condition of
 if/for/while must be wrapped with a parenthesis (other than 
 keeping
 parser simple)? Modern languages have already dropped this 
 requirement
 (i.e. Rust, Nim) and I don't see any reason not to do so.


 For the parentheses to be optional I think the curly brace 
 need to be mandatory, or perhaps force a newline after the 
 condition. I don't see how this would be any better. You're 
 trading one set of required punctuational characters for 
 another set. This would also take D one step further away from 
 the C family of languages.


 I wouldn't like the new line constraint. Forcing Curly braces 
 is nice, logic and natural imo.


Just like spaces line endings are not a thing in D anyway.
Jun 23 2018
prev sibling parent crimaniak <crimaniak gmail.com> writes:
On Saturday, 23 June 2018 at 09:19:45 UTC, user1234 wrote:


 ...Forcing Curly braces is nice, logic and natural imo.


The operator brackets themselves are a separate construction. In 
addition, the more structured the code, the less they are needed. 
In my code, most of the loops and branches contain one operator, 
so forcing the сurly braces would simply add a large amount of 
syntactic noise.
Jun 23 2018
prev sibling parent reply =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
aedt <adnansignsup gmail.com> wrote:

 Modern languages have already 
 dropped this requirement (i.e. Rust, Nim) and I don't see any 
 reason not to do so.


AFAIK the if and else branches in Rust always have to be enclosed in curly
braces because of this.
I don't remember the exact ambiguity though.
Jun 23 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-06-23 14:34, Tobias Müller wrote:


 AFAIK the if and else branches in Rust always have to be enclosed in curly
 braces because of this.
 I don't remember the exact ambiguity though.


There's an ambiguity between the condition and the body. There needs to 
be some kind of symbol to separate the two. In D, that's the closing 
parenthesis (technically the opening parenthesis is not necessary but 
unbalanced parentheses look weird for humans). In Rust it's the opening 
curly brace.

-- 
/Jacob Carlborg
Jun 24 2018
parent Basile B. <b2.temp gmx.com> writes:
On Sunday, 24 June 2018 at 08:30:28 UTC, Jacob Carlborg wrote:

 On 2018-06-23 14:34, Tobias Müller wrote:


 AFAIK the if and else branches in Rust always have to be 
 enclosed in curly
 braces because of this.
 I don't remember the exact ambiguity though.


 There's an ambiguity between the condition and the body. There 
 needs to be some kind of symbol to separate the two. In D, 
 that's the closing parenthesis (technically the opening 
 parenthesis is not necessary but unbalanced parentheses look 
 weird for humans). In Rust it's the opening curly brace.


Yeah, as pointed out at the beginning

https://forum.dlang.org/post/gwxrvrzgycnxwzzszkbr forum.dlang.org

Despite of the ugliness of the construct the main issue is that a 
binary or a relational operator could be missing in this case.
Jun 24 2018