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

[Edward Welbourne]

[...]
>>> == Java-style iteration
>>> (https://codereview.qt-project.org/c/qt/qtbase/+/262344) ==
[...]
On 2019-06-03 11:26, Lars Knoll wrote:
>> I’m a bit torn here. On code review I gave a +1 on deprecating them,
>> but I see that this could lead to a lot of porting effort on user
>> code that makes extensive use of them. And the problem is that the
>> porting can be non-trivial in cases where the list gets modified
>> while iterating. So I think we should most likely keep them for Qt 6.

Mutz, Marc (4 June 2019 22:41) replied:
> As I wrote in the other thread, I'm ok with keeping them. I'd like to
> deprecate them, though.

If it's going to be a lot of effort to port away from them, partly
because there are use-cases where it's easier to use (e.g. iteration
while modifying, apparently), then there are going to be folk who don't
do that porting and just endure the deprecation warnings, at least until
they get wind of the deprecation actually turning into removal.  That,
in turn, inures them to deprecation warnings (indeed, they'll probably
turn them off), so that they won't notice other deprecations that we
intend to act on more promptly.  In effect, by crying "wolf!", we'll be
teaching them to ignore our warnings.

If we're going to deprecate things, we should have a clear plan for when
they'll be removed, so that those who see deprecation warnings
consistently learn that they do need to plan to act on them and so that
they know how soon they'll need to do so.

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.

So please think carefully before deprecating without a plan for when to
remove.  Perhaps we should have a policy that every deprecation *should*
come with a "### Qt x.y Remove" comment, with the choice of which x.y
being one of the things reviewers are expected to scrutinise.  And, of
course, we should act on all those comments at the same time that dev
sets its version to x.y, absent very strong reasons (that should lead to
updates to those comments).

	Eddy.