[Development] Behaviour change in QML in Qt 5.8 regarding null

[Jędrzej Nowacki]

On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote:
> Hi,
> 
> Recently, a few unit test failures[1] in the (unreleased) QtPIM module
> showed that the recent change[2] 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.
> 
> [1] https://codereview.qt-project.org/#/c/170491/
> [2] https://codereview.qt-project.org/#/c/167062/
> 
> 
> www.qinetic.com.au - Qt And QML User Experience Specialists

Hi,

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 
values
 - 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

I guess there are more from QML perspective.

Cheers,
  Jędrek