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.

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.

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

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.

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/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.

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 !

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.

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

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/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.
>
> 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

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

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.