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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
