EuroLLVM Lifetime talk by Gábor Horváth and Matthias Gehre

At CppCon 2018, I gave an update of my Lifetime analysis work that makes common cases of pointer/iterator/range/etc. dangling detectable at compile time (the spec is here in the C++ Core Guidelines GitHub repo). During that talk, we mentioned and demo’d two implementations: as a Visual C++ extension by Kyle Reed and Neil MacIntosh, and in a fork of Clang by Matthias Gehre and Gábor Horváth who both also joined me on-stage.

Last month at EuroLLVM, Matthias and Gábor gave a 30-minute progress report talk about their work to upstream the Lifetime rules implementation into Clang, “Implementing the C++ Core Guidelines’ Lifetime Safety Profile in Clang.” They give a summary of the approach and how it maps to Clang internals, show initial results from testing against Clang’s and LLVM’s own sources, and end with a nice roadmap for the next steps of incrementally upstreaming the work to Clang trunk.

If you care about making C++ safer, I recommend taking a look… it’s a great summary and update. Thanks, Matthias and Gábor and Kyle and Neil for their collaboration on this project!

Trip report: Winter ISO C++ standards meeting (Kona)

A few minutes ago, the ISO C++ committee completed its winter meeting in Kona, HI, USA, hosted with thanks by Plum Hall, NVIDIA, and the Standard C++ Foundation. As usual, we met for six days Monday through Saturday, including most evenings. This and the previous meeting were the biggest ISO C++ meetings in our 29-year history, and this time we had a new record of 13 voting national bodies represented in person: Bulgaria, Canada, Czech Republic, Finland, France, Germany, Netherlands, Poland, Russia, Spain, Switzerland, United Kingdom, and United States. For more details about our size increase, including how we adapted organizationally to handle the load, see my San Diego “pre-trip” report and my San Diego trip report.

Thank you to all of the hundreds of people who participate in ISO C++ in person and electronically. Below, 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 a few weeks from now, and so the links will start working at that time.
  • You can find a brief summary of ISO procedures here.

C++20 feature freeze

Per our official C++20 schedule, this was the last meeting to approve features for C++20, so we gave priority to proposals that might make C++20 or otherwise could make solid progress, and we deferred other proposals to be considered at a future meeting — not at all as a comment on the proposals, but just for lack of time at this meeting. (I’ve been holding back from publishing updates to my own P0707 and P0709 proposals, generation+metaclasses and lightweight exception handling, for this very reason.)

So we now know most of the final feature set of C++20! At our next meeting in July, we expect to formally adopt a few additional features that were design-approved at this meeting but didn’t complete full wording specification review this week, and then at the end of the July meeting we will launch the primary international comment ballot (aka CD ballot) for C++20.

Two more major features adopted for C++20: Modules and coroutines

Again, I want to acknowledge the primary proposal authors by name, who did a lot of the heavy lifting. But none of this would be possible without the hard work of scores of people at this meeting and over the past few years including in alternative proposals.

Modules (Gabriel Dos Reis, Richard Smith) was adopted for C++20. Modules are a new alternative to header files that deliver a number of key improvements, notably isolating the effects of macros and enabling scalable builds. As I’ve said in talks (another example), I personally find this feature very significant for several reasons, but the most fundamental is that this is the first time in about 35 years that C++ has added a new feature where users can define a named encapsulation boundary. Until now, we have had three such language features that let programmers create their own Words of Power by (a) giving a user-defined name to (b) something whose implementation is hidden. They are: the variable (which encapsulates the current value), the function (which encapsulates code and behavior), and the class (which encapsulates both to deliver a bunch of state and functions together). Even other major features such as templates are ways to adorn or parameterize those three fundamental features. To these three we now add a fourth: the module (which encapsulates all three to deliver a bunch of them together). That’s a fundamental reason underlying why modules enable further improvements that can now follow on in future C++ evolution.

Coroutines (Gor Nishanov) was adopted for C++20. A number of other authors that have their own coroutine proposals have also done great work to give feedback to this design and inform the committee in the process of showing their own designs, and the adopted coroutines design is expected to adopt some of their additional programming capabilities in the future as well as we continue to build on it after C++20. At this meeting, we had many detailed design discussions, including notably these papers that will be available in a few weeks when the post-meeting mailing is posted: a unified consensus report from all coroutines proposers describing the strengths and weaknesses of all their proposals, and a consensus report from implementers from all major C++ compilers about the tradeoffs and feasibility of the basic facilities required by the various coroutines proposals. Both of these papers are very educational and highly recommended.

Other changes approved for C++20

A number of other smaller changes were adopted as well.

  • Extending structured bindings and reference capture of structured bindings (Nicolas Lesser) allow a name introduced as a structured binding to be used in additional ways that programmers would naturally expect to work, such as allowing them to be captured by reference in lambdas.
  • Allow initializing aggregates from a parenthesized list of values (Ville Voutilainen and Thomas Köppe) allows using () to initialize aggregates in addition to {}. See N4462 for an example of the kind of problems this fixes.
  • <=> != == (Barry Revzin) adds better language support for composability when writing <=> for types that can write a more efficient == than using the <=> operator alone. For example, vector<T> can short-circuit == comparison by first checking whether the two vectors have the same size; if they don’t, we know in constant time that they cannot be equal without comparing any of the elements. The previous guidance for such types was that in addition to <=> they should also overload == and !=, and that any types that compose such types have to know to do the same so as not to lose the optimization. With this change, we can more simply teach that for such types in addition to <=> they should also overload ==, full stop; there is no need to also overload !=, and no need for other types that use such a type to be especially careful so avoid losing the optimization .
  • Change span to use unsigned size, and add ssize() functions to get signed sizes (Jorg Brown and many others) makes std::span more convenient to use with existing STL types, while also allowing use of signed sizes and indexes via ssize() to get the benefits of signedness.
  • polymorphic_allocator (Pablo Halpern, Dietmar Kühl) allows pmr::memory_resource to be used wherever allocators can be used in the standard library.
  • Adopt vectorization policies from Parallelism TS2 (Alisdair Meredith, Pablo Halpern) further extends the parallel STL algorithms with vector execution policies that allow programs to exploit the parallelism of vector units available on modern CPUs.
  • A slew of broad papers restating the standard library in terms of our new C++20 language features of concepts and contracts that were already adopted at recent meetings. See P0788 and P1369 for a great overview of what this involves. This is part of the standard library’s intentional evolution toward replacing exceptions with contracts for preconditions (such as domain and range errors) in future C++.
  • Lots of smaller features and individual issues resolutions.

Other features targeting C++20 for the July meeting

Several other features were design-approved for C++20 this week but did not yet have their specification wording reviewed to merge into the working draft at this meeting, and they are hoped to be formally adopted at our July meeting in Cologne. These include things like text formatting, flat_map, more ranges and algorithms such as move-only views, an automatically joining thread with stop token support, and more. I’ll cover which of these are actually adopted in my July trip report, when we know what landed at that meeting.

The shape of C++20 (modulo any additional features in July)

Now that we are close to knowing the final feature set of C++20, we can see will be C++’s largest release since C++11. “Major” features include at least the following:

  • modules
  • coroutines
  • concepts
  • contracts
  • <=> spaceship
  • “lots more constexpr”: broad use of normal C++ for direct compile-time programming, without resorting to template metaprogramming (see last trip report)
  • ranges
  • calendars and time zones
  • span
  • and lots more

Combined with what came in C++14 and C++17, the C++14/17/20 nine-year cycle is arguably our biggest nine-year cycle yet alongside the previous two (C++98 and C++11) in terms of new features added. We understand that’s exciting, but we also understand that’s a lot for the community to absorb, and so I’m also pleased that along the way we’ve done things like create the Direction Group and, most recently, SG20 on Education, to help guide and absorb continued C++ evolution in our vibrant living language.

Other progress and decisions

Executors and Networking: Both of these continue to progress together, as Networking depends on Executors. We had hoped that part of Executors might be ready for C++20 but they didn’t make the cut, and both of these are now on track for soon post-C++20 (i.e., early in the C++23 cycle).

Reflection TS v1 (David Sankel, Axel Naumann) completed. The Reflection TS international comments have now been processed and the TS is approved for publication. As I mentioned in other trip reports, 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.

Generic Scope Guard and RAII Wrapper for the Standard Library (Peter Sommerlad, Andrew Sandoval, Eric Niebler, Daniel Krügler) was adopted into the Library Fundamentals 3 TS.

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 spring… our next regular WG21 meeting in July (Cologne, Germany) where we plan to send out C++20 for its major international review ballot, then spend two more meetings responding to those review comments and make other bugfixes before sending final C++20 out for its approval ballot one year from now.

Trip report: Fall ISO C++ standards meeting (San Diego)

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

Pre-trip report: Fall ISO C++ standards meeting (San Diego)

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.

My CppCon 2018 talk is now online

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.

Lifetime profile v1.0 posted

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.