Dangling Else, Yet Again
September 22, 2011
written by Walter Bright
The so-called dangling else problem is a perennial problem that comes up when designing a programming language. Given the code:
if (a) if (b) s; else t;
should it be parsed as:
if (a) { if (b) s; else t; }
or as:
if (a) { if (b) s; } else t;
The usual solution for the compiler is to associate the else with the innermost if, and the ambiguity is resolved. This was solved decades ago. End of story.
But perhaps there's more to it.
It isn't ambiguous to the compiler. But it can be ambiguous to the programmer. Consider:
if (a) if (b) s; else t;
When the indentation looks like that, clearly the programmer is intending the else to be associated with the outer if, while the compiler will silently attach it to the inner if. (At least, in a language where whitespace indenting is irrelevant, like C, C++, Java and D. This wouldn't be an issue in Python, which regards indenting as significant.)
Now I (cough cough) would clearly never make such a heinous error (cough cough) though I am informed it does occur in the wild and causes hidden bugs. Perhaps a tweak to the language's grammar would be in order to prevent the possibility of such mistakes. This came up again in the D newsgroup.
My first thought was to simply disallow the following form:
if (a) if (b) s;
i.e. an if followed by another if without the benefit of { } would be illegal. The D newsgroup informed me how inadequate this would be. Things are a little more subtle. For example, the following should be disallowed, as they are ambiguous:
if (a) if (b) s; else t; if (a) while (b) if (c) s; else t;
and the following should be compiled without complaint, as they are not ambiguous:
if (a) if (b) s; if (a) if (b) s; else t; else u; if (a) do if (b) s; else t; while (c);
Additionally, the various ConditionalStatement grammars also have else clauses.
Kennytm came up with a clever parser solution that nailed it. It's a pure parser solution, no semantic analysis needed. It works by keeping track of any lexically enclosing statement that is looking for an else clause, so if an else clause is found for the current statement without a following { }, then it is marked as illegal.
As far as I know, no other language has implemented this solution, though gcc does check for a subset. I think it's fun that there's still room for better solutions to ancient programming problems.
Conclusion
Solving the dangling else problem needs more than just providing a disambiguation rule for the parser. A complete solution will completely disallow code that is ambiguous, thus preventing possible bugs where the programmer thought the else was associated with one if but the parser another. In general I find that finding ways to eliminate ambiguities completely is a better, more robust programming solution than inventing an arbitrary rule to pick one.
This is implemented as a warning in the current release of the compiler. Eventually, it will be upgraded to a regular error.
Epilogue
I am suitably embarrassed to say that adding this to the D compiler uncovered a previously unknown bug in the D runtime library. (The debug statement has an optional else clause.)
Acknowledgements
Thanks to Andrei Alexandrescu for his helpful comments on a draft of this.