Hi, as far as QMetaType is concerned: We need a way to have some introspection on the "contained" type. That can't really be shoehorned into the current QMetaTypeInterface, because that one has neither enough space, nor a useable function pointer that could be hijacked. However, incrementing the QMetaTypeInterface revision and appending a new member is possible (QMTI has been written with extensibility in mind), and then you can add another function pointer to e.g. retrieve QMetaType::fromType<T>() if you have QMetaType::fromType<std::optional<T>>. Gettnig that in should be mostly straightforward.
At the QML layer, we would need to have some discussion on how to map the values. Should a std::optional<T> be "undefined if it's nullopt, and behave like Q_PROPERTY of type T otherwise"? That would mostly work, unless you want a RESETable property, where RESET shouldn't lead to a nullopt value. Should nullopt be mapped to null instead (but then you can't distinguish nullopt and nullptr). Or should we have optional<T> in QML in the same way we have list<T>? That would require defining its interaction with JS code. In general, I think having a way to expose optional value in a nice way is worthwhile, but I'm currently not sure what the best way forward would be. Kind regards, Fabian ________________________________________ Von: Development <development-boun...@qt-project.org> im Auftrag von Kai Uwe Broulik <k...@privat.broulik.de> Gesendet: Donnerstag, 20. Juli 2023 15:41 An: development@qt-project.org Betreff: [Development] std::optional for Q_PROPERTY Hi everyone, something that came up during this year’s KDE Akademy was that we believe Q_PROPERTY should be able to handle std::optional, such that you get a null QVariant out of it if it has no value. The main use case being interfacing “more modern C++” with QML in a type-safe way, rather than using QJSValue::Undefined for invalid results. The question is also, where do we draw the line: I could see a use for having an std::variant property for when we have a known set of types we accept (e.g. std::variant<QString, QIcon>). Again something where we currently would do a QVariant with manual conversions and missing introspection. Is that something that we would like to see? I was told that a QMetaType is “full” and version bump needs to happen first before it can be extended or something? Cheers Kai Uwe -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
