C++2a synchronisation inefficient in GCC 11

[Thiago Macieira]

On Friday, 26 February 2021 15:58:01 PST Ville Voutilainen wrote:
> > Should they also prevent people from compiling their code with GCC 11,
> > which will define the macro and does support "-std=c++20"?
> 
> Yes, if there's an implementation bug in GCC 11 that renders the GCC
> 12 implementation incompatible.
> This is not new.

One would expect that implementation bugs -- not design flaws -- do not affect 
the entire functionality. And in most inline code, that is not a big deal 
since the operation was still achieved one way or the other.

What we're talking about here makes the entire set of classes unsuitable for 
consumption and dangerous, with no way to programmatically determine when 
they've become suitable. My worry is not that someone will rush to use them in 
2021. My worry is that well-tested code in 2024-2025 breaks because people are 
using a mix of systems that includes Ubuntu 22.04.

> No general one. Here we are talking about implementation bugs;
> feature-testing macros are not
> trying to cover those. And in the sunshine cases where we don't have
> bugs or binary breaks,
> defining the macros early is fine, so we're not going to postpone
> defining them, in the hypothetical
> event that someone might suggest that.

Fair enough, but we know we are not in the sunshine case. We know now, before 
the release, that it WILL change and cause silent incompatibilities. Does that 
change the conclusion?

How about the other way around: only enable the new, experimental code if the 
user defines _GLIBCXX_I_WANT_EXPERIMENTAL before the #includes?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering