<!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 Chicago (2013)</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">N3788</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2013-09-27</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>

<p>Revised 2013-09-27 at 16:09:08 UTC</p>
<h2>Immediate Issues</h2>
<hr>
<h3><a name="2013"></a>2013. Do library implementers have the freedom to add <tt>constexpr</tt>?</h3>
<p><b>Section:</b> 17.6.5.6 [constexpr.functions] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2010-11-12 <b>Last modified:</b> 2013-09-27</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>Suppose that a particular function is not tagged as constexpr in the standard,
but that, in some particular implementation, it is possible to write it within
the constexpr constraints. If an implementer tags such a function as constexpr,
is that a violation of the standard or is it a conforming extension?</p>

<p>There are two questions to consider. First, is this allowed under the
as-if rule? Second, if it does not fall under as-if, is there
(and should there be) any special license granted to implementers
to do this anyway, sort of the way we allow elision of copy constructors
even though it is detectable by users?</p>

<p>I believe that this does not fall under "as-if", so implementers
probably don't have that freedom today. I suggest changing the WP
to grant it. Even if we decide otherwise, however, I suggest that
we make it explicit.</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
General surprise this was not already in 'Ready' status, and so moved.
</p>

<p><i>[
2012 Kona
]</i></p>


<p>
Some concern expressed when presented to full committee for the vote to WP status
that this issue had been resolved without sufficient thought of the consequences
for diverging library implementations, as users may use SFINAE to observe
different behavior from otherwise identical code.  Issue moved back to Review
status, and will be discussed again in Portland with a larger group.

Note for Portland: John Spicer has agreed to represent Core's concerns during
any such discussion within LWG.
</p>

<p><i>[2013-09 Chicago]</i></p>


<p>
Straw poll: LWG strongly favoured to remove from implementations the freedom to add <tt>constexpr</tt>.
</p>
<p>
Matt provides new wording.
</p>

<p><i>[2013-09 Chicago]</i></p>


<p>
Move to Immediate after reviewing Matt's new wording.
</p>



<p><b>Proposed resolution:</b></p>
<p><i>In 17.6.5.6 [constexpr.functions], change paragraph 1 to:</i></p>

<blockquote><p>
<ins>This standard explicitly requires that certain standard library functions
are <tt>constexpr</tt> [dcl.constexpr]. 
An implementation shall not declare any standard library function signature as <tt>constexpr</tt> 
except for those where it is explicitly required.</ins>
Within any header that provides any non-defining declarations of <tt>constexpr</tt>
functions or constructors an implementation shall provide corresponding definitions. 
</p></blockquote>






<hr>
<h3><a name="2018"></a>2018. [CD] <tt>regex_traits::isctype</tt> Returns clause is wrong</h3>
<p><b>Section:</b> 28.7 [re.traits] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2010-11-16 <b>Last modified:</b> 2013-09-27</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.traits">active issues</a> in [re.traits].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.traits">issues</a> in [re.traits].</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 10</b></p>

<p>28.7 [re.traits] p. 12 says:</p>

<blockquote><p>
returns true if <tt>f</tt> bitwise or&#39;ed with the result of calling
<tt>lookup_classname</tt> with an iterator pair that designates the character
sequence &quot;w&quot; is not equal to <tt>0</tt> and <tt>c == '_'</tt>
</p></blockquote>

<p>
If the bitmask value corresponding to &quot;w&quot; has a non-zero value (which
it must do) then the bitwise or with any value is also non-zero, and
so <tt>isctype('_', f)</tt> returns true for any <tt>f</tt>. Obviously this is wrong,
since <tt>'_'</tt> is not in every <tt>ctype</tt> category.
</p>

<p>
There&#39;s a similar problem with the following phrases discussing the
&quot;blank&quot; char class.
</p>

<p><i>[2011-05-06: Jonathan Wakely comments and provides suggested wording]</i></p>


<p>
DR <a href="lwg-defects.html#2019">2019</a> added <tt>isblank</tt> support to <tt>&lt;locale&gt;</tt> which simplifies the
definition of <tt>regex_traits::isctype</tt> by removing the special case for the "blank" class.
<p/>
My suggestion for 2018 is to add a new table replacing the lists of
recognized names in the Remarks clause of <tt>regex_traits::lookup_classname</tt>. 
I then refer to that table in the Returns clause of <tt>regex_traits::isctype</tt> 
to expand on the "in an unspecified manner" wording which is too vague. The conversion 
can now be described using the "is set" term defined by 17.5.2.1.3 [bitmask.types] and
the new table to convey the intented relationship between e.g.
[[:digit:]] and <tt>ctype_base::digit</tt>, which is not actually stated in the
FDIS.
<p/>
The effects of <tt>isctype</tt> can then most easily be described in code,
given an "exposition only" function prototype to do the not-quite-so-unspecified conversion 
from <tt>char_class_type</tt> to <tt>ctype_base::mask</tt>.
<p/>
The core of LWG 2018 is the "bitwise or'ed" wording which gives the
wrong result, always evaluating to true for all values of <tt>f</tt>. That is
replaced by the condition <tt>(f&amp;x) == x</tt> where <tt>x</tt> is the result of calling
<tt>lookup_classname</tt> with "w".  I believe that's necessary, because the
"w" class could be implemented by an internal "underscore" class i.e.
<tt>x = _Alnum|_Underscore</tt> in which case <tt>(f&amp;x) != 0</tt> would give the wrong
result when <tt>f==_Alnum</tt>.
<p/>
The proposed resolution also makes use of <tt>ctype::widen</tt> which addresses
the problem that the current wording only talks about "w" and '_' which assumes 
<tt>charT</tt> is char.  There's still room for improvement here:
the regex grammar in 28.13 [re.grammar] says that the class names in the
table should always be recognized, implying that e.g. U"digit" should
be recognized by <tt>regex_traits&lt;char32_t&gt;</tt>, but the specification of
<tt>regex_traits::lookup_classname</tt> doesn't cover that, only mentioning
<tt>char</tt> and <tt>wchar_t</tt>.  Maybe the table should not distinguish narrow and
wide strings, but should just have one column and add wording to say
that <tt>regex_traits</tt> widens the name as if by using <tt>use_facet&lt;ctype&lt;charT&gt;&gt;::widen()</tt>.
<p/>
Another possible improvement would be to allow additional
implementation-defined extensions in <tt>isctype</tt>. An implementation is
allowed to support additional class names in <tt>lookup_classname</tt>, e.g.
[[:octdigit:]] for [0-7] or [[:bindigit:]] for [01], but the current
definition of isctype provides no way to use them unless <tt>ctype_base::mask</tt> 
also supports them.
</p>

<p><i>[2011-05-10: Alberto and Daniel perform minor fixes in the P&#47;R]</i></p>


<p><i>[
2011 Bloomington
]</i></p>


<p>
Consensus that this looks to be a correct solution, and the presentation as a table is a big improvement.
</p>

<p>
Concern that the middle section wording is a little muddled and confusing, Stefanus volunteered to reword.
</p>

<p><i>[
2013-09 Chicago
]</i></p>


<p>
Stefanus provides improved wording (replaced below)
</p>

<p><i>[
2013-09 Chicago
]</i></p>


<p>
Move as Immediate after reviewing Stefanus's revised wording.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Modify 28.7 [re.traits] p. 10 as indicated:</p>
<blockquote><pre>
template &lt;class ForwardIterator&gt;
  char_class_type lookup_classname(
    ForwardIterator first, ForwardIterator last, bool icase = false) const;
</pre><blockquote><p>
-9- <i>Returns</i>: an unspecified value that represents the character classification named by the character
sequence designated by the iterator range [<tt>first</tt>,<tt>last</tt>). If the parameter <tt>icase</tt> is true then the
returned mask identifies the character classification without regard to the case of the characters being
matched, otherwise it does honor the case of the characters being matched.(footnote 335) The value returned shall
be independent of the case of the characters in the character sequence. If the name is not recognized
then returns a value that compares equal to <tt>0</tt>.
<p/>
-10- <i>Remarks</i>: For <tt>regex_traits&lt;char&gt;</tt>, at least the <del>names "d", "w", "s", "alnum", "alpha", "blank",
"cntrl", "digit", "graph", "lower", "print", "punct", "space", "upper" and "xdigit"</del><ins>narrow character
names in Table X</ins> shall be recognized. For <tt>regex_traits&lt;wchar_t&gt;</tt>, at least the <del>names L"d", L"w", 
L"s", L"alnum", L"alpha", L"blank", L"cntrl", L"digit", L"graph", L"lower", L"print", L"punct", L"space", L"upper" and 
L"xdigit"</del><ins>wide character names in Table X</ins> shall be recognized.
</p></blockquote></blockquote>
</li>

<li><p>Modify 28.7 [re.traits] p. 12 as indicated:</p>
<blockquote><pre>
bool isctype(charT c, char_class_type f) const;
</pre><blockquote><p>
-11- <i>Effects</i>: Determines if the character <tt>c</tt> is a member of the character classification represented by <tt>f</tt>.
<p/>
-12- <i>Returns</i>: <del>Converts <tt>f</tt> into a value <tt>m</tt> of type <tt>std::ctype_base::mask</tt> in an 
 unspecified manner, and returns true if <tt>use_facet&lt;ctype&lt;charT&gt; &gt;(getloc()).is(m, c)</tt> is true. Otherwise 
 returns true if <tt>f</tt> bitwise or'ed with the result of calling <tt>lookup_classname</tt> with an iterator pair that 
 designates the character sequence "w" is not equal to <tt>0</tt> and <tt>c == '_'</tt>, or if <tt>f</tt> bitwise or'ed 
 with the result of calling <tt>lookup_classname</tt> with an iterator pair that designates the character sequence "blank" 
 is not equal to <tt>0</tt> and <tt>c</tt> is one of an implementation-defined subset of the characters for 
 which <tt>isspace(c, getloc())</tt> returns true, otherwise returns false.</del>
<ins>Given an exposition-only function prototype</ins></p>
<blockquote><pre>
<ins style="text-decoration: none">
  template&lt;class C&gt;
   ctype_base::mask convert(typename regex_traits&lt;C&gt;::char_class_type f);
</ins>
</pre></blockquote>
<p>
<ins>that returns a value in which each <tt>ctype_base::mask</tt> value corresponding to a value in <tt>f</tt> named in Table <i>X</i> is set,
then the result is determined as if by:</ins>
</p>
<blockquote><pre>
<ins style="text-decoration: none">
ctype_base::mask m = convert&lt;charT&gt;(f);
const ctype&lt;charT&gt;&amp; ct = use_facet&lt;ctype&lt;charT&gt;&gt;(getloc());
if (ct.is(m, c)) {
  return true;
} else if (c == ct.widen('_')) {
  charT w[1] = { ct.widen('w') };
  char_class_type x = lookup_classname(w, w+1);
  
  return (f&amp;x) == x;
} else {
  return false;
} 
</ins>
</pre></blockquote>
<p><ins>[<i>Example</i>:</ins></p>

<blockquote><pre><ins style="text-decoration: none">
regex_traits&lt;char&gt; t;
string d("d");
string u("upper");
regex_traits&lt;char&gt;::char_class_type f;
f = t.lookup_classname(d.begin(), d.end());
f |= t.lookup_classname(u.begin(), u.end());
ctype_base::mask m = convert&lt;char&gt;(f); // m == ctype_base::digit|ctype_base::upper
</ins></pre></blockquote>
<p><ins>&mdash; <i>end example</i>]</ins></p>
<p><ins>[<i>Example</i>:</ins></p>
<blockquote><pre><ins style="text-decoration: none">
regex_traits&lt;char&gt; t;
string w("w");
regex_traits&lt;char&gt;::char_class_type f;
f = t.lookup_classname(w.begin(), w.end());
t.isctype('A', f); // returns true
t.isctype('_', f); // returns true
t.isctype(' ', f); // returns false
</ins></pre></blockquote>
<p><ins>&mdash; <i>end example</i>]</ins></p>
</blockquote></blockquote>
</li>

<li><p>At the end of 28.7 [re.traits] add a new "Table X &mdash; Character class names and corresponding ctype masks":</p>

<blockquote>
<table border="1">
<caption>Table X &mdash; Character class names and corresponding ctype masks</caption>

<tr>
<th>Narrow character name</th>
<th>Wide character name</th>
<th>Corresponding <tt>ctype_base::mask</tt> value</th>
</tr>
 
<tr>
<td><tt>"alnum"</tt></td>
<td><tt>L"alnum"</tt></td>
<td><tt>ctype_base::alnum</tt></td>
</tr>

<tr>
<td><tt>"alpha"</tt></td>
<td><tt>L"alpha"</tt></td>
<td><tt>ctype_base::alpha</tt></td>
</tr>

<tr>
<td><tt>"blank"</tt></td>
<td><tt>L"blank"</tt></td>
<td><tt>ctype_base::blank</tt></td>
</tr>

<tr>
<td><tt>"cntrl"</tt></td>
<td><tt>L"cntrl"</tt></td>
<td><tt>ctype_base::cntrl</tt></td>
</tr>

<tr>
<td><tt>"digit"</tt></td>
<td><tt>L"digit"</tt></td>
<td><tt>ctype_base::digit</tt></td>
</tr>

<tr>
<td><tt>"d"</tt></td>
<td><tt>L"d"</tt></td>
<td><tt>ctype_base::digit</tt></td>
</tr>

<tr>
<td><tt>"graph"</tt></td>
<td><tt>L"graph"</tt></td>
<td><tt>ctype_base::graph</tt></td>
</tr>

<tr>
<td><tt>"lower"</tt></td>
<td><tt>L"lower"</tt></td>
<td><tt>ctype_base::lower</tt></td>
</tr>

<tr>
<td><tt>"print"</tt></td>
<td><tt>L"print"</tt></td>
<td><tt>ctype_base::print</tt></td>
</tr>

<tr>
<td><tt>"punct"</tt></td>
<td><tt>L"punct"</tt></td>
<td><tt>ctype_base::punct</tt></td>
</tr>

<tr>
<td><tt>"space"</tt></td>
<td><tt>L"space"</tt></td>
<td><tt>ctype_base::space</tt></td>
</tr>

<tr>
<td><tt>"s"</tt></td>
<td><tt>L"s"</tt></td>
<td><tt>ctype_base::space</tt></td>
</tr>

<tr>
<td><tt>"upper"</tt></td>
<td><tt>L"upper"</tt></td>
<td><tt>ctype_base::upper</tt></td>
</tr>

<tr>
<td><tt>"w"</tt></td>
<td><tt>L"w"</tt></td>
<td><tt>ctype_base::alnum</tt></td>
</tr>

<tr>
<td><tt>"xdigit"</tt></td>
<td><tt>L"xdigit"</tt></td>
<td><tt>ctype_base::xdigit</tt></td>
</tr>

</table>
</blockquote> 
</li>
</ol>






<hr>
<h3><a name="2078"></a>2078. Throw specification of <tt>async()</tt> incomplete</h3>
<p><b>Section:</b> 30.6.8 [futures.async] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2011-08-29 <b>Last modified:</b> 2013-09-27</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.async">active issues</a> in [futures.async].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.async">issues</a> in [futures.async].</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 throw specification of <tt>async()</tt> does state:
</p>
<blockquote><p>
-6- <i>Throws</i>: <tt>system_error</tt> if policy is <tt>launch::async</tt> and 
the implementation is unable to start a new thread.
</p></blockquote>
<p>
First it seems not clear whether this only applies if policy equals 
<tt>launch::async</tt> of if the <tt>async</tt> launch mode flag is set 
(if <tt>policy|launch::async!=0</tt>)
<p/>
In the discussion Lawrence Crowl also wrote:
</p>
<blockquote><p>
    More generally, I think what we want to say is that if the
    implementation cannot successfully execute on one of the policies
    allowed, then it must choose another. The principle would apply
    to implementation-defined policies as well.
</p></blockquote>

<p>
Peter Sommerlad:
</p>
<blockquote><p>
Should not throw. That was the intent. "is async" meat exactly.
</p></blockquote>

<p><i>[2012, Portland: move to Tentatively NAD Editorial]</i></p>

<p>
If no launch policy, it is undefined behavior.
</p>
<p>
Agree with Lawrence, should try all the allowed policies. We will rephrase so that
the policy argument should be <tt>lauch::async</tt>. Current wording seems good enough.
</p>
<p>
We believe this choice of policy statement is really an editorial issue.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change 30.6.8 [futures.async] p6, p7 as indicated:</p>

<p>
-6- <i>Throws:</i> <tt>system_error</tt> if <tt>policy</tt> <del>is</del> <ins><tt>==</tt></ins> <tt>launch::async</tt> and the implementation is unable to start a new
thread.
</p>
<p>
-7- <i>Error conditions:</i>
</p><ul>
<li> <tt>resource_unavailable_try_again</tt> -- if <tt>policy</tt> <del>is</del> <ins><tt>==</tt></ins> <tt>launch::async</tt> and the system is unable to
start a new thread.
</li>
</ul>

</li>
</ol>







<hr>
<h3><a name="2097"></a>2097. <tt>packaged_task</tt> constructors should be constrained</h3>
<p><b>Section:</b> 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2011-11-02 <b>Last modified:</b> 2013-09-25</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.task.members">active issues</a> in [futures.task.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.task.members">issues</a> in [futures.task.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>

<p>
With the proposed resolution of <a href="lwg-defects.html#2067">2067</a>, this no longer selects the
copy constructor:
</p>
<blockquote><pre>
std::packaged_task&lt;void()&gt; p1;
std::packaged_task&lt;void()&gt; p2(p1);
</pre></blockquote>
<p>
Instead this constructor is a better match:
</p>
<blockquote><pre>
template &lt;class F&gt;
 explicit packaged_task(F&amp;&amp; f);
</pre></blockquote>
<p>
This attempts to package a <tt>packaged_task</tt>, which internally tries to
copy <tt>p2</tt>, which fails because the copy constructor is deleted. For at
least one implementation the resulting error message is much less
helpful than the expected "cannot call deleted function" because it
happens after instantiating several more templates rather than in the
context where the constructor is called.
<p/>
I believe the solution is to constrain to the template constructors so
the template argument <tt>F</tt> cannot be deduced as (possibly <i>cv</i>)
<tt>packaged_task&amp;</tt> or <tt>packaged_task</tt>.  It could be argued 
this constraint is already implied because <tt>packaged_task</tt> is not 
copyable and the template constructors require that "invoking a copy of <tt>f</tt> 
shall behave the same as invoking <tt>f</tt>".
<p/>
Daniel points out that the variadic constructor of <tt>std::thread</tt>
described in 30.3.1.2 [thread.thread.constr] has a similar problem and 
suggests a similar wording change, which has been integrated below.
<p/>
An alternative is to declare <tt>thread(thread&amp;)</tt> and
<tt>packaged_task(packaged_task&amp;)</tt> as deleted.
</p>

<p><i>[2012, Portland]</i></p>

<p>
This issue appears to be more about library specification than technical
concurrency issues, so should be handled in LWG.
</p>


<p><i>[2012, Portland]</i></p>

<p>
Move to Immediate resolution.
</p>
<p>
Howard volunteered existing implementation experience with the first change, and saw no issue that the second would introduce any new issue.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to the FDIS.</p>

<ol>
<li><p>Insert a new Remarks element to 30.3.1.2 [thread.thread.constr] around p3 as indicated:</p>

<blockquote><pre>
template &lt;class F, class ...Args&gt; explicit thread(F&amp;&amp; f, Args&amp;&amp;... args);
</pre></blockquote>
<p>
-3- <i>Requires</i>: <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall satisfy the <tt>MoveConstructible</tt> 
requirements. <tt><i>INVOKE</i>(<i>DECAY_COPY</i> ( std::forward&lt;F&gt;(f)), <i>DECAY_COPY</i> (std::forward&lt;Args&gt;(args))...)</tt> 
(20.8.2) shall be a valid expression.
<p/>
<ins>-?- <i>Remarks</i>: This constructor shall not participate in overload resolution if <tt>decay&lt;F&gt;::type</tt> 
is the same type as <tt>std::thread</tt>.</ins>
</p>
</li>

<li><p>Insert a new Remarks element to 30.6.9.1 [futures.task.members] around p2 as indicated:</p>

<blockquote><pre>
template &lt;class F&gt;
  packaged_task(F&amp;&amp; f);
template &lt;class F, class Allocator&gt;
  explicit packaged_task(allocator_arg_t, const Allocator&amp; a, F&amp;&amp; f);
</pre></blockquote>
<p>
-2- <i>Requires</i>: <tt><i>INVOKE</i>(f, t1, t2, ..., tN, R)</tt>, where <tt>t1, t2, ..., tN</tt> are values of the corresponding
types in <tt>ArgTypes...</tt>, shall be a valid expression. Invoking a copy of <tt>f</tt> shall behave the same as invoking <tt>f</tt>.
<p/>
<ins>-?- <i>Remarks</i>: These constructors shall not participate in overload resolution if <tt>decay&lt;F&gt;::type</tt> 
is the same type as <tt>std::packaged_task&lt;R(ArgTypes...)&gt;</tt>.</ins>
</p>
</li>

</ol>






<hr>
<h3><a name="2159"></a>2159. <tt>atomic_flag</tt> initialization</h3>
<p><b>Section:</b> 29.7 [atomics.flag] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2012-05-24 <b>Last modified:</b> 2013-09-27</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.flag">issues</a> in [atomics.flag].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>

<p>
29.7 [atomics.flag]&#47;4 describes the <tt>ATOMIC_FLAG_INIT</tt>, but it's not quite clear about a 
couple of points:
</p>
<ol>
<li><p>
it's said that <tt>ATOMIC_FLAG_INIT</tt> "can be used to initialize an object of type <tt>atomic_flag</tt>" 
and the following example:
</p>
<blockquote><pre>
std::atomic_flag guard = ATOMIC_FLAG_INIT;
</pre></blockquote>
<p>
is presented. It's not clear whether the macro can also be used in the other initialization contexts:
</p>
<blockquote><pre>
std::atomic_flag guard ATOMIC_FLAG_INIT; 
std::atomic_flag guard {ATOMIC_FLAG_INIT};

struct A { std::atomic_flag flag; A(); };
A::A() : flag (ATOMIC_FLAG_INIT); 
A::A() : flag {ATOMIC_FLAG_INIT};
</pre></blockquote>
<p>
Please also note that examples are non-normative, according to the ISO directives, meaning that the wording 
presents no normative way to use the macro.
</p>
</li>

<li><p>
it's said that "It is unspecified whether an uninitialized <tt>atomic_flag</tt> object has an initial state 
of set or clear.". I believe the use of "uninitialized" is inappropriate. First of all, if an object is 
uninitialized it is obvious that we cannot assert anything about its state. Secondly, it doesn't address the 
following cases:
</p>
<blockquote><pre>
std::atomic_flag a; <i>// object is "initialized" by trivial default constructor</i>
std::atomic_flag a {}; <i>// object is value-initialized</i>
static std::atomic_flag a; <i>// object is zero-initialized</i>
</pre></blockquote>
<p>
strictly speaking a trivial constructor "initializes" the object, although it doesn't actually initialize the 
sub-objects.
</p></li>

<li><p>it's said that "For a static-duration object, that initialization shall be static.". Considering 
the following example:</p>
<blockquote><pre>
struct A
{
  A(); <i>// user-provided, not constexpr</i>

  std::atomic_flag flag = ATOMIC_FLAG_INIT;
  <i>// possibly other non-static data members</i>
};

static A a;
</pre></blockquote>
<p>
The object <tt>a.flag</tt> (as a sub-object of the object <tt>a</tt>) has static-duration, yet the initialization 
has to be dynamic because <tt>A::A</tt> is not <tt>constexpr</tt>.
</p>

</li>
</ol>

<p><i>[2012, Portland]</i></p>

<p>
We would like to be able to allow more initialisation contexts for example:
</p>
<ol>
<li>C struct</li>
<li>C++ constructor initializer-list</li>
</ol>
<p>
However we need further input from experts with implementation specific knowledge
to identify which additional contexts (if any) would be universally valid.
</p>
<p>
Moved to open
</p>

<p><i>[2012, Portland]</i></p>

<p>
Move to Immediate, following review.
</p>
<p>
Some discussion over the explicit use of only copy initialization, and not direct initializtion.  This is necessary to
allow the implementation of <tt>atomic_flag</tt> as an aggregate, and may be further reviewed in the future.
</p>



<p><b>Proposed resolution:</b></p>
<p><i>[This wording is relative to N3376.]</i></p>


<p>Change 29.7 [atomics.flag]&#47;4 as follows:</p>

<blockquote><p>
The macro <tt>ATOMIC_FLAG_INIT</tt> shall be defined in such a way that it can be used to initialize an object of
type <tt>atomic_flag</tt> to the clear state.  <ins>The macro can be used in the form:</ins>
</p>
<blockquote><pre>
<ins>atomic_flag guard = ATOMIC_FLAG_INIT;</ins>
</pre></blockquote>
<p>
<ins>It is unspecified whether the macro can be used in other initialization contexts.</ins> For a <ins>complete</ins>
static-duration object, that initialization shall be static. <del>It is unspecified whether an uninitialized</del> 
<ins>Unless initialized with <tt>ATOMIC_FLAG_INIT</tt>, it is unspecified whether an</ins> <tt>atomic_flag</tt> 
object has an initial state of set or clear. <del><i>[ Example:</i></del>
</p>
<blockquote><pre>
<del>atomic_flag guard = ATOMIC_FLAG_INIT;</del>
</pre></blockquote>
<p>
<del>&mdash; <i>end example ]</i></del>
</p>
</blockquote>






<hr>
<h3><a name="2275"></a>2275. [CD] Why is <tt>forward_as_tuple</tt> not <tt>constexpr</tt>?</h3>
<p><b>Section:</b> 20.4.2.4 [tuple.creation] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2013-07-30 <b>Last modified:</b> 2013-09-25</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple.creation">issues</a> in [tuple.creation].</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 ES 11</b></p>

<p>
In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3471.html">n3471</a>, a bunch of routines 
from header <tt>&lt;tuple&gt;</tt> were made <tt>constexpr</tt>.
<p/>
<tt>make_tuple/tuple_cat/get&lt;&gt;(tuple)/</tt>relational operators &mdash; all these were "constexpr-ified".
<p/>
But not <tt>forward_as_tuple</tt>.
<p/>
Why not?
<p/>
This was discussed in Portland, and STL opined that this was "an omission" (along with <tt>tuple_cat</tt>, which was added)
<p/>
In discussion on c++std-lib@accu.org list, Pablo agreed that <tt>forward_as_tuple</tt> should be <tt>constexpr</tt>.
</p>

<p><i>[2013-09 Chicago]</i></p>

<p>
Moved to Immediate, this directly addresses an NB comment and the wording is non-controversial.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change header <tt>&lt;tuple&gt;</tt> synopsis, 20.4.1 [tuple.general] as indicated:</p>

<blockquote>
<pre>
template &lt;class... Types&gt;
  <ins>constexpr</ins> tuple&lt;Types&amp;&amp;...&gt; forward_as_tuple(Types&amp;&amp;...) noexcept;
</pre>
</blockquote>
</li>

<li><p>Change 20.4.2.4 [tuple.creation] before p5 as indicated:</p>

<blockquote>
<pre>
template &lt;class... Types&gt;
  <ins>constexpr</ins> tuple&lt;Types&amp;&amp;...&gt; forward_as_tuple(Types&amp;&amp;... t) noexcept;
</pre>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2284"></a>2284. Inconsistency in <tt>allocator_traits::max_size</tt></h3>
<p><b>Section:</b> 20.8.8 [allocator.traits] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2013-08-27 <b>Last modified:</b> 2013-09-26</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 20.8.8 [allocator.traits] says:
</p>
<blockquote><pre>
static size_type max_size(const Alloc&amp; a) noexcept;
</pre></blockquote>
<p>
Section 20.8.8.2 [allocator.traits.members] says:
</p>
<blockquote><pre>
static size_type max_size(Alloc&amp; a) noexcept;
</pre></blockquote>

<p>
These should be the same.
</p>

<p>
Discussion:
</p>

<p>
Pablo (who I believe wrote the <tt>allocator_traits</tt> proposal) says "The function should take a <tt>const</tt> reference."
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change 20.8.8.2 [allocator.traits.members] as follows:</p>

<blockquote><pre>
static size_type max_size(<ins>const</ins> Alloc&amp; a) noexcept;
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2298"></a>2298. [CD] <tt>is_nothrow_constructible</tt> is always false because of <tt>create&lt;&gt;</tt></h3>
<p><b>Section:</b> 20.11.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-09-24 <b>Last modified:</b> 2013-09-26</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</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 18</b></p>

<p>
The trait <tt>is_constructible&lt;T, Args...&gt;</tt> is defined in terms of a helper template, <tt>create&lt;&gt;</tt>, 
that is identical to <tt>std::declval&lt;&gt;</tt> except for the latter's <tt>noexcept</tt> clause.   
<p/>
If the absence of <tt>noexcept</tt> is critical to this definition, insert a Note of explanation; otherwise, excise 
<tt>create&lt;&gt;</tt> and reformulate in terms of <tt>declval&lt;&gt;</tt> the definition of <tt>is_constructible</tt>. 
</p>

<p><i>[2013-09-24 Daniel comments and provides resolution suggestion]</i></p>


<p>
Replacing <tt>create&lt;&gt;</tt> by <tt>std::declval&lt;&gt;</tt> would make the situation worse, because the definition of
<tt>is_constructible</tt> is based on a well-formed variable definition and there is no way to specify a variable definition
without odr-using its initializer arguments. It should also be added, that there is another problem with the specification of
all existing <tt>is_trivially_*</tt> traits, because neither <tt>create&lt;&gt;</tt> nor <tt>std::declval&lt;&gt;</tt>
are considered as trivial functions, but this should be solved by a different issue.
</p>

<p><i>[2013-09-26 Nico improves wording]</i></p>


<p>
The additional change is just to keep both places were <tt>create()</tt> is defined consistent.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change 20.11.4.3 [meta.unary.prop] around p6 as indicated:</p>

<blockquote><p>
-6- Given the following function prototype:
</p>
<blockquote><pre>
template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create() <ins>noexcept</ins>;
</pre></blockquote>
<p>
the predicate condition for a template specialization <tt>is_constructible&lt;T, Args...&gt;</tt> shall be satisfied
if and only if the following variable definition would be well-formed for some invented variable <tt>t</tt>:
</p>
<blockquote><pre>
T t(create&lt;Args&gt;()...);
</pre></blockquote>
<p>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Change 20.11.4.3 [meta.unary.prop] around p4 as indicated:</p>

<blockquote><p>
-4- Given the following function prototype:
</p>
<blockquote><pre>template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create() <ins>noexcept</ins>;
</pre></blockquote>
<p>
the predicate condition for a template specialization <tt>is_convertible&lt;From, To&gt;</tt> shall be satisfied if and
only if the return expression in the following code would be well-formed, including any implicit conversions
to the return type of the function:
</p>
<blockquote><pre>
To test() {
  return create&lt;From&gt;();
}
</pre></blockquote>
<p>
[&hellip;]
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2300"></a>2300. [CD] Redundant sections for <tt>map</tt> and <tt>multimap</tt> members should be removed</h3>
<p><b>Section:</b> 23.4.4.5 [map.ops], 23.4.5.4 [multimap.ops] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2013-09-25 <b>Last modified:</b> 2013-09-26</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 ES 17</b></p>

<p>
Sections are redundant with general associative container requirements at 23.2.4 [associative.reqmts], Table 102. 
<p/>
Suggested action:     
<p/>
Delete sections.
</p>

<p><i>[2013-09-25 Daniel provides resolution suggestion]</i></p>


<p><i>[2013-09-25 Chicago]</i></p>

<p>
Daniel's wording is good, move to Immediate to resolve NB comment.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N3691.</p>

<ol>
<li><p>Change the header <tt>&lt;map&gt;</tt> synopsis, 23.4.4.1 [map.overview] p2 as indicated:</p>

<blockquote><pre>
// <del>23.4.4.5,</del> map operations:
iterator find(const key_type&amp; x);
const_iterator find(const key_type&amp; x) const;
template &lt;class K&gt; iterator find(const K&amp; x);
template &lt;class K&gt; const_iterator find(const K&amp; x) const;
</pre>
</blockquote>
</li>

<li><p>Delete the complete sub-clause 23.4.4.5 [map.ops]:</p>

<p>
<del>23.4.4.5 map operations [map.ops]</del>
</p>
<blockquote><pre>
<del>iterator find(const key_type&amp; x);
const_iterator find(const key_type&amp; x) const;
iterator lower_bound(const key_type&amp; x);
const_iterator lower_bound(const key_type&amp; x) const;
iterator upper_bound(const key_type&amp; x);
const_iterator upper_bound(const key_type &amp;x) const;
pair&lt;iterator, iterator&gt;
  equal_range(const key_type &amp;x);
pair&lt;const_iterator, const_iterator&gt;
  equal_range(const key_type&amp; x) const;</del>
</pre><blockquote>
<p>
<del>-1- The <tt>find</tt>, <tt>lower_bound</tt>, <tt>upper_bound</tt> and <tt>equal_range</tt> member functions each have two versions,
one const and the other non-const. In each case the behavior of the two functions is identical except
that the const version returns a <tt>const_iterator</tt> and the non-const version an <tt>iterator</tt> (23.2.4).</del>
</p>
</blockquote></blockquote>
</li>

<li><p>Delete the complete sub-clause 23.4.5.4 [multimap.ops]:</p>

<p>
<del>23.4.5.4 multimap operations [multimap.ops]</del>
</p>
<blockquote><pre>
<del>iterator find(const key_type &amp;x);
const_iterator find(const key_type&amp; x) const;

iterator lower_bound(const key_type&amp; x);
const_iterator lower_bound(const key_type&amp; x) const;

pair&lt;iterator, iterator&gt;
  equal_range(const key_type &amp;x);
pair&lt;const_iterator, const_iterator&gt;
  equal_range(const key_type&amp; x) const;</del>
</pre><blockquote>
<p>
<del>-1- The <tt>find</tt>, <tt>lower_bound</tt>, <tt>upper_bound</tt> and <tt>equal_range</tt> member functions each have two versions,
one const and one non-const. In each case the behavior of the two versions is identical except
that the const version returns a <tt>const_iterator</tt> and the non-const version an <tt>iterator</tt> (23.2.4).</del>
</p>
</blockquote></blockquote>
</li>

</ol>





</body>
</html>
