Feeds:
Posts
Comments

Archive for the ‘Uncategorized’ Category

On Saturday November 10, the ISO C++ committee completed its fall meeting in San Diego, California, USA, hosted with thanks by Qualcomm. This was the biggest ISO C++ meeting in our 29-year history, with some 180 people at the meeting, representing 12 nations. For more details about our size increase, including how we adapted organizationally to handle the load, see my “pre-trip report” posted before the meeting began.

Because this is one of the last meetings for adding features to C++20, we gave priority to proposals that might make C++20, and we adopted a number of them for C++20. Thank you to all of the hundreds of people who participate in ISO C++, those who came to the meeting and still more who participated electronically, and who all helped with the design refinement and specification wording and organization. I want to at least try to recognize by name many of the authors of the proposals we adopted, but nobody succeeds with a proposal on their own. C++ is a team effort – this wouldn’t be possible without all of your help. So, thank you, and apologies for not being able to acknowledge everyone by name.

Notes:

  • Some of the links below are to papers that will not be published until the post-meeting mailing at the end of this month, and so the links will become public at that time.
  • For more details, see also the Reddit trip report.
  • You can find a brief summary of ISO procedures here.

Prelude: Focus

The committee is actively working to keep coherence and direction in the face of a tsunami of proposals and a huge number of enthusiastic people. Perhaps the most impactful record-setting number was the size of the pre-meeting mailing: 274 papers. For comparison, even excluding the biggest paper which was the updated C++ standard working draft which appears in every mailing, the pre-meeting mailing was enormous:

  • By word count, it exceeded Shakespeare’s complete published works.
  • By paper count, it exceeded the previous pre-meeting papers record by about 65%, and started to approach the total number of technical papers to produce the first C++ standard (total of pre-meeting mailings from 1990-1997).

We appreciate all the input, including that many of the papers are about bug fixes (always welcome) and rounding out existing features. However, a large number were proposals for new “good” features. And the trouble is that we can’t say yes to every feature that is “good” that benefits some users; we have to decide on a focused set, of at least coordinated features and ideally of general composable features, that fulfills the aim and mission of C++ and keeps the language adoptable and usable.

As I reminded in my pre-trip report, focus means saying no more often, and so we’ve taken several steps in recent meetings and at this meeting:

  • About a year ago, we created the Direction Group (Bjarne Stroustrup, Daveed Vandevoorde, Michael Wong, Howard Hinnant, Roger Orr, and the recently retired Beman Dawes) which has created and maintains an advisory document Direction for ISO C++ (P0939).
  • In 2018, Pearson Education made free electronic copies of The Design and Evolution of C++ (Bjarne Stroustrup) available to all committee members. Not only does this help ensure that the newer people have access to this expected-to-be-read foundational work, which continues to be very current, but also having it in machine-readable and -searchable form makes it much easier to reference and quote from in our own papers.
  • At this meeting, we let EWG and LEWG continue to focus on near-term papers, and created SG17 (EWG Incubator, JF Bastien) and SG18 LEWG Incubator (Bryce Adelstein Lelbach) to help review and improve the papers that EWG and LEWG could not handle, to improve them and to prune them before they reach the main subgroup. Thank you to JF and Bryce for being willing to chair these new groups!

Two major features adopted for C++20: Ranges, and Concepts convenience notation

Ranges (Eric Niebler, Casey Carter, Christopher Di Bella) was adopted for C++20. This was a tremendous amount of work by Casey Carter in particular (witness the recurring 3:00am editing update emails during the week). As Eric Niebler put it: “If you liked the Ranges TS, you’ll love C++20.”

Concepts “convenience” notation for constrained templates (Ville Voutilainen, Thomas Köppe, Andrew Sutton, Herb Sutter, Gabriel Dos Reis, Bjarne Stroustrup, Jason Merrill, Hubert Tong, Eric Niebler, Casey Carter, Tom Honermann, Erich Keane, Walter E. Brown, Michael Spertus) passed unanimously on Saturday. I highlighted this paper as a “we may have a winner here” in my last trip report, and indeed it sailed through and was adopted for C++20. Recall that we already added the concepts core feature to C++20 back in 2017, but without the convenience notation to write templates without the “template” or “requires” keywords; at this meeting we finally converged on a convenience syntax to write constrained templates that both addressed all the major problems people had identified in the Concepts TS convenience notation design, and was also acceptable to the primary concepts designers (hence the long list of coauthors). For the first time, besides the special case of generic lambdas, C++ will now let you write lots of generic functions without “template” or angle brackets, and that are concept-constrained and therefore much easier to use correctly than function templates have ever been before.

More constexpr adopted for C++20: Ongoing concerted push toward general compile-time programming

In the first part of my CppCon 2017 talk, I emphasized that C++ is serious about first-class compile-time programming. That is a general theme to current C++ evolution, and is particularly important for being able to make effective use of compile-time reflection, and for building on that further in the future for compile-time code generation such as my metaclasses proposal relies upon.

First-class compile-time programming in C++ has been building since we allowed simple one-liner constexpr functions in C++11, to constexpr functions with loops in C++14, to constexpr lambdas and “if constexpr” in C++17. This week, we have added still more as a coordinated set of additions to C++20:

We’re on track to making most “normal” C++ code available to run at compile time — and although C++20 won’t get quite all the way there, C++20 is a landmark release and a turning point where start to permanently leave behind the angle brackets and workarounds we’ve been using since the 1990s, with the near-complete birth of fully “natural” compile-time C++ code. Recall that we have already been adding support for user-defined types as template parameter types; soon (either before or after C++20’s feature freeze) we may be able to use strings as template arguments, and use containers like std::vector in compile-time code. Of course, there likely will be some limits; for example, supporting compile-time std::thread is possible, but less likely to be worth the effort.

Looking ahead to C++23 for a moment, where we expect still more of that plus (we hope) full static reflection in the standard, this marks a difficult-to-overstate landmark shift in C++ programming — not a course change, but really taking all the things that programmers have already been trying to do indirectly and giving it first-class natural support. The long-term results are likely to exceed our expectations in ways that we can’t fully anticipate yet. So fasten your seat belts, and stay tuned. C++ programming is likely to evolve more, and in better ways, in the upcoming 5 years than it already has in the past 20.

Other changes approved for C++20

A number of other smaller changes were adopted as well.

Other progress and decisions

Modules (Richard Smith; and Gabriel Dos Reis) for the first time had a unified design approved targeting C++20. Wording specification work will continue over the holidays, and we expect to consider modules for C++20 at our next meeting in February.

Executors: Thanks to progress between meetings and special meeting in September, we now are hopeful that an initial Executors design can make it for C++20. The feature was not merged at this meeting, but the design was approved for C++20 and we expect to consider adding the wording specification to C++20 at our next meeting.

Coroutines: We continued to make progress on coroutines. At this meeting, EWG again recommended merging the Coroutines TS (Gor Nishanov) into C++20, and this time EWG additionally explicitly included plans to incorporate features from the competing Core Coroutines proposal (Geoff Romer, James Dennett, Chandler Carruth). As in Rapperswil, the vote to merge the Coroutines TS into C++20 fell just short numerically and was not adopted for C++20 at this meeting. The proposers, and new collaborators from Facebook and other companies, will continue to work on improving consensus over the winter by addressing remaining concerns, including doing further work to merge features from Core Coroutines into the TS approach, such as an upcoming paper “A unifying design for Executors, Sender/Receiver, coroutines, parallel algorithms and networking” by Lewis Baker of Facebook which is expected to appear in the post-meeting mailing. We expect coroutines to be proposed again for C++20 at our February meeting in Kona with this additional information, and with the national bodies having more time to absorb the large amount of new information that was presented at this meeting.

Networking: This depends on Executors, and despite some discussion about decoupling the non-Executor parts, at this meeting we decided to target merging Networking into C++ for soon post-C++20 (i.e., targeting C++23). It also might depend on Coroutines, because some experts are still working through whether there is integration work to be done to merge Networking with Coroutines.

Reflection TS v1 (David Sankel) ISO ballot continues: The Reflection TS international comment ballot was already in progress during the meeting and will conclude next month. As I mentioned in my last trip report, note again that the TS’s current template metaprogramming-based syntax is just a placeholder; the feedback being requested is on the core “guts” of the design, and the committee already knows it intends to replace the surface syntax with a simpler programming model that uses ordinary compile-time code and not <>-style metaprogramming. In San Diego, we began looking at a “next-generation” reflection proposal  P1240 (Andrew Sutton, Faisal Vali, Daveed Vandevoorde).

2D Graphics (Michael B. McLaughlin, Herb Sutter, Jason Zink, Guy Davidson, Michael Kazakov) sent back to SG13: The SG13 HMI (human-machine interface) study group was reopened with Roger Orr as chair and will be taking another look at next steps for the Graphics proposal in the coming months.

Upcoming new work: Machine learning and education

In addition to the two Incubator Study Groups I mentioned in my pre-trip report, we also formed two new domain-specific study groups:

SG19: Machine Learning (Michael Wong). We feel we can leverage C++’s strengths in generic programming, optimization and acceleration, as well as code portability, for the specific domain of Machine Learning. The aim of SG19 is to address and improve on C++’s ability to support fast iteration, better support for array, matrix, linear algebra, in memory passing of data for computation, scaling, and graphing, as well as optimization for graph programming.

SG20: Education (JC van Winkel). We feel we have an opportunity to improve the quality of C++ education, to help software developers correctly use our language and ecosystem to write correct, maintainable, and performing software. SG20 aims to create curriculum guidelines for various levels of expertise and application domains, and to stimulate WG21 paper writers to include advise on how to teach the new feature they are proposing to add to the standard.

Thank you to Michael and JC for volunteering as chairs!

What’s next

Whew! Here is a cheat-sheet summary of our current reasonable expectations for some of the major pieces of work. Note that this is an estimate only, and progress can end up being different than expected.

wg21-proposal-progress

And here is an updated snapshot of where we are on the schedule for C++20, which can always be found in paper P1000:

wg21-schedule

Thank you again to the approximately 180 experts who attended this meeting, and the many more who participate in standardization through their national bodies! Have a good winter… we look forward now to several interim telecons and potentially side meetings, and then our next regular WG21 meeting in February (Kona, HI, USA).

Read Full Post »

In one hour, our fall meeting will begin. I’ll still write a trip report at the end with the results of the meeting, but because this is an unusually (and historically) large meeting we’ve had to make a few adjustments.

This post is combined from a couple of administrative emails I sent to the committee over the past few weeks. Note that they’re written with that audience in mind, so they end with guidance about how to work effectively in the new subgroups, but I thought that others who follow C++ standardization would find them interesting and useful too.


New Study Groups: EWG Incubator and LEWG Incubator

As you may have noticed, we’ve been growing:

  • Record #people: 173 unique names known so far for San Diego.
  • Record #papers: 274 in pre-San Diego.

In the past we’ve had five main subgroups working during the week, but that doesn’t scale well to either the number of people (it’s not ideal to have ~170 in just five huge subgroups) or the number of papers (five subgroups will leave many papers unhandled). The following are some adjustments we’re making in order to scale organizationally.

Effective [October 19], we have formed two new Study Groups with the chairs shown below, both of which will meet in San Diego for three days each:

  • SG17 “EWG Incubator SG” (JF Bastien)
  • SG18 “LEWG Incubator SG” (Bryce Adelstein Lelbach)

Thank you very much to JF and Bryce for making themselves available to serve as chairs!

Notes:

  • The “(L)EWG Incubator” SGs are not additional (L)EWG groups, they are (like all SGs) a pipeline stage in front of EWG and LEWG respectively.
  • As advertised in our agenda, in San Diego (L)EWG will again prioritize C++20-targetable material first, and the Incubator SGs’ primary agendas will be to schedule those papers that are not likely to fit in the main (L)EWG groups. The chairs are coordinating their agendas. Please consult the daily agendas that will be maintained on the wiki to see what topics are scheduled for each session, so that you don’t miss your favorite topic.
  • Although SGs typically forward work to (L)EWG, they can as needed forward work to each other too if they believe the proposal needs domain expert input from that SG before entering (L)EWG. Papers that are primarily about a topic that is owned by an active topic-specific SG should still go to that SG; for example, all other SGs normally redirect any stray concurrency-related papers they receive to SG1 instead.
  • Like most SGs, we should expect the Incubator SGs will forward only a subset of what they receive to (L)EWG, sometimes after first asking for significant changes. As with all SGs, any papers that these SGs refine and forward need to pass through (L)EWG as usual, including to meet the IS ship deadlines described in P1000. As with all SGs[*], SG17 and SG18 never “pre-bless” proposals; if SG17/18 approves forwarding a proposal to (L)EWG, that just means it is ready to have an initial presentation in (L)EWG and begin its journey in those groups, not that it has any default positive standing in (L)EWG. There should never be an expectation of “well the SG blessed it, if we’d wanted to comment we should have been in the SG.”
    • [*] except for SG1 uniquely; proposals coming from SG1 do often have some advanced standing and trust because of SG1’s demonstrated expertise and history, but even SG1’s proposals get looked at by (L)EWG first and don’t skip (L)EWG entirely
  • The quantity of work that we process into the standard is still gated by CWG and LWG bandwidth. Therefore a major function of the Incubator SGs is act as a selection pipeline stage to turn higher input volume into higher average quality, and avoid the status quo default of papers backing up in front of EWG/LEWG/CWG/LWG.

We also have two expanded/reactivated Study Groups, both of which will meet in San Diego:

  • SG12 “UB, Undefined/Unspecifed Behavior” (Gabriel Dos Reis) is now regularly meeting for ~3 days, co-located again with our sister WG23 (Vulnerabilities) in San Diego. – So San Diego is again a combined WG21/WG23 meeting, not just WG21.
  • SG13 “HMI, I/O” (Roger Orr) is now reactivated to handle the Graphics proposal that does not currently have consensus to proceed in LEWG but has a critical mass of people actively interested in working on it, so it makes sense to reactivate the SG. Also, that proposal is actually a group of some 5-6 sub-proposals, so it will be up to SG13 to decide whether to incubate them as a group or individually, and then feed them to appropriate other subgroups for consideration when ready. Thank you to Roger for being willing to chair the group!

And we have a request for at least one new Study Group, though this will not be created until after San Diego:

  • Several companies have approached me to actively pursue work in Machine Learning. No concrete announcement yet, but I’m penciling in an ‘SG19 (chair tbd)’ for that.

So here’s an updated look at our current organization:

wg21-organization

The subgroups with heavy outlines are the ones that, starting in San Diego, will meet for multiple full days during our face-to-face meetings. You’ll notice there are now eight (8) of those, and so starting in San Diego our new standard meeting space requirement will be 8 concurrent breakout rooms (was previously 6, with the 6th shared among SGs and usually lightly utilized). Here’s a summary of the breakout tracks in San Diego (and of course we’ll have plenary first thing Monday and on Saturday – a few subgroups may choose to also meet a little longer on Saturday after plenary, as usual, and that will be announced on Saturday):

wg21-breakouts

(Insert your favorite “8-track” joke here, with de rigueur comment about C and C++ starting in the 1970s.)

Perspective: Our history and trajectory

I counted the #attendees (solid) and #papers (dashed) all the way back to my personal first meeting in July 1997. Here is the resulting graph.*

wg21-graph

Please go look at the quaint 1997 papers page, when we completed C++98 standardization. Fun facts:

  • The highest paper number was N1148. So we had 1148 papers in the entire 8-year cycle to produce C++98.
  • Pre- and post-meeting mailings were typically of a similar size. So we had ~600 pre-meeting papers in the entire 8-year cycle to produce C++98.
  • Many of those were issues lists, a higher proportion than today. And the technical papers were typically shorter than today’s.

So our San Diego technical paper volume is within a close order of all the technical papers to produce C++98. And, as already noted, it’s more than Shakespeare’s lifetime published word count, even excluding the C++ working paper.

Also in 1997, two months before the first meeting shown in the above graph, there was a famous Q&A session at WWDC that included the following quote:

So we had to decide what are the fundamental directions we’re going in and what makes sense and what doesn’t. There were a bunch of things that didn’t, and microcosmically they might have made sense but macrocosmically they made no sense…

Focus is about saying no, and the result of that focus is going to be some really great products where the total is much greater than the sum of the parts.

— Some Guy, 1997  (and Bjarne Stroustrup, 2018, paraphrasing)

What does “focus means saying no” mean to WG21?

We are a standards committee, not a design team. A design team can assign work (because it has employees), can make decisions without democratic vote (because it has a hopefully-benevolent dictator), and can just refuse to listen to ideas. A standards committee isn’t like that: In WG21, we are volunteers and we always review as many papers as we can (of course we assume the author/champion is present etc., see SD-4). For us, “saying no” doesn’t mean ignoring by fiat, it means deciding as a group to decline to go in that direction after first listening to it.

The way I think of this mailing’s papers is in five “buckets”, illustrated here:

wg21-focus.png

Yes, I can count. There’s a bucket 0 that’s not on the slide:

0. Thank you for your papers that used to be missing! In the past we’ve sometime had presentations and reflector mails without papers – aka “please write a paper,” and you did. Thank you for those.

1. Thank you for your bug-fix papers! We appreciate the many eyes to help our standard be better. We expect to take most of these (modulo agreeing on the right fix).

2. Thank you for your papers to improve an existing feature! We appreciate ways to remove limitations on our features (e.g., enable move-capture for lambdas). We expect to take some percentage of these (modulo agreeing on the right improvement).

3. Thank you for your new overlapping feature ideas! Sometimes there is a group of related narrower features where there is a lovable general feature struggling to hatch. We will try to merge-via-generalization N features into 1 general feature that can be orthogonal and composable with the rest of the language and library. Note that this frequently takes a number of meetings. Also, ideally it results in the ability to deprecate existing features by replacement-via-generalization (think how “using” subsumed “typedef”).

4. Thank you for still more new solo feature ideas! We will consider all of them, but for we expect to have a high bar for language proposals and require that they are composable with the rest of the language and clearly aligned with (a step in the direction of) where we want C++ to go in the next 10-30 years. And, over time, expect to see fewer of them, and to have them increasingly make existing features redundant (deprecate existing features by replacement-via-generalization, again).

Both #3’s merging and #4’s filtering procedures are aiming at the same goal: Producing a strong proposal that solves more than one problem.

What you can do (message to new subgroup participants)

Especially in #3 and #4, it’s unavoidable that the Incubator SGs will break hearts by saying “no.” So, please keep in mind the following tips.

When you are an Incubator SG participant, you will participate in polls that break hearts – so be kind, and especially watch for features that are #3’s (related to others and potentially generalizable) or look for ways to help them become #3’s (invite specific overlapping proposals that may not exist yet, to help complement and round out this proposal into something general), don’t just assume they’re #4’s (facing a difficult bar as a partly-fledged solo feature).

When you are an Incubator SG presenter, be prepared that not everyone may love your feature as much as you do, at least at first – but find ways to frame, and to evolve, your proposal to make it #3 instead of #4, especially by finding like-minded proposers of similar features that you can together turn into a #3 feature group and refine/complete/integrate together. Because it’ll be easier to succeed in #3 than in #4.

In general, we encourage all participants to consult:

  • P0939, the Direction Group’s suggestions – people are not expected to necessarily agree with every part but we should be open to the well-informed advice therein.
  • D&E, which is available for free to committee members – contact Bjarne to get a copy.

Although we can’t read all the mailing, we can read these two items.

 

Thank you to everyone, especially to the new subgroup chairs and the existing officers and chairs and upcoming meeting hosts, who have worked very hard at short notice, especially over the past few weeks, to help organize for our current growth.

Read Full Post »

My Thursday talk is now online. Thanks to Mark Bashian and his wonderful team at Bash Films for posting the plenary sessions so quickly… it was great to see each keynote posted the following morning, and the rest of the CppCon 2018 videos will be posted in the next few weeks as usual.

Thanks again to everyone who came! It was a great conference, and we are already looking forward to next year’s CppCon in our new location in Denver, CO, USA.

Read Full Post »

I love C++. I also love safe code and not having to worry about dangling pointers and iterators and views. So I’ve been doing some work to make my life less conflicted: As long promised, the Lifetime profile 1.0 paper is now posted in the C++ Core Guidelines repo. It aims to detect common local cases of dangling pointers/iterators/string_views/spans/etc. in C++ code, at compile time, efficiently enough to run during normal compilation and in IDE tooltips. And, best of all (IMO), leveraging the rich information that’s already in typical modern C++ code, especially code that uses RAII and STL, with little or no annotation (e.g., see section 2.6).

For a quick summary, section 1.1 is a readable 3-page overview. Or, if you prefer watching a talk video, you can also see my CppCon 2015 talk starting at 29:06, where I first talked about this work; the approach is still the same. I’ll also be giving an update on this work next week at CppCon as one of the three major sections of my talk this year.

Many thanks to all of the people who contributed and gave feedback to help me flesh out this design over the past three years. I would like to especially thank Neil MacIntosh and Kyle Reed who did the bulk of the MSVC static analysis extension implementation work, and Matthias Gehre and Gábor Horváth who did the Clang-based implementation. Thank you! Those of you who’ll be at CppCon will see some of these folks on-stage showing their work in my talk, and be able to ask them questions at the conference.

… Did I say Clang? Yes, there’s now also a Clang-based implementation in addition to MSVC. Although I stress this work is still somewhat experimental and that both are partial implementations, both of them do already compile most of the examples in the paper and both already run efficiently enough to run during normal compilation (Clang) and in the IDE for live-squiggle diagnostics (MSVC) even though they have not been optimized yet. And, as you’d expect in 2018, the Clang-based implementation is available on Godbolt — in the paper, just search for “godbolt” to find over 30 links to live examples. Here are a few you might find interesting:

  • godbolt.org/z/szJjnH A simple starter dangling raw pointer example.
  • godbolt.org/z/_midIP This one’s simple but fun… quick, how is the pointer use on line 11 invalidated by the following line, line 12?
  • godbolt.org/z/dymV_C From C++17: A dangling string_view, which is important because it turns out to be easy to convert a std::string to a string_view, so that dangling is almost the default behavior.
  • godbolt.org/z/eqCRLx From the very latest bleeding edge: A dangling filter_view from the Ranges TS that we’re about to see if we can merge into the standard in time for C++20. Those are non-owning indirections, so they can dangle too.
  • godbolt.org/z/iq5Qja From C++98 with a dash of C++11: You know how using auto to deduce a vector<bool> subscript [] operator actually captures a vector<bool>::reference proxy, which can dangle after a push_back or reserve? If you didn’t: Sorry to be the bearer of sad tidings, but here’s some good news about that example.
  • godbolt.org/z/UE-Mb0 This short example can take a few minutes to grok… take a cup of coffee to understand who owns what and points where, and why the pointers are dangling (or not), and what the compiler is understanding about our code in order to be able to tell us about the problems accurately.

If you’re interested in preventing common cases of dangling pointers, iterators, string_views, spans, and more, efficiently at compile time with high quality diagnostics, check out the examples in the paper and play around with them on Godbolt.

If you find new examples that are correctly diagnosed that you think are particularly cool, feel free to distill them down to their essence (and sanitize them if they came from real code) and post them as new Godbolt links in the comments below — bonus points if you also briefly summarize what the problem is, and extra bonus points if they did come from real world code. I may add some of them to the paper, with attribution, and maybe even use one in next week’s talk.

Read Full Post »

In just 10 days, we’ll be at CppCon! I can hardly wait for Bjarne’s new opening keynote and the 100+ other sessions… we have a really great lineup of speakers again this year.

I’ll be giving a talk as well, and here’s the title and abstract for what I’ll be covering this year. I hope to see many of you in sunny Bellevue, WA, USA soon.

 

Thoughts on a more powerful and simpler C++ (5 of N)

Perhaps the most important thing we can do for C++ at this point in its evolution is to make sure we preserve its core strengths while also directing its evolution in ways that make it simpler to use. That is my own opinion at least, and so this talk starts with a perspective question: What “is C++,” really? The language continues to evolve and change; as it does so, how can we be sure we’re picking C++ evolutionary improvements that not only don’t lose its “C++-ic” qualities, but make it a better C++ than ever?

At recent CppCons, I’ve spoken about several of my own personal C++ evolution efforts and experiments, and why I think they’re potentially important directions to explore for making C++ both more powerful and also simpler to use. The bulk of the talk is updates on two of these:

Lifetime and dangling. At CppCon 2015, Bjarne Stroustrup and I launched The C++ Core Guidelines in our plenary talks. In my part starting at 29:06, I gave an early look at my work on the Guidelines “Lifetime” profile, an approach for diagnosing many common cases of pointer/iterator dangling at compile time, with demos in an early MSVC-based prototype. For this year’s CppCon, I’ll cover what’s new, including:

  • use-after-move diagnoses
  • better support for the standard library out of the box without annotation
  • more complete implementations in two compilers: in MSVC as a static analysis extension, and in a Clang-based implementation that is efficient enough to run during normal compilation
  • the complete 1.0 Lifetime specification being released on the Guidelines’ GitHub repo this month

I’ll summarize the highlights but focus on what’s new, so I recommend rewatching that talk video as a refresher for background for this year’s session.

Metaclasses. In my CppCon 2017 talk, I gave an early look at my “metaclasses” proposal to use compile-time reflection and compile-time generation to make authoring classes both more powerful and also simpler. In this case, “simpler” means not only eliminating a lot of tedious boilerplate, but also eliminating many common sources of errors and bugs. For this year, we’ll cover what’s new, including:

  • an update on the Clang-based implementation, which now supports more use cases including function parameter lists
  • new examples, including from domains like concurrency
  • an updated P0707 paper, with more links to working examples live on Godbolt, being posted in the next few weeks for the pre-San Diego committee mailing

 

Read Full Post »

[Edited to add C++20 schedule at end]

On Saturday March 17, the ISO C++ committee completed its winter meeting in Jacksonville, Florida, USA, hosted with thanks by the Standard C++ Foundation and Perennial. We had some 140 people at the meeting, representing 8 national bodies. As usual, we met for six days Monday through Saturday, including all evenings.

A special highlight was on Thursday evening (the only non-officially-working evening) when Bjarne Stroustrup personally hosted the entire committee for a celebratory dinner to share the 2018 Charles Stark Draper Prize, the U.S.’s top engineering honor, which this year was awarded for a programming language for only the second time in its history. Although the prize was awarded to Bjarne personally, he made it clear that he considered this an award for the whole C++ community, without whom C++ would never have been successful, and so he hosted the dinner for the committee as a representative proxy for the entire worldwide C++ community. — So to all C++ programmers and contributors who are reading this: Thank you, from Bjarne and from us, for your support, and consider yourselves part of this year’s Draper Prize.

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.”

Leading up to this meeting

As I reported in my previous trip report for the fall meeting (Albuquerque 2017), last time we almost completed addressing the comments received from national bodies in the Modules comment ballot that ran last summer. The rest were addressed in a series of teleconferences between meetings, and the Modules TS was finalized and shipped to ISO at the end of January.

One of the highlights in the pre-meeting mailing was “Direction for ISO C++” (Beman Dawes, Howard Hinnant, Bjarne Stroustrup, Daveed Vandevoorde, Michael Wong). Although non-binding, it’s the first set of recommendations from our recently created advisory Direction Group, a small subgroup of respected long-time participants that currently consists of those paper authors and is chaired this year by Bjarne Stroustrup.

Features adopted for C++20

We adopted several new features into the draft standard.

[[no_unique_address]] (Richard Smith). You know the empty base optimization (EBO)? If you do, can you remember the (probably many) times you’ve artificially made another class a base of your class, instead of just a data member, just so you could get EBO? And, every time that happened, you wished C++ had the empty member optimization (let’s call it “EMO”)? In C++20, it does, and you opt in via [[no_unique_address]]. Here’s an example from the paper:

template<typename Key, typename Value,
         typename Hash, typename Pred, typename Allocator>
class hash_map {
  [[no_unique_address]] Hash hasher;         // EMOji
  [[no_unique_address]] Pred pred;           // EMOji
  [[no_unique_address]] Allocator alloc;     // EMOji
  Bucket *buckets;
  // ...
public:
  // ...
};

[[likely]] and [[unlikely]] (Clay Trychta). (The link is to R2 of the paper, which contains more description. The R4 version is the one that was adopted.) Many compilers already allow you to “hint” whether a branch is likely or unlikely to be true, which can help optimizations. This standardizes that. Here’s an example from the paper:

if (foo()) [[unlikely]] return false;
if (bar()) [[unlikely]] return false;
baz();

Major disclaimer: This feature comes with the same warning label as the existing compiler extensions, which is “measure, measure, measure!” Compilers already know which branches are likely, usually better than you do (especially with profile-guided optimization, aka PGO). A major reason to use this feature is not actually to optimize (though it can help if you don’t have PGO), but to control which path gets optimized for other reasons. For example, for some code it is essential to make the uncommon path faster so that it is faster when you do hit it — and in such cases you would actually use this attribute in the inverted sense, so please also write a comment nearby to document that intent otherwise some hapless reader (more than likely your future self) will be temporarily confused.

Extending <chrono> to calendars and time zones (Howard Hinnant, Tomasz Kamiński). This is a much-loved (and huger-than-you-think) library addition that will help a lot of users, and really exercises modern C++ features like user-defined literals.

span: Bounds-safe views for sequences of objects (Neil MacIntosh, Stephan T. Lavavej). This one comes directly from the C++ Core Guidelines’ Guideline Support Library (GSL), and is intended to be a replacement especially for unsafe C-style (pointer,length) parameter pairs. We expect to be used pervasively as a vocabulary type for function parameters in particular.

Cleanup adopted for C++20

We also made some improvements to existing features.

“Down with typename!” (Nina Ranns, Daveed Vandevoorde). Are you tired of writing typename redundantly in places where the compiler should know only a type was possible? So were the proposal authors. Now typename is required in fewer places.

Lambda capture initializers can now expand variadic parameter packs (Barry Revzin). An example, taken from the paper:

template<class F, class... Args>
auto delay_invoke(F f, Args... args) {
    return [f=std::move(f), ...args=std::move(args)]() -> decltype(auto) {
        return std::invoke(f, args...);
    };
}

The now-allowed expansion is the one in the third line.

Consistent begin/end for range-for (Ville Voutilainen). The range-based for loop is already customizable, and can handle ranges that have both member rng.begin()/rng.end() functions or ones that have non-member begin(rng)/end(rng) functions. But what if it relies on the non-member functions, but happens to also have one member named either begin or end (such as, say, end in ios_base)? That’s now legal, we ignore the one-off member and use the non-member pair. Here’s an example from the paper that is not legal in C++17 but now works in C++20:

struct X : std::stringstream { /*...*/ };

std::istream_iterator<char> begin(X& x)
  { return std::istream_iterator<char>(x); }

std::istream_iterator<char> end(X& x)
  { return std::istream_iterator<char>(); }

int main() {
    X x;
    for (auto&& i : x) {   // works in C++20
      // ...
    }
}

Interesting tidbit: This is one of those “new functionality” features created by removing wording in the standard, namely removing a restriction. The entire wording change was to change “either (or both) finds” to “both find” in one place.

Structured bindings can access accessible members (Timur Doumler). In C++17, you could use structured bindings to bind to class members as long as they were public. But what if you’re inside a member or friend of the class? Shouldn’t you be able to use structured bindings on members, which are visible (i.e., accessible) to you even if they aren’t public to everyone, just like we can do any other normal thing with those members? In C++17 that didn’t work, but it was an oversight and now we can do that:

class X {
    int i;
    int j;
public:
    friend void f();
};

void f() {
    X x;
    auto [myi, myj] = x;   // now ok
}

We also adopted some other fixes, including:

… and a few more including a couple of small extensions to coroutines and networking. Note that those two TSes were already published, and are not yet merged into the C++ draft standard, but we are still maintaining those experimental TS “branches” with fixes and updates, so that those will be done and ready once we are ready to merge those TS branches into the C++ “trunk” project itself.

Other major full committee approvals

We approved Parallelism TS 2 to be extended with the (huge) extensions in Data-parallel vector types and operations (Matthias Kretz) and declared it feature-complete: It is now being sent out for its main ISO comment ballot.

We also decided to officially open a Reflection TS work item, which means that the committee as a whole is taking ownership of the proposal and intends to progress it as a TS. The initial content is from the paper “Static reflection” (Matúš Chochlík, Axel Naumann, David Sankel) but everyone should understand that the surface syntax will change. The primary point of the TS is in the underlying “engine” and functionality, and the intention is to replace the placeholder template-metaprogramming-like reflexpr syntax with an object-like model that looks like “more constexpr code” — regular C++ code that is able to be run at compile time.

Language/library evolution subgroup approvals

Here is a list of proposals that achieved Evolution or Library Evolution working group (EWG or LEWG) design approval. This means that the subgroup responsible for approving the design has done so (sometimes provisionally, with a few “revision is expected” notes below), and the next step is that they now enter wording review in the Core or Library working group (CWG or LWG), and are slated to be proposed for formal adoption in C++20 at a future meeting. Thanks to Olivier Giroux, Ville Voutilainen, Titus Winters for their notes that contributed to this summary.

For contracts, EWG discussed a clarification to what the result of observable side-effects in contract pre/post-conditions is, and the guidance is that it’s undefined behavior.

For reflection and related facilities, EWG approved some papers that are significant milestones for compile-time programming:

EWG also approved:

We also decided to pursue putting in writing two statements about how we evolve C++:

  • EWG decided to pursue turning “C++ Stability, Velocity, and Deployment Plans” (Titus Winters) into a Standing Document, with the expectation is that the document will be revised and reviewed again. Titus Winters will be the main author, and Gabriel Dos Reis, Bjarne Stroustrup, and Mike Spertus will assist.
  • EWG also supports turning “Standard library compatibility promises” (Titus Winters) into a Standing Document, and to add the promises also to the standard’s own Library Introduction clause. Titus Winters will be the main author, with help from Ashley Hedberg, Nevin Liber, Bjarne Stroustrup, James Dennett, Walter E. Brown, Gor Nishanov, Alisdair Meredith, Mike Spertus, Robert Steagall and Daveed Vandevoorde.

We decided to launch a systematic effort to drive out the remaining uses of macros by providing replacements for those uses. We requested an analysis paper listing all the remaining use cases for macros are, a description of the status of the non-macro solutions for those problems, and possible solutions. This paper will be led by Ville Voutilainen, assisted by Bjarne Stroustrup, Gabriel Dos Reis, James Dennett, and Vittorio Romeo.

Somewhat stunningly (to me), we decided to pursue some cleanup to the C fundamental types that would be a breaking change to certain kinds of C and C++17 code. It came up via the discussion of “Towards consistency between <=> and other comparison operators” (Richard Smith), which observed that when we added <=> to C++20, in <=> only we deliberately decided not to repeat the well-known issues that we did not want to perpetuate with C’s two-way comparisons for fundamental types (e.g., signed-unsigned comparison surprises like -1 < 0u giving the “wrong” answer)… which naturally meant that we now have inconsistencies between the preexisting two-way comparison operators and the shiny new three-way <=> operator. When faced with this, the subgroup discovered that we had a consensus in the room that enough really was enough, and we decided to seriously investigate doing some housecleaning and fix those things even though that would include breaking changes to (mostly ill-behaved) C and C++17 code. For example, we are now on a path to pursue deprecating or outright removing the ability to compare two unrelated enumerations (which is just plain suspicious code), and to require -1 < 0u to give the mathematically correct answer even when in the worst case that means generating two comparison machine instructions instead of just one (any code that does such ill-advised things would change from being a correctness problem into “just” a one-extra-instruction performance problem). — We have made no decisions about actually doing this or the ship vehicle for such changes, which likely would have to be rolled out in stages via deprecation followed by removel, and we expect more data to be gathered before Rapperswil regarding how much code could be affected. But as far as I can recall, this is the most breaking-change cleanup to C’s fundamental types that we have ever been willing to seriously consider.

LEWG approved Standard library concepts (Casey Carter). This is the first part of the Ranges TS to be on track for merging into C++20 at an upcoming meeting, and contains the core concepts from the Ranges TS. It is also the first appearance of the concepts language feature in the standard library.

Other progress

Also for concepts, at this meeting EWG approved pursuing a direction based on my paper “Concepts in-place syntax” (Herb Sutter) to have a shorthand syntax for declaring constrained templates.

At this meeting, we considered further improvements to the modules design, including a renewed proposal focusing on a bridge to help existing header-based code move toward a modules-enabled world. By the end of the meeting, the main participants had hammered out a plan to, over the next few meetings:

  • move a core set of modules functionality into C++20 that is “clean” and uncompromised by legacy concerns; and
  • concurrently update the remaining modules TS with features specific to transitioning header-based code to modules, which might include support for macros.

There’s a lot of work remaining, but we’ll know in the next few meetings how the objectives are progressing.

After several years of incubation, executors are now making strong progress and are on track to become a TS in the C++20 timeframe. (Let me explicitly say “thread pools” for the benefit of those who are Ctrl-F’ing to find out how C++ intends to support modern thread pools such as in Windows 10 and Grand Central Dispatch. You’re now in the right place: Modern thread pool support is coming as part of executors.)

Note that there is a dependency on executors before we can merge the networking TS and the future.then feature in the concurrency TS into the C++ draft standard, which means that all of those features are likely to be merged early in the C++23 cycle rather than in C++20.

We are going to try to ship coroutines in C++20.

We are opening a new work item for Library Fundamentals TS3, the third batch of library additions, even as we will soon be starting to fold in material from the recently-published Library Fundamentals TS2 into C++20.

SG15 (Tooling) (Titus Winters) had its first meeting, and there is a shared belief that we need to take concrete steps toward enabling better support for tools for two things in particular: modules, and C++ library package managers. That coincided very nicely with the 2018-02 isocpp.org survey, where on the open-ended question 10, the #1 write-in answer was to request “dependencies / package manager” (15% of all write-ins mentioned that). Clearly there is interest in this area, and it will be interesting to see how this develops into proposals over the coming meetings.

We also created a new study group SG16 (Unicode) with Tom Honermann as the SG chair.

What’s next

Whew! Here is a cheat-sheet summary of our current expectations for some of the major pieces of work that are not already in draft C++20. Note that this is an estimate only.

cpp11147020 - 201803

And here is an updated snapshot of where we are on the timeline for C++20 and the TSes that are completed, in flight, or expected to begin:

wg21-timeline-2018-03.png

Finally, here is the schedule for the C++20 cycle approved by unanimous consent at this meeting:

wg21-schedule-2018-03

Thank you again to the approximately 140 experts who attended this meeting, and the many more who participate in standardization through their national bodies! Have a good spring… we look forward now to our next meetings in June (Rapperswil, Switzerland) and November (San Diego, CA, USA).

Read Full Post »

A few minutes ago, the ISO C++ committee completed its fall meeting in Albuquerque, New Mexico, USA, hosted with our thanks by Sandia National Laboratories. We had some 140 people at the meeting, representing 10 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.”

Modules TS ballot comments: Almost done

A primary goal of the meeting was to address the comments received from national bodies in the Modules TS’s comment ballot that ran this summer. We managed to address them all in one meeting, as well as deal with most of the specification wording issues discovered in the process of responding to the national comments; we discovered one or two areas where the TS wording did not quite match the approved design intent, and so the plan is to finish addressing those and to approve the Modules TS for publication in between meetings via a teleconference, rather than wait for our next face to face meeting in March.

It will be great to get the TS published, and continue getting experience with implementations now in progress, at various stages, in all of Visual C++, Clang, and gcc as we let the ink dry and hammer out some remaining design issues, before starting to consider adopting modules into the C++ draft standard itself. I do not know whether modules will make the feature cutoff for C++20, but a lot of people are working hard to maximize the chances… we’ll know in another 12-18 months when we reach the C++20 feature cutoff.

Second meeting for C++20

This was also the second meeting where we could vote changes into Draft C++20. And we did!

Here are some of the 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.

Range-based for statements with initializer (Thomas Köppe). In C++17, we already allowed initialization of if-scoped and switch-scoped variables, just like the ordinary for loop has already had for years. Today, we added the same for the range-based for loop, which gives the same benefit: It enables and encourages locally scoped variables without the programmer having to introduce a scope manually. To take an example from the paper, in C++17 we might write the following to get a variable thing that exists just as long as is needed for the for loop, which avoids a bad pitfall (do you see why the “WRONG” comment is wrong? it might work depending on what f() returns, or it might be undefined behavior):

{
  T thing = f();
  for (auto& x : thing.items()) {
    // Note: “for (auto& x : f().items())” is WRONG
    mutate(&x);
    log(x);
  }
}

and now in draft C++20 we can write the recommended local scoping directly with less ceremony of { } and indenting, and follow the C++ Core Guidelines scoping recommendations now also for range-for, as just:

for (T thing = f(); auto& x : thing.items()) {
  mutate(&x);
  log(x);
}

Bit-casting object representations (JF Bastien). This proposal gives a way to copy the bits of an object in a consistent and simple manner. It adds the new header <bit>, and provides bit_cast for trivially-copyable “bag-o-bits” objects, to easily copy the bits of any such object to another of the same size (the types need not be the same). Note: Yes, we already have memcpy, but bit_cast is safer and also can run at compile time.

Lots of other cleanup. We did various smaller features and cleanup, sometimes to fix bugs, sometimes to improve consistency and generality, and sometimes to make the language a little simpler to use.

  • Example of bug fixes: Draft C++20 sets forth more precisely where constexpr functions are defined (core issue 1581).
  • Examples of consistency and generality: Draft C++20 now supports concepts requires-clauses in more places including lambdas (P0857, Thomas Köppe). Also, stateless (non-capturing) lambdas are now default constructible and assignable, which makes them more convenient to create and use (P0624, Louis Dionne).

Operator <=>, aka “spaceship” (myself). Beyond those, my personal favorite is that the committee adopted my own proposal for the <=> “spaceship” three-way comparison operator (language wording; library wording). Many thanks to all the proposal’s reviewers, including all the authors of previous proposals in this area and especially Jens Maurer and Walter Brown for standardese wording help. This will greatly simplify how to write comparisons.

For example, in C++17 if we want to have a case-insensitive string type CIString that supports comparisons between two CIStrings and between a CIString and a C-style char* string, we would have to write something like the following 18 nonmember friend functions:

class CIString {
  string s;
public:
  // ...

  friend bool operator==(const CIString& a, const CIString& b) { return ci_compare(a.s.c_str(), b.s.c_str()) != 0; }
  friend bool operator< (const CIString& a, const CIString& b) { return ci_compare(a.s.c_str(), b.s.c_str()) <  0; }
  friend bool operator!=(const CIString& a, const CIString& b) { return !(a == b); }
  friend bool operator> (const CIString& a, const CIString& b) { return b < a; }
  friend bool operator>=(const CIString& a, const CIString& b) { return !(a < b); }
  friend bool operator<=(const CIString& a, const CIString& b) { return !(b < a); }

  friend bool operator==(const CIString& a, const char* b) { return ci_compare(a.s.c_str(), b) != 0; }
  friend bool operator< (const CIString& a, const char* b) { return ci_compare(a.s.c_str(), b) <  0; }
  friend bool operator!=(const CIString& a, const char* b) { return !(a == b); }
  friend bool operator> (const CIString& a, const char* b) { return b < a; }
  friend bool operator>=(const CIString& a, const char* b) { return !(a < b); }
  friend bool operator<=(const CIString& a, const char* b) { return !(b < a); }

  friend bool operator==(const char* a, const CIString& b) { return ci_compare(a, b.s.c_str()) != 0; }
  friend bool operator< (const char* a, const CIString& b) { return ci_compare(a, b.s.c_str()) <  0; }
  friend bool operator!=(const char* a, const CIString& b) { return !(a == b); }
  friend bool operator> (const char* a, const CIString& b) { return b < a; }
  friend bool operator>=(const char* a, const CIString& b) { return !(a < b); }
  friend bool operator<=(const char* a, const CIString& b) { return !(b < a); }
};

With this proposal, the class’s comparisons could instead be implemented as just two ordinary member functions (vs. the 18 that had to be nonmember friends above):

class CIString {
   string s;
public:
   // ...

  std::weak_ordering operator<=>(const CIString& b) const
      { return ci_compare(s.c_str(), b.s.c_str()); }
  std::weak_ordering operator<=>(const char* b) const
      { return ci_compare(s.c_str(), b); }
};

and objects of this type can still be used just as flexibly and efficiently as if the class author had written all of the above two-way operators in the first version, because now the compiler will rewrite expressions like s1<s2 to (s1<=>s2 < 0) for you automatically. Additionally, unlike the first attempt, this version also documents in code that the kind of ordering being returned is a weak ordering, not a strong (total) ordering. I’m a fan of writing less code to say more, and to say it more accurately. Please see the paper linked above for more details.

In related news, at this meeting the Library Evolution subgroup also began considering David Stone’s proposal to apply operator<=> to the standard library, and it got a warm reception and is expected to progress over the coming meetings. If it succeeds, we hope it may possibly let us get a small reduction in the size of the standard library specification as well as a result. Additionally, at this meeting we discovered that having <=> opens an unanticipated door for language evolution: Because the default operator<=> is guaranteed to be memberwise, so that we can know those are its semantics at compile time, a brand-new proposal by Jeff Snyder can leverage it to solve the remaining problems that before prevented us from using non-built-in types as non-type template parameters; we’ll see more of his proposal at our next meeting. That’s a good sign of a feature that is generally useful in the language beyond just its intended use cases.

We also approved extensions to the standard library:

atomic<shared_ptr<T>> (myself, Alisdair Meredith): This was originally my proposal and I got it into the Concurrency TS; many thanks to Alisdair Meredith who got it the rest of the way into draft C++20 over the past two meetings. There are changes since it appeared in the Concurrency TS, including to make it use the name I originally proposed (and not “atomic_shared_ptr<T>”).

Here’s more that we got at this meeting on the standard library side. If you notice “constexpr” being mentioned a few times above already, and some more below, that’s no accident; in Library subgroup chair Marshall Clow’s words, “the future of constexpr is bright.” The following other progress also includes more work on enabling features to work at compile time, including most of the rest of the standard algorithms:

(Aside: At this meeting, the Evolution subgroup also provisionally allowed constexpr (compile-time) new, vector, and string. Stop a moment, and think about what that means. — That is not yet in C++20, but it’s on its way and could be approved for draft C++20 in another few meetings… and if this all reminds you of the CppCon “constexpr all the things!” talk title, you’re exactly right.)

And much more. Thanks to all those proposal authors and the issues list proposed wording contributors and all their helpers, without which this team effort would not succeed meeting after meeting. None of the proposers could get it done without all the contributions of many people who work tirelessly all the way from design feedback to detailed wording review, usually for no public glory, and we appreciate their indispensable help. For any of the above papers you happen to have interest to click on, please be sure to look also at the Acknowledgments section, many of which are quite extensive and deservedly so.

We also continued incubating other work. In particular, the Reflection study group had presentations, and gave direction and feedback, on static reflection for functions, as well as design feedback on Section 5 of my metaclasses paper. The Undefined/Unspecified Behavior study group met for two days with our sister committee WG23 (Vulnerabilities) co-located at the same venue to start work on a C++-specific document about programming language vulnerabilities and guidance, in conjunction with (and already providing new feedback for) the C++ Core Guidelines.

What’s next

Here’s an updated snapshot of our status:

wg21-timeline-2017-11

Thank you again to the 140 experts in Albuquerque this week, and the many more who participate in standardization through their national bodies! Have a good winter… we look forward now to our next meetings in March (Jacksonville, Florida, USA) and June (Rapperswil, Switzerland).

Read Full Post »

Older Posts »