[Development] QQmlListProperty<T>: static_assert that T inherits QObject

Simon Hausmann Simon.Hausmann at qt.io
Fri Jan 27 16:49:15 CET 2017


Regarding the question about why the engine itself uses QQmlListProperty<void> internally when populating

list properties during instantiation, I think you've already found the answer yourself: Because of interface types :)

I think it would be great if incorrectly used types could be reported to the developer as early as possible, but at the same

time the ability to things like forward-declaring "Foo" used by "Q_PROPERTY(QQmlListProperty<Foo> ...)" is likely a feature

used by many people when designing class interfaces. So I'm not sure it's a good idea to suddenly break their build when

upgrading to a new version of Qt.


From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Milian Wolff <milian.wolff at kdab.com>
Sent: Friday, January 27, 2017 12:20:46 AM
To: qt-dev
Subject: [Development] QQmlListProperty<T>: static_assert that T inherits QObject

Hey all,

the QQmlListProperty states:

"Note: QQmlListProperty can only be used for lists of QObject-derived object

Since I am bad at reading documentation, I previously tried (I think multiple
times) to do something like:


or even


This happily compiles and only at runtime does it not work. So I thought I'd
add a static assert to QQmlListProperty to check this at compile time:


But this uncovered this gem inside qtdeclarative itself:

158:    QQmlListProperty<void> _currentList;

Uhm, a void* list, really? Should this be a QQmlListProperty<QObject>?

Digging further, I find a few places where QQmlListProperty<T> is instantiated
for non-QObjects, mostly within qmlRegisterUncreateableType, which is easy to
prevent by leveraging std::enable_if.

Digging even further, I hit the first road-block though with my approach:
Adding the static assert directly to QQmlListProperty means that T must be
fully defined when the list property gets used. Does this make this change
source-incompatible? Is there a workaround for this? I fixed the issues inside
Qt Declarative itself, but I wonder whether this is acceptable for existing
users of QQmlListProperty outside of QtDeclarative.

The second road-block comes when compiling the tests - apparently
QQmlListProperty also works with interfaces! So I added another type trait for
that. Is that acceptable?


Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170127/746d8bf8/attachment.html>

More information about the Development mailing list