[Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Matthew Woehlke]

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