[Development] std::optional for Q_PROPERTY

[Pierre-Yves Siret]

Le jeu. 20 juil. 2023 à 15:41, Kai Uwe Broulik <kde at privat.broulik.de> a
écrit :

> 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.
>

This is something that I feel is strongly needed if you want to write
clean, modern code and keep QML code typesafe.
There is a related issue here : https://bugreports.qt.io/browse/QTBUG-98300

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.
>

TBH I rarely if ever use std::variant so If we only get std::optional I'd
be happy.
Another potential addition would be the support of futures for asynchronous
invokable functions : https://bugreports.qt.io/browse/QTBUG-101025 . I
believe this would have more positive impact than std::variant

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?
>

I'd like to see it, but don't have much to bring to the technical side of
its implementation.
Glad to answer questions about use cases and review the end-user (more like
end-developer API).

Cheers,
Pierre-Yves
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230720/ef5f0f92/attachment.htm>