On Friday 14 June 2024 09:32:36 GMT-7 Marc Mutz via Development wrote:
> > #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).They *can* now. Some of them choose not to because they've chosen to use vendors who cannot upgrade. Likewise, defining the macro is a choice. Either way it's a choice and choices can be revisited. Saying that C++20 code is cleaner (corollary: C++17 code requires typing more or has worse performance) is a feature, not a bug. Anyway, I am convinced and will review your patches, next week. -- 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
