"Concepts," as developed over the last many years and accepted into the C++0x working paper in 2008, involved some technical compromises (which is natural and necessary). The experimental implementation was sufficient to test the "conceptualized" standard library, but was not production quality. The latter worried some people, but I personally considered it sufficient as a proof of concept.
My concern was with the design of "concepts" and in particular with the usability of "concepts" in the hands of "average programmers." That concern was shared by several members. The stated aim of "concepts" was to make generic programming more accessible to most programmers [BS&GDR2003], but that aim seemed to me to have been seriously compromised: Rather than making generic programming more accessible, "concepts" were becoming yet another tool in the hands of experts (only). Over the last half year or so, I had been examining C++0x from a user's point of view, and I worried that even use of libraries implemented using "concepts" would put new burdens on programmers. I felt that the design of "concepts" and its use in the standard library did not adequately reflect our experience with "concepts" over the last few years.
Then, a few months ago, Alisdair Meredith (an insightful committee member from the UK) and Howard Hinnant (the head of the standard library working group) asked some good questions relating to who should directly use which parts of the "concepts" facilities and how. That led to a discussion of usability involving many people with a variety of concerns and points of view; and I eventually -- after much confused discussion -- published my conclusions [BS2009].
To summarize and somewhat oversimplify, I stated that:
- "Concepts" as currently defined are too hard to use and will lead to disuse of "concepts," possibly disuse of templates, and possibly to lack of adoption of C++0x.
- A small set of simplifications [BS2009] can render "concepts" good-enough-to-ship on the current schedule for C++0x or with only a minor slip.
That's pretty strong stuff. Please remember that standards committee discussions are typically quite polite, and since we are aiming for consensus, we tend to avoid direct confrontation. Unfortunately, the resulting further (internal) discussion was massive (hundreds of more and less detailed messages) and confused. No agreement emerged on what problems (if any) needed to be addressed or how. This led me to order the alternatives for a presentation in Frankfurt:
- "fix and ship"
- Remaining work: remove explicit "concepts," add explicit refinement, add "concept"/type matching, handle "concept" map scope problems
- Risks: no implementation, complexity of description
- Schedule: no change or one meeting
- "Yank and ship"
- Remaining work: yank (core and standard library)
- Risks: old template problems remain, disappointment in "progressive" community ("seven year's work down the drain")
- Schedule: five years to "concepts" (complete redesign needed) or never
- "Status quo"
- Remaining work: details
- Risks: unacceptable programming model, complexity of description (alternative view: none)
- Schedule: no change
I and others preferred the first alternative ("fix and ship") and considered it feasible. However, a large majority of the committee disagreed and chose the second alternative ("yank and ship," renaming it "decoupling"). In my opinion, both are better than the third alternative ("status quo"). My interpretation of that vote is that given the disagreement among proponents of "concepts," the whole idea seemed controversial to some, some were already worried about the ambitious schedule for C++0x (and, unfairly IMO, blamed "concepts"), and some were never enthusiastic about "concepts." Given that, "fixing concepts" ceased to be a realistic option. Essentially, all expressed support for "concepts," just "later" and "eventually." I warned that a long delay was inevitable if we removed "concepts" now because in the absence of schedule pressures, essentially all design decisions will be re-evaluated.
Surprisingly (maybe), there were no technical presentations and discussions about "concepts" in Frankfurt. The discussion focused on timing and my impression is that the vote was decided primarily on timing concerns.
Please don't condemn the committee for being cautious. This was not a "Bjarne vs. the committee fight," but a discussion trying to balance a multitude of serious concerns. I and others are disappointed that we didn't take the opportunity of "fix and ship," but C++ is not an experimental academic language. Unless members are convinced that the risks for doing harm to production code are very low, they must oppose. Collectively, the committee is responsible for billions of lines of code. For example, lack of adoption of C++0x or long-term continued use of unconstrained templates in the presence of "concepts" would lead to a split of the C++ community into separate sub-communities. Thus, a poor "concept" design could be worse than no "concepts." Given the choice between the two, I too voted for removal. I prefer a setback to a likely disaster.