[Development] Qt 6: inline namespace Qt
marc at kdab.com
Fri Sep 6 16:27:04 CEST 2019
On 2019-09-06 14:34, Lars Knoll wrote:
>> On 6 Sep 2019, at 14:10, Giuseppe D'Angelo via Development
>> <development at qt-project.org> wrote:
>> Il 06/09/19 11:26, Mutz, Marc via Development ha scritto:
>>> The change is SC, and makes namespaced and non-namespaced builds
>>> the same.
>> Small question: the claim here is that the change is SC; however below
>> it's pointed out that there may be slight differences in name lookup
>> (in some super-corner cases, I concede). That would make it non-SC.
>> Which one is it? :-)
Yes, the change is SC, because it allows more code to be compiled that
wouldn't've before (see , see Qt::endl). There's a SiC Type A
component, which Lars' comments on below, but as per QUIP-6, we don't
care about those anymore.
>> (Disclaimer: I would agree with the change, cf. the Qt::endl
>> discussion with gerrit).
> Wouldn’t that pull all the enum value in the current Qt namespace into
> the users namespace? Things like Qt::AlignLeft?
Yes, and no. No, the enums are still defined in namespace Qt. Yes, the
Qt:: prefix is then optional, so a user name AlignLeft would conflict at
the source level, giving a ambiguity error, fixable by explicit
prefixing with Qt:: (which is what's required now, and therefore isn't
SiC), or ::, or UserNamespace.
> I can’t see how moving
> from requiring the Qt prefix there to not requiring it anymore is an
This is a small problem (a SiC Type A) that affects only identifiers
that are currently already in namespace Qt and that users use in their
own code to mean something else. I don't expect that to be a problem in
practice; no code changes meaning, some user code just becomes
The proposal is not about that. The proposal is about moving *all* of Qt
into an inline Qt namespace so that all of Qt would be namespaced for
the reasons mentioned in OP.
Let's name the options, as I see them (new additions welcome!):
([NS::] in the below means that namespace is inline)
A) We can keep the existing Qt namespace, then types would be named
[Qt::]Qt::Alignment, [Qt::]QString, [Qt::]QLineEdit, which, in the first
case, is a bit funny but would only show up in the debugger.
B) Same as (A), but we flatten the existing namespace Qt into the new
inline namespace Qt. This is what I propsed in OP: [Qt::]Alignment,
C) I don't think you can have two namespace blocks with the same name
and have one inline and the other not, but if you can, then we could
erect the new inline namespace Qt ex the current non-inline one:
Qt::Alignment, [Qt::]QString, [Qt::]QLineEdit.
D) Alternatively, we can go the extra mile and make a per-library inline
namespace, ex the current non-inline Qt namespace: Qt::Alignment,
I'd still ask to first try (B). The name clashes are entirely
theoretical atm, and when and if they unexpectedly become a source of
problems, we still have the option to go with (A), (C), or (D).
I just think that requiring all users to change from endl to Qt::endl is
entirely unnecessary in the light of options (A)-(D), and I also think
that we as a project should do everything in our power to make our API
harder to use incorrectly (wait, that's _your_ tag line :), and for me
that includes avoiding the subtle name-lookup issues that Daniel
explained in . Yes, it also makes the life of us Qt developers that
tad bit easier. But focus on the users!
More information about the Development