Le jeu. 20 juil. 2023 à 15:41, Kai Uwe Broulik <k...@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
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
