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:
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. 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.
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
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.
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.
(Previously numbered EP009.)
References: N1381, N1604, N1617.Provide a way to make an assertion checked at translation time; the general form is static_assert(expr1, expr2). This is particularly useful in templates (where #error doesn't cut it) to issue compilation errors at instantiation time.
Straw polls:
(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:
(Previously numbered ES078.)
References: N1520 (Mike Miller).Allow
friend T;where T is a template argument or typedef name. Among three options in N1520 EWG selected "option 2" in Kona 2003, but CWG review concluded anything but "option 2".
Straw polls:
(Previously numbered EP012, ES053.)
References: N1511.
(Previously numbered EP005 and ES015.)
References: N1400 (Matt Austern), N1418 (Pete Becker).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.
(Previously numbered EP008, ES047.)
References: N1488, N1601.Introduce the keyword nullptr to denote a value that can be assigned to any pointer, but not to non-pointers.
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.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.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 }
Core issue parallel: Overloaded function address is nondeducible (pending new core resolution).Core issue parallel: Overloaded function address is nondeducible (pending new core resolution).template<class T> void f(T, T); f("hello", nullptr); // If nullptr is deducible, this is ambiguous
Straw polls:
References: N1585 (Francis Glassborow).
See also 57Allow a namespace scope function declaration to be treated as a member function. For example:
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:
(Previously numbered ES079.)
References: N1521.Allow certain inline function calls in constant-expressions.
(Part of Ecma TC39-TG5 liaison work.)
References: c++std-ext-6729 (Thorsten Ottosen).A short-hand construct to iterate over a collection. Examples:
vector<int> V; for each(int &x: V) ... for (int &x; V) ...
Straw polls:
(Previously numbered EP001.)
References: c++std-ext-5364, N1478, N1527, N1607.This is a proposal to enable the deduction of types in various places that currently require decl-specifiers. The following extensions are/were considered:
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:
(Previously numbered ES029, ES030, ES034, ES050, ES051, and ES074.)
References: N1579 (Herb Sutter).Revise some limitations or undesirable properties of enum types.
Straw polls: Directions for semantics
Straw polls: Directions for syntax
(Previously numbered ES077.)
References: N1524 (Jon Jagger).Allow a nested namespace be re-opened with the syntax
namespace N:M { ... }
References: N1602 (Francis Glassborow).For.struct B { f(int i); private: f(); }; struct D: B { using B::f; // Error today. Allowed under proposal. };
Straw polls:
(Previously numbered EP007.)
References: N1377.
(Previously numbered EP011 and ES026.)
References: N1493, N1509.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 12. Alternative proposal by Daniel Gutson: N1493.
References: N1584 (Francis Glassborow).
See also 47Consider 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).
Daveed: This is going to be tough sell. Lots of subtleties. We cannot move forward without substantial help from core experts.Daveed: This is going to be tough sell. Lots of subtleties. We cannot move forward without substantial help from core experts.struct X { explicit X(int){} X(short){} }; X x1(3); // ambiguous X x2=3; // uses short constructor, since long constructor is explicit
Straw polls:
(Previously numbered ES008.)
Forwarded from LWG by Matt Austern.
References: N1581 (Herb Sutter).
See also 79Make it possible to forward one overload of X::X to another overload. Discussion of Herb Sutter's paper N1581:
Straw polls:
(Previously numbered ES083.)
References: N1592 (Lois Goldthwaite).To match explicit constructors.
Another example (from Lois G.):Another example (from Lois G.):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
Explicit conversion functions would not be considered for UDC sequences.Explicit conversion functions would not be considered for UDC sequences.struct X { X(short); explicitly X(long); }; X x1(42); // Ambiguous X x2 = 42; // X(short) X x3 = 42000L; // X(short) !!
"static_cast" (a library solution) allows conversions that are too dangerous."static_cast" (a library solution) allows conversions that are too dangerous.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:
reinterpret_cast<float*>v[0])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:
static_cast<T*>static_cast<float*>v[0]))and is so ugly that nobody but anal retentive programmers like me will touch it.
References: N1583 (Francis Glassborow).
See also 19Provide 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?
Straw polls:
(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*>;This declares Vec to be an alias for the parameterized type 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.N1489 discusses generalizations of this concept.
(Previously numbered EP010, ES046.)
References: N1510, N1522, N1536.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.
(Originally ES005.)
References: N1603.
Straw polls:
(Previously numbered ES080.)
References: N1295.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:
(Previously numbered EP006.)
References: N1427.
(Previously numbered EP004.)
References: N1448, c++std-ext-6930,6939, c++std-ext-6895..., c++std-ext-6981..., c++std-ext-6959...This is a proposal to allow the explicit instantiation syntax to be prefixed with the keyword extern 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.
(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.Sydney 2004 discussion:
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:
References: N1566 (Clark Nelson).A proposal to translate the preprocessor changes made for C99 to C++.
- 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.)
(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:
The problem is an immediate consequence of the the maximum munch principle and the fact that >> is a valid token (right shift) in C++.The problem is an immediate consequence of the the maximum munch principle and the fact that >> is a valid token (right shift) in C++.#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'; }
(Previously numbered ES061.)Allow a member function to be invoked using the free-standing function syntax. For example
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) }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.
(Previously numbered ES012, ES044.)
See also 14
References: N1582 (Francis Glassborow).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.
// Dot h struct S { S(); }; // Dot C S::S() default;
Straw polls:
References: N1611 (Walter Brown).
See also 77Allow niladic functions to be called without an argument list (i.e., "f" instead of "f()").
Straw polls:
References: N1613 (Thorsten Ottosen).
Straw polls:
(Previously numbered ES054.)Define a type that can hold any pointer to member in a way similar to the way void* can hold any pointer. For example:
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?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?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;
(Previously numbered ES021.)It would be nice to be able to indicate that two pointers point to non-overlapping storage (something like the C99 restrict qualifier).
(Previously numbered ES080.)From a programmer:
(Previously numbered ES006.)
Forwarded from LWG by Matt Austern.The ability to overload new-style cases like static_cast and dynamic_cast. This is useful for smart pointers, and it would also be useful if we ever want to remove the gaps in allocator specification.
(Previously numbered ES002.)
Forwarded from LWG by Matt Austern.
See also 14By "the forwarding problem" I mean: create a wrapper function f2 that forwards its arguments to a generic function f1 in exactly the same way as if f1 had been called directly. Not trivial, since some of f1's arguments may by of the form T, some T&, some T const&.
(Previously numbered ES039.)For example:
bool f(string s) { switch(s) { case "yes": return true; case "no": return false; default: throw Unexpected_string(); }This is a frequent suggestion by novices. The frequency of requests has increased since the appearance of C#.
(Previously numbered ES009, ES065.)
Forwarded from LWG by Matt Austern.One example is a simple way to write a compile-time test checking whether a generic class X defines a type called Foo. Another is support for what the library tries to do with type_traits<> (e.g., is_pod, has_dot, and has_arrow).
decltype(T).has_member(Foo);
(Previously numbered ES041.)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.
(Previously numbered ES072.)A kind of typedef that introduces a real type. For example:
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; // ???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.
(Previously numbered ES038.)
References: N1526 (Benjamin Kosnik).Namespace aliasing issues (e.g., extending namespaces through namespace alias names).
(Previously numbered ES071.)
See also 31In other words, somehow combine a using directive with an #include. For example:
using ; // bring in the declarations from header "vector"or
using vector; // find "vector" and bring it inThis should probably be done with some protection against changes of the semantics of "vector" because of macros, etc.
(Previously numbered ES068.)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.
(Previously numbered ES037.)Provide a mechanism to define arrays whose elements are initialized with a nondefault constructor.
(Previously numbered ES048.)
instead of the currently-required:instead of the currently-required:auto_ptr< T> x = new T;
(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!(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!auto_ptr< T> x = auto_ptr< T>(new T);
allowingallowingstruct 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
instead of the awkward:instead of the awkward:X x = Y(Z);
[I know it doesn't generalize to multiple arguments][I know it doesn't generalize to multiple arguments]X x((Y(Z)));
(Previously numbered ES013.)
References: N1420.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.
(Previously numbered ES047.)The change
struct op { char op_name; op *left; op *right; };This struct is used to represent an expression tree. It is of course TOTALLY wrong. The correct representation is:
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; };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).
union X { string s; vector v; }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.
type 'a list = Empty | Cons of int * 'a listwhere 'a is a type variable. My representation is a tagged pointer:
struct X { int caseno; void *p; }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.
(Previously numbered ES022.)Provide a mechanism to prevent a class from being derived from, or a virtual function from being overridden.
(Previously numbered ES031.)
References: N1494 (Daniel Gutson).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.
(Previously numbered ES049.)
References: N1463 and N1529 (Julian Smith).Provide the ability to do a dynamic lookup on more than one operand. Frequent suggestion. Discussion in D&E.
(Previously numbered ES028.)Some operators are currently required to be class members (e.g., [], ()) but there may not be a good reason for such a constraint. If so, allow such operators to be declared in namespace scope.
(Previously numbered ES069.)
(Previously numbered ES019.)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:
void f(int); struct X { void operator()(double); }; X f; f(1); // call the function f(2.0); // call the object
(Previously numbered ES020.)It would be nice to be able to pass an overload set as a template argument.
(Previously numbered ES025.)Allow a user-defined operator.().
(Previously numbered ES010.)
Forwarded from LWG by Matt Austern.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.
(Previously numbered ES027.)Some compilers already support floating-point nontype template parameters.
(Previously numbered ES055.)Allow a namespace name to be passed as a namespace template argument (through a corresponding namespace template parameter).
(Previously numbered ES056.)Introduce the notion of parameterized namespaces.
(Previously numbered ES063.)Allow the keyword typename for any type name.
(Previously numbered ES070.)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.
(Previously numbered ES032.)Allow a finally clause for a try block.
(Previously numbered ES041.)Statically check throw specifications and assume that extern "C" implies "throw()". (Discussion on -ext. Or eliminate them altogether.)
(Previously numbered ES075.)A way to express the name of the enclosing function as a string.
(Previously numbered ES076.)
References: N1492 (Daniel Gutson).Provide a way to express that two classes cannot appear together in an inheritance graph.
(Previously numbered ES060.)Standardize the common practice of providing an operator that evaluates to the alignment multiple of a type (much like sizeof).
(Previously numbered ES033.)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.
(Previously numbered ES052.)Incorporate all or several C99 extensions.
(Previously numbered ES066.)For example, locks, threading, memory barrier, static local initialization. See OpenMP:.
(Previously numbered ES067.)
(Previously numbered ES073.)(No more details provided.)
(Previously numbered ES081.)This may and may not affect the way initializers and string literals are handled. See Kevlin Henney: If not, it is a pure library issue.
(Previously numbered ES082.)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".
(Previously numbered ES084.)
References: N1586 (Walter Brown).
See also 83Allow things like:
template<typename T> T const pi = (T)3.1;
(Previously numbered ES011.)Provide core language facilities, such as events, callbacks, and properties that make a good standard library GUI feasible.
(Previously numbered ES017, ES062.)It is often convenient to be able to write small "function objects" with expressions. For example:
std::for_each(a, b, $(int x) { ++x; })
(Previously numbered ES023.)The packaging of code in translation units combined with the access to interface information through #include directives is outdated and inefficient.
(Previously numbered ES024.)
References: N1600 (Daveed Vandevoorde), N1384 (John Wiegley).Provide Delphi/C#-like properties. It may be possible to provide properties as a standard-library facility.
Straw polls:
(Previously numbered ES046.)Allow functions to nest.
(Previously numbered ES057.)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.
(Previously numbered ES058.)Allow arrays of references.
(Previously numbered ES059.)Provide a mechanism to select the byte order for the members of a struct.
(Previously numbered EI001.)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 #include guards and conditional compilation control macros, have no generally acceptable alternatives. See also 13 and ES042FIXME.
(Previously numbered EI002.)
References: N1445.Too many simple things cannot be expressed simply and require error-prone workarounds. This discourages good style and complicates early teaching.
(Previously numbered EI003.)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.