[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 <thiago.macieira@intel.com>
(cherry picked from commit 6b146566e6686477af99126945df4fd2c059b426)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This commit is contained in:
Marc Mutz 2022-08-17 08:41:50 +02:00 committed by Qt Cherry-pick Bot
parent eed1e0396f
commit d421418bea

View File

@ -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