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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
