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
