[Development] Deprecation/removal model going into Qt 6

[Thiago Macieira]

On Sunday, 2 June 2019 15:29:11 PDT Manuel Bergler wrote:
> > Repeat after me: inline namespaces are not a tool to retain ABI.
> 
> Of course they are. That's the reason they were introduced [0]: To
> allow symbol versioning as part of the language without having to
> write linker scripts, thus enabling standard library vendors to ship
> both C++98 and C++11 conforming versions of the standard library types
> in the same binary.

Except that this is inaccurate and just plain wrong. I don't care what the 
intention of the authors of the feature was, it's not to be used for keeping 
ABI.

> > They may allow the library to provide both ABIs. That only makes the
> > breakage move to the next library that uses those classes.
> 
> The use itself is not the problem, only using them in public
> interfaces will cause problems. But in that case inline namespaces
> also allow users that are not able to update such a library to
> explicitly request the old version by fully qualifying the type (e.g.
> ::v61::QString instead of just QString). It would also be possible to

In other words, a *non-inline* namespace?

> create a feature toggle macro similar to libstdc++'s
> _GLIBCXX_USE_CXX11_ABI to automatically switch which namespace becomes
> the default one, but I'd not do that as this will incentivize users
> not to update to the newer version.

Thank you for using as example the last C++ change that caused Linux 
distributions to recompile EVERYTHING C++ (except the Qt libraries) because it 
broke compatibility.

I don't know why libstdc++ folks bothered with the ABI tag. Everything needed 
a rebuild, so they may as well have just changed the soname.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products