[Development] On deprecating functions

[Eike Ziller]

> On 4. Mar 2019, at 22:27, André Pönitz <apoenitz at t-online.de> wrote:
> 
> On Mon, Mar 04, 2019 at 05:51:08PM +0100, Christian Ehrlicher wrote:
>> Hi,
>> 
>> I recently introduced some new signals
>> (Q(Double)SpinBox::textChanged, QComboBox::textActivated) as
>> replacements for old ones to be able to avoid the use of
>> QOverload<>::of in Qt6 and to better match their respective
>> properties.
> 
>> Within those changes I also marked the old signals as deprecated
>> with QT_DEPRECATED so the developer gets an information to no
>> longer use this function in new code.
> 
>> This lead to a lot of warnings in old code which needs to be
>> compiled with 5.9 and 5.12 (e.g. in QtCreator) which can't be
>> fixed because there the new function is not yet available. It was
>> requested to remove the QT_DEPRECATED decoration until e.g. 5.15.
>> but I think then it's too later to be able to remove them with
>> Qt6.
> 
> Yonder Old Code is kind of actively maintained, and to play its
> role as guinea pig for Qt itself it makes sense to compile it with
> Qt dev at times. I completely agree that the overloaded signals are
> mildly annoying, and getting rid of them in the medium term is a
> worthy goal by itself. So I certainly appreciate the introduction
> of the non-overloaded text* versions, but what is going on top of
> that currently is what I'd call tr("Throw out the baby with the
> bath water").
> 
> The issue at hand is purely cosmetical. Either use of static_cast
> or QOverload or qOverload is at most one extra line in user code
> that will only ever be witnessed by someone looking directly at
> those parts of the code. It's unfortunately a safe assumption that
> in this particular case this might be one or less persons worldwide.
> 
> All possible workarounds that I am aware of (some of them even
> being actively suggested as possible solution) are worse than that:
> 
> (1) Do not do anything: Anyone compiling the code will get the
> warning. That's at least a dozen dayly, i.e. more than a magnitude
> worse. Duh.  (1a) Some people compile with -Werror. While I will
> happily argue that they deserve the outcome for unrelated reasons,
> this still makes it: Duh!
> 
> (2) Replace the (QString) overloads with the (int) overloads and do
> the data extraction manually. Given that Qt is about making coding
> convenient and this is less convenient than before: Duh.
> 
> (3) Only suppport Qt dev of the day. Hard sell to users and 
> distributors, a.k.a. "Duh!"
> 
> (4) Only support a reasonably safe, a.k.a "antique", version of Qt.
> Hard sell for various reasons, one of them is failing to play the
> guinea pig role. DUH.
> 
> (5) Use #if (QT_VERSION / QT_VERSION_CHECK. To "fix" perfectly
> valid code *for cosmetical reasons*? DUH!
> 
> Having *some* grace period for peaceful co-existence makes sense to
> me. We can have a round of bikeshedding on what that period should
> look like, but the very existence of LTS releases suggests that it
> is ok for people to stick to LTS only.

> Qt Creator actually uses
> "last LTS minus one minor release" so far,

Just to clarify for Qt Creator I’m using something like min(last LTS, last released - 1), i.e. we’d like Qt Creator to be compilable with the latest LTS, but at least 2 released Qt versions. (And Qt version requirements are only increased for the next minor release, of course not patch releases.)

> so asking for "last LTS"
> is already a kind of concession. Truly personally, I'd even go for
> "no deprecation at all *for purely cosmetical reasons*" as I've seen
> too many taking route (5) because it was perceived too much effort
> to keep up with "random" changes in Qt, but that's a different story. 
> 
>> See https://codereview.qt-project.org/252208 for the discussion
>> and a possible solution here:
>> https://codereview.qt-project.org/#/c/254909/
>> 
>> So what's the correct way to deprecate a function and not
>> forgetting about QT_DEPRECATED later on as it happened with a lot
>> of functions during Qt4 times?
> 
> Currently there's apparently no agreed policy beyond the usual
> "submit a patch and find someone to +2 it".
> 
> The one I suggested in https://codereview.qt-project.org/#/c/254909/
> makes sure that it is noticed at some time, and at that time there
> was some period in between where people had a reasonable chance to
> update their code base without facing immediate regressions. I
> still don't think that is asked too much for a solution to a truly
> cosmetical issue.
> 
> Andre'
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B