[This post will be updated with additional details as mentioned in the comments section at bottom.]
A few minutes ago, the ISO C++ committee completed its summer meeting in Toronto, Ontario, Canada. We had some 120 people at the meeting, representing nine national bodies. As usual, we met for six days Monday through Saturday, including several evenings.
The following are some highlights of what we achieved this week. You can find a brief summary of ISO procedures here. The main things to note are:
- “IS” means “international standard.” In our case, it’s the core C++ standard itself. Think of this as “trunk.”
- “TS” means “technical specification,” a document separate from the main standard where we can gain experience with new features before putting them into the IS. We have several of these, summarized on the status page. Think of these as “beta branches.”
Note: As I reported in my previous trip report for the winter meeting (Kona 2017), we have already completed our work on C++17, which is now still going through its final ISO approval steps. Nothing we did this week affects C++17, but we did begin work on C++20…
First meeting for C++20
This was the first meeting where we could vote changes into Draft C++20. And we did!
First, the Concepts TS was merged into draft C++20. Yes, Concepts are back in the draft international standard and better than C++0x, which makes the famous concepts feature (principally driven by Bjarne Stroustrup, Gabriel Dos Reis, and Andrew Sutton) the first major language feature voted into draft C++20. Recall that Concepts was published as a separate TS two years ago, and available in GCC; today we voted to adopt nearly of it, except only the “introducer syntax” and “terse/natural syntax” for now because that syntax still has a handful of remaining issues that don’t have consensus, but it’s close and Evolution also voted unanimously to aggressively pursue adding the terse syntax as soon as possible once those design questions can be addressed. A few specific Concepts changes were also approved along with the merge, notably removing the need to write “bool” and removing function concepts until we see a need to overload concepts.
Here are some other features that were added to C++20 at this meeting. Note: These links currently find the most recent pre-meeting papers and so may not reflect the exact wording adopted at the meeting, but the links will light up to the post-meeting versions of the papers that were actually adopted as soon as those are available in the post-meeting mailing about three weeks from now.
- Allow lambda capture [=, this]. Mostly a style issue, but it extends the legal syntax for C++17’s capture of “this” so that programmers can write this stylistically if they want to be explicit in their code.
- Add designated initializers. Draft C++20 now allows code like: struct A { int x; int y; int z; }; A b{.x = 1, .z = 2};
- Allow template parameter lists on lambdas. For example: auto f = []<typename T>(std::vector<T> vector) { /*…*/ };
One TS sent for its ISO ballot, three TSes completed to be published
We also spent quite a bit of the week working on three TSes that completed their review ballots, and sending out one more: The Modules TS is sent out for its comment and approval (PDTS) ballot. And the Coroutines TS, Networking TS, and Ranges TS are all done, as the groups worked hard to process and address all the comments from their ballots and we are sending them out for final publication. – It’s not every meeting that we publish three specifications! Some of them would have been handled at our last meeting, but we were busy finishing C++17 so they stacked up for this meeting.
Thank you very much again to all the volunteers who helped progress our proposals, send out our PDTSes, address our ballot comments and publish three (3) TSes, and get the C++20 cycle off to a roaring start.
Other progress
We considered merging one other published TS, the Concurrency TS. The feeling was that its three major features were in different stages of readiness, and some are advancing toward bring merged into C++20, possibly at our next meeting:
- atomic_shared_ptr<T> is on track to be merged into C++20 with changes, in detailed standardese wording review and expected to be put up for approval at our next meeting. Interestingly, some of the changes are to make it more like the original design I proposed, including to name it atomic<shared_ptr<T>>.
- Latches are also approved, essentially as-is, and the feature is in wording review for the next meeting.
- Barriers are also potentially on track for C++20 but SG1 is still discussing open design problems. Its design can be expected to change substantially from the TS version.
- Some minor pieces of the future extensions are moving ahead, but the extension has several unresolved design issues including to coordinate with the (we hope soon-coming) executors design.
Other items making progress for possible consideration to be adopted in the fall meeting:
- The first part of compile-time reflection is in wording review.
- The library groups are starting to remove deprecated features.
The Library Evolution group has started discussing at how to integrate modules and contracts into the standard library. They expect to start integrating concepts next meeting, which is a big benefit of getting a major feature merged early in the C++20 cycle. They are also actively working on Unicode support, several new containers, and a date library, among other things.
We also continued incubating other work. In particular, the Reflection study group had presentations, and gave direction and feedback, on a few additions to the static reflection proposal that is already progressing in the main subgroups, the compile-time programming proposal, and my new metaclasses paper. (I’ll post a separate report on the metaclasses part soon, probably in the next week or so, with a link to the ACCU video.)
What’s next
In my trip report last fall, two meetings ago, I wrote: “Then, once C++17 ships next year and possibly as soon as our July meeting, I expect we’ll start looking at merging more of the TS ‘beta branches’ into the C++ ‘trunk.’”
Well, that’s exactly what happened: We did finish C++17 at the next meeting, and now at the meeting after that we did merge our first major TS into the C++ trunk.
Here’s an updated snapshot of our status (the latest is always on the isocpp.org/std/status page):
Thank you again to the 120 experts in Toronto this week, and the many more who participate in standardization through their national bodies! Have a good summer – and see you at CppCon!
Sutter’s Mill 
@Jere: The syntax of designated initializers is consistent with C. There would have to be *overwhelming* advantages for the committee to go with some other syntax. (Using the same syntax as C means a) less work for compiler writers; b) headers that are shared between C and C++ can use the feature.
On named arguments, Bjarne Stroustrup has always been opposed to named arguments (on the grounds that they encourage over-long argument lists). See Design and Evolution of C++. Obviously he isn’t a Benevolent Dictator for Life, but his opinion *does* still have weight.
I like the idea (maybe not the syntax) of the designated initializers. It’s one step closer to what Ada refers to as Named Association which is extremely powerful in making designs appear more clean. Using the dot before might be an easy to miss (and spot) mistype.
I hope one day that C++ (and C) could get something analogous to Named Association. Right now in both, if you default all or most of the parameters, if the user wants to change just one of the defaults, they have to specify all the defaults up to that one. With named association, that is no longer the case:
//imagine this with lots more than just 3 defaulted parameters
void SetupSomeMicroTimer(period_t p = ONE_SECOND, bit_mode_t m=MODE_32_BIT, callback_t * c=null);
//not C or C++ code
SetupSomeMicroTimer( c => &MyTimerCallback ); //or whatever syntax. Here, both p and m are still defaulted
The nice thing here is that it doesn’t break any old code since “not using” named association uses the existing rules, but now new code can look cleaner and be easier to use (especially if you are using a poorly documented 3rd party library and you are hesitant about specifying some of the other parameters outside of the one you want to change).
The same would apply to object initialization:
Is the Modules TS still abusing ‘export’ instead of extending private/public keywords to module-level?
Partly related to that, does it include any solution for the current dllexport macro hell? ‘export’ would be a nice keyword for that purpose.
Thank you for the report; and for the effort to get C++ better.
It is not the responsibility of the committee, of course, but: Now that the C++17 standard is finished: the major books on C++ really need to be brought up-to-date. In particular the more specialized / advanced books. A landmark of consolidated oversight in this increasingly fluid programming language would be very much appreciated.
God – The 2D graphics package is simply getting delayed forever. Please make it quick standard :)
Thanks
Nothing unicode on the horizon? Nice immutable utf8 and utf16 strings?
@Raphaël “You have dots in front of member identifiers. Would that break something to not have them ?”
1) That would make the feature incompatible with the C equivalent.
2) It would create parsing issues. Remember: “x = 1” is an expression in C and C++. So if the compiler sees that, it doesn’t know if that’s a designated initializer for a member or an expression whose result should use non-designated initializer rules. Having a dot there disambiguates the code.
@Bender: “your code example is ugly, I would just skip the naming rather than using that ugly code.”
In what way? In the vast majority of code, you don’t need to name the parameters of the function you’re calling. Usually, what those parameters are is obvious locally from variable names, types, the function name, etc. So named parameters is a feature you only need rarely.
So rather than getting a dedicated “named parameter” feature, we get a general feature that can be used for named parameters, but is slightly more inconvenient to use.
How ugly using braces is is of course in the eyes of the beholder. To me, it’s not that bad. And it makes it clear that I’m invoking a “named parameter” call, rather than just a regular function call.
@jmckesson
your code example is ugly, I would just skip the naming rather than using that ugly code.
(as a person writing a class, I would understand if some heavily used libraries would want to use that hack to enable users nicer experience).
Hello,
Concerning the “designated initializers”. You have dots in front of member identifiers. Would that break something to not have them ?
struct A { int x; int y; int z; }; A b{x = 1, z = 2};
@tambre: You can find the latest hi-res chart at isocpp.org/std/status. I’ve updated the post with links.
@jmckesson: Concepts did also change in two ways: removing “bool” and having only variable concepts. We’re not sure we need the capability of overloading concepts, which is the main benefit of function concepts provide, so we’ll hold those back until we have use cases and then we can always add them again. I’ve updated the post.
@Bender: “One should be able to do this for class constructor also (where x, y , z are constructor arguments).”
No. Constructors are just functions. If you can call constructors with named arguments, then you should be able to call functions with named arguments.
Fortunately, designated initializers are good enough to serve this purpose:
struct constructor_params { int x, float y, std::string z }; //Aggregate
class type
{
public:
type(constructor_params cp); //Access parameters as cp.x and so forth.
};
type value{.x = 5, .y = 10.4f, .z = “foo”};
Meh, comments do not like shift operator, what last part of my comment is saying that instead of using stram operator for std::forward you could use it for terse constructor syntax.
“Add designated initializers. Draft C++20 now allows code like: struct A { int x; int y; int z; }; A b{.x = 1, .z = 2};”
One should be able to do this for class constructor also (where x, y , z are constructor arguments).
Also one should be able to write class constructor/initializer list that matches the members of a class in a more terse way than MyClass::MyClass(int x, int y, int z): x(x) ,y(y), z(z){ cout <> for that abomination std::forward do this
MyClass::MyClass(>> x, >> y, >> z):{cout << x}
> except only the “introducer syntax” and “terse/natural syntax”
What about the other concepts issues? Do we still have to use `concept bool`, or is `concept` enough? Are there still function and variable concepts, or are concepts just variables, or are they their own thing now? Were there *any* substantive changes to the nature of concepts, or did they just do a copy/paste of Concepts TS into the standard (minus those two points)?
Is there a higher-resolution graph available of the current status? Kinda hard to read at such a small size.