It's time to default-allow C++20

[Peter Kasting]

To whomever is driving C++ style these days:

C++20 was initially supported in Nov 2023, which was more than two years ago. Per the Modern C++ Features policy, that means it's time to make final decisions on any remaining TBD items, biasing towards allowing, and then default-allow that language version (removing all the text from that page explicitly allowing parts of C++20).

I won't be driving that discussion, but I wanted to mention this here in hopes someone else would.

And while I'm at it, kudos to everyone who worked to get C++23 supported. I'm surprised and pleased it happened as soon as it did. Good work!

PK

[Kyle Charbonneau]

Thanks for bringing this up Peter. There are three features marked TBD that seem straightforward (IMO) to move to the banned list pending future discussion.

• <coroutine>
• It isn't clear how to integrate coroutines with the existing post-task system. There was discussion about it in this thread.
• Clang doesn't currently support coroutines for win32 which is problematic.
• <format> 
• This would require a large migration effort for existing base::StringPrintf() usage due to different format specifiers. 
• base::StringPrintf was changed to use absl::StrFormat internally already (thanks Peter!). A decision on absl::StrFormat vs <format> would have to be made.
• <source_location> 
• std::source_location would be used in place of base::Location. Leaving <source_location> banned until there is a plan for how that migration would work seems reasonable.

That would leave the following features as TBD. I don't have any initial thoughts on these but others might.

• Aggregate Initialization Using Paranthesis
• std::u8string

Kyle

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/cxx/a3876239-6364-4453-bf4b-c448e250ce8en%40chromium.org.

[Nico Weber]

On Wed, Jan 28, 2026 at 4:41 PM Kyle Charbonneau <kyle...@chromium.org> wrote:

Thanks for bringing this up Peter. There are three features marked TBD that seem straightforward (IMO) to move to the banned list pending future discussion.

This sounds right to me.

• <coroutine>
• It isn't clear how to integrate coroutines with the existing post-task system. There was discussion about it in this thread.
• Clang doesn't currently support coroutines for win32 which is problematic.
• <format> 
• This would require a large migration effort for existing base::StringPrintf() usage due to different format specifiers. 
• base::StringPrintf was changed to use absl::StrFormat internally already (thanks Peter!). A decision on absl::StrFormat vs <format> would have to be made.
• <source_location> 
• std::source_location would be used in place of base::Location. Leaving <source_location> banned until there is a plan for how that migration would work seems reasonable.

That would leave the following features as TBD. I don't have any initial thoughts on these but others might.

• Aggregate Initialization Using Paranthesis

I think I'd prefer to ban this, as it seems more bug-prone than brace-init and the difference is very subtle. I don't think we have great tools to enforce the ban though.

• std::u8string

Given we ban char8_t, we should probably ban this too.

 

Kyle

On Sat, Jan 24, 2026 at 2:28 PM Peter Kasting <pkas...@chromium.org> wrote:

To whomever is driving C++ style these days:

C++20 was initially supported in Nov 2023, which was more than two years ago. Per the Modern C++ Features policy, that means it's time to make final decisions on any remaining TBD items, biasing towards allowing, and then default-allow that language version (removing all the text from that page explicitly allowing parts of C++20).

I won't be driving that discussion, but I wanted to mention this here in hopes someone else would.

And while I'm at it, kudos to everyone who worked to get C++23 supported. I'm surprised and pleased it happened as soon as it did. Good work!

PK

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/cxx/a3876239-6364-4453-bf4b-c448e250ce8en%40chromium.org.

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAERSRDCvVP8m-cUGw2gHu2bfKb%2BfuyzOjs0Xv3oNkMzJhTT8QA%40mail.gmail.com.

[Kyle Charbonneau]

• std::u8string 

 Given we ban char8_t, we should probably ban this too.

That makes sense to me. 

• Aggregate Initialization Using Paranthesis

I think I'd prefer to ban this, as it seems more bug-prone than brace-init and the difference is very subtle. I don't think we have great tools to enforce the ban though.

To play devils advocate here, what are the downsides to allowing aggregate initialization using parentheses? I've seen the following come up:

1. Parenthesized initialization can't use designated initializers. That seems like a minor annoyance, eg. "why won't my code compile", but not unexpected behavior.
2. Parenthesized initialization allows narrowing conversions. It's nice that curly brace initialization doesn't allow narrowing. I believe this matches what is allowed for parenthesized initialization of non-aggregate types though.

I worry that without tooling we could mark it as banned but that won't be enforced. It's a big ask for developers to remember that aggregate types shouldn't use parenthesized initialization without assistance when they see T(arg1, arg2). Perhaps more problematic is the indirect use of parenthesized initialization, eg. calling std::vector<T>::emplace_back(arg1, arg2) or std::make_unique<T>(arg1, arg2), when T is an aggregate type. That seems unlikely to be caught.

Kyle

[Peter Kasting]

I agree with banning <coroutine> (maybe with a link to existing discussions, or someone writes up a summary of said discussions). Coroutines are very interesting in principle, but how to use them well in Chromium in practice requires a lot more thought, discussion, and probably real-world experimentation.

I agree with banning <format>, in part because I think if Chromium wants to spend the time to do this, {fmt} is a better route; it's a small dependency, actively maintained, and should be a monotonic improvement to <format> in features, performance, and safety. Several years ago one of the V8 folks sought permission to experiment with {fmt} in V8; I don't know if that was pursued. I think it's worth trying to pursue this if possible, because I think we use string formatting enough that improving it helps developers and the codebase meaningfully. But that's not my call :)

Before banning <source_location> it might be nice to run another experiment with replacing base::Location's underpinnings with the stdlib machinery. IIRC, dcheng@ did this shortly after initial support landed, and it increased binary size. But that was a while back, things have changed, and it would be nice to know if we could allow this. If the results are still bad, or if there's no way to experiment, ban with a note about why.

I agree with banning u8string, perhaps with a note like "ping cxx@ if you have a legit use case". This could also be reconsidered if, in some future C++ version, the standard library actually gets good machinery for working with UTF-8/16 text, a la ICU; but I wouldn't hold my breath. Maybe in C++38.

My weak vote on aggregate initialization via parens would be to allow. I think we probably already have a bunch of this; I don't think there are any dangers that aren't also true of non-aggregates, so our existing guidance on how to init variables should apply; and I think if we _did_ have a tool-enforced way to ban, it would be more frustrating and confusing than helpful. IMO, the biggest danger of this feature is that it misleads readers at a callsite into thinking that a cheap aggregate init is actually a possibly-more-costly constructor call. That is much better than the opposite downside of making people think something costly is actually cheap.

PK

[Daniel Cheng]

On Tue, 3 Feb 2026 at 10:05, Peter Kasting <zer...@gmail.com> wrote:

I agree with banning <coroutine> (maybe with a link to existing discussions, or someone writes up a summary of said discussions). Coroutines are very interesting in principle, but how to use them well in Chromium in practice requires a lot more thought, discussion, and probably real-world experimentation.

I agree with banning <format>, in part because I think if Chromium wants to spend the time to do this, {fmt} is a better route; it's a small dependency, actively maintained, and should be a monotonic improvement to <format> in features, performance, and safety. Several years ago one of the V8 folks sought permission to experiment with {fmt} in V8; I don't know if that was pursued. I think it's worth trying to pursue this if possible, because I think we use string formatting enough that improving it helps developers and the codebase meaningfully. But that's not my call :)

Before banning <source_location> it might be nice to run another experiment with replacing base::Location's underpinnings with the stdlib machinery. IIRC, dcheng@ did this shortly after initial support landed, and it increased binary size. But that was a while back, things have changed, and it would be nice to know if we could allow this. If the results are still bad, or if there's no way to experiment, ban with a note about why.

The binary size implications won't have changed. The CL in question is https://chromium-review.googlesource.com/c/chromium/src/+/4220753. It could likely be significantly simplified at this point, but the results would be very similar. `std::source_location` is designed to be cheap to pass around, so it holds a pointer to the actual struct that stores the function/file/line information, which means lots of relocations.

The binary size increase is (probably) a mix of bigger string constants (e.g. https://godbolt.org/z/rqnn1KjGj) and a significant increase in the number of relocation entries.

 

I agree with banning u8string, perhaps with a note like "ping cxx@ if you have a legit use case". This could also be reconsidered if, in some future C++ version, the standard library actually gets good machinery for working with UTF-8/16 text, a la ICU; but I wouldn't hold my breath. Maybe in C++38.

My weak vote on aggregate initialization via parens would be to allow. I think we probably already have a bunch of this; I don't think there are any dangers that aren't also true of non-aggregates, so our existing guidance on how to init variables should apply; and I think if we _did_ have a tool-enforced way to ban, it would be more frustrating and confusing than helpful. IMO, the biggest danger of this feature is that it misleads readers at a callsite into thinking that a cheap aggregate init is actually a possibly-more-costly constructor call. That is much better than the opposite downside of making people think something costly is actually cheap.

PK

--

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 visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAO5B8RtzJGq6JQw5aALby8PLABdm-VrGwHW%3D%3D7p8RUKHbnFXVg%40mail.gmail.com.

[Joe Mason]

I agree with all of Peter's points.

--

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 visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAO5B8RtzJGq6JQw5aALby8PLABdm-VrGwHW%3D%3D7p8RUKHbnFXVg%40mail.gmail.com.

[Kyle Charbonneau]

I've uploaded https://crrev.com/c/7558108 to update the style guide based on the discussion here (eg. ban everything except aggregate initialization by parentheses). If there are no objections in the next day I'll send it for review.

Kyle