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 <development-boun...@qt-project.org> 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
