[string.view.ops] convert Effects to Returns paragraphs #6818
Conversation
| @@ -1189,7 +1189,7 @@ | |||
|
|
|||
| \pnum | |||
| \effects | |||
| Equivalent to \tcode{traits::copy(s, data() + pos, rlen)}. | |||
| Equivalent to: \tcode{traits::copy(s, data() + pos, rlen)}. | |||
There was a problem hiding this comment.
The current form is in line with https://github.com/cplusplus/draft/wiki/Specification-Style-Guidelines#writing-effects-in-a-function-description
| \effects | ||
| Equivalent to: \tcode{return substr(pos1, n1).compare(str);} | ||
| \returns | ||
| \tcode{substr(pos1, n1).compare(str)}. |
There was a problem hiding this comment.
This has normative effect, because it no longer inherits the preconditions and other specification from substr.
e.g. what happens if pos1 is out of range? The current wording defines that, your change doesn't.
There was a problem hiding this comment.
See [structure.specifications] p4.
There was a problem hiding this comment.
See [structure.specifications] p4.
Hmm, I think you're right, but it still surprises me. Isn't there a substantial amount of \returns uses which are broken then?
For example [string.conversions] p7 simply defines Returns for std::to_string, but no Preconditions or Throws specification.
However, this ultimately forwards to vformat which does have Throws. Does this mean that std::to_string never throws, or does it mean that std::to_string inherits its Throws (although this isn't specified)?
I feel like there's a larger issue. I've always assumed that Returns does inherit Preconditions, Throws, etc.
There was a problem hiding this comment.
See [structure.specifications] p4.
Hmm, I think you're right, but it still surprises me. Isn't there a substantial amount of
\returnsuses which are broken then?
No.
For example [string.conversions] p7 simply defines Returns for
std::to_string, but no Preconditions or Throws specification.
Those functions have no preconditions, so that's fine.
They are allowed to throw anything, which might be somewhat underspecified but isn't broken.
However, this ultimately forwards to
vformatwhich does have Throws. Does this mean thatstd::to_stringnever throws,
No! It has to be noexcept or say "Throws: nothing" for that to be true. Those functions can throw anything.
or does it mean that
std::to_stringinherits its Throws (although this isn't specified)?
No. It will never throw a format_error for example, and it can only throw bad_alloc in practice. But since we don't say what it can throw, it's technically allowed to throw anything (modulo the global restriction that the library only throws things derived from exception).
I feel like there's a larger issue.
I don't think so. The vast majority of cases are written as intended, and correct as written. There might be exceptions of course.
If we want to restrict what they're allowed to throw we could add a Throws element.
I've always assumed that Returns does inherit Preconditions, Throws, etc.
Definitely not, it only tells you the value that is returned. It says nothing about how that's actually achieved.
|
Closing this as going in the wrong direction. |
No description provided.