[Development] On how to deprecate API

[Edward Welbourne]

Kai Köhne (27 February 2020 16:46) wrote:
> Another thing I'm wondering about is the use of QT_DEPRECATED_SINCE in
> Qt's .cpp files. I see the benefit of QT_DEPRECATED_SINCE in the
> headers, because these are compiled into the user code, who in turn
> can use QT_DISABLE_DEPRECATED_BEFORE. Anyhow, for Qt modules, the
> define is always hardcoded to QT_DISABLE_DEPRECATED_BEFORE=0x050000
> (or 0x040800 for Windows), so is there any point in adding checks in
> our .cpp files, or is that just cargo cult? Shouldn't we just delete
> code that we don't want to have in Qt 6 anymore?

Well, there is a certain hygiene to the definition of anything being
nested identically in #if-ery to that around the declaration.
Likewise for use.

As for Qt6, well yes, once the code has merged up to Qt 6, we can remove
both the definition and the declaration.  When we come to do so, having
nice tidy #ife-ry around both makes it easy to be sure we know what to
remove, too.

Are you sure the define is hard-coded the same in developer builds and
in release builds ?  I can believe we would define it as you say in
release builds, but I'm fairly sure I've seen compiler errors due to
"that is not defined" when I've forgotten part of the #if-ery,
e.g. around code *exercising* something deprecated.  But I may just be
confused.

In any case, presumably a developer can over-ride the hard-coding (one
way or another) for local builds and benefit the same as users do, even
if the default for developer builds *isn't* already doing that.

	Eddy.