On Tuesday 11 June 2024 12:44:11 GMT-7 Marc Mutz via Development wrote: > On 11.06.24 21:08, Giuseppe D'Angelo via Development wrote: > > Il 11/06/24 07:12, Thiago Macieira ha scritto: > [...] > > > > I'd like to know how much breakage this solution or mine would imply. > > I may have missed something, but I still can't see what your solution > is? I've enumerated the options, would you be so kind as to point out > which one you want (or continue numbering should I have missed an option)?
I don't have a concrete one. Just some wild ideas to discuss and see if they
are workable.
> 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
> 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.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Systems Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
