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 "Ready," "Review," "Drafting," and "Open."

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:

• No-Action List, 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.
• Accepted Extensions List, which contains the proposals that have been accepted by the Committee for inclusion in the next standard.
• Table of Contents, which contains a summary listing of all proposals in numerical order.
• Index by Section, which contains a summary listing of all proposals arranged in the order of the sections of the Standard with which they deal most directly.
• Index by Status, which contains a summary listing of all proposals grouped by status.

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.

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 Issue Status below.)

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.

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.

The most current public version of this document can be found at http://www.dkuug.dk/jtc1/sc22/wg21. 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 Eye Street NW, Suite 200, Washington, DC 20005, USA.

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 http://www.jamesd.demon.co.uk/csc/faq.html. Public discussion of the C++ Standard and related issues occurs on newsgroup comp.std.c++.

Revision History

• Revision 1: 2004-03-30: Original version created from N1598/04-0038 and notes from the 2004 Sydney meeting.

Issue status

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:

Issues and Suggestions: Issues (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. Suggestions (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.

When a paper is written, the issue or suggestion moves to Open status.

Open: 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.

When the working group reaches informal consensus that is described in rough terms in a Tentative Design, the proposal moves to Drafting status.

Drafting: Informal consensus has been reached in the working group and is described in rough terms in a Tentative Design, although precise wording for the change is not yet available.

When Proposed Wording becomes available, usually in an updated revision of the paper, the proposal moves to Review status.

Review: Exact Proposed Wording 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.

When the working group approves the Proposed Wording, and the Core and Library working groups confirm, then the proposal moves to Ready status.

Ready: The working group has reached consensus on the proposal, the Proposed Wording is correct and confirmed by the Core or Library working groups.

When the Proposed Wording 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 WP status.

WP: 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.

Dup: The issue is identical to or a subset of another issue, identified in a Rationale statement.

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

Policies

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

• Improve the support of generic programming
• Improve the support for library building and use
• Make the language more regular, predictable, and teachable (also known as ҭake simple things simple to expressө
• Support the building of libraries that will make C++ a better platform for systems programming

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.

Typically, a proposal will not go to full committee before CWG or LWG has discussed it either on a reflector or at a meeting.

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.

Compatibility with C++03 and the zero-overhead principle are considered very important.

Straw Polls

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.

Issues with "Ready" Status

Issues with "Review" Status

9. Static assertions

(Previously numbered EP009.)

References: N1381, N1604, N1617.

Straw polls:

Should the first expression be constrained to be a constant-expression convertible to type bool?
SY: all	WY: 0	WN: 0	SN: 0
Should the second expression be restricted to (possibly wide) string literals?
SY: 20	WY: 4	WN: 1	SN: 0
Should the string literal (the second argument) be required to appear in the diagnostic?
SY: 17	WY: 8	WN: 4	SN: 1
Approve of the proposal as ammended?
SY: 30	WY: 1	WN: 0	SN: 2

Issues with "Drafting" Status

24. Adding the long long type to C++

(Previously numbered ES016.)

References: N1565 (Steve Adamczyk).

long long is ugly syntax for a 64-bit type, but given C99 and existing practice wrt. C++ compilers, we should just imitate this.

There are library parts to the long long extension, but the affected areas in the standard are "included by reference." Plauger's omnibus C99 paper deals with the logistics of that.

Controversial typing of "boundary cases." Some constants that are today of unsigned long type would more sensibly have type long long if that type is available. Should C++ follow C99's lead of breaking C89 (and hence C++98) compatibility?

EDG supports both options but C99 experience is small (though it hasn't generated complaints so far).

Straw polls:

Should the proposal of N1565 be followed in its entirety?
SY: 19	WY: 0	WN: 0	SN: 0

70. Extended friend declarations

(Previously numbered ES078.)

References: N1520 (Mike Miller).

        friend T;

Straw polls:

Option 1 (no restrictions)
SY: 10	WY: 4	WN: 5	SN: 0
Option 2 (only dependent type names)
SY: 0	WY: 8	WN: 9	SN: 3
Option 3 (no keywords)
SY: 10	WY: 6	WN: 3	SN: 2

Issues with "Open" Status

12. User-defined literals

(Previously numbered EP012, ES053.)

References: N1511.

5. Dynamic Libraries

(Previously numbered EP005 and ES015.)

References: N1400 (Matt Austern), N1418 (Pete Becker).

8. Null pointer constant

(Previously numbered EP008, ES047.)

References: N1488, N1601.

  template<typename T> class X {};  // (1)
  template<typename T> class X<T*> {};  // (2)
  template<typename T> class X<int T::*> {};  // (3)

  template<typename T> void f(T) {
    X<T>  x;  // Which template is instantiated
  }

  template<class T> void f(T, T);
  f("hello", nullptr);  // If nullptr is deducible, this is ambiguous

Straw polls:

nullptr should not have a 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 we pursue nullptr at all?
SY: 11	WY:7	WN: 2	SN: 2

82. Uniform function call syntax (part II)

References: N1585 (Francis Glassborow).

See also 57

struct X {};
void f(int, X& *this);
void g(X *p) {
  p->f(3);  //  Calls f(3, p) with member-call conversion rules

Straw polls:

Is this a good idea?
SY: 1	WY: 5	WN: 3	SN: 5

71. Constant inline functions

(Previously numbered ES079.)

References: N1521.

85. for each

(Part of Ecma TC39-TG5 liaison work.)

References: c++std-ext-6729 (Thorsten Ottosen).

vector<int> V;
for each(int &x: V) ...
for (int &x; V) ...

Straw polls:

Is collection iteration of potential interest to this group?
SY: 7	WY: 6	WN: 1	SN: 0
Does EWG think using a single semicolon would be OK?
SY: 1	WY: 0	WN: 1	SN: 12
Is "for (decl:expr)" the likely syntax?
SY: 4	WY: 8	WN: 1	SN: 0

1. decltype and auto

(Previously numbered EP001.)

References: c++std-ext-5364, N1478, N1527, N1607.

• decltype(expr): a type specifier denoting the (possibly modified) type of the expression.
• auto x = expr;: the deduction of a variable type from its initializer.
• int f(auto);: implicit templates (equivalent to template<typename T> int f(T);).
• auto f() { ... }: return types deduced from return statements.
• A new function declaration syntax that places the return type after the parameter types. E.g., auto f(T a, U b) -> decltype(a+b);.

General agreement that multiple declarators (as in auto x = expr, *y = expr2;) should not be allowed in a single auto-deduced declaration.

Several attendants voiced that something like pair<auto, auto> x = expr; "may not be worth the trouble."

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.

John S. asked if the return type is a nondeduced context with the new declaration syntax. Jaakko confirmed that that is correct.

Straw polls:

In favor of decltype along the lines presented:
SY: 8	WY: 13	WN: 0	SN: 0
In favor of auto for basic type specifiers in variable declarations:
SY: 10	WY: 10	WN: 1	SN: 0
In favor of auto for any type component specifiers in variable declarations:
SY: 4	WY: 4	WN: 12	SN: 1
In favor of auto return types:
SY: 1	WY: 2	WN: 4	SN: 11
In favor of new function declaration syntax along the lines presented:
SY: 4	WY: 7	WN: 5	SN: 0
Should the authors of the paper work to preserve the existing meaning of "auto"?
SY: 18	WY: 3	WN: 0	SN: 0
Use a different keyword from auto?
SY: 5	WY: 8	WN: 7	SN: 2

36. Extend enum types

(Previously numbered ES029, ES030, ES034, ES050, ES051, and ES074.)

References: N1579 (Herb Sutter).

• implicit conversion to integer
• scoping of enum constants
• underlying type

• complex to specify
• not actually a problem
• doesn't directly address the claimed issue

• Allow "explicit" to inhibit conversions
• Allow ": <type>" to specify the underlying type
• Allow E::x in addition to x for enum constants

Straw polls: Directions for semantics

scoping?
SY: 13	WY: 6	WN: 2	SN: 0
explicit conversion?
SY: 19	WY: 2	WN: 0	SN: 0
explicit underlying type?
SY: 12	WY: 9	WN: 0	SN: 0
floating-point underlying type?
SY: 0	WY: 0	WN: 8	SN: 13
iteration over enumerators?
SY: 1	WY: 9	WN: 10	SN: 1
checkin case labels?
SY: 5	WY: 4	WN: 6	SN: 6
extending set of enumerators?
SY: 5	WY: 9	WN: 5	SN: 1
special member functions (ctors, op=)?
SY: 6	WY: 2	WN: 4	SN: 10
packed enums?
SY: 0	WY: 5	WN: 10	SN: 6
should extended enum semantics be pursued at all?
SY: 12	WY: 8	WN: 0	SN: 0

Straw polls: Directions for syntax

Syntax to enforce strong scoping?
SY: 13	WY: 4	WN:3	SN: 1
Allow ambiguous enumerator constants (no actual syntax)?
SY: 8	WY: 3	WN:5	SN: 5
Should a single construct provide both of the above?
SY: 7	WY: 6	WN:4	SN: 4
Should an enum type be able to pick-and-choose its features (separate independent constructs)?
SY: 13	WY: 4	WN:1	SN: 3

69. Nested namespace notation

(Previously numbered ES077.)

References: N1524 (Jon Jagger).

        namespace N:M { ... }

81. Allow class-scope using declarations to include private members

References: N1602 (Francis Glassborow).

  struct B {
    f(int i);
  private:
    f();
  };
  struct D: B {
    using B::f; // Error today.  Allowed under proposal.
  };

Straw polls:

Is Francis' idea promising
SY: 8	WY: 4	WN: 0	SN: 0
Should Francis and Daveed explore making accessibility affect visibility.
SY: 10	WY: 2	WN: 0	SN: 0

7. Move Semantics

(Previously numbered EP007.)

References: N1377.

11. Generalized initializer lists

(Previously numbered EP011 and ES026.)

References: N1493, N1509.

80. Regularizing initialization syntax

References: N1584 (Francis Glassborow).

See also 47

  struct X {
    explicit X(int){}
    X(short){}
  };
  X x1(3); // ambiguous
  X x2=3; // uses short constructor, since long constructor is explicit

Straw polls:

Should Francis G. pursue this?
SY: 10	WY: 2	WN: 0	SN: 0

19. Forwarding constructors

(Previously numbered ES008.)

Forwarded from LWG by Matt Austern.

References: N1581 (Herb Sutter).

See also 79

Straw polls:

Is this generally a good idea (poll taken twice; last one reported):
SY: 16	WY: 7	WN: 0	SN: 1
Is an object fully constructed after any constructor has run?
SY: 22	WY: 0	WN: 1	SN: 0
Is an object no full construct until all constructors have run?
SY: 2	WY: 1	WN: 1	SN: 17

76. Explicit conversion functions

(Previously numbered ES083.)

References: N1592 (Lois Goldthwaite).

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

  struct X {
    X(short);
    explicitly X(long);
  };
  X x1(42);       // Ambiguous
  X x2 = 42;      // X(short)
  X x3 = 42000L;  // X(short) !!

  template<class T, class U> 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.

Straw polls:

Is this a good idea in general?
SY: 19	WY:4	WN: 0	SN: 0
Does this proposal deserve more analysis before pressing on?
SY: 18	WY:0	WN: 0	SN: 0

      reinterpret_cast<float*>v[0])

      static_cast<T*>static_cast<float*>v[0]))

79. Inheriting constructors

References: N1583 (Francis Glassborow).

See also 19

Straw polls:

Should Francis G. pursue this?
SY: 2	WY: 2	WN: 4	SN: 2

2. Template aliases

(Previously numbered EP002.)

References: c++std-ext-5658 (etc.), N1406, N1449, N1451, N1489.

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:

    template <class T> using Vec = std::vector<T*>;

A key concept is that template aliases cannot be specialized, and that they may deducible if the parameterized type they stand for is deducible.

10. Concepts

(Previously numbered EP010, ES046.)

References: N1510, N1522, N1536.

17. Variadic template parameters

(Originally ES005.)

References: N1603.

Straw polls:

Is this a good direction?
SY: 10	WY: 9	WN: 4	SN: 0
Should pattern-unpacking beyond the basics be pursued?
SY: 5	WY: 6	WN: 1	SN: 8
Should built-in tupling be explored?
SY: 7	WY: 10	WN: 3	SN: 0
Should this proposal attempt to solve the sequence constructor problem?
SY: 7	WY: 8	WN: 5	SN: 0

73. Partial specialization of function templates

(Previously numbered ES080.)

References: N1295.

6. Allow local classes as template arguments

(Previously numbered EP006.)

References: N1427.

4. extern template

(Previously numbered EP004.)

References: N1448, c++std-ext-6930,6939, c++std-ext-6895..., c++std-ext-6981..., c++std-ext-6959...

3. #scope/#endscope

(Previously numbered EP003.)

References: N1614.

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.

Tentative syntax:

#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.

Can chained macro invocations accidentally pick up other macros? E.g.:

  #scope
  #define helper(x) x
  #define macro(x) helper(x)
  #export macro
  #endscope
  #import macro
  #define helper(x) 2
  macro(10)  // ?

Dave A.: It's not clear this supports reasonable "existing practice" preprocessor idioms.

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.

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."

Several note that both #export and #import are already in used by vendor-specific extensions.

Straw polls:

Should the author pursue this general direction?
SY: 6	WY: 3	WN: 3	SN: 5
If we were to go ahead with a mechanism like this, should the import/export feature be separated from the #scope/#endscope delimiters?
SY: 10	WY: 4	WN: 0	SN: 1
Should this specific idea be developed in coordination with WG14?
SY: 10	WY: 2	WN: 2	SN: 3
Should we work with WG14 to solve the macro problem (irrespective of the approach)?
SY: 13	WY: 4	WN: 0	SN: 1

78. C99 Preprocessor

References: N1566 (Clark Nelson).

- 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


- <stdint.h> 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.)

26. Right angle brackets (>>)

(Previously numbered ES018.)

References: N1649 (Daveed Vandevoorde).

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:

#include <vector>
typedef std::vector<std::vector<int> > Table;  // OK
typedef std::vector<std::vector<bool>> Flags;  // Error

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.

N1649 proposes that >> 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:

#include <iostream>
template<int I> struct X {
  static int const c = 2;
};
template<> struct X<0> {
  typedef int c;
};
template<typename T> struct Y {
  static int const c = 3;
};
static int const c = 4;
int main() {
  std::cout << (Y<X<1> >::c >::c>::c) << '\n';
  std::cout << (Y<X< 1>>::c >::c>::c) << '\n';
}

57. Uniform function call syntax

(Previously numbered ES061.)

        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->f(1)
        }

23. Defaulting and inhibiting common operations

(Previously numbered ES012, ES044.)

See also 14

References: N1582 (Francis Glassborow).

  // Dot h
  struct S {
    S();
  };

  // Dot C
  S::S() default;

Straw polls:

Is this proposal going in the right direction?
SY: 10	WY:2	WN: 0	SN: 0

83. Implicitly callable functions

References: N1611 (Walter Brown).

See also 77

Straw polls:

Should this mechanism be pursued?
SY: 6	WY: 4	WN: 1	SN: 0

84. Design-by-Contract facilities

References: N1613 (Thorsten Ottosen).

Straw polls:

Is Design-by-Contract a good idea to pursue in general?
SY: 6	WY: 5	WN: 1	SN: 0

Issues with "Suggestion" Status

50. Opaque pointer-to-member

(Previously numbered ES054.)

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

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

int A::* pm1 = &A::a;   // pointer to int member of A
int* A::* pm2 = &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 = &A::a;  // generic pointer to member of any class
gp2 = &B::a;

29. restrict

(Previously numbered ES021.)

72. Simplify access through iterators

(Previously numbered ES080.)

18. Overloadable new-style casts

(Previously numbered ES006.)

Forwarded from LWG by Matt Austern.

16. Solve the forwarding problem

(Previously numbered ES002.)

Forwarded from LWG by Matt Austern.

See also 14

42. Allow switch on string

(Previously numbered ES039.)

        bool f(string s)
        {
                switch(s) {
                case "yes": return true;
                case "no": return false;
                default: throw Unexpected_string();
        }

1. It makes the language more coherent and consistency. Why compare only integers and floats and no other types?
2. It is elegant and natural, even for beginners.
3. No compatibility issue.
4. It helps to make programs cleaner and less buggy.
5. It was not relevant in 1983 with C string, but now with the STL it is.
6. Easy to implement, the compiler can optimize.
7. It makes pointers (and pointer-to-function) less needed.
8. C++ is a better C.
9. Other recent languages have it (PHP, C#...).

20. Simple compile-time reflection

(Previously numbered ES009, ES065.)

Forwarded from LWG by Matt Austern.

        decltype(T).has_member(Foo);

43. Thread-local storage

(Previously numbered ES041.)

65. Opaque typedefs

(Previously numbered ES072.)

        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;       // ???

41. Fix namespace aliases

(Previously numbered ES038.)

References: N1526 (Benjamin Kosnik).

64. Importing using-directives

(Previously numbered ES071.)

See also 31

        using ; // bring in the declarations from header "vector"

        using vector;   // find "vector" and bring it in

61. Unify default arguments and overloading

(Previously numbered ES068.)

40. Nondefault array initialization

(Previously numbered ES037.)

47. Tweak initialization semantics

(Previously numbered ES048.)

auto_ptr< T> x = new T;

auto_ptr< T> x = auto_ptr< T>(new T);

struct Y
{
Y();
explicit Y(int);
};

struct X
{
explicit X(Y);
};

int z = 3;

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

X& xx = x; // error

X x = Y(Z);

X x((Y(Z)));

23. Class namespaces

(Previously numbered ES013.)

References: N1420.

46. Union generalization

(Previously numbered ES047.)

struct op {
char op_name;
op *left;
op *right;
};

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;
};

union X {
string s;
vector v;
}

type 'a list = Empty | Cons of int * 'a list

struct X { int caseno; void *p; }

30. sealed/final

(Previously numbered ES022.)

37. Virtual overriding control

(Previously numbered ES031.)

References: N1494 (Daniel Gutson).

48. Multimethods

(Previously numbered ES049.)

References: N1463 and N1529 (Julian Smith).

35. Scope requirements on operators

(Previously numbered ES028.)

62. Allow "address of constructor"

(Previously numbered ES069.)

27. Overloading objects and functions

(Previously numbered ES019.)

        void f(int);
        struct X {
                void operator()(double);
        };
        X f;

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

28. Overload sets as first-class entities

(Previously numbered ES020.)

33. operator.()

(Previously numbered ES025.)

21. Named template parameters

(Previously numbered ES010.)

Forwarded from LWG by Matt Austern.

34. Nontype template arguments: Allow floating-point and string constants

(Previously numbered ES027.)

51. Namespace template arguments

(Previously numbered ES055.)

52. Namespace templates

(Previously numbered ES056.)

58. Relax typename constraints

(Previously numbered ES063.)

63. Relax template template parameter matching rules

(Previously numbered ES070.)

38. finally

(Previously numbered ES032.)

44. Revise throw specifications

(Previously numbered ES041.)

67. __func__

(Previously numbered ES075.)

68. Exclusive inheritance

(Previously numbered ES076.)

References: N1492 (Daniel Gutson).

56. alignof

(Previously numbered ES060.)

39. Optional garbage collection

(Previously numbered ES033.)

49. C99 extensions

(Previously numbered ES052.)

59. Support parallel programming

(Previously numbered ES066.)

60. Local templates

(Previously numbered ES067.)

66. Truly randon (crypto secure) numbers

(Previously numbered ES073.)

74. A const string class

(Previously numbered ES081.)

75. An arbitrary-precision integer class

(Previously numbered ES082.)

77. Object templates

(Previously numbered ES084.)

References: N1586 (Walter Brown).

See also 83

template<typename T> T const pi = (T)3.1;

22. GUI facilities

(Previously numbered ES011.)

25. Lambda functions

(Previously numbered ES017, ES062.)

std::for_each(a, b, $(int x) { ++x; })

31. Modules

(Previously numbered ES023.)

32. Properties

(Previously numbered ES024.)

References: N1600 (Daveed Vandevoorde), N1384 (John Wiegley).

Straw polls:

Should properties be pursued (in general)?
SY: 3	WY: 7	WN: 6	SN: 2

45. Nested functions

(Previously numbered ES046.)

53. Closures/Delegates

(Previously numbered ES057.)

54. Arrays of references

(Previously numbered ES058.)

55. Byte order control

(Previously numbered ES059.)

Issues with "Issue" Status

13. Macro pollution

(Previously numbered EI001.)

14. Simplify, generalize, and automate

(Previously numbered EI002.)

References: N1445.

15. GUI

(Previously numbered EI003.)