[Development] Use of std::function in Qt API

[Thiago Macieira]

Em sexta-feira, 17 de março de 2017, às 13:02:36 PDT, Marc Mutz escreveu:
> On Friday 17 March 2017 17:16:39 Thiago Macieira wrote:
> > Em sexta-feira, 17 de março de 2017, às 03:31:23 PDT, Marc Mutz escreveu:
> > > provided the same external libraries, and the same toolchain are used to
> > > build the two Qt releases.
> > 
> > The problem is this line here. People expect to upgrade other libraries.
> > We  should say that we guarantee our ABI provided that libc and the C++
> > library guarantee it too. We won't expose any other library's types in our
> > ABI.
> 
> This is false already today. Or only true for a definition of "libc" that
> approximates "all libraries Qt depends on". 

Actually, I meant what I said but I realise that it's not accurate. I was 
going to say "our dependencies", but I wanted to constrain what we actually do 
expose. We depend on libdoubleconversion and libpcre2, but those aren't 
exposed in the API. But what I constrained to is inaccurate.

> We use Mac types in the ABI. We
> probably use Windows types in the ABI. We provide platform-native handles,
> for one. 

Right. And specialised libraries like QX11Extras also expose Xlib types.

> We expose OpenSSL in our ABI. Yes, we hide it behind a void*
> Qt::HANDLE, but any user of QSslCertificate::handle() already depends on
> OpenSSL. This is a SEP. 

Right, and QDBusConnection also provides a void* to get the DBusConnection, 
but I've warned that it may change. Note that exposing a void* actually means 
we *don't* depend on their ABI and, if they break it, our ABI isn't affected. 
The code inside network/ssl or dbus can deal with the apparent breakage and 
hide the problem, if necessary.

> Don't insist on making all libraries' ABI stability
> _our_ problem. If it wasn't for this rule, QSslCertificate::handle() could
> return the real thing, depending on the platform, saving the user the need
> to write dangerous casts.

I'd insist we keep it a void* (I invite you to take a look at 
qsslcertificate_winrt.cpp) the same way that the native event filter also does 
type-erasure. Converting back to the original type is SEP.

> Let's say it like this:
> 
> ... provided the libraries, toolchain and build settings (incl. compiler
> switches) provide binary compatibility, too.

Agreed, but I want a whitelist of libraries whose ABI we expose in our ABI. 
Libraries that are mere backends of what we implement should not be exposed.

> iow: Qt will not introduce spurious binary incompatibilites not already
> present in libraries, toolchains and settings Qt depends on.

Agreed.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center