From d421418bea209f9f88a3bf890596fe7734c90ed1 Mon Sep 17 00:00:00 2001 From: Marc Mutz Date: Wed, 17 Aug 2022 08:41:50 +0200 Subject: [PATCH] [docs] QAnyStringView: remove the prediction that Qt 7 will drop L1 UTF-8 can never replace Latin-1 as the go-to US-ASCII superset, because, as a variable-length encoding, it cannot use the important size check in equality comparisons with UTF-16 to avoid having to iterate the whole string data. Mention that. UTF-8 only makes sense in a UTF-8-only environment where the size check works again. As long as our preferred charset is UTF-16, Latin-1 must be the preferred US-ASCII wrapper. Change-Id: Ibe52cfc0c9fce0e7aaacd4cd8d6361e8d8bdee3d Reviewed-by: Thiago Macieira (cherry picked from commit 6b146566e6686477af99126945df4fd2c059b426) Reviewed-by: Qt Cherry-pick Bot --- src/corelib/text/qanystringview.qdoc | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/corelib/text/qanystringview.qdoc b/src/corelib/text/qanystringview.qdoc index f34a1c552eb..594b7b55b0b 100644 --- a/src/corelib/text/qanystringview.qdoc +++ b/src/corelib/text/qanystringview.qdoc @@ -17,9 +17,11 @@ Unlike QStringView and QUtf8StringView, QAnyStringView can hold strings of any of the following encodings: UTF-8, UTF-16, and - Latin-1. The latter is supported to keep old source working - efficiently. It is expected that by Qt 7, the Latin-1 support will - be removed. + Latin-1. The latter is supported because Latin-1, unlike UTF-8, + can be efficiently compared to UTF-16 data: a length mismatch + already means the strings cannot be equal. This is not true for + UTF-8/UTF-16 comparisons, because UTF-8 is a variable-length + encoding. The string may be represented as an array (or an array-compatible data-structure such as QString, std::basic_string, etc.) of \c