[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Danila Malyutin]

> The converse (always having to write `.second`, not to mention the
*name* "second") has its own annoyances.

You don't have to write that:

for (const auto &[key, value] : m)

вт, 11 июн. 2019 г. в 22:22, Matthew Woehlke <mwoehlke.floss at gmail.com>:

> On 04/06/2019 16.41, Mutz, Marc via Development wrote:
> > On 2019-06-03 11:26, Lars Knoll wrote:
> >>> == QSharedDataPointer / QExplicitlySharedDataPointer ==
> >>
> >> I see no reason at all for removing those, quite to the contrary. They
> >> are very helpful for building refcounted classes (explicitly or
> >> implicitly shared).
> >
> > I'd still like to deprecate them. QSDP is issuing atomic operations on
> > each mutable access hurting code-gen, and produces surprises such as
> >
> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=96dc9a19ae11ca140d681f0e2605b5f4b953e581
> > or
> >
> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=a2cdfd23d61c8dd3a346982caaf1e846e30513b0
> > or
> >
> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=188eea0eb47c499f70a60f573948d529089d93b1
> .
> >
> > QESDP has the bug that it doesn't propagate const. We could fix that,
> > but it would be SiC, too. So, my idea was to keep them both, deprecate
> > them, and use something much more cumbersome to use outside of Qt for
> > Qt's own classes. I'd also be ok with keeping a fixed QESDP, but QSDP
> > should go sooner rather than later.
>
> As one of the users that would be affected by such a change... I want to
> go on record that I would be fine with *replacing* these... just as long
> as there *is a replacement*, and that replacement isn't "for Qt-internal
> use only".
>
> I don't mind porting my code, especially if there are notable
> improvements in doing so. I *do* mind suddenly having to reimplement
> something that Qt used to provide that doesn't have an STL replacement.
>
> (p.s. It would also be nice if Q_D and friends would also stop being
> private...)
>
> BTW, in qtExtensions, I have explicit QTE_D_SHARED / QTE_D_MUTABLE to
> differentiate getting a mutable d-pointer (which might detach) and an
> immutable one (which won't).
>
> m> How do you intend to address the problem that QHash/QMap are all but
> > unusable in C++11 ranged for loops, because of decltype(*it)?
>
> https://github.com/Kitware/qtextensions/blob/master/core/qtEnumerate.h
>
> WJFFM.
>
> The converse (always having to write `.second`, not to mention the
> *name* "second") has its own annoyances.
>
> In an ideal world, we could do something like:
>
>   for (auto k : map | keys)
>
> ...and have optimal codegen.
>
> --
> Matthew
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190611/87c7f022/attachment.html>