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

[Benjamin TERRIER]

On Wed, 24 Mar 2021 at 12:17, Giuseppe D'Angelo via Interest <
interest at qt-project.org> 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).
> Given a half-cooked solution wouldn't be acceptable into QtCore, we'd
> need to put it somewhere else where we could be more flexible in terms
> of minor API breaks if we think we did a mistake, and we didn't find the
> right place. (KDToolBox comes to mind, eventually).
>
> The other reason was more profound and related to the deprecation of
> these APIs, meaning that in the huge majority of usages found was a form
> of algorithmic abuse. Should we offer APIs which facilitate bad coding
> practices?
>
>
To be fair, most of the times I have encountered them, it was related to
some kind of algorithmic abuse.
The issue is that, once the abuse has lived for many years in the code
base, fixing it is not a priority.

In the end, even if the base issue is algorithmic abuse, the pain the
developers feel comes from Qt removing the API.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210324/3dd052a5/attachment.html>