<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 625: Mixed up Effects and Returns clauses</title>
<meta property="og:title" content="Issue 625: Mixed up Effects and Returns clauses">
<meta property="og:description" content="C++ library issue. Status: Resolved">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue625.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#Resolved">Resolved</a> status.</em></p>
<h3 id="625"><a href="lwg-defects.html#625">625</a>. Mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
<p><b>Section:</b> 16 <a href="https://wg21.link/library">[library]</a> <b>Status:</b> <a href="lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Duplicate of:</b> <a href="lwg-closed.html#895" title="&quot;Requires:&quot; on std::string::at et al (Status: Dup)">895</a></p>
<p><b>Discussion:</b></p>
 <p>

Many member functions of <code>basic_string</code> are overloaded,
with some of the overloads taking a <code>string</code> argument,
others <code>value_type*</code>, others <code>size_type</code>, and
others still <code>iterators</code>. Often, the requirements on one of
the overloads are expressed in the form of <i>Effects</i>,
<i>Throws</i>, and in the Working Paper
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
also <i>Remark</i> clauses, while those on the rest of the overloads
via a reference to this overload and using a <i>Returns</i> clause.
</p>

<p>
The difference between the two forms of specification is that per
16.3.2.4 <a href="https://wg21.link/structure.specifications">[structure.specifications]</a>, p3, an <i>Effects</i> clause specifies
<i>"actions performed by the functions,"</i> i.e., its observable
effects, while a <i>Returns</i> clause is <i>"a description of the
return value(s) of a function"</i> that does not impose any
requirements on the function's observable effects.
</p>

<p>
Since only <i>Notes</i> are explicitly defined to be informative and
all other paragraphs are explicitly defined to be normative, like
<i>Effects</i> and <i>Returns</i>, the new <i>Remark</i> clauses also
impose normative requirements.
</p>

<p>
So by this strict reading of the standard there are some member
functions of <code>basic_string</code> that are required to throw an
exception under some conditions or use specific traits members while
many other otherwise equivalent overloads, while obliged to return the
same values, aren't required to follow the exact same requirements
with regards to the observable effects.
</p>

<p>
Here's an example of this problem that was precipitated by the change
from informative Notes to normative <i>Remark</i>s (presumably made to
address <a href="lwg-closed.html#424" title="normative notes (Status: NAD Editorial)">424</a><sup><a href="https://cplusplus.github.io/LWG/issue424" title="Latest snapshot">(i)</a></sup>):
</p>

<p>
In the Working Paper, <code>find(string, size_type)</code> contains a
<i>Remark</i> clause (which is just a <i>Note</i> in the current
standard) requiring it to use <code>traits::eq()</code>.
</p>

<p>
<code>find(const charT *s, size_type pos)</code> is specified to
return <code>find(string(s), pos)</code> by a <i>Returns</i> clause
and so it is not required to use <code>traits::eq()</code>. However,
the Working Paper has replaced the original informative <i>Note</i>
about the function using <code>traits::length()</code> with a
normative requirement in the form of a <i>Remark</i>. Calling
<code>traits::length()</code> may be suboptimal, for example when the
argument is a very long array whose initial substring doesn't appear
anywhere in <code>*this</code>.
</p>

<p>
Here's another similar example, one that existed even prior to the
introduction of <i>Remark</i>s:
</p>

<p>
<code> insert(size_type pos, string, size_type, size_type)</code> is
required to throw <code>out_of_range</code> if <code>pos >
size()</code>.
</p>

<p>
<code>insert(size_type pos, string str)</code> is specified to return
<code>insert(pos, str, 0, npos)</code> by a <i>Returns</i> clause and
so its effects when <code>pos > size()</code> are strictly speaking
unspecified.
</p>

<p>
I believe a careful review of the current <i>Effects</i> and
<i>Returns</i> clauses is needed in order to identify all such
problematic cases. In addition, a review of the Working Paper should
be done to make sure that the newly introduced normative <i>Remark</i>
clauses do not impose any undesirable normative requirements in place
of the original informative <i>Notes</i>.
</p>

<p><i>[
Batavia: Alan and Pete to work.
]</i></p>


<p><i>[
Bellevue: Marked as NAD Editorial.
]</i></p>


<p><i>[
Post-Sophia Antipolis:
Martin indicates there is still work to be done on this issue.
Reopened.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote><p>
Tom proposes we say that, unless specified otherwise,
it is always the caller's responsibility to verify that supplied arguments
meet the called function's requirements.
If further semantics are specified
(e.g., that the function throws under certain conditions),
then it is up to the implementer to check those conditions.
Alan feels strongly that our current use of Requires in this context
is confusing, especially now that <code>requires</code> is a new keyword.
</p></blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote><p>
Move to Tentatively NAD.
</p></blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote><p>
Move to Open.  Martin will work on proposed wording.
</p></blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote><p>
Moved to NAD Editorial, solved by revision to N3021.
</p></blockquote>




<p><b>Rationale:</b></p>
<p>
Solved by revision to N3021.
</p>


<p id="res-625"><b>Proposed resolution:</b></p>
<p>
</p>





</body>
</html>
