On Friday 18 November 2016 09:30:03 Lars Knoll wrote: > On 17/11/16 23:03, "Development on behalf of Thiago Macieira" <development- bounces+lars.knoll=qt...@qt-project.org on behalf of thiago.macie...@intel.com> wrote: > > On quinta-feira, 17 de novembro de 2016 11:35:54 PST Marc Mutz wrote: > > > The bigger problem is that while owner<T> does not affect the ABI, > > > all other > > > > > > GSL types do, and we're back to our §$%&!§ rule that we can't accept > > > other libs' types in our ABI, preventing anything other than > > > owner<T> from being added to Qt. > > > > We can't accept the Standard Library ABI in our ABI as per previous > > decisions (that I guess will be revisited once we get the QUIP on it > > up). > > Yes, once we have the QUIP process up and running (very soon now), I am > open to revisiting this and start creating QUIP containing a whitelist of > stuff from the STL that we want to allow in our APIs. > > > But GSL is another story. If it is sensibly developed, with a promise > > to binary compatibility for extended periods of time and no nonsense > > stuff like inline namespaces, we could accept it. Especially the > > header-only parts of it. > > > > As for whether we can accept in our *API*, that depends on whether we > > would force our users to learn something alien to Qt or it, and what > > the benefits would be. Similar to the "empty()" function case. > > > > PS: IMO, the name of the library is inconvenient. It's too close to > > GLSL and GST (GStreamer). Of course, not a reason not to use it. > > Let's wait a bit how this develops, and whether they are even interested in > keeping compatibility between versions. But it would be another > dependency, something I don't want to introduce without getting enough > benefit out of it.
The GSL is header-only. There are no BC guarantees, and, "worse", there are different implementations. All the compiler, or a static checker, cares about is the name of type: ::gsl::owner, ::gsl::non_null, ::gsl::string_span. It does not care about the implementation. There's no reason for Qt to extend its BC guarantees to other libraries. STL, GSL, Boost, std::exception, you name it. They are outside of Qt's realm and therefore do not fall under the Qt BC rules. As with every other C++ library: if a user wants BC, it's his job to pin libs without BC guarantees to a fixed version. Not Qts. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
