Hi,
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. Simon ________________________________ From: Development <[email protected]> on behalf of Milian Wolff <[email protected]> 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 pointers." Since I am bad at reading documentation, I previously tried (I think multiple times) to do something like: QQmlListProperty<MyGadget> or even QQmlListProperty<NeitherQObjectNorQGadget> 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: https://codereview.qt-project.org/#/c/183631/ But this uncovered this gem inside qtdeclarative itself: qqmlobjectcreator_p.h: 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? Thanks -- Milian Wolff | [email protected] | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
