- Overview
-
Table of Contents
- Special Member Functions: Constructors, Destructors, and the Assignment Operator
- Operator Overloading
- Memory Management
- Templates
- Namespaces
- Time and Date Library
- Streams
- Object-Oriented Programming and Design Principles
- The Standard Template Library (STL) and Generic Programming
- Exception Handling
- Runtime Type Information (RTTI)
- Signal Processing
- Creating Persistent Objects
- Bit Fields
- New Cast Operators
- Environment Variables
- Variadic Functions
- Pointers to Functions
- Function Objects
- Pointers to Members
- Lock Files
- Design Patterns
- Dynamic Linking
- Tips and Techniques
- Five Things You Need to Know About C++11 Unions
- A Tour of C99
- A Tour of C1X
-
C++0X: The New Face of Standard C++
- Reference Wrapper
- The Performance Technical Report
- auto for the People
- Ironing Templates' Syntactic Wrinkles
- Visual C++ Becomes ISO Compliant
- A Garbage Collector for C++
- C99 Core Features in C++0X
- The <code>shared_ptr</code> Class
- The shared_ptr Class, II
- Lambda Expressions and Closures, Part I
- Lambda Expressions and Closures, Part II
- Lambda Expressions and Closures, Part III
- The Type Traits Library, Part I
- The Type Traits Library, Part II
- The Type Traits Library, Part III
- finally Revisited
- The Any Library
- The nullptr Keyword Proposal
- Delegating Constructors
- The Explicit Conversion Operators Proposal
- Conditionally-Supported Behavior
- The weak ptr Class Template, Part I
- The weak ptr Class Template, Part II
- POD Types Revisited
- The rvalue Reference Proposal, Part I
- The rvalue Reference Proposal, Part II
- Proposal for New String Algorithms
- Concepts, Part I
- Concepts, Part II
- constexpr: Generalized Constant Expressions
- The <u>constexpr</u> Proposal: Constructors
- Strongly-Typed enum Types
- C++09: The Road Ahead
- C++09: Proposals by Statuses
- Changing Undefined Behavior to Diagnosable Errors
- New Character Types
- The __func__ Predeclared Identifier is Coming to C++
- Static Assertions
- The extern template Proposal
- Variadic Templates, Part I
- Variadic Templates, Part II
- Variadic Templates, Part III -- Critique
- Using unique_ptr, Part I
- Using unique_ptr, Part II
- Unrestricted Unions, Part I
- Unrestricted Unions, Part II
- Unrestricted Unions, Part III
- Types With No Linkage as Template Arguments
- New Initialization Syntax
- Initializer Lists and Sequence Constructors
- New Standard Library Algorithms
- Class Member Initializers
- Inheriting Constructors
- Introducing Attributes
- The Removal of Concepts From C++0x
- The Future of C++0x, Part I
- The Future of C++0X, Part II
- The Debate About Attributes, Part I
- The Debate About Attributes, Part II
- The Debate About Attributes, Part III
- The Debate About Attributes, Part IV
- Forward Declarations of Enum Types
- The SCARY Iterators Proposal, Part I
- The SCARY Iterators Proposal, Part II
- Heading for Deprecation: <tt>export</tt>, Exception Specification and <tt>register</tt>
- The Rejection of the Unified Function Syntax Proposal
- Rvalue References as Object Members
- FCD Approved
- The Debate on noexcept, Part I
- The Debate on noexcept, Part II
- The Debate on noexcept, Part III
- About-face -- [[Attributes]] to Be Replaced with Keywords
- Will Delegating Constructors Be Removed From C++0x?
- Rvalue References: Past, Present and Future, Part I
- Rvalue References: Past, Present and Future, Part II
- Rvalue References: Past, Present and Future, Part III
- A Move in the Right Direction, Part I
- A Move in the Right Direction, Part II
- New Keywords for Inheritance Control, Part I
- New Keywords for Inheritance Control, Part II
- FDIS Approved
- C++0x Concurrency
- The Reflecting Circle
- We Have Mail
- The Soapbox
- Numeric Types and Arithmetic
- Careers
- Locales and Internationalization
The Removal of Concepts From C++0x
Last updated Jan 1, 2003.
On Monday, July 13th 2009 Concepts were dramatically voted out of C++0x during the C++ standards committee meeting in Frankfurt. This shocking news raises many questions and concerns. Unquestionably, these will be discussed in various forums in coming weeks and months. However, I will try to answer three burning questions here: What led to the failure of Concepts? How will the removal of Concepts affect C++0x? Will Concepts make a comeback in the near future?
The Writing on the Wall
When I first heard the news, I couldn't believe it. Concepts were supposed to be the most important addition to core C++ since 1998. Tremendous efforts and discussions were dedicated to Concepts in every committee meeting during the past five years. After dozens of official papers, tutorials and articles -- all of which were dedicated to presenting and evangelizing Concepts -- it seemed very unlikely that just before the finishing line, Concepts would be dropped in a dramatic voting. What caused this change of heart among committee members?
Early warning signs emerged long ago. Initially, Concepts were supposed to be integrated into the Standard Library. The C++0x Committee Draft (approved in September 2008) uses concepts in the Standard Library extensively but committee members expressed their concern that concepts were "untried, risky and controversial". The problem was this: other than ConceptsGCC, there weren't any C++ implementations that supported concepts and therefore, it was impossible to field-test them in real world projects or get feedback from individual users other there.
Two strong undercurrents shook and undermined the entire Concepts foundation. First, skepticism regarding the feasibility and usefulness of concepts intensified the antipathy towards this proposal. Some people expressed concerns about compile-time and runtime overhead. Second, the creators of the Concepts proposal tried desperately to improve and patch Concepts. The last nail in the coffin was Bjarne Stroustrup's paper "Simplifying the Use of Concepts" from June. It's a masterpiece in terms of presenting Concepts but it also scared folks. The general sense was that concepts were broken, the committee was not sure what the correct direction was to fix them, and it would probably take several more years to come up with a reasonable fix that would achieve consensus. Considering that Concepts were originally designed to simplify C++, a critical mass of committee members agreed in July 2009 that it was time to bid Concepts goodbye.
Possible Directions
It's still unclear at the time of writing which alternatives the committee will choose. A total overhaul of Concepts is one possibility, however unlikely. This could take up to five years and no one is certain that the redesigned Concepts will not have introduced other problems. A second approach is to leave the door open for a drastically reduced and diluted Concepts proposal. The third approach is to refine the current Concepts proposal further, knowing that it will not be integrated into C++0x. I'm willing to bet on the following -- Concepts are dead for good. Certain members are certain that C++ will have concepts in five years from now, but the C++0x standard will not wait until then, and once the standard has been ratified by ISO, any features waiting in the pipeline will have to wait for the next standard. Five more years means forever, I regret to say. I remember similar promises about a built-in garbage collector back in 1997. And besides, why pursue the current notion of concepts which has thus far proved to be futile? Maybe it's best to start from scratch?
The Concepts proposal was doomed among other reasons because the committee wasn't standardizing existing practice (which is what it usually does) but instead, invented a huge, complex and controversial feature ex nihilo. History shows that features that were added in this unusual way to C++ have all failed. This was the case with exception specifications and exported templates.
Implications and Analysis
It's hard to tell at this stage how the removal of Concepts will affect C++0x. Clearly, the impact will be huge because many other C++0x features presuppose Concepts. In the coming weeks, the committee will have to scrutinize all outstanding proposals and the Committee Draft to assess the impact of this decision.
How will C++0x programming and design look like without Concepts? Brace yourself for many more years of indecipherable template compilation errors. Additionally, type traits will become a hot commodity once again. Presently, type traits are one of the very few proven techniques for enforcing compile-time constraints on templates. Pedagogically, C++ will be a tad easier to teach.
The removal of Concepts paves the way to other radical changes. If Concepts could be removed, there's no reason why other "safe" features should become sacred cows. No, I'm not going to name such features but suffice it to say: the Committee Draft has plenty of features that need to be reconsidered or dropped.
The collapse of Concepts might seem as a sad end to a well-intended attempt to solve a fundamental problem. However, there's no reason for sobbing. This story shows that the committee isn't afraid to take tough decisions if it has to. It's also a good reminder to all programming languages' designers: don't get enamored of your own proposals. Every new proposal seems neat and promising at first but after a few iterations and redesigns, it might easily turn into a bloated tumor that impedes the natural growth and evolution of the language (namespaces anyone?). If we're ever going to have concepts in C++, it's "the marketplace", not the committee, that needs to do its work first and only then should the committee bless the result -- if it so chooses. Doing things the other way around is a recipe for failure.
