LLVM talks 1: Clang for Chromium

[Adam D. Ruppe]

On Friday, 16 December 2011 at 12:23:25 UTC, bearophile wrote:
> This code doesn't compile with DMD:
>   if (x = y) {}
> But this gives no errors:
>   if (x |= y) {}

> Do you know why DMD forbids assignments as conditions, but it 
> accepts compound assignments there? It looks like a 
> incongruence that's better to remove.


They aren't similar at all. Sometimes, if I'm coming from
a couple days writing Visual Basic, I'll hit the wrong
equal sign.

If a = 10 Then ' correct VB
  blah
End If

if(a = 10)  // wrong C/C++/D/etc
  blah


That's a mistake that's pretty easy to make, especially if
you switch languages.


But I've never myself, nor seen anybody else, actually
write += or |= when they meant == or !=. The keys aren't
even close (on en-US anyway) so it's not a likely typo, and
the concepts are nothing alike so a brain or language mixup
isn't likely to cause it.

If you write "if(a += 10)", you almost certainly meant to say
"if(a += 10)".

That's not the case with (a = 10) vs (a == 10).


> a.cc:2:16: warning: operator '?:' has lower precedence than 
> '+'; '+' will be evaluated first
> return x + b ? y : 0;
>
> They say:
>
>> It's a bug every time!

They're wrong. I've done something similar for plurals
where you only care about if it is equal to one or not,
and that was intentional.

That said, if I have to put any effort at all into thinking
about a line of code, I usually rewrite it.

(That's why in some of my code you'll see stuff like

return a != 0 ? true : false;

even though I could have just said

return a != 0;


Sometimes my brain gets mixed up with the double
negative so I just write it out anyway.)



In the case of the ternary, sometimes the precidence
is easy to forget, so I put a lot of parenthesis around
it.


return ((a) ?
           (b) :
           (c));


Just because then each piece is obviously grouped in a certain
way.


That's just a personal style though. I don't think the language
should enforce it since sometimes those parenthesis make it
worse, not better, to read.

> At 14.45-16.39 there is an interesting part, about slide 22 of 
> the PDF. It's about crashes/bugs caused by undefined order of 
> evaluation of function arguments. This is a class of bugs that 
> don't have to happen in D2 code.

I believe the order of evaulation is defined in D.