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

[André Pönitz]

On Wed, Jun 05, 2019 at 01:41:25PM +0200, Mutz, Marc via Development wrote:
> On 2019-06-05 10:40, Edward Welbourne wrote:
> [...]
> > If some things are deprecated and never removed (QRegEx springs to
> > mind), while others get removed (comparably) soon after deprecation
> > (e.g. everything we're currently deprecating with intent to remove in Qt
> > 6), maintainers of client code get mixed signals.  The slow removals may
> > give them an impression that they can take their time, that'll lead to a
> > violation of the principle of least surprise when they trip over one of
> > the fast removals having suddenly gone away.
> 
> There are no mixed signals. I see no contradiction in deprecating QRegExp
> and keeping it around for a loooong time. See the other thread. Deprecation
> means the API is bad, for a certain definition of bad. Keep using it at your
> own peril, think twice before you do, but do keep using it if that's what
> you must do (like Qt itself uses QRegExp).

Wrong.

The "mixed signal" here is that someone in an ivory tower decided to
deprecate something but was not able to offer a viable alternative.

Either because there simply was none (in which case the deprecation was
wrong, and should be undone) or because the work-around was too much hassle
(in which case the deprecation was wrong, and should be un-done) or for some
other reason that nobody cited so far.

As a matter of fact, some of the previous deprecations, e.g. the removal
of qalgorithm, triggered re-implementing the deprecated functionality
downstream, effectively shifting the burden of doing (or, rather,
*keeping*) them once centrally to all users who need it decentrally.

All in all, this is devaluating the overall Qt offering.

Andre'