[Development] Updating holdover API from Qt 1 times

[Sze Howe Koh]

On Sun, 18 Aug 2019 at 07:37, Mutz, Marc <marc at 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