Hi,
I'm somewhat torn about the behavioral change. One the one hand it's the "correct" thing to do, on the other hand it does have the potential of breaking existing code. That said, this is not quite the same as changing the return type of a typed C++ function. QVariant is designed to hold any type and if you receive a QVariant it has always been a little dangerous to rely on specific conversion behavior (throughout Qt). Simon ________________________________ From: Development <[email protected]> on behalf of Thiago Macieira <[email protected]> Sent: Monday, September 26, 2016 9:37:07 AM To: [email protected] Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null 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[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<http://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 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 value). 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
