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.
Cheers,
Lars
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
