C++17 is Here: Interview with Herb Sutter

Last month, the ISO C++ committee formally approved the new C++17 standard, after work on it was finalized in April 2017. InfoQ has already covered the new C++ standard in several occasions in the past, detailing both major new features as they were approved, and progress with compiler implementation. Now, we have taken the opportunity to speak to Herb Sutter, who has been involved for many years with ISO C++ committee activities and is actually its convener.

InfoQ: C++17 includes a large number of new features, which might seem daunting at first. What are the main highlights in this new standard? Which of C++17 features should developers get the most excited about?

Herb Sutter: To me, the main highlights of C++17 are those features that help simplify daily use of the language.

Back when C++11 came out, it had lots of new features including big shiny ones, but it was the “little everyday things” that made the most impact – the range-based for loop, auto, smart pointers, lambdas, class member initializers. Those are the things we see and use every day that make our code cleaner and safer.

Now that we have C++17, some people will be excited by the “big” features like Parallel STL, but I think the things you’ll see and appreciate every day are things like structured bindings (such as writing for (auto [key,value] : my_map) {…}) and class template argument deduction (such as writing pair p{1, 2.0}; instead of pair<int, double>{1, 2.0};) and being able to initialize variables in the scope of if and switch just as we can already do with for loops – these reduce the ceremony that the language requires as we write our code, and makes our code simpler to write and maintain. In the standard library, std::string_view and std::optional are new key “vocabulary types” that will likely be used widely as function parameter and return types, which enables writing simpler signatures including that std::string_view can replace templatizing on string type; and std::variant and std::any are two more common types we’ll more often see used as class members and internally within function bodies.

Little things, especially ones focused on simplification, really do go a long way.

InfoQ: One of the most awaited features of C++ is concepts, which did not make it into C++17. Could you comment on the reason behind that delay?

Sutter: It was just a timing issue; to give it adequate bake time.

Everyone loves the concepts feature and it has been progressing steadily. We published it as a Technical Specification (TS), or “beta branch,” less than a year before the feature freeze for C++17 and so most of the committee wanted to gain experience from the TS before rushing it into a standard under the wire. When we publish a feature in a TS/beta, we can (and should) take time to get feedback on it and take breaking changes before casting it in stone in the standard. When we publish a feature in the C++ International Standard (IS), it is cast in stone for the rest of our careers and almost impossible to fix something that would require a breaking change.

Concepts is now already in draft C++20. This summer at the first meeting for the C++20 cycle, it was the first major thing we added to C++ after C++17. Interestingly, it already contains some improvements based on experience with the TS – changes that would have been difficult or impossible to make if we had jammed it into C++17.

InfoQ: What will be the major focus areas for C++20?

Sutter: You can get a good sense of the major features in an upcoming C++ standard by looking at the TSes we have published, and an up-to-date list of those is maintained at isocpp.org/std/status. Generally speaking, a TS that has been published a year or more before the feature cutoff for the next standard, which for C++20 would be TSes published by early 2018 or so, contains likely candidate material for the next standard. Note that we have never adopted a TS without changes – that bears out the usefulness of doing a TS first for larger or experimental features.

Here are the major TSes that were not part of C++17 but have been published so far:

Concepts TS: We have already adopted all of this, with changes, except for the “terse syntax” (such as writing void f(MyConcept param) {…}). The committee voted strongly in favor of pursuing that syntax, once improvements can be made that address some technical concerns, and I think there’s a decent chance we can get a form of that into draft C++20 in the next few meetings.

Concurrency TS: This is actually a group of features, and will likely be cherry-picked. Atomic smart pointers and latches seem to be likely candidates to include. The future<> extensions depend on the concurrent executors proposal, which is not done yet, and will likely be held up waiting for that to settle out.

Library Fundamentals 2: This also is a group of library features, and is being considered feature by feature to be merged into draft C++20.

Ranges TS, Coroutines TS, and Networking TS: These just received their final approval and are being published, so they will likely be considered for merging into draft C++20 in the next year or so.

Note that I am not making a prediction that these features will be in C++20. I’m just listing the major candidates. There’s a small chance that one or two other large features that are not as far along yet, such as static reflection, might make it for C++20, but that depends a lot on how quickly those proposals can mature over the next 6 to 12 months. And of course the above is not an exhaustive list of potential C++20 features; every standard always also contains many smaller improvements that don’t need to go through a TS first.

InfoQ: Do you find anything interesting or inspiring in newer languages such as Rust, Swift, Go?

Sutter: Absolutely. I am always interested in seeing what other languages explore and experiment with, and I think it’s a great sign of a healthy industry that we are seeing new languages come up and flourish. It improves the ecosystem for everybody, because languages regularly borrow from each other.

Swift in particular is a great experiment from the point of view of explicitly attempting to replace a major incumbent language (Objective-C). It’s an almost optimal situation for the new language, where the company that is developing and promoting the new language is also the major company to use the incumbent language and also the company that owns the two OS platforms where that incumbent language is popular. That is probably the most leverage that any company promoting a new language will ever have in attempting a wholesale takeover (or, let’s say, replacement) of another language’s market and developer base, and it will be interesting and instructive to see how it goes.

InfoQ: You wrote a number of influential books about C++. Is there any new book you are working on? More generally, what is your main focus today?

Sutter: I wrote articles and books because I enjoyed writing about things as I was learning them myself. Not only was it fun to share those new things, but teaching them to others forced me to understand them deeply myself; there’s nothing like having to explain a thing to someone else to make sure you really grok it yourself.

These days I’m more defining new C++ features than learning them. So I’m not writing books or articles much right now, though I may write a few Q&A-style blog articles in the near future. Currently nearly all of my writing is going into standards proposals and into the C++ Core Guidelines.

Starting two years ago, I decided to focus on a long-term project of finding ways to make C++ both more powerful and simpler – that is, making the language more powerful in ways that make actual C++ code and programs simpler to write and maintain. I plan to do that indefinitely. I think there’s a lot that can be done, so I’m trying several experiments and seeing which ones work out and then bringing them one at a time to standardization. So far I have brought one minor feature from that work forward, the spaceship comparison operator described in my paper P0515; that has been approved in the evolution groups and is going into standardese wording review at our next meeting in November, and if all goes well it could be part of draft C++20 soon. The second one, which is larger and still much more experimental and long-term, is the metaclasses work described in my paper P0707 and my CppCon 2017 session that you can find on YouTube.

I’m hopeful that many of my fellow committee members may also join me in focusing on simplicity. It’s fun to add little features here and there in isolation, but that also creates the danger of making the language become an accretion of partial solutions with potential inconsistencies. I think there’s so much value we can still deliver in simplifying the C++ code developers actually write, and finding major ways to do that comes part and parcel with taking a broad and principled view of the language. As I mentioned at the beginning, the most impactful features in C++11, C++14, and I think probably C++17 as well, were not necessarily the “big things,” but rather the little things that made everyday code simpler to write. Now we have a very large opportunity ahead of us to specifically target simplicity with not just little cleanups, but with major simplification, and I’m cautiously optimistic that this can deliver big and welcome improvements in C++. Remember that Bjarne Stroustrup has always famously said that within C++ there was a smaller and simpler languages struggling to get out, literally 1/10 of the complexity of C++ if we could start over from scratch. Of course we can’t simply do that (that would be an Objective-C-to-Swift exercise) but I believe there may be a path to get a large part of that simplification for C++ code, and possibly over time for the language itself, but incrementally and with a long view. We’ll see, but even if we only ever get halfway there it will be an enormous, dramatic improvement.

Sometimes people ask, “why doesn't standardization go faster?” The C++ committee knows that it takes time and care to evolve a language used by some 4.5 million programmers, and that’s relied upon in essentially every major industry and across many billions of lines of code in all sorts of software from critical infrastructure to end applications (including many other languages’ compilers). “Move fast and break things” definitely does not apply here; our job in ISO C++ is to bring this huge ecosystem forward, not to leave it behind – no matter how shiny the object is that we might like to chase but that is off our path. “Move forward with systematic principled improvement” is closer to an appropriate mantra in our case. Remember the maxim that people usually overestimate what we can do in two years, and underestimate what we can achieve in 10 years. I am cautiously optimistic that maxim can apply here too as we continue to evolve C++ and make it better in the coming decade.

Herb Sutter is a leading authority on software development and author of several books including Exceptional C++ and C++ Coding Standards. Sutter has served for 15 years as chair of the ISO C++ standards committee, and is a software architect at Microsoft where he has led the language extensions design of C++/CLI, C++/CX, C++ AMP, and other technologies.