Jump to page: 1 24  
Page
Thread overview
Parenthesis around if/for/while condition is not necessary
Jun 23, 2018
aedt
Jun 23, 2018
Jonathan M Davis
Jun 24, 2018
Dennis
Jun 24, 2018
Jonathan M Davis
Jun 24, 2018
aliak
Jun 24, 2018
Timoses
Jul 01, 2018
Nick Treleaven
Jul 02, 2018
Seb
Jul 04, 2018
Daniel N
Jun 23, 2018
user1234
Jun 23, 2018
aedt
Jun 23, 2018
user1234
Jun 23, 2018
Basile B.
Jun 24, 2018
Basile B.
Jun 24, 2018
aliak
Jun 25, 2018
Basile B.
Jun 25, 2018
Basile B.
Jun 25, 2018
aliak
Jul 02, 2018
Basile B.
Jul 04, 2018
Timon Gehr
Jul 05, 2018
Nick Treleaven
Jul 05, 2018
Basile B.
Jul 05, 2018
Basile B.
Jul 04, 2018
FeepingCreature
Jun 23, 2018
Jacob Carlborg
Jun 23, 2018
user1234
Jun 23, 2018
user1234
Jun 23, 2018
crimaniak
Jun 23, 2018
Tobias Müller
Jun 24, 2018
Jacob Carlborg
Jun 24, 2018
Basile B.
June 23, 2018
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.


June 22, 2018
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

June 23, 2018
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.
June 23, 2018
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
June 23, 2018
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 languages of the time (mainly: C, C++, Java, C#). Making parens optional 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.


June 23, 2018
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.
June 23, 2018
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/83c96d8a789aa82f9bed254ab342ffc4aed4fd88) 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.
June 23, 2018
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
June 23, 2018
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.
June 23, 2018
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.
« First   ‹ Prev
1 2 3 4