[Development] QMetaType and non-const references

Ulf Hermann ulf.hermann at qt.io
Tue Jul 19 08:54:13 CEST 2022


for the purpose of QML support, the types of properties and the 
arguments and return types of invokable methods, signals, and slots have 
to be available as metatypes. We need _all_ types with metaobjects to 
observe this rule, not only the ones explicitly registered with the 
QML_* macros. This is because:

a, You can have properties and methods in a base type and expose a 
derived type to QML. The properties and methods of the base type should 
still be available in QML.

b, You can separate the QML registration from the type declaration with 
QML_FOREIGN. The QML_FOREIGN can live in a different library, and can 
even be written in the future.

QML has no use for non-const references right now. If those are 
encountered, QML should refuse to touch the property or method. (In 
fact, QML might treat them as synonymous to const references right now, 
but that would be a bug).

In the same way, types without copy-ctor are unsupported right now. 
QML's value type wrapper assumes that it can copy values around (wrapped 
in QVariant for the most part). I can't rule out that someone has found 
some trickery to use then in a place _I_ don't see right now, but at the 
moment non-copiable types are not very useful in QML, either.

However, I can see the _possibility_ of supporting movable and 
default-constructible but non-copiable types. Once we have syntax for 
constructing value types in QML, we might allow assigning such things to 

Furthermore, if I have the metatypes available, I can come up with more 
interesting functionality in the future (for example making QML's value 
type references actual references). So, if it's not horribly 
complicated, I would indeed like as many metatypes as possible to be 

Furthermore, I can definitely see a use for a QVariant "move-ctor" that 
takes a T&& or moves out of another QVariant or out of a non-const 
void*. I could use it already today in the code qmlcachegen generates. 
Restricting such a thing to copiable types would be a bit silly. I know 
you want to keep the specifics of this discussion out of this thread, 
but this is another case for move-only types retaining their metatypes.

So, I will amend your proposal a bit:

> - reject them [non-const refs] in QMetaType::fromType, since they're usually not what you
> wanted. See https://codereview.qt-project.org/c/qt/qtquick3d/+/422197

OK, if it has to be done. But don't prevent a future implementation of 
QMetaType::fromReference or similar. We might even come up with a 
QMetaType::fromRValue. One of those may be what you need below.

> - reject non-default constructible, non-copyable or non-destructible types in
> QVariant but not QMetaType -- this includes non-const references
> 	=> corollary: need a way to form them, but not QMetaType::fromType.

Right now this is probably the correct thing to do. However, once we 
allow moving into and out of QVariant, we should revise this.

> - do use them in QMetaObject for reporting purposes

I understand this as "Properties and method arguments or return values 
of such types will still have metatypes." I agree.

> - add a way to link a T& metatype back to T's

That may be useful. I don't have much of an opinion here.

best regards,

More information about the Development mailing list