On Tue, 19 Mar 2019 at 16:22, Florian-Bogdan Tudoran <tfbogdan@xxxxxxxxx> wrote: > > > changes while support is experimental. As a hypothetical example, we > > might realise that our implementation of std::variant has a bug and > > needs an extra bool member added to it in GCC 9+. That would change > > the size of std::variant objects, and so would make C++17 code > > compiled with GCC 9 incompatible with C++17 code compiled with GCC 8. > > > > I'm not aware of any such problems at the moment, but if we need to > > make such changes then we will do so. > > So in that way, C++17 support is experimental in the same way in which > C++14 is No, because our C++14 support is not experimental, and we don't make incompatible changes unless something is very important. > with the difference that the former has been around much less, > therefore it's more likely for those kind of changes to be made. I guess it No. It means we reserve the right to make such changes to C++17 and make no effort to preserve compatibility or give users any migration path from C++17 in GCC 8 to C++17 in GCC 9. That is not true for C++14. We are committed to preserving compatibility for C++14, as much as reasonably possible. If an incompatible change needs to be made for C++14 it's likely there will be command-line options or macros or other mechanisms to choose between the old and new behaviour. For C++17 we'll just change it, and not preserve the old behaviour (while it's experimental). > also means that as long as we stick to GCC8 we are shielded from unexpected > ABI changes and if any such changes will be made they will only be made in > upcoming major versions then? Even that isn't guaranteed, but in practice it's far less likely that incompatible changes would be made to GCC 8. Breaking changes to C++17 support are likely to only be made for a major release.
