On Sun, 18 Aug 2019 at 07:37, Mutz, Marc <m...@kdab.com> wrote: > > On 2019-08-17 07:13, Sze Howe Koh wrote: > [...] > > Which should we implement? I personally prefer (2) as it it can be > > added to Qt 5.x and provides backward compatibility while keeping the > > nice compact function names. We could enable QT_NO_COW by default in > > Qt 6.5 LTS and then remove the old function and Qt::ReturnByValue_t in > > Qt 7.0. > > > > I'm not sure I like the verbosity or SiC-ness of std::optional, hence > > I'm asking for thoughts here. > [...] > > Which one is more SiC? > > old: > > QPixmap *pm = label->pixmap(); > if (pm) > use(*pm); > > with (2): > > QPixmap pm = label->-pixmap(); > if (!pm.isNull()) > use(pm); > > with optional<>: > > std::optional<QPixmap> pm = label->pixmap(); > if (pm) > use(*pm); > > old, using auto: > > auto pm = label->pixmap(); > if (pm) > use(*pm); > > (2), using auto: > > auto pm = label->pixmap(); > if (!pm.isNull()) > use(pm); > > optional<>, with auto: > > auto pm = label->pixmap(); > if (pm) > use(*pm); > > To me, that looks like optional<> with auto is SC while (2) is SiC with > or without auto. > > Seeing as auto will also have to be the solution for code that wants to > stay compatible between Qt 5 and 6 when it comes with QList, I don't > think anything but optional<> passes muster.
I agree that (3) indeed allows these functions to work under Qt 5 and Qt 6 simultaneously. But so does (1) and (2): * (1) lets users opt-in to the deprecated functions. * (2) lets users #undef QT_NO_COW_POINTERS. Note that the options have very different goals: (1) and (2) aim to eliminate an existing inconsistency in the Qt API, while (3) turns the inconsistency into an opportunity to introduce a new language feature into the Qt API. Personally, I'm more interested in the former goal. I can see the value in the latter goal but I can't see a good way to achieve it. As I said in my previous email, we shouldn't just apply (3) to QLabel::pixmap() and QLabel::picture() and call it a day. IMHO, we should only implement (3) if we are prepared convert most (all?) other functions in Qt that return value objects, like QAbstractButton::icon(). And I can't see how we are prepared to do so, because it involves SiC changes throughout the entire Qt code base. > Thanks, > Marc Regards, Sze-Howe _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
