Qt6: Replacing QWebEngine prefix with a namespace

Prefixed class names like QWebEngineCookieStore are old-school and not "modern C++". Should we switch then to the more modern alternative of namespaces and use QtWebEngine::QCookieStore instead?

Pros and cons of namespaces

An often-touted benefit of namespaces is the avoidance of name collisions. This is, however, only an advantage over plain, unprefixed names: it is not an advantage over the QWebEngine prefix. Indeed, the actual advantages over our prefixed names are slight.

Tools like QDoc understand namespaces and can give them special treatment. However, we already have the concept of modules in Qt, making organization by namespaces redundant and more likely to confuse users than assist them.

We would save some typing within the implementation, but probably add more typing for users.

Ultimately, the only significant advantage of namespaces is that they are more "modern C++", meaning more stylistically consistent with other, newer, codebases.

As for disadvantages, in new code there are essentially none. Qt WebEngine is not new code though, so how would the switch to namespaces actually work?

Switching to namespaces

The switch would have to happen in two stages. First, in Qt 5, we would have to add the new namespaced names as typedefs:

// in global header
class QWebEngineCookieStore;
namespace QtWebEngine {
using QCookieStore = QWebEngineCookieStore;
}

// in cookie store header
class QWebEngineCookieStore {
  // ...
};

Then, in Qt 6, we would rename the classes and add typedefs of the old names for backward compatibility:

// in global header
namespace QtWebEngine {
class QCookieStore;
}
using QWebEngineCookieStore = QtWebEngine::QCookieStore;

// in cookie store header
namespace QtWebEngine {
class QCookieStore {
  // ...
};
}

The switch is not fully source compatible. User code that forward declares class QWebEngineCookieStore would be broken in Qt 6: the class is now a typedef. The incompatibility is mitigated by the fact that all public classes would now be forward declared in global headers, meaning there would be no further need for forward declarations in user code. Existing forward declarations in user code would be simply have to be deleted in the transition to Qt 6.

Forward declaring all public classes also means that adding a new class will trigger a rebuild of a larger portion the library than before.

Conclusion

It is doable, but the benefits are only cosmetic.