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

[Simon Hausmann]

Hi,


I'm personally fine with delaying this by one release. What do others think?


That said, I think it can be written without #ifdef perhaps by using QVariant::isNull() ?


(QVariant(nullptr) maps to isNull() as well, right? ;-)



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Tuesday, September 27, 2016 5:04:56 PM
To: development at qt-project.org
Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null

On terça-feira, 27 de setembro de 2016 11:25:49 PDT Simon Hausmann wrote:
> That is exactly the part I'm referring to. Receiving a QVariant from the QML
> engine and relying on it to contain a specific type.

Well, I would say it's acceptable that the QVariant contain different numeric
types as the engine changes. Maybe you originally only had double and now you
have double and int. That would be an acceptable behaviour change.

Changing from void* to nullptr is unexpected, but it does fall into the same
bucket. The problem is that you can't write code to adapt to it without
#ifdef, so there's no way to write forward compatibility.

Can we compromise and you delay this change for one release?

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

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160927/f262764c/attachment.html>