Survey results: Your “top five” ISO C++ feature proposals

Today I collated and analyzed the results of the survey I posted two weeks ago.

I presented you with a daunting unsorted list of ~300 eye-numbing paper titles, and still 289 of you responded with ~1,200 total votes (not everyone picked five things) many of which contained thoughtful “how I would use it” verbatims. Thank you for your time and interest!

In addition to summing your votes per-paper, I also spent several hours manually assigning categories to the individual proposals so that we could see votes per-feature area. For example, “pattern matching” had multiple papers, so I wanted to generate a subtotal also for votes for “all pattern-matching papers” as well as for each of the individual ones. You might assign categories differently than I did, but I think these are a good start to see basic groupings and patterns.

Here’s a 35-page PDF of the full results. The following are some highlights.

The top-voted primary topic categories correlate well with the results we saw in the 2019 global C++ developer survey open-ended write-in questions for ‘if you could change one thing about C++’ and ‘any other feedback.’ The top topic areas are:

Primary topic category #votes
Reflection 154
Convenience/usability 129
Error handling 129
Compile-time programming 105
Pattern matching 73
Concurrency 70
Performance 58
Numeric 47
Systems programming 45

Here’s a partial graph:

The top-voted individual papers were:

Paper #votes
P0707 reflection & metaclasses 89
P0709 error handling, static EH 85
P1371 pattern matching 71
P1240 reflection 40
P0323 error handling, std::expected 24
P1767 package mgmt 23
P1485 coroutine keywords 23
P1750 std::process 22
P1717 compile-time programming 22
? no specific paper (a catchall when the response was useful and fit in a category, but didn’t include a specific paper number) 22
P1629 Unicode 20
P1031 low level file I/O 19
P1040 compile-time data embed 19
P0645 text formatting 16
P1729 text formatting 15

Finally, disclaimers:

  • Experimental: This was advertised as an experiment. The results may not be representative. However, as I mentioned already, the top-voted topic areas correlate well with the results from the 2019 global C++ developer survey open-ended write-in questions for ‘if you could change one thing about C++’ and ‘any other feedback.’
  • Bias: I posted the poll on my personal blog, which could bias results in favor of my proposals. In fact, the two top-voted individual proposals were my own papers on reflection and lightweight exceptions. But even if you remove those two, their topics are still in the top-voted categories of interest because there was strong voting in favor of “reflection” and “efficient exception/error handling” papers that were not written by me (e.g., the #4 and #5 papers were reflection and error handling papers that I didn’t write). Also, the post was Reddit’ed and it looks like most of the responses came via that. (Besides, happily/sadly, many of you who follow my blog freely disagree and argue with me so this isn’t just an echo chamber, and I also had a number of other papers that got fewer votes or none so you weren’t just upvoting my papers.)

Again, thank you very much to everyone who responded for your time and interest. I hope you find these results likewise interesting, and I’ve shared them with the committee as well.

I think this survey was a successful experiment. We’ll keep reading the data, especially the verbatims on how you would use the features you requested. But I think it’s fair that we can say already that, if nothing else, we now have some confirmation that the part of the community that responded supports the basic goals of P0592 so that paper is more than just the opinion of the author (who isn’t me)… that paper recommends that in the C++23 timeframe we focus our efforts on coroutines, executors, networking, reflection, and pattern matching. There’s a good correlation between that list and your “most-wanted papers’ topics” list above. That’s useful to learn, and we’ll look to learn more from your responses; thank you again.

6 thoughts on “Survey results: Your “top five” ISO C++ feature proposals

  1. Interesting results: I would like to see them organised by Language and Library – perhaps using two colours for the bars as appropriate.

  2. @Robert: Nicely said, thanks. To be clear, the “/sadly” was intended to be humor, I’m glad this is not an echo chamber. Even when the manner in which the feedback is presented is snarky (noise), it’s usually useful to try to filter that out where possible to listen to the substance (signal), because that helps reduce blind spots and going too far down dead-end alleys.

  3. Indeed, the results are incredibly biased, in favor of:

    * Your own proposals.
    * Your own interests.
    * Proposals made recently or which have gone through part of the adoption pipeline.

    On a personal level, my top five “proposals” in the general sense would include:

    * restrict … N3635 for example
    * Unified call syntax + classes define namespaces with their own names + method impls are functions in their class namespace which implicitly take this (but subject to public/private/protected and vtables for virtual access).
    * Operator Dot
    * Run-time reflection (well beyond RTTI obviously)
    * Run-time JITing facilities (and not only for the executing platform as the target)

    And some library stuff:

    * spans of bits
    * templated integer types. This is super easy and trivial, and for the life of I can’t understand why it wasn’t in C++98 or C++03 already.

  4. I think it is important to note that Contracts, which is a big feature, had already been accepted into C++20 when this survey was posted. The decision to defer it to a later standard was made quite late when most people had probably already answered. The results of this survey should therefore not be used to judge how much support there is for this feature.

  5. > Besides, happily/sadly, many of you who follow my blog freely disagree and argue with me so this isn’t just an echo chamber

    I believe it’s only because everybody cares about C++ and wants it to be better.

    A relevant blog post on stackoverlfow (long read):

    > That was when something became crystal clear: my coworkers hadn’t become monsters, they were still the kind and caring people I thought they were. The monster in this case is not one person, it was created when lots of people, even with great intentions, publicly disagreed with you at the same time. Even kind feedback can come off as caustic and mean when there is a mob of people behind it. No matter how nicely they say it, when a large group of people you really respect publicly challenge something you’ve done it can feel like a personal attack.

Comments are closed.