<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>C++ Standard Evolution Active Issues List</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">N3566</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2013-03-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">Ville Voutilainen &lt;<a href="mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt;</td>
</tr>
</table>
<h1>C++ Standard Evolution Active Issues List (Revision R01)</h1>
<p>Revised 2013-03-12 at 15:03:58 UTC</p>

  <p>Reference ISO/IEC IS 14882:2003(E)</p>
  <p>Also see:</p>
  <ul>
      <li><a href="ewg-toc.html">Table of Contents</a> for all evolution issues.</li>
      <li><a href="ewg-index.html">Index by Section</a> for all evolution issues.</li>
      <li><a href="ewg-status.html">Index by Status</a> for all evolution issues.</li>
      <li><a href="ewg-defects.html">Evolution Defect Reports List</a></li>
      <li><a href="ewg-closed.html">Evolution Closed Issues List</a></li>
  </ul>
  <p>The purpose of this document is to record the status of issues
  which have come before the Evolution Working Group (EWG) of the INCITS PL22.16
  and ISO WG21 C++ Standards Committee. Issues represent
  potential defects in the ISO/IEC IS 14882:2003(E) document.  
  </p>

  <p>This document contains only evolution issues which are actively being
  considered by the Evolution Working Group, i.e., issues which have a
  status of <a href="ewg-active.html#New">New</a>, <a href="ewg-active.html#Open">Open</a>, 
  <a href="ewg-active.html#Ready">Ready</a>, or <a href="ewg-active.html#Review">Review</a>. See
  <a href="ewg-defects.html">Evolution Defect Reports List</a> for issues considered defects and 
  <a href="ewg-closed.html">Evolution Closed Issues List</a> for issues considered closed.</p>

  <p>The issues in these lists are not necessarily formal ISO Defect
  Reports (DR's). While some issues will eventually be elevated to
  official Defect Report status, other issues will be disposed of in
  other ways. See <a href="#Status">Issue Status</a>.</p>

  <p>This document includes <i>[bracketed italicized notes]</i> as a
  reminder to the EWG of current progress on issues. Such notes are
  strictly unofficial and should be read with caution as they may be
  incomplete or incorrect. Be aware that EWG support for a particular
  resolution can quickly change if new viewpoints or killer examples are
  presented in subsequent discussions.</p>

  <p>For the most current official version of this document see 
  <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
  Requests for further information about this document should include
  the document number above, reference ISO/IEC 14882:2003(E), and be
  submitted to Information Technology Industry Council (ITI), 1250 Eye
  Street NW, Washington, DC 20005.</p>

  <p>Public information as to how to obtain a copy of the C++ Standard,
  join the standards committee, submit an issue, or comment on an issue
  can be found in the comp.std.c++ FAQ.
  </p>

<p><a name="submit_issue"></a><b>How to submit an issue</b></p>

<ol style="list-style-type:upper-alpha">
<li><a name="submit_issue_A"></a>
Mail your issue to the author of this list.
</li>
<li><a name="submit_issue_B"></a>
Specify a short descriptive title.  If you fail to do so, the subject line of your
mail will be used as the issue title.
</li>
<li><a name="submit_issue_C"></a>
If the "From" on your email is not the name you wish to appear as issue submitter,
then specify issue submitter.
</li>
<li><a name="submit_issue_D"></a>
Provide a brief discussion of the problem you wish to correct.  Refer to the latest
working draft or standard using [section.tag] and paragraph numbers where appropriate.
</li>
<li><a name="submit_issue_E"></a>
Provide proposed wording.  This should indicate exactly how you want the standard
to be changed.  General solution statements belong in the discussion area.  This
area contains very clear and specific directions on how to modify the current
draft.  If you are not sure how to word a solution, you may omit this part.
But your chances of a successful issue greatly increase if you attempt wording.
</li>
<li><a name="submit_issue_F"></a>
It is not necessary for you to use html markup.  However, if you want to, you can
&lt;ins&gt;<ins>insert text like this</ins>&lt;/ins&gt; and &lt;del&gt;<del>delete text like
this</del>&lt;/del&gt;.  The only strict requirement is to communicate clearly to
the list maintainer exactly how you want your issue to look.
</li>
<li><a name="submit_issue_G"></a>
It is not necessary for you to specify other html font/formatting
mark-up, but if you do the list maintainer will attempt to respect your
formatting wishes (as described by html markup, or other common idioms).
</li>
<li><a name="submit_issue_H"></a>
It is not necessary for you to specify open date or last modified date (the date
of your mail will be used).
</li>
<li><a name="submit_issue_I"></a>
It is not necessary for you to cross reference other issues, but you can if you
like.  You do not need to form the hyperlinks when you do, the list maintainer will
take care of that.
</li>
<li><a name="submit_issue_J"></a>
One issue per email is best.
</li>
<li><a name="submit_issue_K"></a>
Between the time you submit the issue, and the next mailing deadline
(date at the top of the Revision History), you <em>own</em> this issue. 
You control the content, the stuff that is right, the stuff that is
wrong, the format, the misspellings, etc.  You can even make the issue
disappear if you want.  Just let the list maintainer know how you want
it to look, and he will try his best to accommodate you.  After the
issue appears in an official mailing, you no longer enjoy exclusive
ownership of it.
</li>
</ol>


<h2>Revision History</h2>
<ul>
<li>R01: 2013-03-18 pre-Bristol mailing<ul>
<li><b>Summary:</b><ul>
<li>47 open issues, up by 47.</li>
<li>1 closed issues, up by 1.</li>
<li>48 issues total, up by 48.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issue: <a href="ewg-closed.html#39">39</a>.</li>
<li>Added the following 32 New issues: <a href="ewg-active.html#2">2</a>, <a href="ewg-active.html#5">5</a>, <a href="ewg-active.html#8">8</a>, <a href="ewg-active.html#10">10</a>, <a href="ewg-active.html#11">11</a>, <a href="ewg-active.html#12">12</a>, <a href="ewg-active.html#14">14</a>, <a href="ewg-active.html#15">15</a>, <a href="ewg-active.html#17">17</a>, <a href="ewg-active.html#19">19</a>, <a href="ewg-active.html#23">23</a>, <a href="ewg-active.html#24">24</a>, <a href="ewg-active.html#26">26</a>, <a href="ewg-active.html#28">28</a>, <a href="ewg-active.html#30">30</a>, <a href="ewg-active.html#31">31</a>, <a href="ewg-active.html#32">32</a>, <a href="ewg-active.html#33">33</a>, <a href="ewg-active.html#34">34</a>, <a href="ewg-active.html#35">35</a>, <a href="ewg-active.html#36">36</a>, <a href="ewg-active.html#37">37</a>, <a href="ewg-active.html#38">38</a>, <a href="ewg-active.html#40">40</a>, <a href="ewg-active.html#41">41</a>, <a href="ewg-active.html#42">42</a>, <a href="ewg-active.html#43">43</a>, <a href="ewg-active.html#44">44</a>, <a href="ewg-active.html#45">45</a>, <a href="ewg-active.html#46">46</a>, <a href="ewg-active.html#47">47</a>, <a href="ewg-active.html#48">48</a>.</li>
<li>Added the following 9 Open issues: <a href="ewg-active.html#4">4</a>, <a href="ewg-active.html#9">9</a>, <a href="ewg-active.html#16">16</a>, <a href="ewg-active.html#18">18</a>, <a href="ewg-active.html#21">21</a>, <a href="ewg-active.html#22">22</a>, <a href="ewg-active.html#25">25</a>, <a href="ewg-active.html#27">27</a>, <a href="ewg-active.html#29">29</a>.</li>
<li>Added the following 6 Ready issues: <a href="ewg-active.html#1">1</a>, <a href="ewg-active.html#3">3</a>, <a href="ewg-active.html#6">6</a>, <a href="ewg-active.html#7">7</a>, <a href="ewg-active.html#13">13</a>, <a href="ewg-active.html#20">20</a>.</li>
</ul></li>
</ul>
</li>
</ul>

<h2><a name="Status"></a>Issue Status</h2>

  <p><b><a name="New">New</a></b> - The issue has not yet been
  reviewed by the EWG. Any <b>Wording available</b> is purely a
  suggestion from the issue submitter, and should not be construed as
  the view of EWG.</p>

  <p><b><a name="Open">Open</a></b> - The EWG has discussed the issue
  but is not yet ready to move the issue forward. There are several
  possible reasons for open status:</p>
     <ul>
        <li>Consensus may have not yet have been reached as to how to deal
            with the issue.</li>
        <li>Informal consensus may have been reached, but the EWG awaits
            exact resolution for review.</li>
        <li>The EWG wishes to consult additional technical experts before
            proceeding.</li>
        <li>The issue may require further study.</li>
     </ul>

  <p>A <b>Wording available</b> for an open issue is still not be
  construed as the view of EWG. Comments on the current state of
  discussions are often given at the end of open issues in an italic
  font. Such comments are for information only and should not be given
  undue importance.</p>

  <p><b><a name="Deferred">Deferred</a></b> - The EWG has discussed the issue,
  is not yet ready to move the issue forward, but neither does it deem the
  issue significant enough to delay publishing a standard or Technical Report.
  A typical deferred issue would be seeking to clarify wording that might be
  technically correct, but easily mis-read.</p>

  <p>A <b>Wording available</b> for a deferred issue is still not be
  construed as the view of EWG. Comments on the current state of
  discussions are often given at the end of open issues in an italic
  font. Such comments are for information only and should not be given
  undue importance.</p>

  <p><b><a name="Dup">Dup</a></b> - The EWG has reached consensus that
  the issue is a duplicate of another issue, and will not be further
  dealt with. A <b>Rationale</b> identifies the duplicated issue's
  issue number.  </p>

  <p><b><a name="NAD">NAD</a></b> - The EWG has reached consensus that
  the issue is not a defect in the Standard nor is it an extension
  the EWG deems acceptable.</p>

  <p><b><a name="Review">Review</a></b> - Exact resolution is now 
  available for review on an issue for which the EWG previously reached 
  informal consensus.</p>

  <p><b><a name="Ready">Ready</a></b> - The EWG has reached consensus
  that the issue is an extension that can go forward to Core, Library,
  or a Study Group for further processing.</p>

  <p><b><a name="Resolved">Resolved</a></b> - The EWG has reached consensus
  that the issue is a defect in or an acceptable extension to the Standard, 
  but the resolution adopted to
  resolve the issue came via some other mechanism than this issue in the
  list - typically by applying a formal paper, occasionally as a side effect
  of consolidating several interacting issue resolutions into a single issue.</p>

  <p><b><a name="DR">DR</a></b> - (Defect Report) - It's not expected
  that the EWG would handle Defect Reports.</p>

  <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
  resolution has not been accepted as a Technical Corrigendum, but
  the full WG21/PL22.16 committee has voted to apply the Defect Report's Proposed
  Resolution to the working paper.</p>

  <p><b>Tentatively</b> - This is a <i>status qualifier</i>.  The issue has
  been reviewed online, or at an unofficial meeting, but not in an official meeting, and some support has been formed
  for the qualified status.  Tentatively qualified issues may be moved to the unqualified status
  and forwarded to full committee (if Ready) within the same meeting.  Unlike Ready issues, Tentatively Ready issues
  will be reviewed in subcommittee prior to forwarding to full committee.  When a status is
  qualified with Tentatively, the issue is still considered active.</p>

  <p><b>Pending</b> - This is a <i>status qualifier</i>.  When prepended to
  a status this indicates the issue has been
  processed by the committee, and a decision has been made to move the issue to
  the associated unqualified status.  However for logistical reasons the indicated
  outcome of the issue has not yet appeared in the latest working paper.

  <p>Issues are always given the status of <a href="ewg-active.html#New">New</a> when
  they first appear on the issues list. They may progress to
  <a href="ewg-active.html#Open">Open</a> or <a href="ewg-active.html#Review">Review</a> while the EWG
  is actively working on them. When the EWG has reached consensus on
  the disposition of an issue, the status will then change to
  <a href="ewg-active.html#Dup">Dup</a>, <a href="ewg-active.html#NAD">NAD</a>, or
  <a href="ewg-active.html#Ready">Ready</a> as appropriate.  Once the full J16 committee votes to
  forward Ready issues to the Project Editor, they are given the
  status of Defect Report ( <a href="ewg-active.html#DR">DR</a>). These in turn may
  become the basis for Technical Corrigenda (<a href="ewg-active.html#TC1">TC1</a>),
  or are closed without action other than a Record of Response
  (<a href="ewg-active.html#Resolved">Resolved</a> ). The intent of this EWG process is that
  only issues which are truly defects in the Standard move to the
  formal ISO DR status.
  </p>


<h2>Active Issues</h2>
<hr>
<h3><a name="1"></a>1. N3386 Return type deduction for normal functions</h3>
<p><b>Section:</b> 7.1.6.4 [dcl.spec.auto] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2012-03-27 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3386.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3386.html</a>
<p>Reviewed by EWG in Portland 2012, proceeding to CWG.</p>


<p><b>Wording available:</b></p>
<p>The paper contains the proposed wording.</p>




<hr>
<h3><a name="2"></a>2. N3387 Overload resolution tiebreakers for integer types</h3>
<p><b>Section:</b> 4.13 [conv.rank] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2012-09-12 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3387.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3387.html</a>


<p><b>Wording available:</b></p>
<p>The paper contains the proposed wording.</p>




<hr>
<h3><a name="3"></a>3. N3394 [[deprecated]] attribute</h3>
<p><b>Section:</b> 7.6 [dcl.attr] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2012-06-12 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html</a>

<p>Reviewed by EWG in Portland 2012, proceeding to CWG.</p>


<p><b>Wording available:</b></p>
<p>The paper contains the proposed wording.</p>




<hr>
<h3><a name="4"></a>4. N3396 Dynamic memory allocation for over-aligned data</h3>
<p><b>Section:</b> 18.6 [support.dynamic] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2012-08-30 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm</a>
<p>Reviewed by EWG in Portland, author encouraged to revise.</p>


<p><b>Wording available:</b></p>
<p>The paper contains the proposed wording that is to be revised.</p>




<hr>
<h3><a name="5"></a>5. 
N3400 A proposal for eliminating the underscore madness that library writers have to suffer</h3>
<p><b>Section:</b> 16.3 [cpp.replace] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Jonathan de Boyne Pollard <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3400.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3400.html</a>


<p><b>Wording available:</b></p>
<p>The paper contains the proposed wording.</p>




<hr>
<h3><a name="6"></a>6. 
N3401 Generating move operations (elaborating on Core 1402)
</h3>
<p><b>Section:</b> 12.8 [class.copy] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3401.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3401.html</a>
<p>Reviewed by EWG in Portland 2012, proceeding to CWG.</p>


<p><b>Wording available:</b></p>
<p>The related Core issue contains the proposed wording.</p>




<hr>
<h3><a name="7"></a>7. 
N3402 User-defined Literals for Standard Library Types
</h3>
<p><b>Section:</b> 20.1 [utilities.general] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Peter Sommerlad <b>Opened:</b> 2012-09-08 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3402.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3402.pdf</a>
<p>Reviewed by EWG in Portland 2012, binary literals to be added into the core language, the rest of the paper is on LWG's plate. The binary literals are proceeding to CWG.</p>


<p><b>Wording available:</b></p>
<p>The paper contains the Library wording, Dennett has written the Core
wording for binary literals.</p>




<hr>
<h3><a name="8"></a>8. 
N3403 Use Cases for Compile-Time Reflection
</h3>
<p><b>Section:</b> 18 [language.support] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2012-09-22 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3403.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3403.pdf</a>
<p>Not reviewed by EWG yet, to be handled by the Reflection Study Group (SG7).</p>





<hr>
<h3><a name="9"></a>9. 
N3405 Template Tidbits
</h3>
<p><b>Section:</b> 14 [temp] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2012-09-22 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3405.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3405.html</a>
<p>EWG review started, not completed yet. Likely needs a follow-up paper.</p>





<hr>
<h3><a name="10"></a>10. 
N3407 Proposal to Add Decimal Floating Point Support to C++
</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Dietmar Khl <b>Opened:</b> 2012-09-14 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="ewg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html</a>
<p>Handled by the Numerics Study Group (SG5).</p>





<hr>
<h3><a name="11"></a>11. 
N3409 Strict Fork-Join Parallelism
</h3>
<p><b>Section:</b> 1.10 [intro.multithread] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2012-09-24 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#intro.multithread">active issues</a> in [intro.multithread].</p>
<p><b>View all other</b> <a href="ewg-index.html#intro.multithread">issues</a> in [intro.multithread].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3409.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3409.pdf</a>
<p>Handled by the Concurrency Study Group (SG1)</p>





<hr>
<h3><a name="12"></a>12. 
N3410 Rich Pointers with Dynamic and Static Introspection
</h3>
<p><b>Section:</b> 20.9 [meta] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Dean Michael Berris <b>Opened:</b> 2012-09-18 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#meta">active issues</a> in [meta].</p>
<p><b>View all other</b> <a href="ewg-index.html#meta">issues</a> in [meta].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3410.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3410.pdf</a>
<p>To be handled by the Reflection Study Group (SG7).</p>





<hr>
<h3><a name="13"></a>13. 
N3412 Runtime-sized arrays with automatic storage duration (revision 2)
</h3>
<p><b>Section:</b> 3.9 [basic.types] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2012-09-19 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3412.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3412.html</a>
<p>
Reviewed by EWG in Portland 2012, proceeding to CWG. The library part is <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2648.html">N2648 C++ Dynamic Arrays</a>, and that part is proceeding to LWG.
</p>


<p><b>Wording available:</b></p>
The paper contains the proposed wording, as does the Library counterpart.




<hr>
<h3><a name="14"></a>14. 
N3413 Allowing arbitrary literal types for non-type template parameters
</h3>
<p><b>Section:</b> 14.1 [temp.param] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2012-09-19 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.param">active issues</a> in [temp.param].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.param">issues</a> in [temp.param].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html</a>


<p><b>Wording available:</b></p>
The paper contains the proposed wording.




<hr>
<h3><a name="15"></a>15. 
N3416 Packaging Parameter Packs
</h3>
<p><b>Section:</b> 14.1 [temp.param] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.param">active issues</a> in [temp.param].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.param">issues</a> in [temp.param].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3416.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3416.html</a>





<hr>
<h3><a name="16"></a>16. 
N3418 Proposal for Generic (Polymorphic) Lambda Expressions  
</h3>
<p><b>Section:</b> 5.1.2 [expr.prim.lambda] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Faisal Vali <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#expr.prim.lambda">active issues</a> in [expr.prim.lambda].</p>
<p><b>View all other</b> <a href="ewg-index.html#expr.prim.lambda">issues</a> in [expr.prim.lambda].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf</a>
<p>
Reviewed by EWG in Portland 2012, proceeding with a follow-up paper.
</p>





<hr>
<h3><a name="17"></a>17. 
N3419 Vector loops and Parallel Loops
</h3>
<p><b>Section:</b> 1.10 [intro.multithread] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Robert Geva <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#intro.multithread">active issues</a> in [intro.multithread].</p>
<p><b>View all other</b> <a href="ewg-index.html#intro.multithread">issues</a> in [intro.multithread].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3419.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3419.pdf</a>
<p>
Handled by the Concurrency Study Group (SG1).
</p>





<hr>
<h3><a name="18"></a>18. 
N3424 Lambda Correctness and Usability Issues
</h3>
<p><b>Section:</b> 5.1.2 [expr.prim.lambda] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#expr.prim.lambda">active issues</a> in [expr.prim.lambda].</p>
<p><b>View all other</b> <a href="ewg-index.html#expr.prim.lambda">issues</a> in [expr.prim.lambda].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3424.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3424.pdf</a>
<p>
Reviewed by EWG in Portland 2012, proceeding with a follow-up paper. Changes to const captures rejected, capturing of 'this' and members encouraged to continue with a follow-up paper.
</p>






<hr>
<h3><a name="19"></a>19. 
N3429 A C++ Library Solution To Parallelism
</h3>
<p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Artur Laksberg <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3429.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3429.pdf</a>
<p>
Handled by the Concurrency Study Group (SG1).
</p>


<p><b>Wording available:</b></p>
<p>The paper contains the proposed wording.</p>




<hr>
<h3><a name="20"></a>20. 
N3432 C++ Sized Deallocation
</h3>
<p><b>Section:</b> 3.7.4 [basic.stc.dynamic] <b>Status:</b> <a href="ewg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#basic.stc.dynamic">active issues</a> in [basic.stc.dynamic].</p>
<p><b>View all other</b> <a href="ewg-index.html#basic.stc.dynamic">issues</a> in [basic.stc.dynamic].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3432.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3432.html</a>
<p>
Reviewed by EWG in Portland 2012, proceeding to CWG.
</p>


<p><b>Wording available:</b></p>
<p>The paper contains the proposed wording.</p>




<hr>
<h3><a name="21"></a>21. 
N3433 Clarifying Memory Allocation
</h3>
<p><b>Section:</b> 3.7.4 [basic.stc.dynamic] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#basic.stc.dynamic">active issues</a> in [basic.stc.dynamic].</p>
<p><b>View all other</b> <a href="ewg-index.html#basic.stc.dynamic">issues</a> in [basic.stc.dynamic].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3433.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3433.html</a>
<p>
Reviewed by EWG in Portland 2012, proceeding with a follow-up paper.
</p>


<p><b>Wording available:</b></p>
<p>The paper contains the proposed wording.</p>




<hr>
<h3><a name="22"></a>22. 
N3435 Standardized feature-test macros
</h3>
<p><b>Section:</b> 18.1 [support.general] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2012-09-18 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3435.htm">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3435.htm</a>
<p>
Reviewed by EWG in Portland 2012, proceeding in SG10, Feature Test.
</p>





<hr>
<h3><a name="23"></a>23. 
N3437 Type Name Strings For C++
</h3>
<p><b>Section:</b> 20.9 [meta] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Axel Naumann <b>Opened:</b> 2012-09-24 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#meta">active issues</a> in [meta].</p>
<p><b>View all other</b> <a href="ewg-index.html#meta">issues</a> in [meta].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3437.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3437.pdf</a>
<p>
Not reviewed by EWG yet, to be handled by the Reflection Study Group (SG7).
</p>





<hr>
<h3><a name="24"></a>24. 
N3441 Call Stack Utilities and std::exception Extension Proposal
</h3>
<p><b>Section:</b> 18.8 [support.exception] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Aurelian Melinte <b>Opened:</b> 2012-09-20 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3441.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3441.html</a>





<hr>
<h3><a name="25"></a>25. 
N3444 Relaxing syntactic constraints on constexpr function definitions
</h3>
<p><b>Section:</b> 5.19 [expr.const] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#expr.const">active issues</a> in [expr.const].</p>
<p><b>View all other</b> <a href="ewg-index.html#expr.const">issues</a> in [expr.const].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3444.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3444.html</a>
<p>
Reviewed by EWG in Portland 2012, proceeding with a follow-up paper.
</p>





<hr>
<h3><a name="26"></a>26. 
N3445 Pass by Const Reference or Value
</h3>
<p><b>Section:</b> 8.3.5 [dcl.fct] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3445.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3445.html</a>





<hr>
<h3><a name="27"></a>27. 
N3448 Painless Digit Separation
</h3>
<p><b>Section:</b> 2.10 [lex.ppnumber] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Daveed Vandevoorde <b>Opened:</b> 2012-09-21 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3448.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3448.pdf</a>
<p>
Reviewed by EWG in Portland 2012, proceeding with a follow-up paper.
</p>


<p><b>Wording available:</b></p>
<p>The paper contains the proposed wording.</p>




<hr>
<h3><a name="28"></a>28. 
N3449 Open and Efficient Type Switch for C++
</h3>
<p><b>Section:</b> 5.2.7 [expr.dynamic.cast] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Bjarne Stroustrup <b>Opened:</b> 2012-09-23 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdf</a>





<hr>
<h3><a name="29"></a>29. 
N3329 Proposal: static if declaration
</h3>
<p><b>Section:</b> 20.9 [meta] <b>Status:</b> <a href="ewg-active.html#Open">Open</a>
 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2012-01-10 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#meta">active issues</a> in [meta].</p>
<p><b>View all other</b> <a href="ewg-index.html#meta">issues</a> in [meta].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf</a>
<p>
Reviewed by EWG in Portland 2012, to be handled by the Concepts Study Group (SG8).
</p>





<hr>
<h3><a name="30"></a>30. 
[tiny] Efficient/Flexible Access to Argument Packs
</h3>
<p><b>Section:</b> 14.5.3 [temp.variadic] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2012-10-16 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There are lots of very basic manipulations that are either really hard
or impossible to do with argument packs unless you use something that
causes a big recursive template instantiation, which is expensive at
compile-time and can cause bad error messages.  I want to be able to
index argument packs with integral constant expressions, "take" or
"drop" the first N elements of the pack, etc.
</p>





<hr>
<h3><a name="31"></a>31. 
[tiny] constexpr functions must work at runtime
</h3>
<p><b>Section:</b> 5.19 [expr.const] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2012-10-16 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#expr.const">active issues</a> in [expr.const].</p>
<p><b>View all other</b> <a href="ewg-index.html#expr.const">issues</a> in [expr.const].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
constexpr functions are crippled by the fact that they have to be valid
at runtime.  Things that are tantalizingly close but you can't quite do
include returning a type that depends on the /value/ of a function
parameter:

<pre>
  constexpr auto ptr_array(int N) -> int(*)[N]
  { ... }
</pre>

If we would allow for constexpr functions that can only be evaluated at
compile time, we'd be able to do compile-time computation in a much less
template-heavy way.
</p>





<hr>
<h3><a name="32"></a>32. 
[tiny] Templated constructor accidentally preferred over copy constructor
</h3>
<p><b>Section:</b> 13 [over] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2012-10-19 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<pre>

struct Silly
{
    template&lt;class... Ts&gt;
    Silly(Ts&&...)
    {}
};

int main()
{
    Silly s;
    Silly t(s);	// Silly::Silly(Ts &&...) [Ts = &lt;Silly &&gt;]
    const Silly u;
    Silly v(u); // calls Silly::Silly(Silly const&)
}
</pre>

The problem is that users expect the copy constructor to be called in both situations.

Note:  you do not need variadics for this; it made the example smaller.  Also, this issue existed in C++03, but rarely happened in practice because templated parameters were usually declared const T&.
</p>





<hr>
<h3><a name="33"></a>33. 
[tiny] contextual bool conversion from scoped enum
</h3>
<p><b>Section:</b> 7.2 [dcl.enum] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-10-20 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In Beman's filesystem code, I found the following problem, which he
didn't see because he's been building with MSVC 10:

A scoped enum defined at
<p>
<a href="https://github.com/Beman/filesystem-proposal/blob/master/include/boost/filesystem/operations.hpp#L230">https://github.com/Beman/filesystem-proposal/blob/master/include/boost/filesystem/operations.hpp#L230</a>
</p>
is used like

<p>
if (opts & copy_options::skip_existing) ++ct;
</p>

at 
<p>
<a href="https://github.com/Beman/filesystem-proposal/blob/master/src/operations.cpp#L773">https://github.com/Beman/filesystem-proposal/blob/master/src/operations.cpp#L773</a>.
</p>

This causes an error like:

<p>../../../libs/filesystem/src/operations.cpp:773:9: error: value of
type 'boost::filesystem::copy_options' is not contextually convertible
to 'bool'
</p>

I believe it makes sense to define a contextual conversion to bool for
certain scoped enumerations, but I don't see a way to do it. I do see
a way to overload & to return bool, but that seems to prevent using &
to remove bits from a value, which shouldn't always be prevented.
</p>





<hr>
<h3><a name="34"></a>34. 
[tiny] Defining hash functions for composite user-defined types is annoying
</h3>
<p><b>Section:</b> 17.6.3.4 [hash.requirements] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2012-10-23 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We have a hash function for built-in types and for some standard library types, but we don't have automatically generated hash&lt;&gt; specializations for user-defined types like
<pre>
  struct my_type {
    int x;
    std::string y;
    vector&lt;int&gt; z;
  };
</pre>
Defining a good and efficient hash function for composite types takes a fair amount of work. One consequence is that there are a lot of user-defined types with bad hash functions floating around.

One possibility is automatically generating hash&lt;&gt; specializations, but that's tricky. A simpler possibility is providing tools that make it easier for users to do the right thing.
</p>





<hr>
<h3><a name="35"></a>35. 
[tiny] Some concise way to generate a unique, unused variable name
</h3>
<p><b>Section:</b> 3.4 [basic.lookup] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-10-24 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Sometimes we want to define a variable that's unused except for its
constructor and destructor. lock_guard&lt;mutex&gt; and ScopeGuard are
decent examples of this. In C++11, we have to manually name the
variable something unique. Sometimes we use _some_name_##__LINE__
(suitably wrapped so the concatenation happens after expanding
__LINE__) to try to generate unique names automatically, and gcc/clang
have an extension _some_name_##__COUNTER__
<p>
<a href="http://gcc.gnu.org/onlinedocs/gcc-4.7.2/cpp/Common-Predefined-Macros.html">http://gcc.gnu.org/onlinedocs/gcc-4.7.2/cpp/Common-Predefined-Macros.html</a>
</p>
to allow multiple such variables on the same line. These are pretty
verbose and not convenient for casual use.

Haskell allows _ (underscore) to stand in for a variable that's not
going to be used. Googlemock defines testing::_ to mean "don't care"
as an argument, which is similar but not identical.
</p>





<hr>
<h3><a name="36"></a>36. 
[tiny] no way to say "prefer this implicit conversion over that"
</h3>
<p><b>Section:</b> 12.3 [class.conv] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2012-10-24 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
If a type has two implicit conversions, and I call a function with overloads for both target types, there's no way to disambiguate short of writing the conversion explicitly or adding another overload. It would be nice to be able to extend the partial order on conversions.
</p>





<hr>
<h3><a name="37"></a>37. 
[tiny] Logical xor operator
</h3>
<p><b>Section:</b> 5 [expr] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2012-10-28 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I have a low-priority issue for adding the (neglected) logical-xor operator, ^^.
This has traditionally been dismissed as un-necessary, as it is equivalent to boolean operator!=, and there is no short-circuiting benefit to justify adding it.

However, contextual conversions to 'bool' are handled specially for logical operators, and in that context it would be completing a hole in the language.

I wish I had a better example, but pulling from the standard library:
<pre>
   function&lt;void()&gt; a;
   function&lt;void()&gt; b;
   assert(a != b);  // does not compile
   assert(a ^^ b);  // would compile, and assert!
</pre>
</p>





<hr>
<h3><a name="38"></a>38. 
[tiny] Core issue 1542
</h3>
<p><b>Section:</b> 5.17 [expr.ass] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Mike Miller <b>Opened:</b> 2012-11-02 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In Portland, CWG categorized a number of issues as "extension," which
I presume you
will automatically look at for potential EWG involvement once the new
revision of the
issues list is out.  I did want to mention one issue for which we will
be resolving part
and referring the other part to EWG: issue 1542 raises the question of
whether the
narrowing rules make sense for a compound assignment, e.g.,
<pre>
    char c;
    c += {1};
</pre>
CWG addressed a similar issue (1078) for an ordinary assignment and
decided that,
although the narrowing error was annoying in that case, it wasn't
worth the effort to
change the language because the workaround was simply to add a cast.  In this
case, however, there's no way to avoid the error (no place to put the
cast).  I think we'd
be happy with a revision of the narrowing rules that addressed both
this case and the
one in 1078; maybe the answer is just "why would you use the { } form
in a case like
this anyway?"
</p>

The Core issue link <a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1542">here</a>.






<hr>
<h3><a name="40"></a>40. 
[tiny] Relax the allocator requirements on vector so that the small object optimization is allowed
</h3>
<p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2012-11-27 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'd like it to be possible to use the small object optimization (embedding up to a fixed number of objects inside the allocator itself) inside a vector.
</p>





<hr>
<h3><a name="41"></a>41. 
[tiny] In-class explicit specializations forbidden but not partial specializations
</h3>
<p><b>Section:</b> 14.7.3 [temp.expl.spec] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Faisal Vali <b>Opened:</b> 2012-10-27 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.expl.spec">active issues</a> in [temp.expl.spec].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.expl.spec">issues</a> in [temp.expl.spec].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I had submitted a DR (727) about this in October 2008 - and it was
classified as an extension - I wonder if Spertus' DR (1077) that was
also classified as an extension should be considered along with this
one.


14.7.3 [temp.expl.spec] paragraph 2 requires that explicit
specializations of member templates be declared in namespace scope,
not in the class definition. This restriction does not apply to
partial specializations of member templates; that is,
<pre>
    struct A {
      template&lt;class T&gt; struct B;
      template &lt;class T&gt; struct B&lt;T*&gt; { }; // well-formed
      template &lt;&gt; struct B&lt;int*&gt; { }; // ill-formed
    };
</pre>
There does not seem to be a good reason for this inconsistency.
</p>





<hr>
<h3><a name="42"></a>42. 
[tiny] basic_string(const charT*, size_type, const Allocator&) requires clause too restrictive
</h3>
<p><b>Section:</b> 21.4.2 [string.cons] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2012-12-19 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In n3485 21.4.2p6 (basic_string constructors and assignment operators), we have:

<pre>
  basic_string(const charT* s, size_type n,
  const Allocator& a = Allocator());
  Requires: s shall not be a null pointer and n &lt; npos.
</pre>


That requires clause is too restrictive; s can be a null pointer when n==0.

A (simplified) use case I have seen:

<pre>
  std::string StringFromVector(std::vector&lt;char&gt; const& vc)
  { return std::string(vc.data(), vc.size()); }
</pre>

Since a conforming implementation can return a null pointer for vc.data() when vc.size() == 0.  I don't see any reason to disallow this construct, especially since it takes a Standards expert to see that this is possibly illegal, but not std::string(vc.data(), vc.data() + vc.size()).
</p>

This is likely to go onto the LEWG's plate.


<p><b>Wording available:</b></p>
<pre>
  Requires: n &lt; npos and either s shall not be a null pointer or n == 0.
</pre>




<hr>
<h3><a name="43"></a>43. 
[tiny] simultaneous iteration with new-style for syntax
</h3>
<p><b>Section:</b> 6.5.4 [stmt.ranged] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2013-01-12 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The new-style 'for' syntax allows us to dispense with administrative
iterator declarations when iterating over a single seuqence.

The burden and noise remain, however, when iterating over two or more
sequences simultaenously.  We should extend the syntax to allow that.
E.g. one should be able to write:
<pre>
    for (auto& x : v; auto& y : w)
       a = combine(v, w, a);
</pre>

instead of the noisier
<pre>
    auto p1 = v.begin();
    auto q1 = v.end();
    auto p2 = w.begin();
    auto q2 = w.end();
    while (p1 &lt; q1 and p2 &lt; q2) {
       a = combine(*p1, *p2, a);
       ++p1;
       ++p2;
    }
</pre>
</p>




<hr>
<h3><a name="44"></a>44. 
[tiny] variadic bind
</h3>
<p><b>Section:</b> 20.8.9 [bind] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2013-01-25 <b>Last modified:</b> 2013-03-09</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As more variadic functions work their way into my C++ code, I'm getting increasingly annoyed that there isn't a variadic bind.

There is a tiny bit of annoyance on exactly what to use. There seems to me to be 2 sensible choices (other people may have others)

<pre>
  1) _args : Use all otherwise unnamed arguments.
  2) _3onwards : All arguments from the 3rd onwards.
</pre>

I haven't personally found a need for multiple ranges of variadic arguments, or more complicated chopping (such as getting the last few arguments), and I'd want to hopefully keep this simple if possible!
</p>




<hr>
<h3><a name="45"></a>45. 
[tiny] Type Trait is_range<T>
</h3>
<p><b>Section:</b> 20.9.4.3 [meta.unary.prop] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2013-02-05 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="ewg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'd like to have an is_range&lt;T, R = void&gt; type trait, which derives from true_type if and only if T can be used in range-based for, and *__begin is convertible to R (where R == void means don't bother checking this condition).
</p>




<hr>
<h3><a name="46"></a>46. 
[tiny] Type Trait is_final<T>
</h3>
<p><b>Section:</b> 20.9.4.3 [meta.unary.prop] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2013-02-05 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="ewg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'd like to have an is_final&lt;T&gt; type trait, which is true if and only if T is a final type.
</p>




<hr>
<h3><a name="47"></a>47. 
[tiny] Fix the relation operators on standard templated types
</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2013-02-05 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="ewg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In C++11, all the containers, pair, tuple, etc. always have the relation operators defined for them (==, !=, &lt;, &gt;, &lt;=, &gt;=), even if the contained type does not have them; they just fail to compile if one tries to invoke them.  It would be better if those operators were SFINAEed out, so that generic code can then detect it and apply alternate strategies.
<p>
A use case I've have for this is when holding stateless objects that don't normally have the relation operators defined for them.
</p>
</p>




<hr>
<h3><a name="48"></a>48. 
[tiny] Specializing templates in different namespaces
</h3>
<p><b>Section:</b> 14.7.3 [temp.expl.spec] <b>Status:</b> <a href="ewg-active.html#New">New</a>
 <b>Submitter:</b> Mike Spertus <b>Opened:</b> 2013-03-06 <b>Last modified:</b> 2013-03-09</p>
<p><b>View other</b> <a href="ewg-index-open.html#temp.expl.spec">active issues</a> in [temp.expl.spec].</p>
<p><b>View all other</b> <a href="ewg-index.html#temp.expl.spec">issues</a> in [temp.expl.spec].</p>
<p><b>View all issues with</b> <a href="ewg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This is a proposal to allow specializing templates from within a different namespace. The motivation is that when we declare a new class, it is natural to want to provide associated template specializations. For example, it is really painful that whenever I declare a class, I need to leave my namespace and enter namespace std just to specialize std::less as shown below

<pre>
  namespace A {
    namespace B {
      class C {...};
    }
  }

  namespace std {
    template &lt;&gt;
    struct less&lt;C&gt; : binary_function &lt;C, C, bool&gt; {
       bool operator() (const C & x, const C & y) const {...}
   };
  }

  namespace A {
    namespace B {
      ... // Continue working in A::B
    }
  }
</pre>
 

Instead, I should be able to specialize std::less without having to break out of my namespace:

<pre> 
  namespace A {
    namespace B {
      class C {...};
      template &lt;&gt;
      struct ::std::less&lt;C&gt; : binary_function &lt;C, C, bool&gt; {
        bool operator() (const C & x, const C & y) const {...}
      };
    ... // Continue working in A::B
    }
  }
</pre>
</p>




</body>
</html>
