I don't see how QVariant could support a non-copyable type any time in the future, since QVariant itself is copyable. What is it going to do if it were holding a non-copyable type and you copied it?
Yes, it would be ugly. It would have to move internally and warn about it. But let's forget about QVariant and concentrate on the metatype side of things.
But how would you use it? Right now, you can't make a signal-slot connection to an rvalue reference, in either the old or new syntax. It simply doesn't make sense, since signal-slot connections are meant to be N:M things: moving from an input in one slot, thus making the content unavailable to the next slot, is a weird situation.
We don't only use signals and slots in QML. We can also invoke methods directly using QMetaObject::invokeMethod() and friends. And we call property write accessors. Being able to encode references and rvalue references in QMetaType could be useful for such a case. It doesn't have to be exposed in public API yet, but it should be possible to add it later.
best regads, Ulf _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
