Re: [chromium-dev] C++20 is now allowed in Chromium

[Mark Mentovai]

(Moving this to cxx.)

Where was this discussed/decided? I would have expected some part of the discussion to occur on cxx, but I don’t see anything there.

To be clear, I don’t think there’s any particular problem with allowing C++20, but the “longer version” in the announcement reveals that some go/no-go decisions were made with respect to specific features, and it would be valuable to the Chromium and, in particular, cxx@chromium community to know more about how those decisions were made. I’m wondering why those discussions weren’t opened up to the cxx list, which is the venue that the message advertises as appropriate to request changes.

On Mon, Nov 13, 2023 at 2:31 PM 'Peter Kasting' via Chromium-dev <chromi...@chromium.org> wrote:

If you do not write C++ in Chromium you can ignore this message.

TLDR: C++20 is now formally allowed. See the features list for what you can and cannot use. To request a feature status change, email c...@chromium.org.

Longer version follows

As of today, first-party code in Chromium is allowed to use C++20 language and library features. Unlike with past version upgrades where initially few (or no) new features were allowed, we are allowing a significant number of features immediately; see the Modern C++ features list for complete details, but the most significant allowed features are:

• Concepts, which make template definitions more readable and faster to compile
• Defaulted comparison operators and the <=> ("spaceship") operator, which simplify writing value types
• Member initializers for bitfields, like other member types
• <bit>, which can replace various parts of base/bits.h
• <numbers>, which can replace various parts of base/numerics/math_constants.h
• std::erase[_if], which can replace base::Erase[If]
• std::lerp and std::midpoint, which can be useful for UI
• std::string::(starts,ends)_with, which can replace base::(Starts,Ends)With

Some features you might have wanted are disallowed or TBD:

• Modules, which need further toolchain (including gn) support and a migration plan
• Ranges, which cause compile time concerns (among others); use base/ranges/algorithm.h
• Coroutines, which need significant local support and a migration plan
• <span>, which does not make use of MiraclePtr; use base::span
• <format>, which is not backwards-compatible with printf-style strings and does not support std::u16string; use base::StringPrintf
• <source_location>, which seems to regress code size; use base::Location
• std::u8string, a string type which is explicitly UTF-8; use std::string

If you wish to debate any feature classifications or propose allowing a TBD feature, email c...@chromium.org.

FAQ:

• Are there any downsides of this change?
• Changing to C++20 caused both binary sizes and compile times to increase, in part because more STL types and APIs are constexpr (and inlineable). We made these changes beginning around a year ago and determined that the regressions were acceptable. (That said, I'd love if someone investigated improving inlining decisions around constexpr code in Chromium's build context...)
• What about third-party code?
• We don't restrict third-party use of C++20 beyond "it has to still work in our build". However, some third-party code, such as PDFium, may not yet allow C++20. Also, ChromeOS code outside Chromium is not covered by this announcement.
• Will we be replacing base:: APIs with std:: ones?
• In some cases, yes, over time. The features list generally links to applicable migration bugs, and we welcome contributions. In a few cases, like <ranges> or std::span, future use of the std:: version is uncertain.
• When will we get C++23?
• We've generally allowed new language versions about three years after standardization. The delay is not due to caution as much as the necessary time for our toolchain to support the new spec and for us to fix any compilation issues. So if history is a guide, expect C++23 around 2026. That said, there is no central team or person who owns these transitions, so if you'd like to see something sooner, start trying to fix C++23 problems yourself :)
• Wait, we're still using C++? I thought Rust/Carbon/etc. was the future?
• While work to support and use Rust more broadly continues, we will still be using C++ in Chrome for the foreseeable future, and it makes sense to stay current with newer language specs. We will still be writing new C++ code five years out, and we will still be at least maintaining C++ code ten years out.

Thank Yous

This announcement has been a year and a half in the making, and in that time a huge number of people have been helpful. I'd like to extend special thanks to Hidehiko Abe for doing much of the technical work on ChromeOS, Dana Jensens for code reviews, moral support, and pushing to get the final approval flipped, Daniel Cheng for code reviews and expertise, Eric Lok for managing and driving the ChromeOS side, Nico Weber for ATL coordination and clang expertise, George Burgess for clang-tidy coordination, Christopher Di Bella for stability data and Google-side coordination, Rob Liao and Rachel Blum for steady management-side support, and anyone who wrote or reviewed C++20-related changes or contributed to the discussion around them. I appreciate you.

PK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAHOzFBbFO1unqBEx46umm_8tsud7EcjfHfu0tfqxh8xTRWAhQ%40mail.gmail.com.

[Dana Jansens]

The discussion occurred here: https://chromium-review.googlesource.com/c/chromium/src/+/4217486

There were quite a few people involved, but I am not sure how it was advertised. (I see you're there too, but it was quite a while ago now as the discussion was mostly around Feb-March 2023).

You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAHk1GDxiSUzqpkrPBCL0yxdOuBBzk719%2BXiJbK_MdBB_21PYuQ%40mail.gmail.com.

[Peter Kasting]

I can't recall for sure, but I thought I emailed cxx@ to say that interested parties should debate things on that cl.

PK

[Mark Mentovai]

Thanks. I think what’s surprising is that nine months elapsed between then and now, and with no substantive discussion since March, it might have been useful to circulate a “last call” to cxx.

[Peter Kasting]

Yeah, that's fair. I did something sort of like that in early August when I thought we were about to ship, but I think that only got advertised on the slack #cxx channel and to some number of direct reviewers (Dana, Jeremy, etc.); I don't think that note got mailed to cxx@.

We can definitely make changes. I already reversed the allowance of [[no_unique_address]], for example. So if there's anything unsatisfying, let's discuss it.

PK

[K. Moon]

I think one last call for input is a reasonable thing to ask for (in the spirit of open discussion), but it'll have to be for C++23 at this point, of course.

My own knowledge about the timing of this is pestering Peter repeatedly on Slack about when C++20 was finally going to be flipped on. :-) I think the context here is that there was general agreement within Chromium about proceeding a long time ago, but then the final flip got blocked on downstream projects not being ready for many months. Those blockers finally went away quite recently, so I can see not wanting to reopen what had been a settled discussion.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAHk1GDzJ1QjoBTQ16QHaJTsJs4%2B50xLnXdPQpRy8Us_wcrGm%2BQ%40mail.gmail.com.

[Peter Kasting]

It's totally reasonable, I just didn't think of it. And in August when I did think of it, I pinged #cxx because that's where I usually discuss such things and it's easy and we have way too many overlapping comms channels.

If we want to make sure such rollouts happen in an orderly way, then instead of relying on memory, we'll need to make a playbook doc and check it in somewhere, e.g. styleguide/c++/. It probably makes sense to do this; now that I've run one of these end-to-end I can try to take a stab.

PK

[K. Moon]

+1 to have a playbook for the next one of these; great idea!

[Mark Mentovai]

Thanks, Peter! I think that would help for next time.

As long as the full discussion occurred on the code review, I think that good practice was generally followed well enough. I suppose I do have a minor remaining concern that the reason for the delay was never announced here in cxx or on that code review. It sounds like that’s something that may only have come up on Slack, but this should serve as a reminder that while it’s fine to have some discussions by chat, we should really elevate the more important conclusions or updates like “delayed pending projects x, y, z” to a more widely visible forum, and in particular, the one that was advertised as the place for relevant discussion.

Mark

[Peter Kasting]

Yeah, agreed.

One challenge in this case was that we were generally "just about to ship" (for months on end). At the very least, though, I could have said something when Cronet notified me of their omg blocking things.

I also didn't want to say too much that would be construed as disrespectful to another team. But I think I could have been brief here and not stepped on any toes.

google3 did this well with their c++20 rollout. I should try and give guidance in the playbook to match.

PK