Optional braces

[Steven Schveighoffer]

On Fri, 26 Aug 2011 11:03:21 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> It's a legitimate concern, and there's no right response to it. My point  
> is that the argument is weak and caving to it would be a mistake. In  
> essence Nick claims he can't be bothered to change:
>
> if (long_expression_one)
> if (long_expression_two)
> if (long_expression_three)
>    statement
>
> with
>
> if ((long_expression_one)
> && (long_expression_two)
> && (long_expression_three))
>    statement
>
> which adds a grand total of two parens. The claim "blah blah long thing  
> with the simple unrelated condition requiring ugly line breaks and  
> screwy formattng/alignment in a big pita to read uber-expression. fuck  
> this shit. It looks ok in english, but in code the damn thing reads like  
> a fucking regex" does not stand scrutiny, and mixing in the matter of  
> indentation is a red herring as indentation is unaffected by the  
> introduction of the rule.
>
> I'll also note that the argument smacks of the misleading vividness  
> fallacy (http://en.wikipedia.org/wiki/Misleading_vividness). We  
> shouldn't shelve an idea because a poor argument against it was  
> eloquently phrased.
>
> Finally, we've derived significant benefits from ideas in the same  
> spirit. I don't see signs that we've started overdoing it, or that the  
> returns are diminishing. To me all signs point to a fertile approach to  
> explore.

Hm... the only problem I see with simply disallowing if(a) if(b) is this:

if(a)
   while(condition)
     if(b)
       statement;
else // oops! this goes with if(b)
   statement;

Or would this be disallowed as well?  This could not be combined into a  
single if statement obviously, so the only the option to fix this is  
adding braces.

I'd hate to see this disallowed, which seems perfectly legitimate:

if(a)
    while(condition)
       if(b)
         statement;

-Steve