Not yet, but there is continued enthusiasm for adding more features to C++.
Bjarne wants it to have lifetime tracking. Wouldn't it be nice if your C++ compiler could point out that you can't very well return this object since you've no reason to think it will exist by the time you return?
Vittorio wants it to have Rust-style language version management through epochs.
Herb wants it to offer slimmer exceptions instead of the bulky mess that people often opt to switch off entirely.
All of them agree C++ is too big. However, before it can be slimmed down properly, they just have one more thing to add...
Instead, pretty much all that is listed there are small and useful cleanups of the standard:
- two's complemement is required, which I assume will remove some UBs
- Labels can appear before declarations and at the end of compound statements
- Removal of K&R function definitions
- Unnamed parameters in function definitions
In fact those are some of the major complaints people are having with the language currently.
As well as some very useful features that are small and self-contained
- A feature for binary resource inclusion in the preprocessor (#embed)
- Binary literals such as 0b10101010
- _Static_assert
I don't know the process and the people well enough to say I agree with everything WG 14 does, but I'll say that's how you improve quality of life while staying humble. The changes I see here, no chance of having to fix some grand idea over decades, like with RAII which requires N new type specifiers and constructors, move semantics...
> The C proposal N1451 provides a new syntax for lambda expressions. While details of the proposal are unclear, it is clear that there are both significant commonalities and significant differences [NOTE: document's title is "Comparing Lambda in
C Proposal N1451 and C++ FCD N3092"]. The syntax is in many places a shallow inconsistency. More deeply, the model of reference capture seems inherently incompatible. The N1451 model seems more appropriate to Smalltalk, from whence it originated, than to C/C++. If the C commitee chooses to modify the proposal to be more inline with C++, then syntactic changes to both C and C++ would provide considerable value to working programmers, who often fail to appreciate any differences in approach.
In summary, there seems to be one guy who has invested effort in a proposal, and all I can find is at best mixed reactions to this proposal, inside and outside of WG14.
While the stuff I listed in above comment is all simple or even simplifying the language, and that's what's already integrated in the working draft in the standard.
But that is what they'd have to do with C++, since its problem is not the features it has, but that it has every feature.