https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118301
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Richard Sandiford from comment #6) > You obviously know better than me :), but I thought c++2a was used for > things that aren't yet fully specified. Here it's about something that is > fully specified but whose GCC implementation isn't fully supported/is still > experimental. A specific feature, yes - but -std=c++20preview (or whatever it's called) would not relate to a specific feature, so is at the wrong granularity. And the lines between "not yet fully specified" and "not yet fully supported" are extremely blurry. The impl might be added before the spec is final, but then the spec might change under us, or it might be published without changes, but conformance problems or bugs in the impl might be discovered later. It doesn't make sense to have a global "everything in C++20 is an experimental preview" flag is inaccurate and IMHO no better than what we have now. I think a better solution would be to do one or both of: 1) require a macro like -D_GLIBCXX_EXPERIMENTAL or -D_GLIBCXX_EXPERIMENTAL_CXX20 or -D_GLIBCXX_EXPERIMENTAL_CXX20_ATOMICS to make new features visible. Without that, they're not even declared. All three macros could exist, with the later ones implied by the earlier ones (so you could choose to enable all experimental stuff, or only subsets). 2) make new features depend on a non-inline symbol defined in libstdc++exp.a so you get linker errors unless you use -lstdc++exp In both cases, when a feature is deemed to be "stable enough" it would become available unconditionally (by no longer gating it on the macro, or moving the symbols to libstdc++.so so that the -lstdc++exp is a harmless no-op).
