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' _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
