diff options
| author | Marc Mutz <marc.mutz@qt.io> | 2025-02-06 08:15:36 +0100 |
|---|---|---|
| committer | Topi Reinio <topi.reinio@qt.io> | 2025-02-28 13:51:18 +0000 |
| commit | b7a67b46e66f161def5bf879f19c66d3fcec1d8b (patch) | |
| tree | feb68ba2f835a8aeced04ad3563230db49ecb011 /src/corelib/text/qanystringview.cpp | |
| parent | 6f89357f59b507c0dcdc177bc1ecfbbc94d6fed3 (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.cpp | 19 |
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() */ |
