Document number:   J16/04-0140 = WG21 N1700
Date:  9 September, 2004
Project:  Programming Language C++
Reference:  ISO/IEC IS 14882:2003(E)
Reply to:  Daveed Vandevoorde (daveed@edg.com)
 Bjarne Stroustrup (bs@cs.tamu.edu)
 Herb Sutter (hsutter@microsoft.com)


C++ Evolution Working Group -- Active Proposals, Revision 1b

Committee Version


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.

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

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

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

Section: dcl.dcl     Status: review     Submitter: Robert Klarer, John Maddock     Date: unknown     Priority: 1     Drafting: Robert Klarer

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

Daveed: Does this allow extern "C" static_assert(...);? It probably shouldn't.

Straw polls:

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






Issues with "Drafting" Status


24. Adding the long long type to C++

Section: 3.9  basic.types     Status: drafting     Submitter:     Date: unknown     Drafting: Adamczyk

(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: 19WY: 0WN: 0SN: 0




70. Extended friend declarations

Section: 7.1.4  dcl.friend     Status: drafting     Submitter: Mike Miller     Date: unknown     Drafting: Mike Miller

(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".
Clark N. prefers option 1 because he suspects the wording of option3 is not quite complete.

Straw polls:

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


Run-off of option 1 vs. option 3:
Favor option 1: 16
Favor option 3: 6
Direction for Mike M.: Pursue option 1.
John S. notes that this allows "friend;". (Mike will rework the wording to address this.)




Issues with "Open" Status


12. User-defined literals

Section: lex     Status: open     Submitter: Bjarne Stroustrup     Date: unknown     Priority: 1     Drafting: B. Stroustrup

(Previously numbered EP012, ES053.)

References: N1511.




5. Dynamic Libraries

Section: basic     Status: open     Submitter: various     Date: unknown     Priority: 1     Drafting: P. Becker

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


8. Null pointer constant

Section: expr     Status: open     Submitter: Herb Sutter, Bjarne Stroustrup     Date: unknown     Priority: 1     Drafting: H. Sutter, B. Stroustrup

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

In N1601:
2nd- and 3rd-to-last bullets on p. 2 to be dropped
. 3rd-to-last bullet on p. 3 to be dropped
.
Daveed's example:
  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
  }
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.

Lawrence Crowl: Prefers library solution.

Tom Plum: Arguments in favor of a core-language solution (among others, you're not limited to existing language semantics).

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.

John S.: Why does it need a type?

Dave A./ Daveed: Useful to be able to overload on it.

Clark N.: We should drop nullptr altogether.

Mike Miller: It should be a T* (select the (2) partial specialization).

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.

John S.: Example
  template<class T> void f(T, T);
  f("hello", nullptr);  // If nullptr is deducible, this is ambiguous
Core issue parallel: Overloaded function address is nondeducible (pending new core resolution).

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

Straw polls:

nullptr should not have a real type?
SY: 11WY:5WN: 3SN: 2
In favor of slimmed down proposal with a (nondeducible) unique/magical type?
SY: 15WY:4WN: 1SN: 0
Should we pursue nullptr at all?
SY: 11WY:7WN: 2SN: 2




82. Uniform function call syntax (part II)

Section: expr     Status: open     Submitter: Francis Glassborow     Date: unknown

References: N1585 (Francis Glassborow).

See also 57

Allow 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:

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




71. Constant inline functions

Section: 5.2.2  expr.call     Status: open     Submitter: Gabriel Dos Reis     Date: unknown     Priority: 1

(Previously numbered ES079.)

References: N1521.

Allow certain inline function calls in constant-expressions.


85. for each

Section: stmt.stmt     Status: open     Submitter: Tom Plum     Date: March 2004     Priority: 1

(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:

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




1. decltype and auto

Section: dcl.dcl     Status: open     Submitter: Bjarne Stroustrup     Date: unknown     Priority: 1     Drafting: J. Jarvi, B. Stroustrup

(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: Sydney 2004 discussion:

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.



The current proposal makes auto int x; invalid.

Daveed notes that a search for "auto double" on Google finds lots of code.

Straw polls:

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



The wording for decltype part of the proposal can be reviewed by EWG and forwarded to CWG.


36. Extend enum types

Section: 7.2  dcl.enum     Status: open     Submitter:     Date: unknown

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

References: N1579 (Herb Sutter).

Revise some limitations or undesirable properties of enum types.
N1579 addresses three basic issues: The syntax is the same as that chosen for Microsoft's C++/CLI extensions.
Discussion:
Floating-point enum constants are a bad idea because:
Walter Brown: Would have expected more features given that enum class suggests it's a sort of class (e.g., default constructors).
Daveed is strongly opposed to the syntax.
Clark Nelson: "enum namespace" better says it.
Francis G. also wants to be able to overload the assignment operator. Thinks specifying an underlying type may affect portablity.
Existing enums can also be extended in the following ways:
Allow forward enum declarations? Separable.
Mat Marcus: Is there a more general language mechanism (e.g. strong typedefs) within this?
Atilla F.: Desire to iterate over every enum constant. Compile-time checking of switches having _all_ the enumerator variants (and perhaps beyond switch).
Antonio B.: Strongly dislikes the syntax.
Francis G.: Can the underlying type be a typedef? Enumerating over enum constants must deal with having multiple constants of the same value.

Straw polls: Directions for semantics

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


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.
Further discussion about syntax:
Should there be a "bundling" of features in a single type kind?
Daveed: We should not create a new type kind. Use double braces for scoping, explicit for disabling implicit conversion and ": <type>" for the underlying type.
Requirement for backward compatibility is a given.

Straw polls: Directions for syntax

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




69. Nested namespace notation

Section: 7.3  basic.namespace     Status: open     Submitter: Jon Jagger     Date: unknown

(Previously numbered ES077.)

References: N1524 (Jon Jagger).

Allow a nested namespace be re-opened with the syntax
        namespace N:M { ... }



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

Section: 7.3  basic.namespace     Status: open     Submitter: Francis Glassborow     Date: March 2004     Priority: 1

References: N1602 (Francis Glassborow).

For example:
  struct B {
    f(int i);
  private:
    f();
  };
  struct D: B {
    using B::f; // Error today.  Allowed under proposal.
  };
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.

Straw polls:

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




7. Move Semantics

Section: dcl.decl     Status: open     Submitter: Howard Hinnant     Date: unknown     Priority: 1     Drafting: H. Hinnant, D. Abrahams

(Previously numbered EP007.)

References: N1377.




11. Generalized initializer lists

Section: 8.5  dcl.init     Status: open     Submitter: Bjarne Stroustrup     Date: unknown     Priority: 1     Drafting: G. dos Reis, B. Stroustrup

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


80. Regularizing initialization syntax

Section: 8.5  dcl.init     Status: open     Submitter: Francis Glassborow     Date: March 2004     Priority: 1

References: N1584 (Francis Glassborow).

See also 47

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

The following example would change meaning:
  struct X {
    explicit X(int){}
    X(short){}
  };
  X x1(3); // ambiguous
  X x2=3; // uses short constructor, since long constructor is explicit
Daveed: This is going to be tough sell. Lots of subtleties. We cannot move forward without substantial help from core experts.

Daveed: It's probably going to break auto_ptr.

Straw polls:

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




19. Forwarding constructors

Section: 12  special     Status: open     Submitter: (unknown)     Date: unknown

(Previously numbered ES008.)

Forwarded from LWG by Matt Austern.

References: N1581 (Herb Sutter).

See also 79

Make it possible to forward one overload of X::X to another overload. Discussion of Herb Sutter's paper N1581:

Mike Miller: What about Martin O'Riordan's view that there are philosophical problems with this, no matter the details of the semantics.

Daveed: It is strange that a normal converting constructor can delegate to an explicit converting constructor.

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.

Straw polls:

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




76. Explicit conversion functions

Section: 12  special     Status: open     Submitter:     Date: unknown     Priority: 1

(Previously numbered ES083.)

References: N1592 (Lois Goldthwaite).

To match explicit constructors.
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
Another example (from Lois G.):
  struct X {
    X(short);
    explicitly X(long);
  };
  X x1(42);       // Ambiguous
  X x2 = 42;      // X(short)
  X x3 = 42000L;  // X(short) !!
Explicit conversion functions would not be considered for UDC sequences.

Dave A. thinks this fills an important void, but he wants more: A "safe cast" (one that doesn't narrow). For example
  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.
"static_cast" (a library solution) allows conversions that are too dangerous.

Clark N.: Is an expression used in a boolean control context (if (x) ...) considered explicit?

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.

Straw polls:

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



Volunteers to work on further analysis: Walter Brown, Steve Adamczyk, Dave Abrahams.

Specific direction for analysis: General conversion issues.

[ From Dave Abrahams by e-mail:

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<T> is accepted, given a vector<complex<float> > v, people will be tempted to:
      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.

]


79. Inheriting constructors

Section: 12  special     Status: open     Submitter: Francis Glassborow     Date: March 2004     Priority: 1

References: N1583 (Francis Glassborow).

See also 19

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?

Daveed: Lots of subtleties make this a less cost-effective issue.

Jaakko J.: There may be an alternative feature ("forwarding", "delegating") that may cover the need.

Francis G.: This may help us get something close to a strong typedef.

Walter B.: This is really an instance of "the forwarding problem."

Straw polls:

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




2. Template aliases

Section: 14  temp     Status: open     Submitter: Gabriel dos Reis     Date: unknown     Priority: 1     Drafting: G. dos Reis, B. Stroustrup, M. Marcus

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


10. Concepts

Section: 14  temp     Status: open     Submitter: Bjarne Stroustrup, Gabriel dos Reis     Date: unknown     Priority: 1

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


17. Variadic template parameters

Section: 14  temp     Status: open     Submitter: J. Jarvi     Date: March 2004
A proposal for a new kind of template parameter that can be substituted by an arbitrary number of template arguments.

(Originally ES005.)

References: N1603.

Straw polls:

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




73. Partial specialization of function templates

Section: 14  temp     Status: open     Submitter:     Date: unknown     Priority: 1

(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:
"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)."



6. Allow local classes as template arguments

Section: 14.3.1  temp.arg.type     Status: open     Submitter: Anthony Williams     Date: unknown     Priority: 1     Drafting: Anthony Williams

(Previously numbered EP006.)

References: N1427.




4. extern template

Section: 14.7.2  temp.explicit     Status: open     Submitter: various     Date: unknown     Priority: 1     Drafting: M. Marcus, G. dos Reis

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


3. #scope/#endscope

Section: 16  cpp     Status: open     Submitter: Bjarne Stroustrup     Date: unknown     Priority: 1     Drafting: B. Stroustrup, T. Plum

(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:

Should the author pursue this general direction?
SY: 6WY: 3WN: 3SN: 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: 10WY: 4WN: 0SN: 1
Should this specific idea be developed in coordination with WG14?
SY: 10WY: 2WN: 2SN: 3
Should we work with WG14 to solve the macro problem (irrespective of the approach)?
SY: 13WY: 4WN: 0SN: 1




78. C99 Preprocessor

Section: 16  cpp     Status: open     Submitter: Clark Nelson     Date: March 2004     Priority: 1

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



26. Right angle brackets (>>)

Section:       Status: open     Submitter:     Date: unknown

(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
The problem is an immediate consequence of the the maximum munch principle and the fact that >> is a valid token (right shift) in C++.

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

Section:       Status: open     Submitter:     Date: unknown

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


23. Defaulting and inhibiting common operations

Section:       Status: open     Submitter: (unknown)     Date: unknown

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

Attila: It would be nice to also allow (syntax suggested by Francis G.)
  // Dot h
  struct S {
    S();
  };

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


"default:" section idea: Not viable because we might want to allow explicitly generated private/publis/protected members.

Daveed: What about "operator & "operator,", "operator.*",... in "explicit classes"? Are those also unavailable?

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

Straw polls:

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




83. Implicitly callable functions

Section:       Status: open     Submitter: Walter Brown     Date: March 2004     Priority: 1

References: N1611 (Walter Brown).

See also 77

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

Straw polls:

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




84. Design-by-Contract facilities

Section:       Status: open     Submitter: Thorsten Ottosen     Date: March 2004     Priority: 1

References: N1613 (Thorsten Ottosen).

Straw polls:

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






Issues with "Suggestion" Status


50. Opaque pointer-to-member

Section: basic     Status: suggestion     Submitter:     Date: unknown

(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:
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;
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?


29. restrict

Section: 3.10  basic.lval     Status: suggestion     Submitter:     Date: unknown

(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).


72. Simplify access through iterators

Section: expr     Status: suggestion     Submitter:     Date: unknown     Priority: 1

(Previously numbered ES080.)

From a programmer:
"I often have to write (*p)[i] and (*p)->m, that's ugly. Could we get operators to clear that up? For example p->[i] and p->->m."
Another idea is a postfix dereference operator. For example p*[i] and p*->m. This idea may relate to the common wish for more operators (to overload).


18. Overloadable new-style casts

Section: 5.2  expr.post     Status: suggestion     Submitter: (unknown)     Date: unknown

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


16. Solve the forwarding problem

Section: 5.2.2  expr.call     Status: suggestion     Submitter: (unknown)     Date: unknown

(Previously numbered ES002.)

Forwarded from LWG by Matt Austern.

See also 14

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


42. Allow switch on string

Section: stmt.stmt     Status: suggestion     Submitter: Daniel Gutson     Date: unknown

(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#.
From one of the many people who emailed Bjarne Stroustrup asking:
  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

Section: dcl.dcl     Status: suggestion     Submitter: (unknown)     Date: unknown

(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).
BS: This ought to relate to decltype (1). For example
        decltype(T).has_member(Foo);



43. Thread-local storage

Section: dcl.dcl     Status: suggestion     Submitter:     Date: unknown

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


65. Opaque typedefs

Section: 7.1.3  dcl.typedef     Status: suggestion     Submitter:     Date: unknown

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


41. Fix namespace aliases

Section: 7.3  basic.namespace     Status: suggestion     Submitter: Daniel Gutson     Date: unknown

(Previously numbered ES038.)

References: N1526 (Benjamin Kosnik).

Namespace aliasing issues (e.g., extending namespaces through namespace alias names).


64. Importing using-directives

Section: 7.3  basic.namespace     Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES071.)

See also 31

In 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 in
This should probably be done with some protection against changes of the semantics of "vector" because of macros, etc.


61. Unify default arguments and overloading

Section: 8.3.6  dcl.fct.default     Status: suggestion     Submitter:     Date: unknown

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


40. Nondefault array initialization

Section: 8.5  dcl.init     Status: suggestion     Submitter: Daniel Gutson     Date: unknown

(Previously numbered ES037.)

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


47. Tweak initialization semantics

Section: 8.5  dcl.init     Status: suggestion     Submitter: David Abrahams     Date: unknown

(Previously numbered ES048.)


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:
auto_ptr< T> x = new T;
instead of the currently-required:
auto_ptr< T> x = auto_ptr< T>(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!
This is also useful for cases like:
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
allowing
X x = Y(Z);
instead of the awkward:
X x((Y(Z)));
[I know it doesn't generalize to multiple arguments]
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?


23. Class namespaces

Section: class     Status: suggestion     Submitter: Carl Daniel     Date: unknown

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


46. Union generalization

Section: 9.5  class.union     Status: suggestion     Submitter: John Max Skaller     Date: unknown

(Previously numbered ES047.)

The change
-----------
1. Remove the restriction that unions may not contain members of a constructible type.
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.
[-----------
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.
---------]

The motivation
---------------
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.
There are two primary uses for unions.
(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.
(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.
The canonical example is the transacation, which includes the messages sent by windowing systems.
Unions provide two important features:
(a) they guarrantee enough storage is reserved for any one of the components
(b) they ensure that the storage is aligned correctly for any one of the components
They also provide a convenient notation to refer to the storage components.
Unions are not safe: the programmer may inadvertantly access a component for which a value has not been stored.
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.
However, in C++ there is an even stronger motivation: in C we are not concerned with execution of constructors and destructors.
In C++, use of an internal discriminant allows automatic copying and destruction of the correct union component.
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.
I can't emphasise how endemic this design fault is: it is used in text books. Here is a common example:
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).
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.
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.
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.
No code is broken by the proposal since it is a relaxation of a restriction.
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.
My personal need here is two-fold.
First, I am generating C++ code for a programming language which allows users to specify a new primitive type by nominating a C++ type.
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:
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.
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.
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:
type 'a list = Empty | Cons of int * 'a list
where '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.
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.
[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]



30. sealed/final

Section: 10  class.derived     Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES022.)

Provide a mechanism to prevent a class from being derived from, or a virtual function from being overridden.


37. Virtual overriding control

Section: 10  class.derived     Status: suggestion     Submitter: (unknown)     Date: unknown

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


48. Multimethods

Section: 10  class.derived     Status: suggestion     Submitter:     Date: unknown

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


35. Scope requirements on operators

Section: 12  special     Status: suggestion     Submitter:     Date: unknown

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


62. Allow "address of constructor"

Section: 12  special     Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES069.)




27. Overloading objects and functions

Section: 13  over     Status: suggestion     Submitter:     Date: unknown

(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




28. Overload sets as first-class entities

Section: 13  over     Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES020.)

It would be nice to be able to pass an overload set as a template argument.


33. operator.()

Section: 13  over     Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES025.)

Allow a user-defined operator.().


21. Named template parameters

Section: 14  temp     Status: suggestion     Submitter: (unknown)     Date: unknown

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


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

Section: 14  temp     Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES027.)

Some compilers already support floating-point nontype template parameters.


51. Namespace template arguments

Section: 14  temp     Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES055.)

Allow a namespace name to be passed as a namespace template argument (through a corresponding namespace template parameter).


52. Namespace templates

Section: 14  temp     Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES056.)

Introduce the notion of parameterized namespaces.


58. Relax typename constraints

Section: 14  temp     Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES063.)

Allow the keyword typename for any type name.


63. Relax template template parameter matching rules

Section: 14  temp     Status: suggestion     Submitter:     Date: unknown

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


38. finally

Section: 15  except     Status: suggestion     Submitter: (unknown)     Date: unknown

(Previously numbered ES032.)

Allow a finally clause for a try block.


44. Revise throw specifications

Section: 15  except     Status: suggestion     Submitter: Sean Parent     Date: unknown

(Previously numbered ES041.)

Statically check throw specifications and assume that extern "C" implies "throw()". (Discussion on -ext. Or eliminate them altogether.)


67. __func__

Section: 16  cpp     Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES075.)

A way to express the name of the enclosing function as a string.


68. Exclusive inheritance

Section: 16  cpp     Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES076.)

References: N1492 (Daniel Gutson).

Provide a way to express that two classes cannot appear together in an inheritance graph.


56. alignof

Section:       Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES060.)

Standardize the common practice of providing an operator that evaluates to the alignment multiple of a type (much like sizeof).
GNU version described in c++std-ext-4274. VC++ version described in c++std-ext-4276. Note by Atila Fehrer.


39. Optional garbage collection

Section:       Status: suggestion     Submitter: (unknown)     Date: unknown

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


49. C99 extensions

Section:       Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES052.)

Incorporate all or several C99 extensions.


59. Support parallel programming

Section:       Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES066.)

For example, locks, threading, memory barrier, static local initialization. See OpenMP: http://www.openmp.org.


60. Local templates

Section:       Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES067.)




66. Truly randon (crypto secure) numbers

Section:       Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES073.)

(No more details provided.)


74. A const string class

Section:       Status: suggestion     Submitter:     Date: unknown     Priority: 1

(Previously numbered ES081.)

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.


75. An arbitrary-precision integer class

Section:       Status: suggestion     Submitter:     Date: unknown     Priority: 1

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


77. Object templates

Section:       Status: suggestion     Submitter:     Date: unknown     Priority: 1

(Previously numbered ES084.)

References: N1586 (Walter Brown).

See also 83

Allow things like:
template<typename T> T const pi = (T)3.1;



22. GUI facilities

Section:       Status: suggestion     Submitter: (unknown)     Date: unknown

(Previously numbered ES011.)

Provide core language facilities, such as events, callbacks, and properties that make a good standard library GUI feasible.


25. Lambda functions

Section:       Status: suggestion     Submitter:     Date: unknown

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



31. Modules

Section:       Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES023.)

The packaging of code in translation units combined with the access to interface information through #include directives is outdated and inefficient.


32. Properties

Section:       Status: suggestion     Submitter:     Date: unknown

(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:

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




45. Nested functions

Section:       Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES046.)

Allow functions to nest.


53. Closures/Delegates

Section:       Status: suggestion     Submitter:     Date: unknown

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


54. Arrays of references

Section:       Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES058.)

Allow arrays of references.


55. Byte order control

Section:       Status: suggestion     Submitter:     Date: unknown

(Previously numbered ES059.)

Provide a mechanism to select the byte order for the members of a struct.




Issues with "Issue" Status


13. Macro pollution

Section: 16  cpp     Status: issue     Submitter: (unknown)     Date: unknown     Priority: 1

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


14. Simplify, generalize, and automate

Section:       Status: issue     Submitter: (unknown)     Date: unknown

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


15. GUI

Section:       Status: issue     Submitter: (unknown)     Date: unknown

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