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()}; }
What was so hard about that? If that's wrong, then so AFAICT is the
deprecation message.
Yes, it does not generalize to every possible container type, but I
don't know that anyone is asking for that (and I agree we shouldn't try
to support that). We're not talking about adding many, many variations
upon this theme, just *not* removing the ones that already existed. The
ones that do exist, exist because they are more convenient to use, and
because they cover *the most common* use cases.
Oh, another problem I've run into is that the replacements for a lot of
these deprecated methods aren't even available until the same version
that deprecated them. That makes it a PITA to write warning-free code
when we have to support older versions of Qt.
--
Matthew
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
