[Development] Behaviour change in QML in Qt 5.8 regarding null
thiago.macieira at intel.com
Mon Sep 26 09:37:07 CEST 2016
On segunda-feira, 26 de setembro de 2016 09:02:58 PDT Jędrzej Nowacki wrote:
> On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote:
> > Hi,
> > Recently, a few unit test failures in the (unreleased) QtPIM module
> > showed that the recent change which changes the semantics of null
> > assignment (from JS) to a QVariant Q_PROPERTY can affect existing client
> > code.
> > Certainly, the cases which are affected are most likely edge-cases (that
> > is, specifically testing the type or value of the QVariant within C++ code
> > to detect "null" assignment), however it is probably worth raising for
> > discussion.
> > Why was the change made? The commit message tells us what was changed,
> > but
> > not the reasoning behind the change. The unit tests were changed, so the
> > behaviour change was clearly intentional (and the old behaviour considered
> > problematic), and I assume that there must be very good reasons to make
> > such a change, but it wasn't discussed on the mailing list, so I don't
> > know
> > what those reasons are.
> > Best regards,
> > Chris.
> >  https://codereview.qt-project.org/#/c/170491/
> >  https://codereview.qt-project.org/#/c/167062/
> > www.qinetic.com.au - Qt And QML User Experience Specialists
> There are many reasons, mostly related to C++11 (in more or less
> chronological order):
> - 5.8 depends on C++11 that has null defined sensibly so we want to use it
> to mark null values.
> - std::nullptr_t became registered type which is meant to be use for null
> - QJson support got better null handling (the feature was waiting for
> std::nullptr_t in metatype)
> - using (void*)0 for null in QVariant was suboptimal as it could not detect
> invalid states like for example (void*)1
Those are the reasons that enabled the change, not a justification for why it
is better (except the last one, which I don't agree; you can always check the
Repeating Chris's question: is it worth the breakage on the user code?
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development