[Development] Deprecated/Obsolete API that survived the transition from Qt 5 to Qt 6

Volker Hilsheimer volker.hilsheimer at qt.io
Wed Apr 7 22:40:38 CEST 2021

> On 7 Apr 2021, at 17:44, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
> On Mittwoch, 7. April 2021 16:53:16 CEST Henry Skoglund wrote:
>> On 2021-04-07 16:11, Volker Hilsheimer wrote:
>>>> On 7 Apr 2021, at 15:55, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
>>>> On Mittwoch, 7. April 2021 15:18:10 CEST Giuseppe D'Angelo via
>>>> Development
>>>> wrote:
>>>>> Il 07/04/21 14:56, Sze Howe Koh ha scritto:
>>>>>> Is it acceptable to remove them during Qt 6's lifetime? Or should we
>>>>>> wait till Qt 7?
>>>>> It's for Qt 7, I'm afraid. We're bound to an API/ABI compatibility
>>>>> promise. And not marking things _in code_ but only in docs isn't good
>>>>> enough.
>>>> We remove and change private API all the time. If it was declared
>>>> deprecated long ago, we could argue it is kind of private in qt6.
>>>> 'Allan
>>> But declaring an API deprecated requires two things:
>>> * documentation marking it as obsolete
>>> * QT_DEPRECATED_SINCE macro usage to trigger compile time warnings
>>> QMessageBox::buttonText for instance doesn’t have said macro, and is not
>>> inline, so we can’t remove it without de-facto breaking BiC in a material
>>> way (since at least on Windows, the DLL found at runtime has to provide
>>> all symbols that the static import library had at link time, no matter if
>>> used or not).
>>> So, what would be not only acceptable but desirable is a bunch of changes
>>> that add QT_DEPRECATED_SINCE to those methods that so far have only been
>>> documented as obsolete. And perhaps even a bit of qdoc tinkering to help
>>> us maintain consistency.
>>> Volker
>> Hi, not to be a nitpick, but doing that stunt is possible on Windows,
>> i.e. you can remove obsolete stuff from .dlls without rebuilding any
>> app, if that obsolete stuff never is called.
>> You can see what symbols/functions your .exe or .dll needs by doing a
>> *dumpbin/imports* on it, and normally (unless you're crazy and call
>> *all* functions in a library) the list of imports will be a subset of
>> what the static import library provides/offers at link time.
> Yeah, we wouldn't be able to remove private API if that wasn't the case.
> Allan

Right, thanks for correcting.

Nevertheless, without compile time warning those methods will still be in use, so we can’t remove them.


More information about the Development mailing list