Why C++ cannot adopt D's approach for its concept implementation?

Question

As many of you guys know, concepts, C++'s approach for constraining possible types for a template argument has failed to be included in C++11.

I learned that the D programming language 2.0 has a similar feature for its generic programming. Its solution seems to me quite elegant & simple.

So my question is why C++ cannot use a similar approach.

• The C++ concept's goal might be bigger than what D's implementation provides?
• Or C++'s legacy prevents it from adopting such an approach?
• Or any other?

Thanks for your answers.

p.s. To see some examples of D's generic programming power, please refer to this: https://stackoverflow.com/questions/7300298/metaprogramming-in-c-and-in-d/7303534#7303534

Answer 1

The Standard of C++ is a normative document, which sets rules that will remain (mostly unaffected) in the future documents. Therefore the committee has taken a very cautious approach with regard to its updates.

The additions to the standard library were somewhat easy. A number of libraries had been in Boost for a long time: it had been proved they worked.

Additions to core concepts in the language however are much more difficult to experiment with, because it first requires modifying a compiler. A C++03 feature (the export of templates) had been specified without compiler support... the result was horrid. The implementers of the EDG compiler frontend reported it as a massive task (several man years) for very little gain. No other compiler ever tried to implement it. It's not a comfortable situation.

Features like constexpr or static_assert were easy (and already emulated by libraries). Lambdas are quite well understood and implemented in a variety of other languages, there has been extensive research already, so it was mainly a matter of syntax.

On the other hand Concepts were judged too new and untried. They were barely specified in time, there had been no proof of concept... and thus they were rejected, rather than waiting for them (or making a mistake).

Why not following D ? There is no saying that it won't. The committee has encouraged people to rethink from scratch, with no urging deadline, and to try their hands at including them in a compiler to see how they interact with other features in the language. There's notably the question of separating Concepts and Concept Maps: should they be bundled as one or not ?

FYI: There is currently a branch of Clang dedicated to this experimentation, led by Larisse Voufo from the university of Indiana.

Answer 2

For the 2011 standard, C++ concepts were what was being worked on, and they were ultimately dropped from that standard, because they weren't "baked enough." Work continues on C++ concepts which may lead to them making it into the next standard. It could be, however, that some folks will work on a proposal for the next standard which is similar to D's template constraints. Whether that happens or not remains to be seen. As far as I know, there was no such proposal for the 2011 standard, so there was no chance for it to make it into that standard regardless of its merits, but what will or won't make it into the next standard is completely unknown at this point.

I'm not aware of any major reason why something similar to D's template constraints could not be implemented for C++, though given that C++ is generally more limited in what it can do at compile time, it might be harder to make them work quite as well as they do in D (though the introduction of stuff like constexpr certainly helps).

So really, I think that the short answer is that there's no technical reason why something similar to D's template constraints couldn't be in C++.

The question is whether such a proposal will be made for the next standard and how it will compare with whatever similar proposals are made (e.g. proposals relating to concepts). Assuming that an acceptable proposal can be made, I would fully expect that something similar to concepts or D's template constraints will make it into the next standard simply because there's a lot of desire for it. The question is whether anyone can come up with a proposal which is solid enough and "baked enough" to be acceptable.

Answer 3

You mean D's template constrains?

As far a I know, C++ concepts had been proposed on behalf of boost::concept. The problem, here, is that boost is a library written for C++03. C++11 has other syntax capabilities that allow to implement certain things in a different way C++03 allows (hence, boost itself can be rewritten taking advantages of the new syntax).

The standard committee dropped concepts because it will had taken too long to specify them (thus delaying again the c++11 approval). They will probably go in the next C++ release.

Meanwhile, D syntax is different then C++ and D itself retain some expression evaluation capabilities at compile time C++ cannot always have without breaking some legacy code (something D dosn't have, having it a shorter history). C++ itself now has static_assert and costexpr, that allows to improve the compile time evaluation capabilities. May be in future will reach a similar level.

Answer 4

Here is a QA with Herb Sutter, he talks about concepts at the 15minutes mark.

http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers

If you like that, here is another one: http://channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11

Now as to your question. Why not the D version? Well why use it? C++ is a very complex and stable language. Each feature needs to be selected extremely carefully, because it usually has to be supported for decades. If you look at the first C++ standard and follow the revisions, there are some deprecated features, but even those have to be still supported. So it makes sense to design concepts to 100% fit C++.

As for why it wasn't included in C++0x. Well because it was huge. The proposal was 100 pages long and very hard to implement. It was decided that this feature needs more time to mature until it is included into the standard.

Answer 5

Quite simply, C++ has a hell of a lot more historical baggage than D. It would be much easier to implement an awful lot of things if it wasn't for the fact that C++ has massive amounts of historical code which must continue to work correctly and as expected. D doesn't have this problem.