[Development] std::optional for Q_PROPERTY

[Fabian Kosmale]

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-bounces at qt-project.org> im Auftrag von Kai Uwe Broulik <kde at privat.broulik.de>
Gesendet: Donnerstag, 20. Juli 2023 15:41
An: development at 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 at qt-project.org
https://lists.qt-project.org/listinfo/development