[Development] Qt 6: inline namespace Qt

[Mutz, Marc]

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 
>>> behave
>>> 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 [1], 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
> improvement.

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 
ambiguous.

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, 
[Qt::]QString, [Qt::]QLineEdit.

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, 
[QtCore::]QString, [QtWidgets::]QLineEdit.

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 [1]. Yes, it also makes the life of us Qt developers that 
tad bit easier. But focus on the users!

Thanks,
Marc