C++ Reference Guide

The Rejection of the Unified Function Syntax Proposal

Last updated Nov 27, 2009.

A detailed proposal for replacing the auto-arrow style declaration of functions with a new syntax was rejected at the Santa Cruz meeting. That proposal was the collective work of several members, who'd been refining and refactoring it for a long time. Find out what that proposal was all about and why it was wasn't accepted into the Working Draft.

The auto-arrow Function Declarations

C++0x introduced a function declaration syntax whereby the auto type specifier and a -> return type are used. For example:

auto f() -> int;

is a declaration of a function called f which takes no parameters and returns int. The so-called "auto-arrow" syntax was problematic for various reasons, including parsing ambiguity and the confusion between auto as a storage type and the C++0x auto used for automatic type deduction (recall that the auto storage type was eventually removed from C++0x). For a detailed discussion about the problems with the above syntax see The Syntax of auto Declarations. It was therefore decided that the committee should pursue a new, unified function syntax for C++0x. The addition of lambda expressions and closures to C++0x inspired the authors to design a new notation that would be based the lambda syntax for all functions, including ordinary member functions and freestanding functions. Although the lambda notation seemed promising at first, the proposed uniform syntax was far from being consistent, clear or complete. It's not unusual to have proposals redesigned repeatedly until they're fully baked (or at least baked enough to be voted into the Working Draft). Take for example the lambda proposal. It was changed at least four times, including two major syntactic overhauls, and even today it still has some minor "loose ends". The unified function syntax proposal wasn't exceptional in this respect. But there were other factors that led to its demise. As one of the members said in his a pull-no-punches style:

[T]his proposal had good intentions, but that the realization of those intentions is horrible. ...[T]he syntax doesn't look readable, wouldn't help anyone understand the language better, and it's very late to be introducing something as optional as this proposal given how unstable the series of proposals have been and that the proposal doesn't fix a problem that needed to be addressed.

The unified function syntax proposal was rejected in Santa Cruz. I will not go through the complex and ever-changing technical details of the proposed syntax here. If you're interested, you can read the latest version here and get a glimpse of the proposed syntax.

Problems with the Unified Function Syntax

What was wrong with the unified function syntax? The minutes from the Santa Cruz meeting reveal that many members didn't like the proposed new syntax, which they found ugly and not very readable (it should be noted that similar comments were expressed in previous meetings). It also had no added value in terms of teachability. But other than the decorative aspects, there are other, more concrete problems with the proposal:

• You can't write casts to function types with the new syntax.
• Some new-style declarations require a typedef.
• One can not express a function that returns a function pointer with the new syntax.

All these corner cases might have been resolved later but the clock is ticking. There's simply no time for that. It's fairly safe to say that what hasn't made it into the WD yet (except for fixes) -- will have to wait for the C++1x standard.

Dry Your Tears

When I read C++0x new proposals, I have a habit of mentally marking them as either "looks good, even if it still requires polishing" or "I hope this never makes it into the standard". I can say that when I read the unified function syntax proposal I felt that it belonged to the latter category, along with the infamous Concepts. In The Practice of Programming, Brian Kernighan writes that one of his most productive days as a programmer was when he removed hundreds of lines of code from a project he was working on. At this stage, there is only one way to make the C++0x standard better --by removing features that aren't fully-baked, not by adding new ones. The rejection of the unified function syntax proposal was the right thing to do.