> Sent: Wednesday, March 24, 2021 at 8:49 AM
> From: "Matthew Woehlke" <mwoehlke.fl...@gmail.com>
> To: "Giuseppe D'Angelo" <giuseppe.dang...@kdab.com>, interest@qt-project.org
> Subject: Re: [Interest] The willy-nilly deletion of convenience methods (was:
> Mixing Commercial and Open...)
>
> On 24/03/2021 07.17, Giuseppe D'Angelo via Interest wrote:
> > On 22/03/2021 17:19, Thiago Macieira wrote:
> >> I thought we'd fixed that and reverted them. Or didn't we add
> >> toContainer?
> >>
> >> Peppe, what was our final conclusion here?
> >
> > There was no conclusion reached, unfortunately, and didn't manage to
> > provide a replacement in time. I was (and still am) afraid at simply
> > reintroducing .to<Container>() functions.
> >
> > One reason is purely API quality: implementing them "correctly" in
> > C++14/17 without ranges/concepts is not exactly funny (just look at the
> > ranges::to proposal for how many corner cases are there to consider),
> > and there's indeed already ranges-v3::to as the ready-made solution (so
> > why spending time redoing it).
>
> Huh?
>
> Let's take e.g. QList::toSet as an example. The deprecation message says
> to use `QSet(list.begin(), list.end())` instead. How, then, is the
> correct implementation *not*:
>
> QSet<T> QList<T>::toSet() { return QSet<T>{begin(), end()}; }
+1024
I also think that this is also made a problem because of lack of a general
collection interface. QVector, QList, QSet, I don't want to care what is passed
into my function. I just want to take multiple of some thing. Let my API user
determine what the best storage mechanism is.
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
