Hi,
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
properties.
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
available.
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,
Ulf
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
