<HTML>
<HEAD>
<TITLE>



    Evolution Working Group
    
      Active Proposals
     </TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD><TD>
      &nbsp;



      J16/04-0090 = WG21 N1650</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD><TD>
      &nbsp;15 April, 2004</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Project:
     </TD><TD>
      &nbsp;Programming Language C++
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reference:
     </TD><TD>
      &nbsp;ISO/IEC IS 14882:2003(E)
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reply to:
     </TD><TD>
      &nbsp;Daveed Vandevoorde (<TT>daveed@edg.com</TT>)
     </TD>
</TR>
<TR>
<TD></TD><TD>
      &nbsp;Bjarne Stroustrup (<TT>bs@cs.tamu.edu</TT>)
     </TD>
</TR>
<TR>
<TD></TD><TD>
      &nbsp;Herb Sutter (<TT>hsutter@microsoft.com</TT>)
     </TD>
</TR>
</TABLE>
<BR CLEAR="ALL">
<BR>
<CENTER>
<H2>



     C++ Evolution Working Group --
     
       Active Proposals,
      



     Revision
     1</H2>
<H3>Committee Version</H3>
</CENTER>
<BR>
<P>
      This document contains the proposals for extensions actively considered
      by the Evolution Working Group (but on which the Committee (J16 + WG21)
      has not yet acted), that is, proposals with status
      "<A HREF="#Ready Status">Ready</A>,"
      "<A HREF="#Review Status">Review</A>,"
      "<A HREF="#Drafting Status">Drafting</A>," and
      "<A HREF="#Open Status">Open</A>."
     </P>
<P>
    This document is part of a group of related documents that
    together describe the proposals that have been considered by
    the Evolution Working Group.  The other documents in the group are:
   </P>
<UL>
<LI>
<A HREF="ewg_na.html">No-Action List</A>, which contains
      the proposals which the Committee has decided should not be
      included
      in the International Standard, including a brief rationale
      explaining the reason for the decision.
     </LI>
<LI>
<A HREF="ewg_wp.html">Accepted Extensions List</A>, which contains
      the proposals that have been accepted by the Committee for inclusion
      in the next standard.
     </LI>
<LI>
<A HREF="ewg_toc.html">Table of Contents</A>, which contains a
     summary listing of all proposals in numerical order.
    </LI>
<LI>
<A HREF="ewg_index.html">Index by Section</A>, which contains a
     summary listing of all proposals arranged in the order of the
     sections of the Standard with which they deal most directly.
    </LI>
<LI>
<A HREF="ewg_status.html">Index by Status</A>, which contains a
     summary listing of all proposals grouped by status.
    </LI>
</UL>
<P>The purpose of these documents is to record the disposition of proposals
which have come before the Evolution Working Group (EWG) of the ANSI
(J16) and ISO (WG21) C++ Standard Committee.</P>

<P>Proposals represent potential changes and extensions to the
ISO/IEC IS 14882:2003 document.
While some proposals will eventually result in changes to the Committee's
working paper (WP), others
will be disposed of in other ways.  (See <A HREF="#Issue Status">Issue
Status</A> below.)</P>


<P>This set of documents exists in two slightly different versions.  The
Committee Version (this version) is the master version and should be
made available only to committee members.  The Public Version is
extracted from the Committee Version by removal of sensitive and/or
unnecessary information, such as drafting assignments, reflector
message numbers, and the like.</P>

<P>Committee members with the HTML version of the IS may wish to place
the issues list documents in the same directory; references to the IS
in the issues can then be explored by hyperlink.</P>


<P>The most current public version of this document can be found at
<A HREF="http://www.dkuug.dk/jtc1/sc22/wg21">http://www.dkuug.dk/jtc1/sc22/wg21</A>. 
Requests for further information about these documents should include
the document number, reference ISO/IEC 14882:2003, and be
submitted to the International Committee for Information Technology Standards
(INCITS),
1250&nbsp;Eye&nbsp;Street&nbsp;NW, Suite 200, Washington,&nbsp;DC&nbsp;20005,
USA.</P>

<P>Information regarding how to obtain a copy of the C++ Standard,
join the Standard Committee, or submit an issue
can be found in the C++ FAQ at
<A HREF="http://www.jamesd.demon.co.uk/csc/faq.html">http://www.jamesd.demon.co.uk/csc/faq.html</A>.
Public discussion of the C++ Standard and related issues occurs on
newsgroup <A HREF="news:comp.std.c++">comp.std.c++</A>.</P>

<BR>
<H3>Revision History</H3>

<UL>
<LI>
<B>Revision 1: 2004-03-30:</B> Original version created from N1598/04-0038 and notes from the 2004 Sydney meeting.

</LI>

</UL>

<A NAME="Issue Status"></A>
<H3>Issue status</H3>

<P>Issues progress through various statuses as the Evolution
Working Group and, ultimately, the full J16 and WG21 committees
deliberate and act.  For ease of reference, issues are grouped in these
documents by their status.  Issues have one of the following statuses:</P>

<P>
<B>Issues and Suggestions:</B>
<I>Issues</I> (formerly numbered EIddd) represent attempts to identify a set
of related problems that might be addressed by a language extension; some
issues have come directly from users without serious suggestions for how
to solve them.  <I>Suggestions</I> (formerly numbered ESddd) are simply noted
suggestions made directly or indirectly to the working group; the working
group does not make value judgments about a suggestion beyond either
having heard a suggestion repeatedly or received/seen a reasonably
detailed description of what's desired. Some ideas and suggestions will
contain references to original written versions.</P>
<BLOCKQUOTE>
When a paper is written, the issue or suggestion moves to <B>Open</B> status.
</BLOCKQUOTE>

<P>
<B>Open:</B>
The proposal, now numbered, is new or the working group has not yet formed
an opinion on the proposal. The proposal reflects the opinion of the
proposal's submitter, not necessarily that of the working group or the
Committee as a whole.</P>
<BLOCKQUOTE>
When the working group reaches informal consensus that is described in
rough terms in a <I>Tentative Design</I>, the proposal moves to 
<B>Drafting</B> status.
</BLOCKQUOTE>

<P>
<B>Drafting:</B>
Informal consensus has been reached in the working group and is
described in rough terms in a <I>Tentative Design</I>, although
precise wording for the change is not yet available.</P>
<BLOCKQUOTE>
When <I>Proposed Wording</I> becomes available, usually in an 
updated revision of the paper, the proposal moves to <B>Review</B> status.
</BLOCKQUOTE>

<P>
<B>Review:</B>
Exact <I>Proposed Wording</I> is now available for a proposal on 
which the working group previously reached informal consensus. 
The proposal continues to be owned by the Evolution working group,
but specific input from the Core and/or Library working groups is
solicited to verify and improve the accuracy of the proposed wording
with respect to Core and Library clauses to ensure that the wording
correctly implements the intended design.</P>
<BLOCKQUOTE>
When the working group approves the <I>Proposed Wording</I>, and the
Core and Library working groups confirm, then the proposal moves to
<B>Ready</B> status. 
</BLOCKQUOTE>


<P>
<B>Ready:</B>
The working group has reached consensus on the proposal, the
<I>Proposed Wording</I> is correct and confirmed by the Core or
Library working groups.</P>
<BLOCKQUOTE>
When the <I>Proposed Wording</I> remains unchanged at the meeting
following the meeting at which it was last changed (other than possible
editorial changes or simple tracking of changes in the Working Paper),
the proposal is forwarded to the full Committee for voting for inclusion
in the current Working Paper. If approved by the full Committee, the
proposal moves to <B>WP</B> status.
</BLOCKQUOTE>

<P>
<B>WP:</B>
A proposal that the Committee has voted to apply to the current
Working Paper. The Working Paper is a draft for a future version
of the Standard.</P>

<P>
<B>Dup:</B>
The issue is identical to or a subset of another issue, identified in
a <I>Rationale</I> statement.</P>

<P>
<B>NA (Closed With No Action):</B>
The working group has reached consensus that the issue is a problem
or specific solution that it does not want to pursue further.
A <I>Rationale</I> statement describes the working group's reasoning.</P>


<H3>Policies</H3>
<P>
The EWG (Evolution Working Group) tries to classify suggestions, issues,
and proposals according to which larger language concerns they address
and to favor proposals that address 
<UL>
	<LI>Improve the support of generic programming</LI>
	<LI>Improve the support for library building and use</LI>
	<LI>Make the language more regular, predictable, and teachable (also known as &#1197;ake simple things simple to express&#1257;</LI>
	<LI>Support the building of libraries that will make C++ a better platform for systems programming</LI>
</UL>
</P>
<P>
We expect that these directions will eventually become reasonably well specified and be explicitly approved by the committee. Currently, they are simply synthesized from committee and working group discussions.
</P>
<P>
Typically, a proposal will not go to full committee before CWG or LWG has discussed it either on a reflector or at a meeting.
</P>
<P>
We would like to minimize the size and number of core language extensions. Conseqently, for each proposal, we will consider if a standard library facility would be sufficient to solve the problem or if a combination of a small core language change plus a standard library extension would do the job.
</P>
<P>
Compatibility with C++03 and the zero-overhead principle are considered very important.
</P>

<H3>Straw Polls</H3>
<P>
During its face-to-face meetings, the EWG commonly polls its attendance for
opinions on various matters.  Such polls usually count four mutually 
exclusive options: "strong yes" (SY), "weak yes" (WY), "weak no" (WN),
and "strong no" (SN).  Attendants can also opt to abstain (abstentions
are not counted).  Two-way (yes/no) and three-way (yes/no/abstain) polls
are also sometimes conducted.
</P>


<SCRIPT type="text/javascript">
  var seqno = 1;
 </SCRIPT>
<HR>
<A NAME="Ready Status"></A>
<H3>Issues with "Ready" Status</H3>
<BR>
<BR>
<HR>
<A NAME="Review Status"></A>
<H3>Issues with "Review" Status</H3>
<HR>
<A NAME="9"></A>
<H4>9.
  
Static assertions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7&nbsp;



 <A HREF="dcl.html#dcl.dcl">dcl.dcl</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Robert Klarer, John Maddock
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Robert Klarer<BR>



<P>(Previously numbered EP009.)</P>
<P>References: N1381, N1604, N1617.</P>


Provide a way to make an assertion checked at translation time; the general
form is <tt>static_assert(expr1, expr2)</tt>.
This is particularly useful in templates (where #error doesn't cut it)
to issue compilation errors at instantiation time.
<br>
<br>


Daveed: Does this allow <tt>extern "C" static_assert(...);</tt>?
It probably shouldn't.
<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Should the first expression be constrained to be a constant-expression
convertible to type bool?
</TD>
</TR>
<TR>
<TD>SY: all</TD><TD>WY: 0</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should the second expression be restricted to (possibly wide) string literals?
</TD>
</TR>
<TR>
<TD>SY: 20</TD><TD>WY: 4</TD><TD>WN: 1</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should the string literal (the second argument) be required to appear in
the diagnostic?
</TD>
</TR>
<TR>
<TD>SY: 17</TD><TD>WY: 8</TD><TD>WN: 4</TD><TD>SN: 1</TD>
</TR>
<TR>
<TD COLSPAN="5">
Approve of the proposal as ammended?
</TD>
</TR>
<TR>
<TD>SY: 30</TD><TD>WY: 1</TD><TD>WN: 0</TD><TD>SN: 2</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>



<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Drafting Status"></A>
<H3>Issues with "Drafting" Status</H3>
<HR>
<A NAME="24"></A>
<H4>24.
  
Adding the <tt>long long</tt> type to C++
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>



<P>(Previously numbered ES016.)</P>
<P>References: N1565 (Steve Adamczyk).</P>

<P>
<tt>long long</tt> is ugly syntax for a 64-bit type, but given C99 and
existing practice wrt. C++ compilers, we should just imitate this.
</P>
<P>
There are library parts to the <tt>long long</tt> extension, but the affected
areas in the standard are "included by reference."  Plauger's omnibus C99
paper deals with the logistics of that.
</P>
<P>
Controversial typing of "boundary cases."  Some constants that are today
of <tt>unsigned long</tt> type would more sensibly have type <tt>long long</tt>
if that type is available.
Should C++ follow C99's lead of breaking C89 (and hence C++98) compatibility?
</P>
<P>
EDG supports both options but C99 experience is small (though it hasn't
generated complaints so far).
</P>

<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Should the proposal of N1565 be followed in its entirety?
</TD>
</TR>
<TR>
<TD>SY: 19</TD><TD>WY: 0</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>


<BR>
<BR>
<HR>
<A NAME="70"></A>
<H4>70.
  
Extended friend declarations
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.1.4&nbsp;



 <A HREF="dcl.html#dcl.friend">dcl.friend</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Mike Miller<BR>



<P>(Previously numbered ES078.)</P>
<P>References: N1520 (Mike Miller).</P>


Allow
<tt>
<pre>
        friend T;
</pre>
</tt>
where <tt>T</tt> is a template argument or typedef name.


Among three options in N1520 EWG selected "option 2" in Kona 2003,
but CWG review concluded <i>anything but</i> "option 2".
<br>
Clark N. prefers option 1 because he suspects the wording of option3 is not quite complete.

<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Option 1 (no restrictions)
</TD>
</TR>
<TR>
<TD>SY: 10</TD><TD>WY: 4</TD><TD>WN: 5</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Option 2 (only dependent type names)
</TD>
</TR>
<TR>
<TD>SY: 0</TD><TD>WY: 8</TD><TD>WN: 9</TD><TD>SN: 3</TD>
</TR>
<TR>
<TD COLSPAN="5">
Option 3 (no keywords)
</TD>
</TR>
<TR>
<TD>SY: 10</TD><TD>WY: 6</TD><TD>WN: 3</TD><TD>SN: 2</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>

<br>
Run-off of option 1 vs. option 3:
<br>
Favor option 1: 16
<br>
Favor option 3: 6

<br>
Direction for Mike M.: Pursue option 1.

<br>
John S. notes that this allows "<tt>friend;</tt>".  (Mike will rework the
wording to address this.)


<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Open Status"></A>
<H3>Issues with "Open" Status</H3>
<HR>
<A NAME="12"></A>
<H4>12.
  
User-defined literals
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>2&nbsp;



 <A HREF="lex.html#lex">lex</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Bjarne Stroustrup
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>B. Stroustrup<BR>



<P>(Previously numbered EP012, ES053.)</P>
<P>References: N1511.</P>


<BR>
<BR>
<HR>
<A NAME="5"></A>
<H4>5.
  
Dynamic Libraries
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3&nbsp;



 <A HREF="basic.html#basic">basic</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>various
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>P. Becker<BR>



<P>(Previously numbered EP005 and ES015.)</P>
<P>References: N1400 (Matt Austern), N1418 (Pete Becker).</P>


The standard currently does not have a concept of dynamic libraries,
but many (most) large C++ programs deal with them in some way.

Pete Becker is coordinating work to identify language specifications
that would make it easier to work portably in dynamic library environments.
<BR>
<BR>
<HR>
<A NAME="8"></A>
<H4>8.
  
Null pointer constant
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5&nbsp;



 <A HREF="expr.html#expr">expr</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Herb Sutter, Bjarne Stroustrup
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>H. Sutter, B. Stroustrup<BR>



<P>(Previously numbered EP008, ES047.)</P>
<P>References: N1488, N1601.</P>


Introduce the keyword <TT>nullptr</TT> to denote a value that can be assigned
to any pointer, but not to non-pointers.

<br>
<br>
In N1601: <br>
2nd- and 3rd-to-last bullets on p. 2 to be dropped<br>.
3rd-to-last bullet on p. 3 to be dropped<br>.
<br>
Daveed's example:
<blockquote>
<tt>
<pre>  template&lt;typename T&gt; class X {};  // (1)
  template&lt;typename T&gt; class X&lt;T*&gt; {};  // (2)
  template&lt;typename T&gt; class X&lt;int T::*&gt; {};  // (3)

  template&lt;typename T&gt; void f(T) {
    X&lt;T&gt;  x;  // Which template is instantiated
  }
</pre>
</tt>
</blockquote>
If nullptr has a non-pointer, non-pointer-to-member type, then (1) is
selected.  If it has both pointer and pointer-to-member type, then it
is ambiguous.
<br>
<br>
Lawrence Crowl: Prefers library solution.
<br>
<br>
Tom Plum: Arguments in favor of a core-language solution (among others,
          you're not limited to existing language semantics).
<br>
<br>
Tom Plum: How about nullptr being a pointer type convertible to a
          pointer-to-member.  In the example, this would cause (2)
          to be selected.
<br>
<br>
John S.: Why does it need a type?
<br>
<br>
Dave A./ Daveed: Useful to be able to overload on it.
<br>
<br>
Clark N.: We should drop nullptr altogether.
<br>
<br>
Mike Miller: It should be a T* (select the (2) partial specialization).
<br>
<br>
Daveed: Cannot think of an advantage to select either one and points out
        that we probably don't want to say what the T is in T* if (2) is
        selected.
<br>
<br>
John S.: Example
<blockquote>
<tt>
<pre>  template&lt;class T&gt; void f(T, T);
  f("hello", nullptr);  // If nullptr is deducible, this is ambiguous
</pre>
</tt>
</blockquote>
Core issue parallel: Overloaded function address is nondeducible (pending new core resolution).
<br>
<br>
Straw vote:

Has no real type:
	SY: 11	WY: 5	WN: 3	SN: 2
In favor of slimmed down proposal with a (nondeducible) unique/magical type.
	SY: 15	WY: 4	WN: 1	SN: 0

Should pursue nullptr at all?
	SY: 11	WY: 7	WN: 2	SN: 2


<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
nullptr should not have a real type?
</TD>
</TR>
<TR>
<TD>SY: 11</TD><TD>WY:5</TD><TD>WN: 3</TD><TD>SN: 2</TD>
</TR>
<TR>
<TD COLSPAN="5">
In favor of slimmed down proposal with a (nondeducible) unique/magical type?
</TD>
</TR>
<TR>
<TD>SY: 15</TD><TD>WY:4</TD><TD>WN: 1</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should we pursue nullptr at all?
</TD>
</TR>
<TR>
<TD>SY: 11</TD><TD>WY:7</TD><TD>WN: 2</TD><TD>SN: 2</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>

<BR>
<BR>
<HR>
<A NAME="82"></A>
<H4>82.
  
Uniform function call syntax (part II)
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5&nbsp;



 <A HREF="expr.html#expr">expr</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Francis Glassborow
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>References: N1585 (Francis Glassborow).</P>
<P>See also <A HREF="
     ewg_active.html#57">57</A>
</P>


Allow a namespace scope function declaration to be treated as a member
function.  For example:
<blockquote>
<tt>
<pre>struct X {};
void f(int, X&amp; *this);
void g(X *p) {
  p-&gt;f(3);  //  Calls f(3, p) with member-call conversion rules
</pre>
</tt>
</blockquote>


<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Is this a good idea?
</TD>
</TR>
<TR>
<TD>SY: 1</TD><TD>WY: 5</TD><TD>WN: 3</TD><TD>SN: 5</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>


<BR>
<BR>
<HR>
<A NAME="71"></A>
<H4>71.
  
Constant inline functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gabriel Dos Reis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>(Previously numbered ES079.)</P>
<P>References: N1521.</P>


Allow certain inline function calls in constant-expressions.
<BR>
<BR>
<HR>
<A NAME="85"></A>
<H4>85.
  
<tt>for each</tt>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>6&nbsp;



 <A HREF="stmt.html#stmt.stmt">stmt.stmt</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Tom Plum
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>March 2004
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>(Part of Ecma TC39-TG5 liaison work.)</P>
<P>References: c++std-ext-6729 (Thorsten Ottosen).</P>


A short-hand construct to iterate over a collection.  Examples:
<blockquote>
<tt>
<pre>vector&lt;int&gt; V;
for each(int &amp;x: V) ...
for (int &amp;x; V) ...
</pre>
</tt>
</blockquote>


<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Is collection iteration of potential interest to this group?
</TD>
</TR>
<TR>
<TD>SY: 7</TD><TD>WY: 6</TD><TD>WN: 1</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Does EWG think using a single semicolon would be OK?
</TD>
</TR>
<TR>
<TD>SY: 1</TD><TD>WY: 0</TD><TD>WN: 1</TD><TD>SN: 12</TD>
</TR>
<TR>
<TD COLSPAN="5">
Is "for (decl:expr)" the likely syntax?
</TD>
</TR>
<TR>
<TD>SY: 4</TD><TD>WY: 8</TD><TD>WN: 1</TD><TD>SN: 0</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>



<BR>
<BR>
<HR>
<A NAME="1"></A>
<H4>1.
  
<TT>decltype</TT> and <TT>auto</TT>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7&nbsp;



 <A HREF="dcl.html#dcl.dcl">dcl.dcl</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Bjarne Stroustrup
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>J. Jarvi, B. Stroustrup<BR>



<P>(Previously numbered EP001.)</P>
<P>References: c++std-ext-5364, N1478, N1527, N1607.</P>


This is a proposal to enable the deduction of types in various places that
currently require decl-specifiers.  The following extensions are/were
considered:
<UL>
<LI>
<TT>decltype(<I>expr</I>)</TT>: a type specifier denoting the (possibly modified) type of the expression.</LI>
<LI>
<TT>auto x = <I>expr</I>;</TT>: the deduction of a variable type from its initializer.</LI>
<LI>
<TT>int f(auto);</TT>: implicit templates (equivalent to <TT>template&lt;typename T&gt; int f(T);</TT>).</LI>
<LI>
<TT>auto f() { ... }</TT>: return types deduced from return statements.</LI>
<LI>A new function declaration syntax that places the return type after the parameter types.  E.g., <TT>auto f(T a, U b) -&gt; decltype(a+b);</TT>.</LI>
</UL>


<B>Sydney 2004 discussion:</B>
<BR>
<P>
General agreement that multiple declarators (as in
<TT>auto x = <I>expr</I>, *y = <I>expr2</I>;</TT>)
should not be allowed in a single auto-deduced declaration.
</P>
<P>
Several attendants voiced that something like
<TT>pair&lt;auto, auto&gt; x = <I>expr</I>;</TT>
"may not be worth the trouble."
</P>
<P>
Several pointed out that auto return type require that
function templates be fully instantiated and that that
is impractical.  Daveed V. asked why the feature was
retained in the proposal when the Kona straw polls indicated
even less support for auto return types than for implicit
templates.
</P>
<P>
John S. asked if the return type is a nondeduced context
with the new declaration syntax.  Jaakko confirmed that
that is correct.
</P>
<br>
<br>
The current proposal makes <tt>auto int x;</tt> invalid.
<br>
<br>
Daveed notes that a search for "auto double" on Google finds lots of code.
<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
In favor of <TT>decltype</TT> along the lines presented:
</TD>
</TR>
<TR>
<TD>SY: 8</TD><TD>WY: 13</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
In favor of <TT>auto</TT> for basic type specifiers in variable declarations:
</TD>
</TR>
<TR>
<TD>SY: 10</TD><TD>WY: 10</TD><TD>WN: 1</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
In favor of <TT>auto</TT> for any type component specifiers in variable declarations:
</TD>
</TR>
<TR>
<TD>SY: 4</TD><TD>WY: 4</TD><TD>WN: 12</TD><TD>SN: 1</TD>
</TR>
<TR>
<TD COLSPAN="5">
In favor of <TT>auto</TT> return types:
</TD>
</TR>
<TR>
<TD>SY: 1</TD><TD>WY: 2</TD><TD>WN: 4</TD><TD>SN: 11</TD>
</TR>
<TR>
<TD COLSPAN="5">
In favor of new function declaration syntax along the lines presented:
</TD>
</TR>
<TR>
<TD>SY: 4</TD><TD>WY: 7</TD><TD>WN: 5</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should the authors of the paper work to preserve the existing meaning of "auto"?
</TD>
</TR>
<TR>
<TD>SY: 18</TD><TD>WY: 3</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Use a different keyword from <tt>auto</tt>?
</TD>
</TR>
<TR>
<TD>SY: 5</TD><TD>WY: 8</TD><TD>WN: 7</TD><TD>SN: 2</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>

<br>
<br>
The wording for <tt>decltype</tt> part of the proposal can be reviewed
by EWG and forwarded to CWG.


<BR>
<BR>
<HR>
<A NAME="36"></A>
<H4>36.
  
Extend enum types
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES029, ES030, ES034, ES050, ES051, and ES074.)</P>
<P>References: N1579 (Herb Sutter).</P>


Revise some limitations or undesirable properties of enum types.
<BR>
N1579 addresses three basic issues:
<UL>
  <LI>implicit conversion to integer</LI>
  <LI>scoping of enum constants</LI>
  <LI>underlying type</LI>
</UL>
The syntax is the same as that chosen for Microsoft's C++/CLI extensions.
<BR>
Discussion: 
<BR>
Floating-point enum constants are a bad idea because:
<UL>
  <LI>complex to specify</LI>
  <LI>not actually a problem</LI>
  <LI>doesn't directly address the claimed issue</LI>
</UL>


<br>
Walter Brown: Would have expected more features given that <tt>enum class</tt>
suggests it's a sort of class (e.g., default constructors).

<br>
Daveed is strongly opposed to the syntax.

<br>
Clark Nelson: "<tt>enum namespace</tt>" better says it.

<br>
Francis G. also wants to be able to overload the assignment operator.
Thinks specifying an underlying type may affect portablity.

<br>
Existing enums can also be extended in the following ways:
<UL>
  <LI>Allow "explicit" to inhibit conversions</LI>
  <LI>Allow "<tt>: &lt;type&gt;</tt>" to specify the underlying type</LI>
  <LI>Allow <tt>E::x</tt> in addition to <tt>x</tt> for enum constants</LI>
</UL>

<br>
Allow forward enum declarations?  Separable.

<br>
Mat Marcus: Is there a more general language mechanism (e.g. strong typedefs) within this?

<br>
Atilla F.:
Desire to iterate over every enum constant.
Compile-time checking of switches having _all_ the enumerator variants
(and perhaps beyond switch).

<br>
Antonio B.:
Strongly dislikes the syntax.

<br>
Francis G.:
Can the underlying type be a typedef?
Enumerating over enum constants must deal with having multiple constants of the same value.


<P>
<I>Straw polls: Directions for semantics</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
scoping?
</TD>
</TR>
<TR>
<TD>SY: 13</TD><TD>WY: 6</TD><TD>WN: 2</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
explicit conversion?
</TD>
</TR>
<TR>
<TD>SY: 19</TD><TD>WY: 2</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
explicit underlying type?
</TD>
</TR>
<TR>
<TD>SY: 12</TD><TD>WY: 9</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
floating-point underlying type?
</TD>
</TR>
<TR>
<TD>SY: 0</TD><TD>WY: 0</TD><TD>WN: 8</TD><TD>SN: 13</TD>
</TR>
<TR>
<TD COLSPAN="5">
iteration over enumerators?
</TD>
</TR>
<TR>
<TD>SY: 1</TD><TD>WY: 9</TD><TD>WN: 10</TD><TD>SN: 1</TD>
</TR>
<TR>
<TD COLSPAN="5">
checkin case labels?
</TD>
</TR>
<TR>
<TD>SY: 5</TD><TD>WY: 4</TD><TD>WN: 6</TD><TD>SN: 6</TD>
</TR>
<TR>
<TD COLSPAN="5">
extending set of enumerators?
</TD>
</TR>
<TR>
<TD>SY: 5</TD><TD>WY: 9</TD><TD>WN: 5</TD><TD>SN: 1</TD>
</TR>
<TR>
<TD COLSPAN="5">
special member functions (ctors, op=)?
</TD>
</TR>
<TR>
<TD>SY: 6</TD><TD>WY: 2</TD><TD>WN: 4</TD><TD>SN: 10</TD>
</TR>
<TR>
<TD COLSPAN="5">
packed enums?
</TD>
</TR>
<TR>
<TD>SY: 0</TD><TD>WY: 5</TD><TD>WN: 10</TD><TD>SN: 6</TD>
</TR>
<TR>
<TD COLSPAN="5">
should extended enum semantics be pursued at all?
</TD>
</TR>
<TR>
<TD>SY: 12</TD><TD>WY: 8</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>

<br>
French opinion (via Lois G.): Concerned that this is an accumulation of
small extensions that do not look at the big picture.  Generally think the
properties sought after by the paper are desirable though.


<br>
Further discussion about syntax:
<br>
Should there be a "bundling" of features in a single type kind?

<br>
Daveed: We should not create a new type kind.  Use double braces for scoping,
explicit for disabling implicit conversion and "<tt>: &lt;type&gt;</tt>" for
the underlying type.

<br>
Requirement for backward compatibility is a given.

<P>
<I>Straw polls: Directions for syntax</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Syntax to enforce strong scoping?
</TD>
</TR>
<TR>
<TD>SY: 13</TD><TD>WY: 4</TD><TD>WN:3</TD><TD>SN: 1</TD>
</TR>
<TR>
<TD COLSPAN="5">
Allow ambiguous enumerator constants (no actual syntax)?
</TD>
</TR>
<TR>
<TD>SY: 8</TD><TD>WY: 3</TD><TD>WN:5</TD><TD>SN: 5</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should a single construct provide both of the above?
</TD>
</TR>
<TR>
<TD>SY: 7</TD><TD>WY: 6</TD><TD>WN:4</TD><TD>SN: 4</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should an enum type be able to pick-and-choose its features (separate independent constructs)?
</TD>
</TR>
<TR>
<TD>SY: 13</TD><TD>WY: 4</TD><TD>WN:1</TD><TD>SN: 3</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>



<BR>
<BR>
<HR>
<A NAME="69"></A>
<H4>69.
  
Nested namespace notation
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3&nbsp;



 <A HREF="dcl.html#basic.namespace">basic.namespace</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jon Jagger
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES077.)</P>
<P>References: N1524 (Jon Jagger).</P>


Allow a nested namespace be re-opened with the syntax
<tt>
<pre>
        namespace N:M { ... }
</pre>
</tt>
<BR>
<BR>
<HR>
<A NAME="81"></A>
<H4>81.
  
Allow class-scope using declarations to include private members
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3&nbsp;



 <A HREF="dcl.html#basic.namespace">basic.namespace</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Francis Glassborow
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>March 2004
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>References: N1602 (Francis Glassborow).</P>


For example:
<blockquote>
<tt>
<pre>  struct B {
    f(int i);
  private:
    f();
  };
  struct D: B {
    using B::f; // Error today.  Allowed under proposal.
  };
</pre>
</tt>
</blockquote>
The proposal is to change the place where the error regarding the
private member manifests from the point  of the using-declaration
to the place where (if any) overload resolution selects the
private member of the base class.  


Daveed: Would like something more ambitious: Make private members invisible
        where possible.

<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Is Francis' idea promising
</TD>
</TR>
<TR>
<TD>SY: 8</TD><TD>WY: 4</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should Francis and Daveed explore making accessibility affect visibility.
</TD>
</TR>
<TR>
<TD>SY: 10</TD><TD>WY: 2</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>


<BR>
<BR>
<HR>
<A NAME="7"></A>
<H4>7.
  
Move Semantics
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8&nbsp;



 <A HREF="decl.html#dcl.decl">dcl.decl</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Howard Hinnant
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>H. Hinnant, D. Abrahams<BR>



<P>(Previously numbered EP007.)</P>
<P>References: N1377.</P>


<BR>
<BR>
<HR>
<A NAME="11"></A>
<H4>11.
  
Generalized initializer lists
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Bjarne Stroustrup
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>G. dos Reis, B. Stroustrup<BR>



<P>(Previously numbered EP011 and ES026.)</P>
<P>References: N1493, N1509.</P>


A mechanism for initializing containers with initializer lists and
for using initializer lists as function arguments.

Note by Gabriel Dos Reis and Bjarne Stroustrup: N1509.
See also proposal for user-defined literals <A HREF="
     ewg_active.html#12">12</A>.
Alternative proposal by Daniel Gutson: N1493.
<BR>
<BR>
<HR>
<A NAME="80"></A>
<H4>80.
  
Regularizing initialization syntax
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Francis Glassborow
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>March 2004
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>References: N1584 (Francis Glassborow).</P>
<P>See also <A HREF="
     ewg_active.html#47">47</A>
</P>


Consider replacing all copy-initialization by direct-initialization;
i.e., give the two syntactical forms the same meaning (and to the
extent possible allow both forms everywhere one of the forms is currently
accepted).
<br>
<br>
The following example would change meaning:
<blockquote>
<tt>
<pre>  struct X {
    explicit X(int){}
    X(short){}
  };
  X x1(3); // ambiguous
  X x2=3; // uses short constructor, since long constructor is explicit
</pre>
</tt>
</blockquote>


Daveed: This is going to be tough sell.  Lots of subtleties.  We cannot move forward without substantial help from core experts.
<br>
<br>

Daveed: It's probably going to break auto_ptr.
<br>
<br>

<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Should Francis G. pursue this?
</TD>
</TR>
<TR>
<TD>SY: 10</TD><TD>WY: 2</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>



<BR>
<BR>
<HR>
<A NAME="19"></A>
<H4>19.
  
Forwarding constructors
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12&nbsp;



 <A HREF="special.html#special">special</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES008.)</P>
<P>Forwarded from LWG by Matt Austern.</P>
<P>References: N1581 (Herb Sutter).</P>
<P>See also <A HREF="
     ewg_active.html#79">79</A>
</P>


Make it possible to forward one overload of <tt>X::X</tt> to
another overload.


Discussion of Herb Sutter's paper N1581:<br>
<br>

Mike Miller: What about Martin O'Riordan's view that there are
philosophical problems with this, no matter the details of the semantics.
<br>
<br>
Daveed: It is strange that a normal converting constructor can delegate
to an explicit converting constructor.

<br>
<br>
A key issue is whether an object is considered fully constructed after
all its proper constructors have run, or after any of its proper
constructors has run.  This matter in particular because it determines
whether destructors will be invoked automatically in some cases.


<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Is this generally a good idea (poll taken twice; last one reported):
</TD>
</TR>
<TR>
<TD>SY: 16</TD><TD>WY: 7</TD><TD>WN: 0</TD><TD>SN: 1</TD>
</TR>
<TR>
<TD COLSPAN="5">
Is an object fully constructed after any constructor has run?
</TD>
</TR>
<TR>
<TD>SY: 22</TD><TD>WY: 0</TD><TD>WN: 1</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Is an object no full construct until all constructors have run?
</TD>
</TR>
<TR>
<TD>SY: 2</TD><TD>WY: 1</TD><TD>WN: 1</TD><TD>SN: 17</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>



<BR>
<BR>
<HR>
<A NAME="76"></A>
<H4>76.
  
Explicit conversion functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12&nbsp;



 <A HREF="special.html#special">special</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>(Previously numbered ES083.)</P>
<P>References: N1592 (Lois Goldthwaite).</P>


To match explicit constructors.
<blockquote>
<tt>
<pre>class Color {
public:
        explicit Color(int);
        explicit operator int();
        // ...
};

Color col = 7;          // error
Color col(7);           // ok
Color col = Color(7);   // ok
int i = col;            // error
int i(col);                     // ok (explicit enough?)
int i = int(col);               // ok
</pre>
</tt>
</blockquote>



Another example (from Lois G.):
<blockquote>
<tt>
<pre>  struct X {
    X(short);
    explicitly X(long);
  };
  X x1(42);       // Ambiguous
  X x2 = 42;      // X(short)
  X x3 = 42000L;  // X(short) !!
</pre>
</tt>
</blockquote>

Explicit conversion functions would not be considered for UDC sequences.
<br>
<br>
Dave A. thinks this fills an important void, but he wants more: A "safe cast" (one that doesn't narrow).
For example
<blockquote>
<tt>
<pre>  template&lt;class T, class U&gt; void f(U x) {
    // How to write a "safe" conversion
    g(T(x));  // There is no way to inhibit B-to-D conversions or
              // narrowing conversions.
  }           // However, Dave doesn't want to be limited to implicit
              // conversions.
</pre>
</tt>
</blockquote>
"static_cast" (a library solution) allows conversions that are too dangerous.
<br>
<br>
Clark N.: Is an expression used in a boolean control context (if (x) ...) considered explicit?
<br>
<br>
Steve A.: Boolean control is now a copy-initialization context.
          An interesting concept is that it may be useful to treat casts as
          something distinct from initialization.
<br>
<br>

<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Is this a good idea in general?
</TD>
</TR>
<TR>
<TD>SY: 19</TD><TD>WY:4</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Does this proposal deserve more analysis before pressing on?
</TD>
</TR>
<TR>
<TD>SY: 18</TD><TD>WY:0</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>

<br>
<br>
Volunteers to work on further analysis:
Walter Brown, Steve Adamczyk, Dave Abrahams.
<br>
<br>
Specific direction for analysis: General conversion issues.

<br>
<br>
[ From Dave Abrahams by e-mail:
<br>
<br>
When we discuss issues with conversions, we should also deal with
problem of reliably converting pointers.  For example, if the LWG
resolution to constrain the layout of complex&lt;T&gt; is accepted, given a
vector&lt;complex&lt;float&gt; &gt; v, people will be tempted to:
<tt>
<pre>
      reinterpret_cast&lt;float*&gt;v[0])
</pre>
</tt>
in fact, most people think they can do things like that portably today
(and others are just offended that they can't), but it yields
implementation-defined behavior.  The portable expression would be:
<tt>
<pre>
      static_cast&lt;T*&gt;static_cast&lt;float*&gt;v[0]))
</pre>
</tt>
and is so ugly that nobody but anal retentive programmers like me will
touch it.
<br>
<br>
]





<BR>
<BR>
<HR>
<A NAME="79"></A>
<H4>79.
  
Inheriting constructors
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12&nbsp;



 <A HREF="special.html#special">special</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Francis Glassborow
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>March 2004
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>References: N1583 (Francis Glassborow).</P>
<P>See also <A HREF="
     ewg_active.html#19">19</A>
</P>


Provide a construct that allows a compiler to generate derived-class
constructors based on base-class constructors (this is specifically for
nondefault, noncopy constructors).


Brendan B.: Are private constructors brought in?  What are the consequences of that?
<br>
<br>
Daveed: Lots of subtleties make this a less cost-effective issue.
<br>
<br>
Jaakko J.: There may be an alternative feature ("forwarding", "delegating") that may cover the need.
<br>
<br>
Francis G.: This may help us get something close to a strong typedef.
<br>
<br>
Walter B.: This is really an instance of "the forwarding problem."
<br>
<br>

<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Should Francis G. pursue this?
</TD>
</TR>
<TR>
<TD>SY: 2</TD><TD>WY: 2</TD><TD>WN: 4</TD><TD>SN: 2</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>



<BR>
<BR>
<HR>
<A NAME="2"></A>
<H4>2.
  
Template aliases
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gabriel dos Reis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>G. dos Reis, B. Stroustrup, M. Marcus<BR>



<P>(Previously numbered EP002.)</P>
<P>References: c++std-ext-5658 (etc.), N1406, N1449, N1451, N1489.</P>

<P>
This proposal evolved out of a suggestion for "typedef templates."
At the time of this writing, the more popular syntax appears to be along
the lines of the following example:
<PRE>
    template &lt;class T&gt; using Vec = std::vector&lt;T*&gt;;
</PRE>
This declares <TT>Vec</TT> to be an alias for the parameterized type
<TT>std::vector&lt;T*&gt;</TT>.
</P>
<P>
A key concept is that template aliases cannot be specialized, and that
they may deducible if the parameterized type they stand for is deducible.
</P>

N1489 discusses generalizations of this concept.

<BR>
<BR>
<HR>
<A NAME="10"></A>
<H4>10.
  
Concepts
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Bjarne Stroustrup, Gabriel dos Reis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>(Previously numbered EP010, ES046.)</P>
<P>References: N1510, N1522, N1536.</P>

A mechanism for better specification of template arguments, leading to
better error messages and selection of templates based on template 
argument types.

Note by Gabriel Dos Reis and Bjarne Stroustrup: Concepts - design
choices for template argument checking. N1522=03-0105. Note by
Bjarne Stroustrup: Concept checking - a more abstract complement to
type checking. N1510. Note by Bjarne Strousrup and Gabriel Dos Reis:
Concepts - syntax and composition. N1536.
<BR>
<BR>
<HR>
<A NAME="17"></A>
<H4>17.
  
Variadic template parameters
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>J. Jarvi
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>March 2004<BR>


A proposal for a new kind of template parameter that can be substituted by
an arbitrary number of template arguments.

<P>(Originally ES005.)</P>
<P>References: N1603.</P>


<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Is this a good direction?
</TD>
</TR>
<TR>
<TD>SY: 10</TD><TD>WY: 9</TD><TD>WN: 4</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should pattern-unpacking beyond the basics be pursued?
</TD>
</TR>
<TR>
<TD>SY: 5</TD><TD>WY: 6</TD><TD>WN: 1</TD><TD>SN: 8</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should built-in tupling be explored?
</TD>
</TR>
<TR>
<TD>SY: 7</TD><TD>WY: 10</TD><TD>WN: 3</TD><TD>SN: 0</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should this proposal attempt to solve the sequence constructor problem?
</TD>
</TR>
<TR>
<TD>SY: 7</TD><TD>WY: 8</TD><TD>WN: 5</TD><TD>SN: 0</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>



<BR>
<BR>
<HR>
<A NAME="73"></A>
<H4>73.
  
Partial specialization of function templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>(Previously numbered ES080.)</P>
<P>References: N1295.</P>


Overloading function templates is often not as convenient as partial
specialization.  For example, partial specialization involves fewer
lookup issues (once you found the template, all the specializations
are known).

Stephan T. Lavavej writes:<br>
"I encountered my problem while writing code to serialize and deserialize
 data structures. Overloading worked fine for the serialization functions
 since they took as parameters the objects to be serialized. But the
 deserialization functions all took exactly one argument, a deque, and were
 templated on the return type (what to extract)."
<br>

<BR>
<BR>
<HR>
<A NAME="6"></A>
<H4>6.
  
Allow local classes as template arguments
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.3.1&nbsp;



 <A HREF="template.html#temp.arg.type">temp.arg.type</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Anthony Williams
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Anthony Williams<BR>



<P>(Previously numbered EP006.)</P>
<P>References: N1427.</P>


<BR>
<BR>
<HR>
<A NAME="4"></A>
<H4>4.
  
<TT>extern template</TT>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>various
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>M. Marcus, G. dos Reis<BR>



<P>(Previously numbered EP004.)</P>
<P>References: N1448, c++std-ext-6930,6939, c++std-ext-6895..., c++std-ext-6981..., c++std-ext-6959...</P>


This is a proposal to allow the explicit instantiation syntax to be prefixed
with the keyword <TT>extern</TT> to indicate that an instantiation is
available in another translation unit.

An issue of some contention is the effect of this syntax on inline member
functions if the syntax is used on an enclosing class specialization.
<BR>
<BR>
<HR>
<A NAME="3"></A>
<H4>3.
  
#scope/#endscope
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>16&nbsp;



 <A HREF="cpp.html#cpp">cpp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Bjarne Stroustrup
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>B. Stroustrup, T. Plum<BR>


<P>(Previously numbered EP003.)</P>
<P>References: N1614.</P>

<P>
This is a proposal for a preprocessor mechanism to restrict the set of
macros used in a  region of code and similarly to limit the set of
macros "escaping" from a region of code.  The aim is to
provide both greater freedom for the use of macros (within a macro
scope) and greater freedom from undesirable macros.
</P>
<P>
Tentative syntax:
<PRE>
#define M A
#define M2 B
#scope          // Begin protected region
#define P M     // P not visible outside region.
extern int P;   // variable named "M"; not "A".  (Macro M invisible here.)
#import M2
extern int M2;  // OK: variable named B.
#define F f
#export F       // Make macro F visible outside protected region.
#endscope       // End protected region
void F();       // OK: declares function named f.
</PRE>
</P>

<B>Sydney 2004 discussion:</B>
<BR>
<P>
Can chained macro invocations accidentally pick up other macros?  E.g.:
<PRE>
  #scope
  #define helper(x) x
  #define macro(x) helper(x)
  #export macro
  #endscope
  #import macro
  #define helper(x) 2
  macro(10)  // ?
</PRE>
</P>
<P>
Dave A.:
It's not clear this supports reasonable "existing practice" preprocessor
idioms.
</P>
<P>
Clark N.: (agreement from several)
We cannot evaluate the merit of this until (a) it is implemented, and
(more importantly) (b) significant uses are demonstrated.
</P>
<P>
Tom P.:
Very much in favor of this because so many people have been looking for
a solution to this.  We shouldn't reject the concept just "because it's 
too hard."
</P>
<P>
Several note that both <TT>#export</TT> and <TT>#import</TT> are already
in used by vendor-specific extensions.
</P>
<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Should the author pursue this general direction?
</TD>
</TR>
<TR>
<TD>SY: 6</TD><TD>WY: 3</TD><TD>WN: 3</TD><TD>SN: 5</TD>
</TR>
<TR>
<TD COLSPAN="5">
If we were to go ahead with a mechanism like this, should the import/export
feature be separated from the #scope/#endscope delimiters?
</TD>
</TR>
<TR>
<TD>SY: 10</TD><TD>WY: 4</TD><TD>WN: 0</TD><TD>SN: 1</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should this specific idea be developed in coordination with WG14?
</TD>
</TR>
<TR>
<TD>SY: 10</TD><TD>WY: 2</TD><TD>WN: 2</TD><TD>SN: 3</TD>
</TR>
<TR>
<TD COLSPAN="5">
Should we work with WG14 to solve the macro problem
(irrespective of the approach)?
</TD>
</TR>
<TR>
<TD>SY: 13</TD><TD>WY: 4</TD><TD>WN: 0</TD><TD>SN: 1</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>

<BR>
<BR>
<HR>
<A NAME="78"></A>
<H4>78.
  
C99 Preprocessor
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>16&nbsp;



 <A HREF="cpp.html#cpp">cpp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Clark Nelson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>March 2004
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>References: N1566 (Clark Nelson).</P>


A proposal to translate the preprocessor changes made for C99 to C++.


<br>
<br>
<pre>
- Universal character names:
  Abandon C++ words and embrace C99 words.
  (C++: All characters not in the basic character set at translated to UCNs
   early on and translated to execution character set later on; C99 specifies
   it all in terms of escape scode.  Example difference: C99 allows a UCN for
   "$" in an identifier, but C++ does not.)

Tom Plum: Proposes us to defer the UCN issues until JTC1 has decided on responsibility for maintaining the table of identifier character set.  Tom also fears that even synchronizing with C would cause serious political problems with some strong personalities.

Clark N. will investigate what the effect of this is.


- C99 preprocessing has standard pragmas

John S.: Separate out the "#pragma STDC ..." pragmas since they're not really a preprocessing issue.
(general agreement)

- Predefined macros
Some are part of the floating-point package, which fall under the #pragma issue.

__STDC_VERSION__
Jens M.: Leave it implementation defined and presumably it would initially refer to C89 + TC1.
(general agreement)

__STDC_HOSTED__
__STDC_ISO_10646__

Straw poll:
Adopt the non-floating-point macros but making them imlementation-defined.
SY: 8	WY: 8	WN: 1	SN: 2


- &lt;stdint.h&gt; and the integer types used by the preprocessor
Defer to a paper by Steve Adamczyk to add extended integer types.

- _Pragma operator

Straw poll: Should we adopt this?
SY: 13	WY: 6	WN: 0	SN: 1


- Variadic macros
Straw poll: Should we adopt this?
SY: 20	WY: 1	WN: 0	SN: 1


- String literal concatenation
No objection for adoption.


- Header and include file names?
No objection for adoption.


- Translation limit changes?
No objection for adoption.


- Alternative tokens.  bool data type.  template instantiation.
Should be preserved or confirmed (not adopted).

(See also "Conditionally-Supported Behavior"; N1564 by Mike Miller.)
</pre>



<BR>
<BR>
<HR>
<A NAME="26"></A>
<H4>26.
  
Right angle brackets (<tt>&gt;&gt;</tt>)
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES018.)</P>
<P>References: N1649 (Daveed Vandevoorde).</P>


<P>
Ever since the introduction of angle brackets, C++ programmers have been
surprised by the fact that two consecutive right angle brackets must be
separated by whitespace:
<BLOCKQUOTE>
<tt>
<PRE>#include &lt;vector&gt;
typedef std::vector&lt;std::vector&lt;int&gt; &gt; Table;  // OK
typedef std::vector&lt;std::vector&lt;bool&gt;&gt; Flags;  // Error
</PRE>
</tt>
</BLOCKQUOTE>
The problem is an immediate consequence of the the <i>maximum munch</i> principle and the fact that <tt>&gt;&gt;</tt> is a valid token (right shift) in C++.
</P>
<P>
This issue is a minor, but persisting, annoying, and somewhat
embarrassing problem.  If the cost is reasonable, it seems therefore
worthwhile to eliminate the surprise.
</P>
<P>
N1649 proposes that <tt>&gt;&gt;</tt> would be treated as a double angle
bracket if closing angle brackets are at all expected.  This silently
changes the meaning of the following example:
<blockquote>
<tt>
<pre>#include &lt;iostream&gt;
template&lt;int I&gt; struct X {
  static int const c = 2;
};
template&lt;&gt; struct X&lt;0&gt; {
  typedef int c;
};
template&lt;typename T&gt; struct Y {
  static int const c = 3;
};
static int const c = 4;
int main() {
  std::cout &lt;&lt; (Y&lt;X&lt;1&gt; &gt;::c &gt;::c&gt;::c) &lt;&lt; '\n';
  std::cout &lt;&lt; (Y&lt;X&lt; 1&gt;&gt;::c &gt;::c&gt;::c) &lt;&lt; '\n';
}
</pre>
</tt>
</blockquote>
</P>

<BR>
<BR>
<HR>
<A NAME="57"></A>
<H4>57.
  
Uniform function call syntax
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES061.)</P>

Allow a member function to be invoked using the free-standing function syntax. For example
<tt>
<pre>
        class X {
        public:
                void f(int);
        };

        void f(int,int);

        void g(X x, X* p)
        {
                f(1,2); // call global function
                f(x,1); // call x.f(1)
                f(1,x); // error
                f(p,1); // call p-&gt;f(1)
        }
</pre>
</tt>
This would make the writing of generic (template) code simpler by saving the
template writer from having to distinguish between the two kinds of functions.

<BR>
<BR>
<HR>
<A NAME="23"></A>
<H4>23.
  
Defaulting and inhibiting common operations
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES012, ES044.)</P>
<P>See also <A HREF="
     ewg_active.html#14">14</A>
</P>
<P>References: N1582 (Francis Glassborow).</P>


This might include te systematic synthesis of certain operator in terms of
other operators (e.g., != in terms of ==; suggested by Alex Stepanov).


Daveed: Maybe (or maybe not) we need to distinguish default declarations from default definitions.
<br>
<br>
Attila: It would be nice to also allow (syntax suggested by Francis G.)
<blockquote>
<tt>
<pre>  // Dot h
  struct S {
    S();
  };

  // Dot C
  S::S() default;
</pre>
</tt>
</blockquote>
<br>
<br>
"default:" section idea: Not viable because we might want to allow explicitly generated private/publis/protected members.

<br>
<br>
Daveed: What about "operator &amp; "operator,", "operator.*",... in "explicit classes"?  Are those also unavailable?

<br>
<br>
Howard H.: Explicitly default members should still be "trivial" if appropriate.

<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Is this proposal going in the right direction?
</TD>
</TR>
<TR>
<TD>SY: 10</TD><TD>WY:2</TD><TD>WN: 0</TD><TD>SN: 0</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>



<BR>
<BR>
<HR>
<A NAME="83"></A>
<H4>83.
  
Implicitly callable functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Walter Brown
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>March 2004
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>References: N1611 (Walter Brown).</P>
<P>See also <A HREF="
     ewg_active.html#77">77</A>
</P>


Allow niladic functions to be called without an argument list
(i.e., "f" instead of "f()").

<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Should this mechanism be pursued?
</TD>
</TR>
<TR>
<TD>SY: 6</TD><TD>WY: 4</TD><TD>WN: 1</TD><TD>SN: 0</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>



<BR>
<BR>
<HR>
<A NAME="84"></A>
<H4>84.
  
Design-by-Contract facilities
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Thorsten Ottosen
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>March 2004
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>References: N1613 (Thorsten Ottosen).</P>



<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Is Design-by-Contract a good idea to pursue in general?
</TD>
</TR>
<TR>
<TD>SY: 6</TD><TD>WY: 5</TD><TD>WN: 1</TD><TD>SN: 0</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>



<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Suggestion Status"></A>
<H3>Issues with "Suggestion" Status</H3>
<HR>
<A NAME="50"></A>
<H4>50.
  
Opaque pointer-to-member
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3&nbsp;



 <A HREF="basic.html#basic">basic</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES054.)</P>


Define a type that can hold any pointer to member in a way similar to the way void* can hold any pointer. For example:
<blockquote>
<tt>
<pre>struct A {
        int a;
        int* p;
};

struct B {
        int a;
        int* p;
};

int A::* pm1 = &amp;A::a;   // pointer to int member of A
int* A::* pm2 = &amp;A::p;  // pointer to int* member of A
void A::* gp1 = pm1;    // generic pointer to member of A
gp2 = pm2;
pm2 = gp2;      // error no uncast assignment from generic pointer to specific pointer
pm2 = static_cast(gp2);

void *::* gp2 = &amp;A::a;  // generic pointer to member of any class
gp2 = &amp;B::a;
</pre>
</tt>
</blockquote>

Is there sufficeint need for a notion of "generic pointer to member of A"?
Is there sufficient need for a notion of "generic pointer to member of
any class"?
Is there an acceptable syntax?
Do these notions fit into common implementation schemes?
<BR>
<BR>
<HR>
<A NAME="29"></A>
<H4>29.
  
<tt>restrict</tt>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES021.)</P>


It would be nice to be able to indicate that two pointers point to 
non-overlapping storage (something like the C99 <tt>restrict</tt>
qualifier).
<BR>
<BR>
<HR>
<A NAME="72"></A>
<H4>72.
  
Simplify access through iterators
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5&nbsp;



 <A HREF="expr.html#expr">expr</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>(Previously numbered ES080.)</P>


From a programmer:<br>
"I often have to write (*p)[i] and (*p)-&gt;m, that's ugly.
 Could we get operators to clear that up? For example p-&gt;[i] and p-&gt;-&gt;m."
<br>

Another idea is a postfix dereference operator. For example p*[i] and p*-&gt;m.
This idea may relate to the common wish for more operators (to overload).
<BR>
<BR>
<HR>
<A NAME="18"></A>
<H4>18.
  
Overloadable new-style casts
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.2&nbsp;



 <A HREF="expr.html#expr.post">expr.post</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES006.)</P>
<P>Forwarded from LWG by Matt Austern.</P>


The ability to overload new-style cases like <tt>static_cast</tt> and
<tt>dynamic_cast</tt>. This is useful for smart pointers, and it would
also be useful if we ever want to remove the gaps in allocator specification.
<BR>
<BR>
<HR>
<A NAME="16"></A>
<H4>16.
  
Solve the forwarding problem
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES002.)</P>
<P>Forwarded from LWG by Matt Austern.</P>
<P>See also <A HREF="
     ewg_active.html#14">14</A>
</P>


By "the forwarding problem" I mean: create a wrapper function <tt>f2</tt>
that forwards its arguments to a generic function <tt>f1</tt> in exactly
the same way as if <tt>f1</tt> had been called directly.

Not trivial, since some of <tt>f1</tt>'s arguments may by of the form
<tt>T</tt>, some <tt>T&amp;</tt>, some <tt>T const&amp;</tt>.
<BR>
<BR>
<HR>
<A NAME="42"></A>
<H4>42.
  
Allow switch on string
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>6&nbsp;



 <A HREF="stmt.html#stmt.stmt">stmt.stmt</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daniel Gutson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES039.)</P>


For example:
<tt>
<PRE>
        bool f(string s)
        {
                switch(s) {
                case "yes": return true;
                case "no": return false;
                default: throw Unexpected_string();
        }
</PRE>
</tt>

This is a frequent suggestion by novices.
The frequency of requests has increased since the appearance of C#.
<br>
From one of the many people who emailed Bjarne Stroustrup asking:
<ol>
<li>It makes the language more coherent and consistency.
    Why compare only integers and floats and no other types?</li>
<li>It is elegant and natural, even for beginners.</li>
<li>No compatibility issue.</li>
<li>It helps to make programs cleaner and less buggy.</li>
<li>It was not relevant in 1983 with C string, but now with the STL it is.</li>
<li>Easy to implement, the compiler can optimize.</li>
<li>It makes pointers (and pointer-to-function) less needed.</li>
<li>C++ is a better C.</li>
<li>Other recent languages have it (PHP, C#...).</li>
</ol>

<BR>
<BR>
<HR>
<A NAME="20"></A>
<H4>20.
  
Simple compile-time reflection
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7&nbsp;



 <A HREF="dcl.html#dcl.dcl">dcl.dcl</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES009, ES065.)</P>
<P>Forwarded from LWG by Matt Austern.</P>


One example is a simple way to write a compile-time test checking whether
a generic <tt>class X</tt> defines a type called <tt>Foo</tt>.  Another is
support for what the library tries to do with <tt>type_traits&lt;&gt;</tt>
(e.g., is_pod, has_dot, and has_arrow).
<br>
BS: This ought to relate to <tt>decltype</tt> (<A HREF="
     ewg_active.html#1">1</A>).
For example
<PRE>
        decltype(T).has_member(Foo);
</PRE>

<BR>
<BR>
<HR>
<A NAME="43"></A>
<H4>43.
  
Thread-local storage
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7&nbsp;



 <A HREF="dcl.html#dcl.dcl">dcl.dcl</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES041.)</P>


In multi-threaded programs, namespace-scope variables (and static data members)
could either be shared among all threads or be private to threads.
Existing practice is that by default such variables are shared and a
proprietary construct is used to indicate that the variable should be
private to the threads.
<BR>
<BR>
<HR>
<A NAME="65"></A>
<H4>65.
  
Opaque typedefs
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES072.)</P>


A kind of typedef that introduces a real type. For example:
<tt>
<pre>
        real typedef int A;
        real typedef int B;
        A a, a2;
        B b;
        a = b;  // error
        a = a2; // ok
        a = a+b;        // ???
        a = a+a2;       // ???
</pre>
</tt>
There have been explicit requests for such a mechanism for user defined
types, possibly a way of deriving a class that requires an explicit cast
to convert to its base.
<BR>
<BR>
<HR>
<A NAME="41"></A>
<H4>41.
  
Fix namespace aliases
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3&nbsp;



 <A HREF="dcl.html#basic.namespace">basic.namespace</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daniel Gutson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES038.)</P>
<P>References: N1526 (Benjamin Kosnik).</P>


Namespace aliasing issues (e.g., extending namespaces through namespace
alias names).
<BR>
<BR>
<HR>
<A NAME="64"></A>
<H4>64.
  
Importing using-directives
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3&nbsp;



 <A HREF="dcl.html#basic.namespace">basic.namespace</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES071.)</P>
<P>See also <A HREF="
     ewg_active.html#31">31</A>
</P>


In other words, somehow combine a using directive with an #include.
For example:
<tt>
<pre>
        using ; // bring in the declarations from header "vector"
</pre>
</tt>
or
<tt>
<pre>
        using vector;   // find "vector" and bring it in
</pre>
</tt>

This should probably be done with some protection against changes of the
semantics of "vector" because of macros, etc.

<BR>
<BR>
<HR>
<A NAME="61"></A>
<H4>61.
  
Unify default arguments and overloading
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES068.)</P>


Define default arguments as syntactic sugar for overloading.
This would simplify the language, make pointers to functions work better,
and eliminate "special pleading" language in the standard library
specification.
<BR>
<BR>
<HR>
<A NAME="40"></A>
<H4>40.
  
Nondefault array initialization
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daniel Gutson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES037.)</P>


Provide a mechanism to define arrays whose elements are initialized with
a nondefault constructor.

<BR>
<BR>
<HR>
<A NAME="47"></A>
<H4>47.
  
Tweak initialization semantics
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>David Abrahams
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES048.)</P>

<br>
As a separate related matter, I think we ought to be thinking about
removing the use of copy-initialization for forms not involving curly
braces. Among other things, that would allow:
<blockquote>
<tt>
<pre>auto_ptr&lt; T&gt; x = new T;
</pre>
</tt>
</blockquote>
instead of the currently-required:
<blockquote>
<tt>
<pre>auto_ptr&lt; T&gt; x = auto_ptr&lt; T&gt;(new T);
</pre>
</tt>
</blockquote>
(due to auto_ptr's explicit constructor). I know it says "explicit",
but that's really there to prevent unintended conversions. The
declaration above is highly intentional in either form, and probably
clearer in the first form!
<br>
This is also useful for cases like:
<blockquote>
<tt>
<pre>struct Y
{
Y();
explicit Y(int);
};

struct X
{
explicit X(Y);
};

int z = 3;

X x(Y(z)); // oops, declares a function

X&amp; xx = x; // error
</pre>
</tt>
</blockquote>
allowing
<blockquote>
<tt>
<pre>X x = Y(Z);
</pre>
</tt>
</blockquote>
instead of the awkward:
<blockquote>
<tt>
<pre>X x((Y(Z)));
</pre>
</tt>
</blockquote>
[I know it doesn't generalize to multiple arguments]
<br>
Also, I note that at least one important compiler front-end does
copy-elision for the copy-initialization case but NOT for the
direct-initialization case, which is awfully unintuitive. Why should
users have to worry about the fact that one form might be more
efficient than the other, at the whim of the compiler vendor?
<BR>
<BR>
<HR>
<A NAME="23"></A>
<H4>23.
  
Class namespaces
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9&nbsp;



 <A HREF="class.html#class">class</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Carl Daniel
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES013.)</P>
<P>References: N1420.</P>


The suggestion is to allow a class's namespace to be opened so that one
can define several members at once. The main utility would be to avoid
tedious (and therefore error-prone) repetition of template parameters
for template classes.
<BR>
<BR>
<HR>
<A NAME="46"></A>
<H4>46.
  
Union generalization
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9.5&nbsp;



 <A HREF="class.html#class.union">class.union</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Max Skaller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES047.)</P>

The change<br>
-----------<br>

1. Remove the restriction that unions may
not contain members of a constructible type.
<br>
2. Add a restriction to those clauses which
define the semantics of generated default
constructors, copy constructors, copy assignment
operators, and destuctors to the effect that
a program is ill formed if there is a need
to generate one or more of these functions
for a union containing a constructible type.
<br>
[-----------
<br>
There is an existing situation where
such a function is required and cannot be
generated, and that is when it must call
a function of a base class which is not accessible:
this feature is regularly exploited by programmers
to prevent objects being copied.<br>
---------]
<br>
<br>
The motivation<br>
---------------<br>

In ISO C there is a univeral mechanism
for using the same storage extent to
hold different objects at different times,
namely the union. It is universal in the sense
that all data types may be put into unions.
<br>
There are two primary uses for unions.
<br>
(a) The first use is to save storage by reusing
some space which is no longer required.
In this use, the position in the code
determines which component of the union,
if any, is in use.
<br>
(b) The second use is to store data
describing one of several different cases,
in this use, a discriminant either within
the union, or some associated storage,
is used to determine dynamically which component
is in use.
<br>
The canonical example is the transacation,
which includes the messages sent by windowing systems.
<br>
Unions provide two important features:
<br>
(a) they guarrantee enough storage is reserved
for any one of the components
<br>
(b) they ensure that the storage is aligned
correctly for any one of the components
<br>
They also provide a convenient notation
to refer to the storage components.
<br>
Unions are not safe: the programmer may
inadvertantly access a component for which
a value has not been stored.
<br>
In C++, exactly the same motivations
for unions exists as in C. There is a need
to save space and to correctly align storage
to hold heterogenous data, whether the discriminant
is the program counter, an external variable,
or the first member of every component type.
<br>
However, in C++ there is an even stronger
motivation: in C we are not concerned
with execution of constructors and destructors.
<br>
In C++, use of an internal discriminant
allows automatic copying and destruction of the correct
union component.
<br>
The alternatives which most
programmers employ are serious design errors.
The first is to store all the alternatives in
a struct. The problem with this method is
not just that it wastes space, but that
all the values are initialised at one time,
and all destroyed at one time. If one of the
types does not admit a convenient default
constructor, it may even be impossible to use
this representation directly: instead a union
of pointer may be used, which is equivalent
to a proper union except that there is an extra
overhead referencing the components and
allocating heap storage.
<br>
I can't emphasise how endemic this design fault is:
it is used in text books. Here is a common example:
<tt>
<pre>
struct op {
char op_name;
op *left;
op *right;
};</pre>
</tt>
This struct is used to represent an expression tree.
It is of course TOTALLY wrong. The correct representation is:
<tt>
<pre>
struct op;
struct unop { char op_name; op *arg; };
struct binop { char op_name; op *left; op *right; };
union opcase {
char id;
unop u;
binop b;
};
struct op {
enum {id_t, unop_t, binop_t} tag;
opcase n;
};</pre>
</tt>
The reason is that: (1) it is not restricted
to arity 0,1 an 2 operators. (2) the case discriminant
is explicit (rather than relying on NULL pointer checks).
<br>

I note in passing that a C pointer or SQL data base type
is actually a discriminated union of pointer to object
or NULL, and, data value or NIL, respectively.
<br>
The second design error is
using an abstract base and a deirved
class for each alternative: it suffers
the same problem of allocation overhead
mentioned above, and almost invariably requires
a downcast to access the desired alternative.
<br>
At present then, C++ programmers can only use
the convenient, low overhead solution they desire
if the types involved are not constructible.
The change above removes that restriction,
and allows programmers to obtain correctly
sized and aligned storage which can be used
for any finite set of data types.
<br>
No code is broken by the proposal
since it is a relaxation of a restriction.
<br>
No safety is lost, even if constructible
types are used, since a union containing
constructible types requires a user defined
constructor, assignment operator, or destructor
to be used in contexts requiring construction,
assigment, or destruction.
<br>
My personal need here is two-fold.
<br>
First, I am generating C++ code
for a programming language which allows users
to specify a new primitive type by nominating a
C++ type.
<br>
This programming language needs to allocate storage
for these types in a block structured context,
which is the kind (a) of use mentioned above
where the program counter (position in the code)
determines what component of the union is used.
Indeed, it determines when to construct the
component, and when to destroy it. In this case
I need a naked union like:
<tt>
<pre>
union X {
string s;
vector v;
}
</pre>
</tt>
without any constructors or destructors, since
I will use placement new and expicit
destruction to build and destroy objects.
Since I'm emulating a stack frame, I'm happy
to prevent copying by leaving out copy and assignment
operators too.
<br>
Present workaround: I allocate the store as required
on the heap in some cases, and use a struct instead
of a union in others, costing time and storage, respectively.
In addition, there may be a problem failing to destroy
an object at the correct time in the second workaround.
<br>
The second use is the categorical sum, or discriminated
union, usage type (b). In this case I am emulating
ML style variants. This canonical ML example is the list:
<tt>
<pre>
type 'a list = Empty | Cons of int * 'a list
</pre>
</tt>
where 'a is a type variable. My representation is a tagged
pointer:
<tt>
<pre>
struct X { int caseno; void *p; }
</pre>
</tt>
where p is cast as appropriate. Unfortunately,
apart from costing allocations, there is a serious
semantic problem, since copying these pointers
does not copy the objects pointed at by p.
<br>
This second use is a very common need: i cited
before the example of transation types,
which are all so often *incorrectly* encoded
using a base and derived types. That encoding
is popular partly due to ignorance of correct
structure, but also because it is relatively simple
to use RTTI to determine the case.
<br>
[The technique suffers from both allocation costs
and lack of type closure over the union type,
quite apart from confusing programs by adding
yet another abuse of inheritance]
<br>
<BR>
<BR>
<HR>
<A NAME="30"></A>
<H4>30.
  
<tt>sealed/final</tt>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>10&nbsp;



 <A HREF="derived.html#class.derived">class.derived</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES022.)</P>


It would be nice to be able to indicate that two pointers point to 
non-overlapping storage (something like the C99 <tt>restrict</tt>
qualifier).
<BR>
<BR>
<HR>
<A NAME="37"></A>
<H4>37.
  
Virtual overriding control
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>10&nbsp;



 <A HREF="derived.html#class.derived">class.derived</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES031.)</P>
<P>References: N1494 (Daniel Gutson).</P>


Provide a way of saying that a function overrides a specific existing virtual
function, and/or a way of saying that a function does not override an
existing function.
<BR>
<BR>
<HR>
<A NAME="48"></A>
<H4>48.
  
Multimethods
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>10&nbsp;



 <A HREF="derived.html#class.derived">class.derived</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES049.)</P>
<P>References: N1463 and N1529 (Julian Smith).</P>


Provide the ability to do a dynamic lookup on more than one operand.
Frequent suggestion. Discussion in D&amp;E.
<BR>
<BR>
<HR>
<A NAME="35"></A>
<H4>35.
  
Scope requirements on operators
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12&nbsp;



 <A HREF="special.html#special">special</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES028.)</P>


Some operators are currently required to be class members (e.g., <tt>[]</tt>,
<tt>()</tt>) but there may not be a good reason for such a constraint.
If so, allow such operators to be declared in namespace scope.
<BR>
<BR>
<HR>
<A NAME="62"></A>
<H4>62.
  
Allow "address of constructor"
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12&nbsp;



 <A HREF="special.html#special">special</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES069.)</P>


<BR>
<BR>
<HR>
<A NAME="27"></A>
<H4>27.
  
Overloading objects and functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13&nbsp;



 <A HREF="over.html#over">over</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES019.)</P>


It may be useful for function and function objects of the same name to
coexist in the same scope (and subsequently, for overload resolution to
be able to pick among both kinds of candidates).  For example:
<tt>
<PRE>
        void f(int);
        struct X {
                void operator()(double);
        };
        X f;

        f(1);           // call the function
        f(2.0); // call the object

</PRE>
</tt>
<BR>
<BR>
<HR>
<A NAME="28"></A>
<H4>28.
  
Overload sets as first-class entities
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13&nbsp;



 <A HREF="over.html#over">over</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES020.)</P>


It would be nice to be able to pass an overload set as a template argument.
<BR>
<BR>
<HR>
<A NAME="33"></A>
<H4>33.
  
<tt>operator.()</tt>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13&nbsp;



 <A HREF="over.html#over">over</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES025.)</P>


Allow a user-defined <tt>operator.()</tt>.
<BR>
<BR>
<HR>
<A NAME="21"></A>
<H4>21.
  
Named template parameters
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES010.)</P>
<P>Forwarded from LWG by Matt Austern.</P>


This would be useful for policy classes.

One might argue for named function parameters as well, just for
consistency's sake, but there isn't as strong a demand for it.
<BR>
<BR>
<HR>
<A NAME="34"></A>
<H4>34.
  
Nontype template arguments: Allow floating-point and string constants
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES027.)</P>


Some compilers already support floating-point nontype template parameters.
<BR>
<BR>
<HR>
<A NAME="51"></A>
<H4>51.
  
Namespace template arguments
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES055.)</P>


Allow a namespace name to be passed as a namespace template argument (through
a corresponding namespace template parameter).
<BR>
<BR>
<HR>
<A NAME="52"></A>
<H4>52.
  
Namespace templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES056.)</P>


Introduce the notion of parameterized namespaces.
<BR>
<BR>
<HR>
<A NAME="58"></A>
<H4>58.
  
Relax <tt>typename</tt> constraints
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES063.)</P>


Allow the keyword <tt>typename</tt> for any type name.
<BR>
<BR>
<HR>
<A NAME="63"></A>
<H4>63.
  
Relax template template parameter matching rules
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES070.)</P>


Take a template template argument's default arguments into consideration
when matching it up with a template template parameter.  This would allow
a two-parameter template argument to match a one-parameter template template
parameter.

<BR>
<BR>
<HR>
<A NAME="38"></A>
<H4>38.
  
<tt>finally</tt>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>15&nbsp;



 <A HREF="except.html#except">except</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES032.)</P>


Allow a finally clause for a try block.
<BR>
<BR>
<HR>
<A NAME="44"></A>
<H4>44.
  
Revise throw specifications
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>15&nbsp;



 <A HREF="except.html#except">except</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Sean Parent
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES041.)</P>


Statically check throw specifications and assume that extern "C" implies
"<tt>throw()</tt>".  (Discussion on -ext. Or eliminate them
altogether.)
<BR>
<BR>
<HR>
<A NAME="67"></A>
<H4>67.
  
<tt>__func__</tt>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>16&nbsp;



 <A HREF="cpp.html#cpp">cpp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES075.)</P>


A way to express the name of the enclosing function as a string.
<BR>
<BR>
<HR>
<A NAME="68"></A>
<H4>68.
  
Exclusive inheritance
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>16&nbsp;



 <A HREF="cpp.html#cpp">cpp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES076.)</P>
<P>References: N1492 (Daniel Gutson).</P>


Provide a way to express that two classes cannot appear together in an
inheritance graph.
<BR>
<BR>
<HR>
<A NAME="56"></A>
<H4>56.
  
<tt>alignof</tt>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES060.)</P>


Standardize the common practice of providing an operator that evaluates to
the alignment multiple of a type (much like <tt>sizeof</tt>).
<br>
GNU version described in c++std-ext-4274. VC++ version described in c++std-ext-4276.
Note by Atila Fehrer.
<BR>
<BR>
<HR>
<A NAME="39"></A>
<H4>39.
  
Optional garbage collection
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES033.)</P>


Explicitly acknowledge that garbage collection is a valid implementation
technique for C++ and define when destructors are called and what it
means for a an object to be unreferenced. See TC++PL3 C.9.1.
<BR>
<BR>
<HR>
<A NAME="49"></A>
<H4>49.
  
C99 extensions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES052.)</P>


Incorporate all or several C99 extensions.
<BR>
<BR>
<HR>
<A NAME="59"></A>
<H4>59.
  
Support parallel programming
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES066.)</P>


For example, locks, threading, memory barrier, static local initialization.
See OpenMP: http://www.openmp.org.
<BR>
<BR>
<HR>
<A NAME="60"></A>
<H4>60.
  
Local templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES067.)</P>


<BR>
<BR>
<HR>
<A NAME="66"></A>
<H4>66.
  
Truly randon (crypto secure) numbers
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES073.)</P>


(No more details provided.)
<BR>
<BR>
<HR>
<A NAME="74"></A>
<H4>74.
  
A const string class
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>(Previously numbered ES081.)</P>


This may and may not affect the way initializers and string literals
are handled.
See Kevlin Henney: http://www.cuj.com/documents/s=7995/cujcexp1905henney/
If not, it is a pure library issue.
<BR>
<BR>
<HR>
<A NAME="75"></A>
<H4>75.
  
An arbitrary-precision integer class
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>(Previously numbered ES082.)</P>


This may and may not affect the way initializers and string literals are
handled, and it may require some other direct language support. If not,
it is a pure library issue. This has been proposed under many names -
often the popular, descriptive, but ugly "Bignum".
<BR>
<BR>
<HR>
<A NAME="77"></A>
<H4>77.
  
Object templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>(Previously numbered ES084.)</P>
<P>References: N1586 (Walter Brown).</P>
<P>See also <A HREF="
     ewg_active.html#83">83</A>
</P>


Allow things like:
<blockquote>
<tt>
<pre>template&lt;typename T&gt; T const pi = (T)3.1;
</pre>
</tt>
</blockquote>

<BR>
<BR>
<HR>
<A NAME="22"></A>
<H4>22.
  
GUI facilities
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES011.)</P>


Provide core language facilities, such as events, callbacks, and properties
that make a good standard library GUI feasible.
<BR>
<BR>
<HR>
<A NAME="25"></A>
<H4>25.
  
Lambda functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES017, ES062.)</P>


It is often convenient to be able to write small "function objects"
with expressions.  For example:
<PRE>
std::for_each(a, b, $(int x) { ++x; })
</PRE>
<BR>
<BR>
<HR>
<A NAME="31"></A>
<H4>31.
  
Modules
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES023.)</P>


The packaging of code in translation units combined with the access to
interface information through <tt>#include</tt> directives is outdated
and inefficient.
<BR>
<BR>
<HR>
<A NAME="32"></A>
<H4>32.
  
Properties
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES024.)</P>
<P>References: N1600 (Daveed Vandevoorde), N1384 (John Wiegley).</P>


Provide Delphi/C#-like properties.
It may be possible to provide properties as a standard-library facility.


<P>
<I>Straw polls:</I>
<BR>
<BLOCKQUOTE>
<TABLE>
<TR>
<TD COLSPAN="5">
Should properties be pursued (in general)?
</TD>
</TR>
<TR>
<TD>SY: 3</TD><TD>WY: 7</TD><TD>WN: 6</TD><TD>SN: 2</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</P>



<BR>
<BR>
<HR>
<A NAME="45"></A>
<H4>45.
  
Nested functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES046.)</P>


Allow functions to nest.
<BR>
<BR>
<HR>
<A NAME="53"></A>
<H4>53.
  
Closures/Delegates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES057.)</P>


Introduce a new kind of entity that essentially consists of a pointer-to-member
bound to a specific object: The result acts like an ordinary function pointer.
<BR>
<BR>
<HR>
<A NAME="54"></A>
<H4>54.
  
Arrays of references
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES058.)</P>


Allow arrays of references.
<BR>
<BR>
<HR>
<A NAME="55"></A>
<H4>55.
  
Byte order control
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>suggestion
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered ES059.)</P>


Provide a mechanism to select the byte order for the members of a struct.
<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Issue Status"></A>
<H3>Issues with "Issue" Status</H3>
<HR>
<A NAME="13"></A>
<H4>13.
  
Macro pollution
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>16&nbsp;



 <A HREF="cpp.html#cpp">cpp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>issue
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>(Previously numbered EI001.)</P>


Macros can arbitrarily change the meaning of any piece of code.
This imposes restrictive defensive naming practices and even then
leads to surprises and errors. Namespaces provide no defense.
Since macros are typically found in headers (incl. standard headers)
a programmer cannot be expected to know every macro used in a program.

Macros are so widely used and some uses, such <tt>#include</tt> guards
and conditional compilation control macros, have no generally acceptable
alternatives.

See also <A HREF="
     ewg_active.html#13">13</A> and <A HREF="">ES042FIXME</A>.
<BR>
<BR>
<HR>
<A NAME="14"></A>
<H4>14.
  
Simplify, generalize, and automate
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>issue
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered EI002.)</P>
<P>References: N1445.</P>


Too many simple things cannot be expressed simply and require
error-prone workarounds. This discourages good style and complicates
early teaching.

<BR>
<BR>
<HR>
<A NAME="15"></A>
<H4>15.
  
GUI
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>&nbsp;



 <A HREF=".html#"></A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>issue
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>(unknown)
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>



<P>(Previously numbered EI003.)</P>


C++ doesn't have a standard GUI. This is widely considered to mean that C++
doesn't have GUI capabilities at all and can't be used for applications
requiring a graphical user interface. It also hampers education by biasing
teaching towards either proprietary extensions (limiting the utility of
what is taught to a single library or vendor), or to command-line exercises
widely perceived as boring and old-fashioned.

GUIs are often built using language extensions - thus rendering them
non-portable.
<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>
