Hi,
just for the record, I would like to point out that the implications on
tooling need to be considered:
The clang-C-API (libclang) as used by Qt for Python, qdoc (and
potentially lupdate) does not know about inline namespaces AFAIK; the
code would have to ported to the Clang C++ API.
Regar
On 06.09.19 11:26, 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, -
06.09.2019, 20:28, "Thiago Macieira" :
> On Friday, 6 September 2019 09:04:09 PDT Giuseppe D'Angelo via Development
> wrote:
>> I was actually proposing option A, to avoid clashes. The Qt:: namespace
>> at the moment is simply too big to reasonably claim that there will be
>> no conflicts. A f
On 2019-09-06 19:26, Thiago Macieira wrote:
On Friday, 6 September 2019 09:04:09 PDT Giuseppe D'Angelo via
Development
wrote:
I was actually proposing option A, to avoid clashes. The Qt::
namespace
at the moment is simply too big to reasonably claim that there will be
no conflicts. A few examp
On Friday, 6 September 2019 09:04:09 PDT Giuseppe D'Angelo via Development
wrote:
> I was actually proposing option A, to avoid clashes. The Qt:: namespace
> at the moment is simply too big to reasonably claim that there will be
> no conflicts. A few examples that come into mind: Qt::horizontal,
>
Il 06/09/19 16:27, Mutz, Marc via Development ha scritto:
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,
On Friday, 6 September 2019 02:26:43 PDT Mutz, Marc via Development wrote:
> 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.
On 2019-09-06 14:34, Lars Knoll wrote:
On 6 Sep 2019, at 14:10, Giuseppe D'Angelo via Development
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 ch
On 06.09.2019 14:34, Lars Knoll wrote:
>
> Wouldn’t that pull all the enum value in the current Qt namespace into the
> users namespace?
I imagine code like in qnamespace.h would be a special case which would
not be 'inline'. It then couldn't use Q_{BEGIN,END}_NAMESPACE, but that
should be f
> On 6 Sep 2019, at 14:10, Giuseppe D'Angelo via Development
> 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
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 supe
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 follow
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 configurat
13 matches
Mail list logo
