summaryrefslogtreecommitdiffstats
path: root/src/corelib/text/qstringview.cpp
diff options
context:
space:
mode:
authorMarc Mutz <marc.mutz@qt.io>2025-02-06 08:15:36 +0100
committerTopi Reinio <topi.reinio@qt.io>2025-02-28 13:51:18 +0000
commitb7a67b46e66f161def5bf879f19c66d3fcec1d8b (patch)
treefeb68ba2f835a8aeced04ad3563230db49ecb011 /src/corelib/text/qstringview.cpp
parent6f89357f59b507c0dcdc177bc1ecfbbc94d6fed3 (diff)
Long live \constraints!
We have divergence in the way we document function, operator and constructor constraints. About half use \note, while the other doesn't. Some say "if and only if" while others say just "participates only if". So add a qdoc macro, \constraints, to semantically mark up these constraints. It expands to a section titled `Constraints`, and uses a predefined sentence (prefix) for constraints. Documentation for constraints is moved to the end of the comment blocks to separate them from the rest of the text. Apply them to all the standard-ish constraint documentation blocks (grepped for "participate"). I didn't look for other, one-off, ways documentation authors may have documented constraints, but I'm also not aware of any. Re-wrap lines only if the result fits into a single line. As a drive-by, drop additional "if"s, as in "only if X and -if- Y" to make the texts work with the `Constraints` section. Fixes: QTBUG-106871 Pick-to: 6.9 6.8 6.5 Change-Id: I18c2f9f734474017264e49165389f8c9c7f34030 Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Diffstat (limited to 'src/corelib/text/qstringview.cpp')
-rw-r--r--src/corelib/text/qstringview.cpp12
1 files changed, 6 insertions, 6 deletions
diff --git a/src/corelib/text/qstringview.cpp b/src/corelib/text/qstringview.cpp
index 923eed5539c..b3ac645ceda 100644
--- a/src/corelib/text/qstringview.cpp
+++ b/src/corelib/text/qstringview.cpp
@@ -196,7 +196,7 @@ QT_BEGIN_NAMESPACE
The behavior is undefined if \a len is negative or, when positive, if \a str is \nullptr.
//! [compatible-char-types]
- This constructor only participates in overload resolution if \c Char is a compatible
+ \constraints \c Char is a compatible
character type. The compatible character types are: \c QChar, \c ushort, \c char16_t and
(on platforms, such as Windows, where it is a 16-bit type) \c wchar_t.
//! [compatible-char-types]
@@ -265,15 +265,15 @@ QT_BEGIN_NAMESPACE
\c{std::data(str)} must remain valid for the lifetime of this string view object.
- This constructor only participates in overload resolution if \c Container is a
- container with a compatible character type as \c{value_type}. The
- compatible character types are: \c QChar, \c ushort, \c char16_t and
- (on platforms, such as Windows, where it is a 16-bit type) \c wchar_t.
-
The string view will be empty if and only if \c{std::size(str) == 0}. It is unspecified
whether this constructor can result in a null string view (\c{std::data(str)} would
have to return \nullptr for this).
+ \constraints \c Container is a
+ container with a compatible character type as \c{value_type}. The
+ compatible character types are: \c QChar, \c ushort, \c char16_t and
+ (on platforms, such as Windows, where it is a 16-bit type) \c wchar_t.
+
\sa isNull(), isEmpty()
*/