Dangling Else, Yet Again The so-called "dangling else" problem is a perennial one that comes up when designing a programming language.



The so-called "dangling else" problem is a perennial one 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 (decades-old) solution for the compiler is to associate the else with the innermost if , and the ambiguity is resolved. 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;

In other words, 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 subtler. 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 great that there is still room for better solutions to ancient programming problems.

Conclusion

Solving the "dangling else" problem requires more than just providing a disambiguation rule for the parser. A complete solution will totally 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 eliminating 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.)

Thanks to Andrei Alexandrescu for his helpful comments on this draft.