On 12.06.24 20:21, Thiago Macieira wrote:
> On Tuesday 11 June 2024 12:44:11 GMT-7 Marc Mutz via Development wrote:
[...]
>> I don't want to break _any_ code. I could live with QAnyStringView(char)
>> being deprecated before a future QT_NO_CAST_FROM_CHAR becomes the
>> default, and demands users to pick between u8 (come C++20) and _L1 (and
>> use std::byte for binary¹).
>
> While trying to experiment with solutions, I noticed that QChar already has an
> #if and it's QT_NO_CAST_FROM_ASCII. When that is defined, you cannot write:
>
> QChar('a')
>
> because
>
> #ifndef QT_NO_CAST_FROM_ASCII
> // Always implicit -- allow for 'x' => QChar conversions
> QT_ASCII_CAST_WARN constexpr Q_IMPLICIT QChar(char c) noexcept :
> ucs(uchar(c)) { }
> #ifndef QT_RESTRICTED_CAST_FROM_ASCII
> QT_ASCII_CAST_WARN constexpr explicit QChar(uchar c) noexcept : ucs(c) {
> }
> #endif
> #endif
>
> https://gcc.godbolt.org/z/rqovbzMTz
Yes, I had mentioned QT_NO_CAST_FROM_ASCII, and I did offer to add it to
QASV. That QASV doesn't respect QT_N_C_F_A can be considered a bug. I
would really like to wait until we require C++20's char8_t, though, so
users can use u8"..." as a way to keep their code working across
multiple Qt versions, falling into the pit of success (if they instead
start to wrap their string literals in QU8SV, that's not what we want
them to do: u8"" should be the idiomatic way to create string literals
in Qt - it's by far the simplest and most efficient, esp. if we can get
the compile-time US-ASCII auto-detection going reliably, and not just in
constexpr contexts).
>> But _if_, until then, we want to _be_ consistent, incl. between C++17
>> and C++20 builds, btw, then statistics say that you will have fewer
>> users of the relatively-recent QASV(char) API than the other APIs, incl.
>> the important group of users still on Qt 5, so the path of least risk is
>> "clearly" fixing QAnyStringView, is it not?
>>
>> Esp. if we pick the fix back to 6.5 or at least 6.8.
>
> Doubtful, given it's a refactor. There's no reason to backport refactors
I don't know where you got your definition of refactoring from, but the
original source (Fowler) defines it as
https://refactoring.com/:
> Refactoring is a disciplined technique for restructuring an existing
> body of code, altering its internal structure without changing its
> external behavior.
We want/need to change the "external behaviour", so whatever we do, it
is not a _refactoring_.
Thanks,
Marc
.--
Marc Mutz <marc.m...@qt.io> (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
