[Development] Qt 5.5.0 header diff: QtCore.diff

[Thiago Macieira]

On Tuesday 09 June 2015 12:10:02 Olivier Goffart wrote:
> A change in the IsGadget flag is fine.
> 
> Old code did not need this flag. And code that relies on it requires anyway
> that the code that register the types register the isGadget flag.
> 
> Even if one could build a complicated use case that breaks, it would be very
> unlikely to happen.

And yet it did happen, or we wouldn't be having this conversation. If Alex 
could do it in qtconnectivity, why can't others do it in other circumstances?

> And any change is dangerous. When we fix any small bug, there can always be
> applications that breaks because it was relying on the bug for something.

The problem is the associated risk because this code is complex and varies 
depending on factors we usually don't think about. This isn't about your 
standard class that operates on data.

> Anyway, let us summarize the "problem" in that case.
> 
> In Qt <= 5.4, QtLocation was using QML Private API to basically creates
> QObject wrapper around QGeoCoordinate so it can be exposed in QML. But in Qt
> 5.5, one does not need private API, everybody can expose value types to QML
> just by adding Q_GADGET to it and registering Q_PROPERTY or Q_INVOKABLE. So
> QGeoCoordinate became a Q_GADGET.  But for QML to be able to take advantage
> of it, the type needs to be registered with the QMetaType::IsGadget flag.
> This is automatic. But if the metatype is registered by code compiled with
> Qt 5.4 or before, the IsGadget flag is not present.
> This is what is happening in a application that was compiled against Qt 5.4,
> QGeoCoordinate was used in signal and slot and registered as a metatype by
> the application. QMetaType will detect the difference in the flags on the
> second registration and do a qFatal.
> The solution is obviously not to do a qFatal, but take the new flags in
> addition. And then everything works as expected.

And register the metatype for the Q_GADGET, which it hadn't done before.

My point is that you had not thought of this when you wrote the feature. 
Therefore, there shall be no more such features without major discussion 
because we are failing to see all the possible consequences. And I am not 
convinced yet we've found them all.

What are the consequences of overriding the flag and the metatype? Could it be 
that the user did intentionally break compatibility, yet failed to recompile 
one module? That's what the qFatal was there for: a reminder. We're removing 
it.

> > And it's not just the flag. I'm not convinced about the template detection
> > either. You had to apply two late fixes to the detection so that we
> > wouldn't break source compatibility or create unnecessary warnings.
> 
> Yes, I had to apply fixes after the beta was released and it got tested in
> the wild. But is that not what beta releases are for?

The problem is the precedent. We are not finding everything and this code is 
extremely complex. The more we add to it, the more complex it becomes 
(exponentially so).

> Well, then it will be reviewed as usual.
> There are few improvements that can be done to QMetaType that we were
> discussing at the summit, like the ability to modify list types (append and
> such) or including some of the C++11 features. I bet one can simplify
> qmetatype.h when we require C++11's decltype and proper SFINAE rules

We will have to discuss each modification in the mailing list.

And note that replacing the rules with C++11 simpler rules may have side-
effects too, so you should not simplify for the sake of simplification.

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