Walter Bright

Dr. Dobb's Bloggers

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);

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.)

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!