2

Herb Sutter in a video answers a question about the concepts proposal considered for C++11 and from his remarks it sounds like multiple groups offered prototype implementations but all of them left concerns about slow compile times. The comment surprised me because it suggests that, at least in some cases, the prototypes being developed are not just proofs of concept -- they're even expected to perform. All the work that must take has me curious.

For mature languages, especially C++, how are experimental language features developed? Is it much different from developing a compiler that implements a standard? Does a developer have a sense of if it will work and perform or even if it ever could? What are the most time consuming parts and are any parts surprisingly easier than one might expect?

The question is not what does the C++ standards committee do, but rather the part that comes before. When an experimental implementation for a proposal is being put together and there aren't any completely solidified rules, how is the sausage made?

I'm not a professional compiler developer nor do I expect answers with step by step accounts. I'd like a high-level idea of how this would be done or if there are any general patterns at all. I don't know what to expect from the answers but even if there are no rules to the process and the small number of people who do this just cowboy it and then, for stuff that worked out, write up the "official version" as a proposal, that answer would still be informative.

  • 3
    Step 1) Find a feature you haven't stolen from Lisp yet. – Phoshi Jun 12 '14 at 13:59
3

Principally it is sufficient to have a prototype implementation, or even just to "prove" that a feature is implementable. So the process is not much different than it would be to implement any feature into the compiler, but since it is a prototype you can cut some corners. Nobody expects production quality speed or results from these prototypes.

The problem with the pre-C++11 Concepts was not that the prototypes were slow, but that nobody was sure if and how the performance could be significantly improved, given the involved algorithms and the extend of data they required.

The work of getting a feature (even small ones) into the standard is significant. You basically have to

  1. motivate why you want the feature (by showing a problem which cannot be solved / is more difficult to solve without it )
  2. proof that the feature really solves the problem (implementation experience helps here)
  3. proof that the problem is real and relevantly prevalent (having different solutions which are used in real projects help here)
  4. proof that it will improve the language more than the additional complexity costs (often very contentious)
  5. proof that it is (efficiently) implementable (prototype helps enormously)
  6. proof that there is no easier solution (i.e. a throughoutly researched design rationale )
  7. proof that there is no more general solution
  • 2
    Painstakingly sort through all possible interactions with both existing and other proposed language features also should be somewhere on the list, I think. When LINQ was introduced into C#, they actually fed the original and the new modified grammar into an automated theorem prover to figure out whether there were any backwards-incompatible corner cases. – Jörg W Mittag Jun 12 '14 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.