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
