Don: > I would say that disallowing it would _always_ lead to clearer code.
OK. It's in Bugzilla since some time: http://d.puremagic.com/issues/show_bug.cgi?id=5409 (But if we want to disallow something then we have to list exactly what syntax are not allowed.) > Making #7 an error would break a lot of my code, unless it were done in > a really complicated way (allowing boolean expressions, but not integral > ones other than UnaryExpressions). And that seems quite hard to justify. I think in this case introducing complex rules is not good. auto z = x * y ? 10 : 20; //#7 auto z = x * (y ? 10 : 20); > But I don't find the other cases convincing. They don't seem any more > likely to be bugs than not. For example, a variation of case #3: > if (1 || y) {} > is common and completely legitimate. Disallowing that would be very > annoying. I agree that sometimes it's not a bug (example: the 1 is the __ctfe pseudo-constant). Always true or always false boolean conditions (unless they are just a single "true", "false", "0" or "1" literal) are sometimes associated with bugs. Good C lints give just a warning in this case, no error. I agree that statically disallowing this in all cases is too much harsh. ------------------ The midway cases are #5 and #6. If I write manually code like that, it's probably a bug. A similar case (auto-assign): x = x; Or even (auto-assign, through alias): alias x y; x = y; Or even (repeated assign): x = 10; x = 10; (repeated assign, this happens often enough, the second variable is not x): x = Foo.barx; x = Foo.bary; On the other hand automatic code generation (in CTFE) sometimes produces some redundancy in code, this may cause some false positives. But similar redundancies that often hide bugs. So I think this class of troubles deserves more thinking. A common bug in my code is this one, I have had something like this six times or more: http://d.puremagic.com/issues/show_bug.cgi?id=3878 Bye, bearophile