[Development] QMetaType and non-const references

[Thiago Macieira]

On Tuesday, 19 July 2022 14:50:32 PDT Ulf Hermann wrote:
> "will not change" apparently means "I'm not doing it right now". I'm
> aware that it would be a new feature, but I can imagine someone adding
> support for move-only types to QVariant eventually. We may not actually
> need it though. Your point below, about QMetaType being enough to handle
> move-only types in QML, is valid.

See https://codereview.qt-project.org/c/qt/qtbase/+/422249

That's how it is designed, though it is currently buggy and crashy. We're 
fixing it.

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?

> We generally pass QObject-derived classes as pointers in QML. So we
> usually need the metatype of the pointer. However, those are the less
> interesting metatypes. The more interesting ones are the metatypes of
> QML value types. QML value types are pretty much everything except
> QObjects and namespaces, and we pass those by value. So we do have to
> construct/copy/destruct them and sometimes it would be quite handy to
> move them, too.

Adding API to QMetaType to move and also to relocate a type would be welcome. 
It's not in my to-do list right now.

> I currently don't have any plans for them, but we need more syntax for
> value types in QML anyway. Depending on how we phrase this, we might
> support moving them, explicitly or implicitly. If we could then know
> that a method takes an rvalue ref as parameter, that would be
> beneficial. However, all of this is quite far in the future.

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.

> Non-default-constructible but movable is an interesting API challenge
> for QVariant, but I wouldn't rule it out just yet. We don't have to
> implement all of this right away, but we shouldn't take decisions now
> that make such a thing impossible in the future.

Fair enough, I'm not ruling it out right now.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering