On Mon, 1 Mar 2021 at 21:44, Thiago Macieira <thiago.macie...@intel.com> wrote: > But you can see someone doing: > > #if __cplusplus >= 202002L && __has_include(<latch>) > # include <latch> > #else > # error "Please upgrade your compiler & standard library" > #endif > > and using <latch> in their inline code. And as you say, if they then mix DSOs > compiled with different versions of GCC, one of them might be the old, > experimental and binary-incompatible code. Remember that before April 2024, > the most recent Ubuntu LTS will be 22.04, which will be released before GCC > 12, which means it will contain GCC 11. > > So, wholly aside from how we fix the inefficiencies, we must decide how to > deal with the ABI break. We can: > > a) not have an ABI break in the first place, by having the above code not > compile with GCC until we promise ABI compatibility > b) cause a non-silent ABI break > c) accept the silent ABI break > > I advocate for (a) and vehemently disagree with (c). Meanwhile, (b) can be > something like (untested!):
I can't make the above code work, in any reasonable manner, because it's doing feature detection incorrectly. :) What I can imagine doing, however, is this: 1) a published IS always bumps feature-macro values (this won't help now, it's a future fix, we don't currently do this in WG21) 2) an implementation uses the pre-IS draft values before it deems itself stable 3) users who want stability should require the feature-testing macro to have at least the IS value 4) adventurous users can either use the macro without checking its value, or use at least the value that gives them whatever shiny toy they're interested in With that, we can keep allowing adventurous users to opt in early, and you have a portable way to detect that features are stable, for an implementation-defined definition of "stable".
