[Bug libstdc++/99058] Consider adding a note about std::optional ABI break to the C++17 status table

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Brad Spencer from comment #3)
> Ok.  What's the right way for me to learn what version of GCC has stable
> support for a C++ version?

The release notes:
https://gcc.gnu.org/gcc-9/changes.html#libstdcxx


> I am under the (possibly mistaken) impression that the libstdc++ ABI (in a
> given configuration) has been stable for a very long time, and that
> generally integrators (such as Debian or Ubuntu, for example) provide
> versions of libstdc++ that are ABI-compatible with code compiled against
> previous versions. 

The shared library ABI is stable. There are no std::optional symbols in the
shared library, so changes to std::optional do not affect the ABI of the shared
library (only of user code compiled using the libstdc++ headers).

> As per https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html this is
> reflected in the long-standing .so major version of 6.  I know there are
> many caveats here, especially around the early introduction of
> pre-standardized features, etc.

Right, like std::optional.

What matters is not whether the features has been standardized but whether it's
considered stable in GCC. The features don't suddenly become complete and
stable on the day that ISO publishes the next standard.

> Is it correct to think that the _intention_ is that it is possible to
> configure the library to remain ABI compatible into the future until a
> conscious decision is made to introduce an ABI break?

Only for parts of the library that are not considered experimental.

Support for C++17 in GCC 7 and 8 is experimental, as noted in the release
notes:
https://gcc.gnu.org/gcc-7/changes.html#libstdcxx
https://gcc.gnu.org/gcc-8/changes.html#libstdcxx

It is declared no longer experimental in GCC 9:
https://gcc.gnu.org/gcc-9/changes.html#libstdcxx

If you use experimental pieces (like C++17 support in GCC 8, or C++20 support
in GCC 10) then you are giving up the expectation of ABI stability between
releases.

https://stackoverflow.com/questions/46746878/is-it-safe-to-link-c17-c14-and-c11-objects/49119902#49119902