On Thu, May 21, 2026 at 1:31 PM Volker Hilsheimer via Development <[email protected]> wrote: > > > Am 21.05.26 um 13:30 schrieb Volker Hilsheimer via Development: > >>> On 21 May 2026, at 20:07, Edward Welbourne via Development > >>> <[email protected]> wrote: > >>> > >>> Artem Dyomin (21 May 2026 12:49) wrote: > >>> > >>>> Well, according to the input, the word "experimental" brings messages > >>>> regarding temporary status and transferring to public API in the future, > >>>> that doesn't fit well to some cases. To address this, I'd rather choose > >>>> the word that reflects its semiprivate status and limited compatibility > >>>> guarantees. > >>>> > >>>> * protected - for me, it doesn't sound clear in terms of headers > >>>> * limited_compat - looks good, but doesn't reflect private status > >>>> * semiprivate - perhaps better as it reflects what it does > >>>> > >>>> So, what about "semiprivate"? > >>> It's a half-way decent answer. > >>> One other name springs to mind, more apt at least than "protected", but > >>> likewise inspired by terms from C++: "mutable" - after all, we're > >>> talking about APIs on which we don't promise compatibility - they may > >>> change from one release to the next. > >>> > >>> Eddy. > >> > >> One idea I just had was to use the major.minor version number of Qt. > >> > >> #include <QtGui/6.12/qrhi.h> > >> > >> The advantage is that you are clearly seeing that you are using an API > >> that is specific to that Qt version. > >> The disadvantage is that you have to change the include statement when > >> upgrading Qt version, but that might as much be an advantage because it > >> creates awareness - just because things still compile doesn't necessary > >> mean that they also still work the same way. And it can be made very > >> simple by having a single wrapper-header for a project. > >> > >> […] > > > On 21 May 2026, at 23:55, Mathias Hasselmann via Development > > <[email protected]> wrote: > > > > This goes into the same direction I was thinking of: Versioning. > > > > What speaks against putting these APIs into versioned headers and > > namespaces? > > > > Mathias >
As a user of QRhi since it was in very, very experimental preview in Qt 5.12, I really don't see which value would be brought by requiring versioned headers, only more churn ; there's been only two or three API breaks that impacted me between 5.12 and 6.11, but versioned headers would require #ifdef __has_include(...) for every individual Qt version in-between even when most didn't break anything and just added e.g. some enum values or new functions. If it were to happen, the very next thing I would do in my code is pre-emptively add a project-local IncludeQRhi.hpp header that would look like: #pragma once #if __has_include(<QtGui/7.0/qrhi.h>) #include <QtGui/7.0/qrhi.h> #elif __has_include(<QtGui/6.20/qrhi.h>) #include <QtGui/6.20/qrhi.h> #elif __has_include(<QtGui/6.19/qrhi.h>) ... #elif __has_include(<private/qrhi.h>) #include <private/qrhi.h> #endif > > We wouldn’t be able to maintain multiple versions of those APIs in parallel > anyway, so a <QtGui/6.12/qrhi.h> would be gone once we bump the version that > dev build to 6.13. Or they would linger as stale headers in self-built Qt. > > And as we are using those headers ourselves as installed headers in Qt > modules (i.e. Qt Multimedia has to #include <QtGui/rhi/qrhi.h> today), it > would be very impractical indeed to use that scheme, probably requiring some > weeks of submodule update catch-up just to get to a worktree that builds. > > Volker > > -- > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
