Hi Marc,
Could you elaborate a bit, what the real value of this change?
I'm asking, because there are only cons I see now:
1) Adding inline after namespace *implicitly* throws all symbols to the
global (or outer) namespace, which, potentially might lead to name
clashes. For example, the following code won't be compiled:
inline namespace foo { void bar() {} };
void bar() {}
// ...
bar();
2) Negative user experience especially when moving to a fresh Qt
version: some names are implicitly appears.
3) Potentially force users to compile Qt in a namespace. This is not
required in a lot of cases, really. One of the cases might be when your
app is a plugin and a host app also uses Qt of the same version. But
it's rarely.
On 9/6/19 11:26 AM, Mutz, Marc via Development wrote:
> Hi,
>
> I would like to propose to make the existing Qt namespace inline and
> move all of Qt's declarations into it.
>
> == TL;DR: ==
>
> Qt can already, optionally, be configured into a user-specified
> namespace (QT_BEGIN_NAMESPACE/QT_END_NAMESPACE, -qtnamespace), and
> this is one of the build configurations in the CI, so we're reasonably
> sure it works. The change would be very limited (via existing macros).
> Only pre-existing declarations of "namespace Qt" would have to be
> touched. The change is SC, and makes namespaced and non-namespaced
> builds behave the same.
>
>
> == Rationale ==
>
> As we see with the introduction of Qt::endl, a SiC change, we have a
> problem in that we have existing Qt API that traditionally (dare I say
> "for decades") doesn't have a Q/q prefix. Adding Qt:: in front now is
> a massive SiC change. Making the Qt namespace inline allows users to
> continue to write << endl; while we still have the symbol moved out of
> the global namespace.
>
> Furthermore, the global namespace is special in that ADR does "not
> work in it"[1]; [1] can be summarized as "C++ just works better when
> all types are in some namespace". This means that we have very subtle
> differences in name lookup, depending on whether Qt is compiled with
> -qtnamespace or without. I remember having hit these multiple times in
> the past, but can't remember details anymore (and one or the other
> might have had to do more with two-phase name lookup in templates, and
> not with ADR).
>
> [1]
> https://groups.google.com/forum/#!msg/comp.lang.c++.moderated/1Qz71aFnXlI/Gd71gwRaWssJ
>
> The language has also started stipulating in a few places that certain
> functions are only found via ADR, not by ordinary name lookup (the
> begin() and end() functions called by ranged-based loop for non-array
> types that don't have a .begin()/.end() come to mind). There seems to
> be some confusion[2] over whether that means that functions in the
> global namespace would be found at all under such circumstances (I
> guess Ville could confirm or deny), and vice versa: when functions are
> defined as friends in the body of types (in which case they're only
> found via ADL and not via ordinary name lookup) in the global
> namespace, do they exist at all? But we can do very well without such
> dipping into C++'s dark corners: if we are always in a namespace, ADL
> always works.
>
> [2]
> https://stackoverflow.com/questions/25133383/does-adl-work-for-the-global-namespace
>
> Thus, I'd like to propose to move all of Qt into an inline namespace
> Qt. Any user namespace would be wrapping it:
>
> inline namespace Qt {
> class QString;
> }
>
> without `-qtnamespace` and
>
> namespace TestNamespace {
> inline namespace Qt {
> class QString;
> }
> }
>
> with `-qtnamespace TestNamespace`.
>
> Because the namespace is inline, existing code will just have to be
> recompiled to pick it up. In particular, no `using namespace Qt` is
> needed anywhere to still use QString etc unqualified, yet, the
> executable would refer to Qt::QString everywhere. Even
> Q_DECLARE_TYPEINFO would continue to work unchanged, since you don't
> need to open an inline namespace to specialise templates from it.
>
> It's a BiC change, though, so it's for Qt 6.0, if ever.
>
>
> == Design Decisions ==
>
> === inline Qt::Qt3D or inline Qt3D ? ===
>
> Some Qt modules have started using a (non-inline) namespace, often
> derived from the module or library name, since Qt 4 (QtPatternist,
> QtConcurrent, Qt3D, ...). A legitimate design would leave the Qt
> namespace alone, and put each library Lib into an inline namespace
> QtLib instead. This would solve the same problems, and could be used
> to unify the different libraries' choices of handling naming. The
> reason that it's not proposed here is that it's a much grander scheme
> than just wrapping everything into `inline namespace Qt` - all the Qt
> modules are already known to work with the user namespace feature and
> this proposal simply suggests to append `inline namespace Qt {` to
> QT_BEGIN_NAMESPACE so that this macro always expands to at least one
> namespace begin. Giving each module or library its own inline
> namespace would be much more work.
>
>
> Flame away :)
>
> Thanks,
> Marc
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
--
Best Regards,
Fanaskov Vitaly
Senior Software Engineer
The Qt Company / Qt Quick and Widgets Team
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
