Re: [Development] Qt UDL operators
Hi, On 05/04/2022 14:28, Sona Kurazyan wrote: I'm not sure how this work: unless the new _s takes another kind input (e.g. number literals), you can't add it no matter what, as users under "using namespace Qt;" would then get a conflict...? Right, it will work only if the types of the literals with the same name differ, so we can add e.g. _s for seconds (or something else) in future. Well, if that's the case, they can _also_ both be added to the "free" _qX versions, before their deprecation kicks in. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt UDL operators
Hi, > From: Giuseppe D'Angelo > > Hi, > > Il 04/04/22 15:53, Sona Kurazyan ha scritto: > > I see two main issues with keeping both: > > > > - If we want to add UDLs with same names for different domains in future, > adding the "q"-prefixed counterparts will be problematic. For example, let's > say we want to add Qt::inline Literals::inline OtherDomain::_s, what should > be the "q"-prefixed version of it? We can name it to something like _qXs, > where X is some domain specific letter, but it will require even more typing, > and make the name inconsistent with Qt::inline Literals::inline > OtherDomain::_s. > > I'm not sure how this work: unless the new _s takes another kind input > (e.g. number literals), you can't add it no matter what, as users under > "using namespace Qt;" would then get a conflict...? > Right, it will work only if the types of the literals with the same name differ, so we can add e.g. _s for seconds (or something else) in future. > > > > > - We will have multiple ways of doing the same thing, and I assume, it might > be confusing for users. > > Sure thing, that's why I'm OK at deprecating one of the two. > > Thanks, > I'll wait a bit more, to make sure that there are no more concerns/objections against deprecating _qX and adding their counterparts to Qt::StringLiterals, and merge https://codereview.qt-project.org/c/qt/qtbase/+/401308/ and https://codereview.qt-project.org/c/qt/qtbase/+/401604/. Best regards, Sona ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt UDL operators
Hi, Il 04/04/22 15:53, Sona Kurazyan ha scritto: I see two main issues with keeping both: - If we want to add UDLs with same names for different domains in future, adding the "q"-prefixed counterparts will be problematic. For example, let's say we want to add Qt::inline Literals::inline OtherDomain::_s, what should be the "q"-prefixed version of it? We can name it to something like _qXs, where X is some domain specific letter, but it will require even more typing, and make the name inconsistent with Qt::inline Literals::inline OtherDomain::_s. I'm not sure how this work: unless the new _s takes another kind input (e.g. number literals), you can't add it no matter what, as users under "using namespace Qt;" would then get a conflict...? - We will have multiple ways of doing the same thing, and I assume, it might be confusing for users. Sure thing, that's why I'm OK at deprecating one of the two. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt UDL operators
I see two main issues with keeping both:
- If we want to add UDLs with same names for different domains in future,
adding the "q"-prefixed counterparts will be problematic. For example, let's
say we want to add Qt::inline Literals::inline OtherDomain::_s, what should be
the "q"-prefixed version of it? We can name it to something like _qXs, where X
is some domain specific letter, but it will require even more typing, and make
the name inconsistent with Qt::inline Literals::inline OtherDomain::_s.
- We will have multiple ways of doing the same thing, and I assume, it might be
confusing for users.
Best regards,
Sona
> -Original Message-
> From: Development On Behalf Of
> Giuseppe D'Angelo via Development
> Sent: Monday, April 4, 2022 3:22 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt UDL operators
>
> Il 30/03/22 15:44, Sona Kurazyan ha scritto:
> > # keep _qs, _qba, add _qL1, keep Qt::StringLiterals::_L1, add
> > Qt::StringLiterals::{_s, _ba}
> > (https://codereview.qt-project.org/c/qt/qtbase/+/402948
> > <https://codereview.qt-project.org/c/qt/qtbase/+/402948> +
> > https://codereview.qt-project.org/c/qt/qtbase/+/401308
> > <https://codereview.qt-project.org/c/qt/qtbase/+/401308>)
>
> I'd personally vote for this option -- whatever users use, they have the full
> set. It'd be super-annoying to have to mix and match (codebase already
> using _qba now has to import the others...)
>
> I'm not also too sold on the argument that _qs ought to be deprecated.
> Qt de-facto has always reserved every single name starting in q (or Q) in the
> global namespace. Whether polluting the global namespace (and/or living
> "without a namespace") is a good idea or not, that's a sailed ship
> unfortunately. That just carries over to these UDLs. This is to say, I'm not
> opposing their deprecation and subsequent removal, and I'm much in favour
> of actual deprecation rather than hiding behind yet another
> QT_NO_GLOBAL_UDLS or similar, I'm just saying that "name pollution" isn't a
> very much convincing argument (for the good and the bad)...
>
> My 2 c,
>
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software
> Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt UDL operators
Il 30/03/22 15:44, Sona Kurazyan ha scritto:
# keep _qs, _qba, add _qL1, keep Qt::StringLiterals::_L1, add
Qt::StringLiterals::{_s, _ba}
(https://codereview.qt-project.org/c/qt/qtbase/+/402948
+
https://codereview.qt-project.org/c/qt/qtbase/+/401308
)
I'd personally vote for this option -- whatever users use, they have the
full set. It'd be super-annoying to have to mix and match (codebase
already using _qba now has to import the others...)
I'm not also too sold on the argument that _qs ought to be deprecated.
Qt de-facto has always reserved every single name starting in q (or Q)
in the global namespace. Whether polluting the global namespace (and/or
living "without a namespace") is a good idea or not, that's a sailed
ship unfortunately. That just carries over to these UDLs. This is to
say, I'm not opposing their deprecation and subsequent removal, and I'm
much in favour of actual deprecation rather than hiding behind yet
another QT_NO_GLOBAL_UDLS or similar, I'm just saying that "name
pollution" isn't a very much convincing argument (for the good and the
bad)...
My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt UDL operators
Following Thiago's advice, updated https://codereview.qt-project.org/c/qt/qtbase/+/401604/ to enable the warning only after N+4 minor release of Qt (i.e. 6.8). That should give more time for updating the existing code. Best regards, Sona > -Original Message- > From: Development On Behalf Of > Thiago Macieira > Sent: Sunday, April 3, 2022 4:05 PM > To: development@qt-project.org > Subject: Re: [Development] Qt UDL operators > > On Saturday, 2 April 2022 07:46:33 PDT Kai Köhne wrote: > > If you use the "Qt Quick Application" wizard in any recent Qt Creator, > > and selected a Qt 6 version as minimally required version, the > > generated main.cpp code will contain code like > > > > const QUrl url(u"qrc:/myproject/main.qml"_qs); > > > > Deprecating the u""_qs will mean that we break the most basic user > > 'hello world' projects utilizing this wizard. I therefore think it's > > too late to deprecate u""_qs any time soon. > > It'll have to be a multi-year process then. > > Step 1) stop generating this for new code > > Step 2) 2 years later, add the warning of deprecation (the actual code change > can be done now, with the warning enabled for the N+4 minor release of Qt) > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt UDL operators
On Saturday, 2 April 2022 07:46:33 PDT Kai Köhne wrote: > If you use the "Qt Quick Application" wizard in any recent Qt Creator, and > selected a Qt 6 version as minimally required version, the generated > main.cpp code will contain code like > > const QUrl url(u"qrc:/myproject/main.qml"_qs); > > Deprecating the u""_qs will mean that we break the most basic user 'hello > world' projects utilizing this wizard. I therefore think it's too late to > deprecate u""_qs any time soon. It'll have to be a multi-year process then. Step 1) stop generating this for new code Step 2) 2 years later, add the warning of deprecation (the actual code change can be done now, with the warning enabled for the N+4 minor release of Qt) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt UDL operators
> From: Development On Behalf Of Sona
> Kurazyan
> Sent: Wednesday, March 30, 2022 3:44 PM
> To: Marc Mutz ; development@qt-project.org
> Subject: [Development] Qt UDL operators
>
> [...]
> As you can see, https://codereview.qt-project.org/c/qt/qtbase/+/401604 raised
> a lot of discussion, and not everyone felt comfortable with deprecating (and
> later removing) the “q”-prefixed UDLs.
> To summarize the discussion, I see following options:
>
> 1. deprecate _qs, _qba, add Qt::StringLiterals::{_s, _ba}, as suggested
> above (https://codereview.qt-project.org/c/qt/qtbase/+/401308 +
> https://codereview.qt-project.org/c/qt/qtbase/+/401604)
> 2. keep _qs, _qba, add_qL1 and remove Qt::StringLiterals::_L1
> (https://codereview.qt-project.org/c/qt/qtbase/+/402948 +
> https://codereview.qt-project.org/c/qt/qtbase/+/402950)
> 3. keep _qs, _qba, add _qL1, keep Qt::StringLiterals::_L1, add
> Qt::StringLiterals::{_s, _ba}
> (https://codereview.qt-project.org/c/qt/qtbase/+/402948 +
> https://codereview.qt-project.org/c/qt/qtbase/+/401308)
>
> I personally prefer the 1st option, but it would be nice to hear more
> opinions/concerns and decide how to proceed.
If you use the "Qt Quick Application" wizard in any recent Qt Creator, and
selected a Qt 6 version as minimally required version, the generated main.cpp
code will contain code like
const QUrl url(u"qrc:/myproject/main.qml"_qs);
Deprecating the u""_qs will mean that we break the most basic user 'hello
world' projects utilizing this wizard. I therefore think it's too late to
deprecate u""_qs any time soon.
My 2 cents,
Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Qt UDL operators
Hi,
I'd like to continue the discussion started by Marc and try to find out what
should be the "fate" of our literal operators.
For the reasons explained by Marc, we've added _L1 to Qt::inline
Literals::inline StringLiterals namespace, but we still have the literals
operators _qs (for QString) and _qba (for QByteArray) in the global inline
QtLiterals namespace. This is clearly inconsistent, so the next logical step is
to move _qs to _qba to Qt::inline Literals::inline StringLiterals too. This
assumes:
* Adding Qt::inline Literals::inline StringLiterals ::{_s, _ba}
(https://codereview.qt-project.org/c/qt/qtbase/+/401308)
* Deprecating _qs and _qba
(https://codereview.qt-project.org/c/qt/qtbase/+/401604)
As you can see, https://codereview.qt-project.org/c/qt/qtbase/+/401604 raised a
lot of discussion, and not everyone felt comfortable with deprecating (and
later removing) the "q"-prefixed UDLs.
To summarize the discussion, I see following options:
1. deprecate _qs, _qba, add Qt::StringLiterals::{_s, _ba}, as suggested
above (https://codereview.qt-project.org/c/qt/qtbase/+/401308 +
https://codereview.qt-project.org/c/qt/qtbase/+/401604)
2. keep _qs, _qba, add_qL1 and remove Qt::StringLiterals::_L1
(https://codereview.qt-project.org/c/qt/qtbase/+/402948 +
https://codereview.qt-project.org/c/qt/qtbase/+/402950)
3. keep _qs, _qba, add _qL1, keep Qt::StringLiterals::_L1, add
Qt::StringLiterals::{_s, _ba}
(https://codereview.qt-project.org/c/qt/qtbase/+/402948 +
https://codereview.qt-project.org/c/qt/qtbase/+/401308)
I personally prefer the 1st option, but it would be nice to hear more
opinions/concerns and decide how to proceed.
Thanks,
Sona
From: Development On Behalf Of Marc Mutz
Sent: Tuesday, March 29, 2022 4:31 PM
To: development@qt-project.org
Subject: Re: [Development] Renaming QLatin1String to QLatin1StringView
Hi all,
There seems to be some confusion over the form the literal operators ("UDLs")
have taken: Qt::inline Literals::inline StringLiterals::_L1 instead of inline
QtLiterals::_qL1.
There are several reasons for doing it this way, and it's important for any
follow-up discussions to understand them, so bear with me as I lay them out:
1. UDLs are operators, and as operators, the usual way to call them is with
unqualified calls: a + b may be seen by the compiler as NS::operator+(a, b),
but that's not how we'd like to write our code. So, we'd like to use "meep"_L1,
not QtLiterals::operator""_L1("meep", 4), assuming the latter is even valid C++.
2. All unqualified function calls in C++ always consider all overloads that
are in scope. If two of them conflict (are ambiguous), as an API consumer, you
have three ways to fix this:
* change the arguments (e.g. by casting) to avoid the ambiguity (not
possible for UDLs, because the argument must always be a string, integer, or
floating-point literal)
* use a qualified call (foo() -> NS1::foo() or NS2::foo(), depending on
which one you want; undesirable for UDLs, as per point (1))
* change the scope so as to remove one of the conflicting overloads
while leaving the other (this is what namespaces were designed for): Instead of
"using namespace NS1; using namespace NS2; foo();", you do "using namespace
NS1; foo();"
1. Seeing as (a) and (b) are not applicable for UDLs, (c) is the only
option. This is why std arranges its UDLs that way, and that's why we chose to
do the same for _L1. It allows API consumers to pick Qt's _L1 or some other
(presumably their own), by adding or removing using directives. The
disadvantage is that you cannot access these UDLs (std or Qt's) without first
writing a using directive. This is a necessary evil, though:
2. We have prior art (_qs) which does things differently: ::inline
QtLiterals::_qs. This UDL is declared in an inline namespace hanging in the
global namespace. That means we don't need to write a using directive to be
able to use it, but it also means API consumers cannot switch it off. It's
always in-scope. If they now have a conflict, all they can do is to move the
code to a separate .cpp file to include less headers or to not use the
conflicting UDL. The conflict is unfixable using normal means, which is why we
need to use an additona; character, the q prefix, to limit possible conflicts.
But we can't eliminate them. As a physicist, it's not hard to come up with UDLs
that start with q: _qcd, _quant, ... We like to think that Qt owns the q
prefix, but it doesn't (qsort), so it's just a way to make clashes less likely.
With KDE adopting the same strategy with a different letter, we already claim
1/13th of the available C++ namespace! The only reason why we got away with it,
so far, is that we don't use very short function names like qs(), qe(), etc.
But that's exactly what we've introduced with _qs, and it's why it should be
fixed.
3. UDLs should be short at the use site, because we want people to use
