<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>C++ Standard Library Issues Resolved Directly In Batavia</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  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}
</style>
</head>
<body>
<table>
<tr>
  <td align="left">Doc. no.</td>
  <td align="left">N3208=10-0198</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2010-11-12</td>
</tr>
<tr>
  <td align="left">Project:</td>
  <td align="left">Programming Language C++</td>
</tr>
<tr>
  <td align="left">Reply to:</td>
  <td align="left">Alisdair Meredith &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<h1>Library Working group Issues resolved in Batavia</h1>
<p>
The following Library Working Group issues were moved to "Ready" to applied directly to the C++0x working document in the 2010 Batavia meeting.
</p>

<h2>Immediate Issues</h2>
<hr>
<h3><a name="1294"></a>1294. Difference between callable wrapper and forwarding  call wrapper unclear</h3>
<p><b>Section:</b> 20.8.2 [func.require] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-12-21 <b>Last modified:</b> 2010-11-08</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.require">active issues</a> in [func.require].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.require">issues</a> in [func.require].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current wording in the standard makes it hard to discriminate the difference
between a "call wrapper" as defined in 20.8.1 [func.def]/5+6:
</p>

<blockquote>
<p>
5 A <i>call wrapper type</i> is a type that holds a callable object and supports
a call operation that forwards to that object.
</p>
<p>
6 A <i>call wrapper</i> is an object of a call wrapper type.
</p>
</blockquote>

<p>
and a "forwarding call wrapper" as defined in 20.8.2 [func.require]/4:
</p>

<blockquote>
<p>
4 [..] A <i>forwarding call wrapper</i> is a call wrapper that can be called
with an argument list. [<i>Note:</i> in a typical implementation forwarding call
wrappers have an overloaded function call operator of the form
</p>

<blockquote><pre>
template&lt;class... ArgTypes&gt;
R operator()(ArgTypes&amp;&amp;... args) <i>cv-qual</i>;
</pre></blockquote>

<p>
&mdash; <i>end note</i>]
</p>
</blockquote>

<p>
Reason for this lack of clear difference seems to be that the wording adaption
to variadics and rvalues that were applied after it's original proposal in <a
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1673.html#call%20wrapper">N1673</a>:
</p>

<blockquote>
<p>
[..] A <b>forwarding call wrapper</b> is a call wrapper that can be called
with an argument list <tt>t1, t2, ..., tN</tt> where each <tt>ti</tt> is an lvalue.
The effect of calling a forwarding call wrapper with one or more
arguments that are rvalues is implementation defined. [<i>Note:</i> in
a typical implementation forwarding call wrappers have overloaded
function call operators of the form
</p>

<blockquote><pre>
template&lt;class T1, class T2, ..., class TN&gt;
R operator()(T1&amp; t1, T2&amp; t2, ..., TN&amp; tN) <i>cv-qual</i>;
</pre></blockquote>

<p>
&mdash; <i>end note</i>]
</p>
</blockquote>

<p>
combined with the fact that the word "forward" has two different meanings in
this context. This issue attempts to clarify the difference better.
</p>

<p><i>[
2010-09-14 Daniel provides improved wording and verified that it is correct against N3126. Previous resolution is shown here:
]</i></p>


<blockquote>
<p>
4 [..] A <i>forwarding call wrapper</i> is a call wrapper that can be called
with an <ins>arbitrary</ins> argument list<ins> and uses perfect forwarding to
deliver the arguments to the wrapped callable object</ins>. [<i>Note:</i> in a
typical implementation forwarding call wrappers have an overloaded function call
operator of the form
</p>

<blockquote><pre>
template&lt;class... ArgTypes&gt;
R operator()(ArgTypes&amp;&amp;... args) <i>cv-qual</i>;
</pre></blockquote>

<p>
&mdash; <i>end note</i>]
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.8.2 [func.require]/4 as indicated:
</p>

<blockquote><p>
[..] A <em>forwarding call wrapper</em> is a call wrapper that can be called with an <ins>arbitrary</ins> argument 
list <ins>and delivers the arguments as references to the wrapped callable object. This forwarding step shall ensure
that rvalue arguments are delivered as rvalue-references and lvalue arguments are delivered as lvalue-references</ins>. 
[<em>Note</em>: in a typical implementation forwarding call wrappers have an overloaded function call operator of the 
form
</p>

<blockquote><pre>
template&lt;class... UnBoundArgs&gt;
R operator()(UnBoundArgs&amp;&amp;... unbound_args) <em>cv-qual</em>;
</pre></blockquote>
<p>
&mdash; <em>end note</em> ]
</p>
</blockquote>






<hr>
<h3><a name="1354"></a>1354. [FCD] The definition of deadlock excludes cases involving a single thread</h3>
<p><b>Section:</b> 17.3.7 [defns.deadlock] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-12</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-52</b></p>
<p>
The definition of deadlock in 17.3.7 excludes cases
involving a single thread making it incorrect.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
The definition should be corrected.
</p>

<p><i>[
2010 Batavia Concurrency group provides a Proposed Resolution
]</i></p>




<p><b>Proposed resolution:</b></p>
Change 17.3.7 [defns.deadlock] as indicated:
<blockquote>
<b>deadlock</b>
<p/>
<del>two</del><ins>one</ins> or more threads are unable to continue execution because each is blocked waiting for one or more of the
others to satisfy some condition.
</blockquote>





<hr>
<h3><a name="1362"></a>1362. [FCD] Description of binding to rvalue-references should use the new 'xvalue' vocabulary</h3>
<p><b>Section:</b> 17.6.3.9 [res.on.arguments] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-08</p>
<p><b>View all other</b> <a href="lwg-index.html#res.on.arguments">issues</a> in [res.on.arguments].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-82</b></p>
<p>
17.6.3.9 [res.on.arguments] p.1. b.3: The second Note can benefit by adopting recent nomenclature.
</p>


<p><i>[
Resolution proposed by the ballot comment:
]</i></p>

<p>
Rephrase the Note in terms of xvalue.
</p>

<p><i>[
Pre-Batavia:
]</i></p>

<p>
Walter Brown provides wording.
</p>
<p><i>[Batavia: Immediate]</i></p>

<p><b>Proposed resolution:</b></p>

<p>
Amend the note in 17.6.3.9 [res.on.arguments] p1 bullet 3.
</p>
<blockquote>
[ <i>Note</i>: If a program casts an lvalue to an <del>rvalue</del><ins>xvalue</ins> while passing that lvalue to a library function (e.g. by calling the function with the argument <tt>move(x)</tt>), the program is effectively asking that function to treat that lvalue as a temporary. The implementation is free to optimize away aliasing checks which might be needed if the argument was anlvalue. <i>—endnote</i>]
</blockquote>






<hr>
<h3><a name="1368"></a>1368. [FCD] Thread safety of <tt>std::uncaught_exception()</tt></h3>
<p><b>Section:</b> 18.8.5 [uncaught] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-12</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-73</b></p>
<p>
The thread safety <tt>std::uncaught_exception()</tt> and the
result of the function when multiple threads throw
exceptions at the same time are unspecified. To make the
function safe to use in the presence of exceptions in
multiple threads the specification needs to be updated.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Update this clause to support safe calls from
multiple threads without placing synchronization
requirements on the user.
</p>

<p><i>[
2010 Batavia Concurrency group provides a Proposed Resolution
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>Change 18.8.5 [uncaught] p. 1 as follows:</p>
<p>
<i>Returns</i>: <tt>true</tt> after <ins> the current thread has initialized </ins><del>initializing</del>
 an exception object (15.1) until a handler for the exception (including <tt>unexpected()</tt> or <tt>terminate()</tt>) 
 is activated (15.3). [ <i>Note</i>: This includes stack unwinding (15.2). &mdash; <i>end note</i> ]
</p>






<hr>
<h3><a name="1370"></a>1370. [FCD] <tt>throw_with_nested</tt> should not use perfect forwarding</h3>
<p><b>Section:</b> 18.8.7 [except.nested] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-10</p>
<p><b>View all other</b> <a href="lwg-index.html#except.nested">issues</a> in [except.nested].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-84</b></p>
<p>
The <tt>throw_with_nested</tt> specification passes in its argument as
<tt>T&amp;&amp;</tt> (perfect forwarding pattern), but then discusses
requirements on <tt>T</tt> without taking into account that <tt>T</tt>
may be an lvalue-reference type. It is also not clear in the spec that
<tt>t</tt> is intended to be perfectly forwarded.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Patch [except.nested] p6-7 to match the intent with regards to
requirements on <tt>T</tt> and the use of
<tt>std::forward&lt;T&gt;(t)</tt>.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3144.html">n3144</a> would solve this issue.
</blockquote>

<p><i>[2010-11-10 Batavia: LWG accepts Howard's updated wording with
corrected boo boos reported by Sebastian Gesemann and Pete Becker,
which is approved for Immediate adoption this meeting.]</i></p>




<p><b>Proposed resolution:</b></p> 
<p><i>Change 18.8.7 nested_exception [except.nested] as indicated:</i></p>
<blockquote>
  <pre>[[noreturn]] template &lt;class T&gt; void throw_with_nested(T&amp;&amp; t);
</pre>
  <blockquote>
    <p><ins>Let <tt>U</tt> be <tt>remove_reference&lt;T&gt;::type</tt> </ins></p>
    <p>6 <i>Requires:</i> <tt><del>T</del> <ins>U</ins></tt> shall be <tt>
    CopyConstructible</tt>. </p>
    <p>7 <i>Throws:</i> If <tt><del>T</del> <ins>U</ins></tt> is a non-union 
    class type not derived from <tt>nested_exception</tt>, an exception of 
    unspecified type that is publicly derived from both <tt><del>T</del> <ins>U</ins></tt> 
    and <tt>nested_exception</tt> <ins>and constructed from <tt>std::forward&lt;T&gt;(t)</tt></ins>, 
    otherwise <ins>throws</ins> <tt><ins>std::forward&lt;T&gt;(</ins>t<ins>)</ins></tt>.
    </p>
  </blockquote>
</blockquote>





<hr>
<h3><a name="1435"></a>1435. [FCD] Unclear returns specifications for C99 complex number functions</h3>
<p><b>Section:</b> 26.4.7 [complex.value.ops] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-11</p>
<p><b>View all other</b> <a href="lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-120</b></p>

The complex number functions added for compatibility
with the C99 standard library are defined purely as a
cross-reference, with no hint of what they should return.
This is distinct from the style of documentation for the
functions in the earlier standard. In the case of the
inverse-trigonometric and hyperbolic functions, a
reasonable guess of the functionality may be made from
the name, this is not true of the cproj function, which
apparently returns the projection on the Reimann Sphere.
A single line description of each function, associated with
the cross-reference, will greatly improve clarity.

<p><i>[2010-11-06 Beman provides proposed resolution wording.]</i></p>


<p><i>[
2010 Batavia: The working group concurred with the issue's Proposed Resolution
]</i></p>




<p><b>Proposed resolution:</b></p>

<p><i>Change 26.4.7 complex value operations [complex.value.ops] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i> the projection of <tt>x</tt> onto the Riemann 
    sphere.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>cproj</tt>, 
    defined in 7.3.9.4.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; acos(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc cosine  of <tt>x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>cacos</tt>, 
    defined in 7.3.5.1.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; asin(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc sine  of <tt>x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>casin</tt>, 
    defined in 7.3.5.2.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; atan(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc tangent  of <tt>x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>catan</tt>, 
    defined in 7.3.5.3.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; acosh(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc hyperbolic cosine of
    <tt>x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>cacosh</tt>, 
    defined in 7.3.6.1.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; asinh(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc hyperbolic sine  of <tt>
    x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>casinh</tt>, 
    defined in 7.3.6.2.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; atanh(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc hyperbolic tangent  of
    <tt>x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>catanh</tt>, 
    defined in 7.3.6.2.</p>
  </blockquote>
</blockquote>







<hr>
<h3><a name="1436"></a>1436. [FCD] Random number engine constructor concerns</h3>
<p><b>Section:</b> 26.5.3 [rand.eng] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-11</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-121</b></p>

All the random number engine types in this clause have a
constructor taking an unsigned integer type, and a
constructor template for seed sequences. This means that
an attempt to create a random number engine seeded by
an integer literal must remember to add the appropriate
unsigned suffix to the literal, as a signed integer will
attempt to use the seed sequence template, yielding
undefined behaviour, as per 26.5.1.1p1a. It would be
helpful if at least these anticipated cases produced a
defined behaviour, either an erroneous program with
diagnostic, or a conversion to unsigned int forwarding to
the appropriate constructor.

<p><i>[
2010-11-03 Daniel comments and provides a proposed resolution:
]</i></p>


<p>
I suggest to apply a similar solution as recently suggested for <a href="lwg-active.html#1234">1234</a>.
It is basically a requirement for an implementation to constrain the template.
</p>

<p><i>[
2010-11-04 Howard suggests to use <tt>!is_convertible&lt;Sseq, result_type&gt;::value</tt>
as minimum requirement instead of the originally proposed <tt>!is_scalar&lt;Sseq&gt;::value</tt>.
This would allow for a user-defined type <tt>BigNum</tt>, that is convertible to <tt>result_type</tt>,
to be used as argument for a seed instead of a seed sequence. The wording has been updated to 
reflect this suggestion.
]</i></p>


<p><i>[
2010 Batavia: There were some initial concerns regarding the portability and reproducibility of results 
when seeded with a negative signed value, but these concerns were allayed after discussion. Thus, after
reviewing the issue, the working group concurred with the issue's Proposed Resolution. 
]</i></p>




<p><b>Proposed resolution:</b></p>
Add the following paragraph at the end of 26.5.3 [rand.eng]:
<blockquote>
<blockquote>
5 Each template specified in this section [rand.eng] requires one or more relationships, involving the value(s) of
its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
any such required relationship fails to hold.
</blockquote>

<blockquote>
<ins>? For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this sub-clause 
[rand.eng] and in sub-clause [rand.adapt]:</ins>
<ul>
<li><ins>If the constructor</ins>
<blockquote><pre>
<ins>template&lt;class Sseq&gt; explicit X(Sseq&amp; q);</ins>
</pre></blockquote>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor 
shall not participate in overload resolution.
</ins>
</li>
<li><ins>If the member function</ins>
<blockquote><pre>
<ins>template&lt;class Sseq&gt; void seed(Sseq&amp; q);</ins>
</pre></blockquote>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function 
shall not participate in overload resolution.
</ins>
</li>
</ul>
<ins>The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
except that as a minimum a type shall not qualify as seed sequence, if it is implicitly convertible
to <tt>X::result_type</tt>.</ins>
</blockquote>

</blockquote>





<hr>
<h3><a name="1437"></a>1437. [FCD] Mersenne twister meaningless for word sizes less than two</h3>
<p><b>Section:</b> 26.5.3.2 [rand.eng.mers] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-11</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-124</b></p>

The Mersenne twister algorithm is meaningless for word
sizes less than two, as there are then insufficient bits
available to be &#8220;twisted&#8221;.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
Insert the following among the relations that are required to hold: <tt>2u &lt; w</tt>.
</blockquote>

<p><i>[
2010 Batavia: The working group concurred with the issue's Proposed Resolution
]</i></p>




<p><b>Proposed resolution:</b></p>
Change 26.5.3.2 [rand.eng.mers] p. 4 as indicated:
<p/>
<blockquote>
4 The following relations shall hold: <tt>0 &lt; m</tt>, <tt>m &lt;= n</tt>, <ins><tt>2u &lt; w</tt>,</ins>
<tt>r &lt;= w</tt>, <tt>u &lt;= w</tt>, <tt>s &lt;= w</tt>, <tt>t &lt;= w</tt>, 
<tt>l &lt;= w</tt>, <tt>w &lt;= numeric_limits&lt;UIntType&gt;::digits</tt>, 
<tt>a &lt;= (1u&lt;&lt;w) - 1u</tt>, <tt>b &lt;= (1u&lt;&lt;w) - 1u</tt>, 
<tt>c &lt;= (1u&lt;&lt;w) - 1u</tt>, <tt>d &lt;= (1u&lt;&lt;w) - 1u</tt>, 
and <tt>f &lt;= (1u&lt;&lt;w) - 1u</tt>.
</blockquote>





<hr>
<h3><a name="1439"></a>1439. [FCD] Return from <tt>densities()</tt> functions?</h3>
<p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-12</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-134</b></p>

These two distributions have a member function called
<tt>densities()</tt> which returns a <tt>vector&lt;double&gt;</tt>. The
distribution is templated on <tt>RealType</tt>. The distribution
also has another member called <tt>intervals()</tt> which returns
a <tt>vector&lt;RealType&gt;</tt>. Why doesn't densities return
<tt>vector&lt;RealType&gt;</tt> as well? If <tt>RealType</tt> is <tt>long double</tt>,
the computed densities property isn't being computed to
the precision the client desires. If <tt>RealType</tt> is <tt>float</tt>, the
densities vector is taking up twice as much space as the client desires.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
Change the piecewise constant and linear
distributions to hold / return the densities in a
<tt>vector&lt;result_type&gt;</tt>.
<p/>
If this is not done, at least correct 26.5.8.5.2 [rand.dist.samp.pconst] p. 13 which describes
the return of densities as a <tt>vector&lt;result_type&gt;</tt>.
</blockquote>

<p><i>[
Batavia 2010: After reviewing this issue, the working group concurred with the first of the 
suggestions proposed by the NB comment: "Change the piecewise constant and linear distributions 
to hold / return the densities in a vector. "
]</i></p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>Change 26.5.8.5.2 [rand.dist.samp.pconst] p. 2, class template <tt>piecewise_constant_distribution</tt> synopsis
and the prototype description 26.5.8.5.2 [rand.dist.samp.pconst] before p. 13 as indicated:
<blockquote><pre>
vector&lt;<del>double</del><ins>result_type</ins>&gt; densities() const;
</pre></blockquote>
</li>

<li>Change 26.5.8.5.3 [rand.dist.samp.plinear] p. 2, class template <tt>piecewise_linear_distribution</tt> synopsis
and the prototype description 26.5.8.5.3 [rand.dist.samp.plinear] before p. 13 as indicated:
<blockquote><pre>
vector&lt;<del>double</del><ins>result_type</ins>&gt; densities() const;
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="1440"></a>1440. [FCD] Incorrect specification for rand.dist.samp.plinear</h3>
<p><b>Section:</b> 26.5.8.5.3 [rand.dist.samp.plinear] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-11</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-135</b></p>

This paragraph says: Let bk = xmin+k&middot;&delta; for k = 0,...,n,
and wk = fw(bk +&delta;) for k = 0,...,n.
However I believe that fw(bk) would be far more desirable.
I strongly suspect that this is nothing but a type-o.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
Change p. 10 to read:<BR/>
Let bk = xmin+k&middot;&delta; for k = 0,...,n, and wk = fw(bk)
for k = 0,...,n.
</blockquote>

<p><i>[
2010-11-02 Daniel translates into a proposed resolution
]</i></p>


<p><i>[
2010 Batavia: The working group concurred with the issue's Proposed Resolution
]</i></p>




<p><b>Proposed resolution:</b></p>
Change 26.5.8.5.3 [rand.dist.samp.plinear] p. 10 as indicated:
<blockquote>
10 <em>Effects</em>: Constructs a <tt>piecewise_linear_distribution</tt> object with parameters taken or calculated
from the following values: Let <tt><em>b<sub>k</sub></em> = xmin+<em>k</em>&middot;&delta;</tt> for 
<tt><em>k</em> = 0, . . . , <em>n</em></tt>, and <tt><em>w<sub>k</sub></em> = fw(<em>b</em><sub><em>k</em></sub><del> +&delta;</del>)</tt> 
for <tt><em>k</em> = 0, . . . , <em>n</em></tt>.</blockquote>





<hr>
<h3><a name="1522"></a>1522. <tt>conj</tt> specification is now nonsense</h3>
<p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2010-10-14 <b>Last modified:</b> 2010-11-11</p>
<p><b>View all other</b> <a href="lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In Pittsburgh, we accepted the resolution of library issue <a href="lwg-defects.html#1137">1137</a>, to add
a sentence 3 to [cmplx.over]:
</p>
<blockquote>
All the specified overloads shall have a return type which is the nested
<tt>value_type</tt> of the effectively cast arguments."
</blockquote>
<p>
This was already true for four of the six functions except <tt>conj</tt> and
<tt>proj</tt>. It is not completely unreasonable to make <tt>proj</tt> return
the real value only, but the IEC specification does call for an imaginary part
of -0 in some circumstances. The people who care about these distinctions really
care, and it <em>is</em> required by an international standard.
</p>
<p>
Making <tt>conj</tt> return just the real part breaks it horribly, however. It is
well understood in mathematics that <tt>conj(re + i*im)</tt> is <tt>(re - i*im)</tt>,
and it is widely used. The accepted new definition makes <tt>conj</tt> useful only
for pure real operations. This botch <em>absolutely must</em> be fixed.
</p>

<p><i>[
2010 Batavia: The working group concurred with the issue's Proposed Resolution
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Remove the recently added paragraph 3 from [cmplx.over]:
</p>
<blockquote>
<del>3 All the specified overloads shall have a return type which is the nested 
<tt>value_type</tt> of the effectively cast arguments.</del>
</blockquote>





</body>
</html>
