== Quote from Steve Horne (stephenwantshornenospam100@aol.com)'s article
> Trying to get the best of both worlds risks bringing in a whole bunch
> of new problems...
>   if a == b        //  fine
>   {
>     ...
>   }
>   if a == b return c;  //  errm - well...
>   if a == b *c++;       //  aaarrrggghhh!!!

Forgive me for my ignorance (I've never programmed in C), but what isn't clear about those statements?

>   if a == b return c;  //  errm - well...
This one seems perfectly clear to me.  Maybe I'm reading it wrong.  To me, it says; if a equals b then return and pass back c.  Is that not correct?

>   if a == b *c++;       //  aaarrrggghhh!!!
Likewise, this one says; if a is equal to b, add one to... pointer c?  Although I'm not positive of the meaning of the *, everything else seems crystal clear. Again, am I not reading it correctly?  Other than my uncertainty over the *, I don't see any ambiguity in those statements...  or any reason why C(++) programmers don't like them.  But since I'm not a C(++) programmer, perhaps there's something unclear about those statements that I'm just not recognizing.

As for the a = b + c * d  statement...  The only thing I need to know is, Does the
language use the standard arithmetic precedence?  If it does, then the statement
means a = b + (c * d)  otherwise I'd just use standard left to right evaluation...
 i.e. a = (b + c) * d.  Other than a quick check of the language reference (which
I SHOULD only need to do once  ) to see how it handles arithmetic precedence (or
not) where's the ambiguity?

By the way, I'm not suggesting that D should be modified to use this style of syntax.  I understand completely that it is INTENTIONALLY "C like" to make it easy(er) for C(++) programmers to adapt to.  So please don't take my comments as arguing for any change.  I'm just trying to understand WHY C(++) programmers find statements that seem perfectly clear  to me, confusing.

On Sat, 23 Dec 2006 12:44:16 +0200, Wolven <rma@wolven.net> wrote:
[snip]
>>   if a == b return c;  //  errm - well...
> This one seems perfectly clear to me.  Maybe I'm reading it wrong.  To me, it
> says; if a equals b then return and pass back c.  Is that not correct?

It's correct.

>>   if a == b *c++;       //  aaarrrggghhh!!!
> Likewise, this one says; if a is equal to b, add one to... pointer c?  Although
> I'm not positive of the meaning of the *, everything else seems crystal clear.
> Again, am I not reading it correctly?  Other than my uncertainty over the *, I
> don't see any ambiguity in those statements...  or any reason why C(++)
> programmers don't like them.  But since I'm not a C(++) programmer, perhaps
> there's something unclear about those statements that I'm just not recognizing.

The problem is how * is treaded: is it unary or binary?

I read the statement as:

if(a == b)
    *c++;

, but using arithetic precedence it will be:

if(a == b * c++);

Of course, in D you have to use {} to create an empty statement, so the compiler should thread it as "if(a == b) *c++;" too. (But that would add complexity to the compiler.)

Anyway, I think that *optional* parenthesis can make the code a bit harder to read. For example:

if(a && b) || c
    a = 1;

At first glance it could seem that "(a && b)" is the condition of the if-statement. Of course one can write unreadable code with any given syntax.

You do not have an ambuity because you will allways write curly brackets:

if a == b { return 1; } else { return 2 }

This can solve the problem with forgetting the curly brackets:

if(a == b)
  writefln("a");
  return 1;

if a == b
{ // You must write this
  writefn("a");
  return 1;
} // You must write this

The good point is that you can write parenthesis nevermind that you can write without them. If you want to write them you are wellcome:

if(a == b) { return 1; } else { return 2; }

If you don't want you can write:
if a == b { return 1; } else { return 2; }

If you allways write curly brackets you do not have a problem with understanding the code.

I disagree.

This works well for scripting languages like Ruby, but then again, this is D, which has a C style syntax. And C style syntax just can't work without paranthesis.

Alex

NN wrote:
> What about removing unuseful parenthesis in 'if', 'for', 'while' ?
> E.g. instead of:
> if(a == b)
> {
>   while(c)
>   {
>      ...
>   }
> }
> We can write:
> if a == b
> {
>   while c
>   {
>      ...
>   }
> }
> 
> If someone writes parenthesis the code will compile too.
> So this is almost backwards compatible feature.
> 
> What about 'if' with one expression ?
> Almost everyone writes curly brackets for more than one expression, so there they will be always written, and there will be no bugs.

This works in some good languages, why this won't work in D ?

The good news that you still can write them ;)
If you want to write them you can, if you don't want you can too :)

NN wrote:
> This works in some good languages, why this won't work in D ?
> 
> The good news that you still can write them ;)
> If you want to write them you can, if you don't want you can too :)

IMHO it offers less than the effort needed to specify (so it doesn't leak..) and implement it, so I don't think it's applicable.

>NN wrote:
>> This works in some good languages, why this won't work in D ?
>>
>> The good news that you still can write them ;)
>> If you want to write them you can, if you don't want you can too :)

>IMHO it offers less than the effort needed to specify (so it doesn't leak..) and implement it, so I don't think it's applicable.

It is not too much hard to implement :)
Even if it takes a week to implement, it is not too much, this will not affect the language development too much.

> It is not too much hard to implement :)
> Even if it takes a week to implement, it is not too much, this will not affect the language development too much.

There's still the leaking part.. :P

Steve Horne wrote:
> On Fri, 22 Dec 2006 15:49:22 -0600, Chris Nicholson-Sauls
> <ibisbasenji@gmail.com> wrote:
> 
>> Personally, I almost always write in the braces.  It just makes things so much simpler if I later need to go back and expand that statement body, or want to add debugging/temporary output or checks of some kind.
> 
> To me, redundant braces are extra clutter, making it harder to read
> the code. I used to always use them in the past, back when I was more
> Pascal-family-influenced than now, but over time I just got irritated
> with them. And leaving them out has never caused a problem.
> 
> The basic rule is that if I only drop the braces if the whole block
> statement is on a single line - a useful way to tidy up code, and
> something that can be done similarly in Pascal, but not really
> Modula-2 or Ada due to begin/end issues.
> 
> Of course the amount of clutter we're talking about from braces is a
> trivial issue. Just like adding in the braces when they are needed is
> a trivial issue.
> 
> Not that anything above should influence anyone one way or the other.
> The point is that both views are equally valid. There never will be a
> definitive right way.
> 

I can understand.  One of the few occasions where I leave them out is with things like:
# if (x) doThis();
# else   doAnother();

Particularly if debugging output or such doesn't make any sense in there.

And also like:
# foreach (i, inout x; arr) x = foo(i);

If any sensible debug output would typically come after the for*each anyway.

-- Chris Nicholson-Sauls