On 9/20/12, Michael Matz <m...@suse.de> wrote: > On Wed, 19 Sep 2012, Lawrence Crowl wrote: > > On 9/19/12, Eric Botcazou <ebotca...@adacore.com> wrote: > > > > The language syntax would bind the conditional into the > > > > intializer, as in > > > > > > > > if (varpool_node *vnode = (node->try_variable () > > > > && vnode->finalized)) > > > > varpool_analyze_node (vnode); > > > > > > > > which does not type-match. > > > > > > > > So, if you want the type saftey and performance, the cascade > > > > is really unavoidable. > > > > > > Just write: > > > > > > varpool_node *vnode; > > > > > > if ((vnode = node->try_variable ()) && vnode->finalized) > > > varpool_analyze_node (vnode); > > > > > > This has been the standard style for the past 2 decades and > > > trading it for cascading if's is really a bad idea. > > > > Assignments in if statements are known to cause confusion. > > So? Make it: > > varpool_node *vnode = node->try_variable (); > if (vnode && vnode->finalized) > varpool_analyze_node (vnode); > > > The point of the change is to limit the scope of the variable > > to the if statement, which prevents its unintended use later. > > I'm not worried about this.
It is helpful to have the language and the usage in concurrence. Okay, so unless someone objects, I'll move the variable out when it introduces a cacade. > > Why do you think cascading ifs is a bad idea? > > Precedent. Confusion in case of dangling else (requiring more {}, > and hence even more indentation). Ugly. I generally take ugly as an indication that the function needs refactoring. -- Lawrence Crowl