The ISO C++ committee now regularly receives many more proposals than we can/should accept. For the meeting that begins this coming Monday, we have about 300 active technical papers, most targeting post-C++20. I now regularly get asked, including again a few hours ago, “how do we know which of these customers actually want and will use? what is our data that we’ve prioritized them correctly?”
So a colleague has challenged me: Can the ISO C++ committee get useful information by crowdsourcing public feedback on ISO C++ proposals? I don’t know, so let me try by asking one targeted question…
I don’t expect you to know all of the proposals (and I know it’s a big list!), but I suspect many of you know about some of them that matter to you. I will share your feedback with the ISO C++ committee and post the results publicly. Thanks again for all of you who’ve already provided feedback in our spring C++ developer survey, that feedback is being used by the committee and the experiment here is try for finer-grained feedback at the proposal level. If this works perhaps we can explore things like allowing community comment/upvote on these issues.
Thank you in advance for your time, it’s appreciated and helpful.
Herb
Note: PLEASE use the survey (not the comments section on this post) to respond to this question, because the survey form makes it easier to track and use the data.
Please do use the comments section below for other discussion, including suggestions about other ways the committee might usefully engage the community.
Sutter’s Mill 
Hoestly, I was surprised how hard it was for me to find five. The three I definitely want are:
P1371 Pattern Matching
https://github.com/cplusplus/papers/issues/166
P1279 std::breakpoint
https://github.com/cplusplus/papers/issues/307
P1255 A view of 0 or 1 elements: view::maybe
https://github.com/cplusplus/papers/issues/60
I’m really interested in metaclasses/metaprogramming/expansion statements/parametric expressions/etc. but it strikes me that these are all heading toward something like Lisp macros, or could be implemented via something like Lisp macros. Rust shows one possible direction. I can’t claim to fully comprehend all of those proposals, but the one thing I would *really* like in C++ is something morally equivalent to Lisp macros.
The only path forward for C++ is to crumble under its own weight. The committee has no desire, intention or capability to improve the language.
Unfortunately there is no viable alternative to replace C++, so, we’ll probably have to go back to using plain old C. (rust fanatics don’t dare to mention your slower to compile language, I’ll be really embarrassed if I’ve made a language which compiles slower than C++! Pathetic!!!)
I doubt the need to handle OOM specially. Even now you can set new_handler to terminate. What are the benefits of changing the default behavior? Also, we can’t predict all the ways an environment might make the program behave different from code. If an OS may kill the program randomly due to OOM, a debugger may break the execution. If the former is an argument to treat OOM specially, is the latter an argument to insert pauses to ask user to continue execution? Why is this bundled with lightweight exceptions?
Concerning priorities, if C++ should remain a general-purpose programming language, you should prioritise features that are instantly useful to most programmers. A web poll may be misleading: you still need good judgment in addition to that.
Btw, I saw a paper for 2D graphics. This is just a matter of taste, but a standard graphics API sounds weird when you need 3rd party libs for a visual interface. Standardising ncurses first would feel more logical.
@Martin,
Good point. I should have added the link to the list of SGs etc.
https://isocpp.org/std/the-committee
@Yehezkel : That only helps if you know the groups. I don’t; Herb’s readership probably contains a higher proportion of those that do than the general C++ programmer population – but I suspect they are still in a minority.
@Roland,
There is a bit of “tagging” by looking at the target audience. SG7 is the reflection study group, SG15 it tools, etc.
This doesn’t cover them all, of course, especially papers targeting EWG/LEWG, but it can help a bit in some cases.
While I love C++, there is one topic that will drive me away if not properly addressed, asap:
– “reflection”, analysis AND synthesis of types, constexpr blocks, maybe metaclasses
Still requiring hand-written code for serializing enums or structs? Ridiculous.
Still having to distinguish between tuples and structs? Laughable.
I cannot explain why we should use C++, if it requires this kind of time consuming monkey tasks.
We must get this done. I can help with use-cases, experiments and feedback. Let me know how.
This is extremely hard, even though I happen to know a few proposals. What makes it so hard is the (seemingly) random nature of the titles. How about a bit of tagging? Like [reflection] or [bugfix] or [constexpr]?
In this data science era, there is a high demand and requirement for data frames and data visualization. I am looking forward for an efficient data plotting utility in native c++. We do a lot of data crunching and finally depend on 3rd party utility for plotting.
who can create proposal like get memory usage for all of container ?
till now its very ugly https://stackoverflow.com/questions/25375202/how-to-measure-memory-usage-of-stdunordered-map
I don’t know how I would use them yet but these are the top ones ranked best first:
P0707R4 Metaclasses: Generative C++ (Herb Sutter)
https://github.com/cplusplus/papers/issues/403
P1371R0 Pattern Matching (Sergei Murzin, Michael Park, David Sankel, Dan Sarginson)
https://github.com/cplusplus/papers/issues/166
P1717R0 Compile-time Metaprogramming in C++ (Andrew Sutton, Wyatt Childers)
https://github.com/cplusplus/papers/issues/483
P1306R1 Expansion statements (Andrew Sutton, Sam Goodrick, Daveed Vandevoorde)
https://github.com/cplusplus/papers/issues/156
P1179R0 Lifetime safety: Preventing common dangling (Herb Sutter)
https://github.com/cplusplus/papers/issues/312
P1705R0 Enumerating Core Undefined Behavior (Shafik Yaghmour)
https://github.com/cplusplus/papers/issues/473
P0554R0 Composition of Arithmetic Types (John McFarlane)
https://github.com/cplusplus/papers/issues/360
As a hardcore C++ enthusiast, I never envisioned myself saying this ever, but to be honest at this point C++ could benefit more from “top five ISO C++ features to remove” rather than add.
If we care about long-term viability of C++ in the decades ahead, and I assume everyone here does, it would serve us well to aim for a simpler, more steamlined language. Considering that C++ has always been big on backwards compatibility, and rightly so may I add, adding more and more features every few years is a dangerous proposition – one that must be very carefully weighted against the cost these new features bring to the simplicity and long-term maintainability of the language.
As a hardcore C++ enthusiast, I never envisioned myself saying this ever, but to be honest at this point C++ could benefit more from “top five ISO C++ features to remove” rather than add.
If we care about long-term viability of C++ in the decades ahead, and I assume everyone here does, it would serve us well to aim for a simpler, more steamlined language. Considering that C++ has always been big on backwards compatibility, and rightly so may I add, adding more and more features every few years is a dangerous proposition – one that must be very carefully weighted against the cost these new features bring to the simplicity and long-term maintainability of the language.
Sorry Herb, but this is just a horrible idea… especially since good proposals from unknown people will not get as much votes as your’s(you gave talk at ACCU about your stuff).
Also there can be proposals that are important for me but I will never know because they help library implementers to give me better libraries…
But I can give you an example of stuff I liked from previous standards:
4 iter std::equal – was idiotic that it was not in C++98
.contains for maps/sets – again embarrasing how many millions of lines of !=.bla.end() exist in the codebases
starts_with/ends_with for string view -again how was this not in C++17?
In other words boring usability stuff that nobody from WG21 seems to care about that much.
regarding core language:
inline variables and decltype(auto) are ugly beause WG21 does not want to use new keywords, but it was nice.
structured bindings are bad(to much corner cases that are just horrible), so please avoid stuff like that.
Convinience is not worth learning extra corner cases.
Also if possible please consider that proposal that removes co_ abomination from the C++20 and replaces it with 1 decoration on the function, co_ is terrible.
if constexpr was amazing, finally a way to get rid of SFINAE junk in my code, anything that makes consteval/constexpr nicer would be nice.
P.S. Remember the Vasa :)
I skimmed so far 8 of the 13 pages of proposals, seeing nothing so far that hit me as useful. Though some titles hinted at being essentially (design level) bug fixes. I guess if I delved into those, then some I might agree with.
The most important to me would be to not break existing code by changing the return type of `std::filesystem::path::u8string`.
One can work around it changing all use of it in existing code to inefficiently copying the result bytewise to a `std::string`.
Changing the return type to something incompatible is just so dang harebrained when viewed as something intended to be positive, an advantage.
It’s like whoever proposed that is, instead, waging a very narrowly focused war against use of C++ in Windows.
I don’t know any of the proposals. I can guess that some of them are uninteresting for me, just from the titles – but I can’t step through them all to find the five I most like. Can someone prepare a table with *short* summaries of each proposal? (Then I can investigate the ~20 that might interest me.)
The proposed deterministic value based exceptions would be life changing!