summaryrefslogtreecommitdiffstats
path: root/src/corelib/text/qanystringview.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/qanystringview.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/qanystringview.cpp')
-rw-r--r--src/corelib/text/qanystringview.cpp19
1 files changed, 8 insertions, 11 deletions
diff --git a/src/corelib/text/qanystringview.cpp b/src/corelib/text/qanystringview.cpp
index ad992fbfc39..da72e5f18d4 100644
--- a/src/corelib/text/qanystringview.cpp
+++ b/src/corelib/text/qanystringview.cpp
@@ -145,8 +145,7 @@ QT_BEGIN_NAMESPACE
The behavior is undefined if \a len is negative or, when positive, if \a str is \nullptr.
- This constructor only participates in overload resolution if \c Char is a compatible
- character type.
+ \constraints \c Char is a compatible character type.
\sa isNull(), {Compatible Character Types}
*/
@@ -165,8 +164,7 @@ QT_BEGIN_NAMESPACE
The behavior is undefined if \a last precedes \a first, or \a first
is \nullptr and \a last is not.
- This constructor only participates in overload resolution if \c Char
- is a compatible character type.
+ \constraints \c Char is a compatible character type.
\sa isNull(), {Compatible Character Types}
*/
@@ -181,9 +179,8 @@ QT_BEGIN_NAMESPACE
Passing \nullptr as \a str is safe and results in a null string view.
- This constructor only participates in overload resolution if \a
- str is not an array and if \c Char is a compatible character
- type.
+ \constraints \a str is not an array and \c Char is a
+ compatible character type.
\sa isNull(), {Compatible Character Types}
*/
@@ -199,7 +196,7 @@ QT_BEGIN_NAMESPACE
\a string must remain valid for the lifetime of this string view
object.
- This constructor only participates in overload resolution if \a
+ \constraints \a
string is an actual array and \c Char is a compatible character
type.
@@ -233,13 +230,13 @@ 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 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}.
+
\sa isNull(), isEmpty()
*/