Doc. no. N3736
Date: 2013-08-27
Project: Programming Language C++
Reply to: Ville Voutilainen <ville.voutilainen@gmail.com>

C++ Standard Evolution Active Issues List (Revision R03)

Revised 2013-08-27 at 16:08:33 UTC

Reference ISO/IEC IS 14882:2003(E)

Also see:

The purpose of this document is to record the status of issues which have come before the Evolution Working Group (EWG) of the INCITS PL22.16 and ISO WG21 C++ Standards Committee. Issues represent potential defects in the ISO/IEC IS 14882:2003(E) document, and proposed extensions to it.

This document contains only evolution issues which are actively being considered by the Evolution Working Group, i.e., issues which have a status of New, Open, Ready, or Review. See Evolution Completed Issues List for issues considered completed (adopted) and Evolution Closed Issues List for issues considered closed (rejected).

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

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

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

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

How to submit an issue

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

Revision History

Issue Status

New - The issue has not yet been reviewed by the EWG. Any Wording available is purely a suggestion from the issue submitter, and should not be construed as the view of EWG.

Open - The EWG has discussed the issue but is not yet ready to move the issue forward. There are several possible reasons for open status:

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

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

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

Dup - The EWG has reached consensus that the issue is a duplicate of another issue, and will not be further dealt with. A Rationale identifies the duplicated issue's issue number.

NAD - The EWG has reached consensus that the issue is not a defect in the Standard nor is it an extension the EWG deems acceptable.

Review - Exact resolution is now available for review on an issue for which the EWG previously reached informal consensus.

Ready - The EWG has reached consensus that the issue is an extension that can go forward to Core, Library, or a Study Group for further processing.

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

DR - (Defect Report) - It's not expected that the EWG would handle Defect Reports.

WP - (Working Paper) - The proposed resolution has not been accepted as a Technical Corrigendum, but the full WG21/PL22.16 committee has voted to apply the issue's resolution to the working paper.

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

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

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

Active Issues

2. N3387 Overload resolution tiebreakers for integer types

Section: 4.13 [conv.rank] Status: New Submitter: Jens Maurer Opened: 2012-09-12 Last modified: 2013-04-30

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3387.html

Wording available:

The paper contains the proposed wording.

3. N3394 [[deprecated]] attribute

Section: 7.6 [dcl.attr] Status: Ready Submitter: Alberto Ganesh Barbati Opened: 2012-06-12 Last modified: 2013-04-30

View all issues with Ready status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html

Reviewed by EWG in Portland 2012, proceeding to CWG.

Wording available:

The paper contains the proposed wording.

4. N3396 Dynamic memory allocation for over-aligned data

Section: 18.6 [support.dynamic] Status: Open Submitter: Clark Nelson Opened: 2012-08-30 Last modified: 2013-04-30

View all issues with Open status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm

Reviewed by EWG in Portland, author encouraged to revise.

Wording available:

The paper contains the proposed wording that is to be revised.

5. N3400 A proposal for eliminating the underscore madness that library writers have to suffer

Section: 16.3 [cpp.replace] Status: New Submitter: Jonathan de Boyne Pollard Opened: 2012-09-21 Last modified: 2013-04-30

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3400.html

Wording available:

The paper contains the proposed wording.

8. N3492, N3403 Use Cases for Compile-Time Reflection

Section: 18 [language.support] Status: New Submitter: Mike Spertus Opened: 2012-09-22 Last modified: 2013-04-30

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3403.pdf

http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3492.pdf

Not reviewed by EWG yet, to be handled by the Reflection Study Group (SG7).

9. N3601 Implicit template parameters, N3405 Template Tidbits

Section: 14 [temp] Status: Open Submitter: Mike Spertus Opened: 2012-09-22 Last modified: 2013-04-30

View all issues with Open status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3405.html

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3601.html

EWG review started, not completed yet. Likely needs a follow-up paper.

Bristol 2013: Encouraged to pursue further. Template parameter deduction for constructors has been split into EWG Issue 60.

10. N3407 Proposal to Add Decimal Floating Point Support to C++

Section: 17 [library] Status: New Submitter: Dietmar Kühl Opened: 2012-09-14 Last modified: 2013-04-30

View all other issues in [library].

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html

Handled by the Numerics Study Group (SG5).

11. N3409 Strict Fork-Join Parallelism

Section: 1.10 [intro.multithread] Status: New Submitter: Pablo Halpern Opened: 2012-09-24 Last modified: 2013-04-30

View other active issues in [intro.multithread].

View all other issues in [intro.multithread].

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3409.pdf

Handled by the Concurrency Study Group (SG1)

12. N3410 Rich Pointers with Dynamic and Static Introspection

Section: 20.9 [meta] Status: New Submitter: Dean Michael Berris Opened: 2012-09-18 Last modified: 2013-04-30

View other active issues in [meta].

View all other issues in [meta].

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3410.pdf

To be handled by the Reflection Study Group (SG7).

14. N3413 Allowing arbitrary literal types for non-type template parameters

Section: 14.1 [temp.param] Status: Open Submitter: Jens Maurer Opened: 2012-09-19 Last modified: 2013-04-30

View other active issues in [temp.param].

View all other issues in [temp.param].

View all issues with Open status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html

Bristol 2013: Maurer expressed surprise at the paper being under discussion, and explained that he doesn't think it can be made to work under current linker environments, and further explained that user-defined equality operators cause confusion and surprises. Maurer said that he'd want Stroustrup to clarify which parts of the paper he would want.

Two-way Straw polls:

Rules for agument expressions:

F: 5 A: 0

Structs without operator==

F: 0 A: 0

Structs with operator==

F: 1 A: 3

The issue is not pushed at this time.

Wording available:

The paper contains the proposed wording.

15. N3416 Packaging Parameter Packs

Section: 14.1 [temp.param] Status: New Submitter: Mike Spertus Opened: 2012-09-21 Last modified: 2013-04-30

View other active issues in [temp.param].

View all other issues in [temp.param].

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3416.html

17. N3419 Vector loops and Parallel Loops

Section: 1.10 [intro.multithread] Status: New Submitter: Robert Geva Opened: 2012-09-21 Last modified: 2013-04-30

View other active issues in [intro.multithread].

View all other issues in [intro.multithread].

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3419.pdf

Handled by the Concurrency Study Group (SG1).

18. N3424 Lambda Correctness and Usability Issues

Section: 5.1.2 [expr.prim.lambda] Status: Open Submitter: Herb Sutter Opened: 2012-09-23 Last modified: 2013-04-30

View all other issues in [expr.prim.lambda].

View all issues with Open status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3424.pdf

Reviewed by EWG in Portland 2012, proceeding with a follow-up paper. Changes to const captures rejected, capturing of 'this' and members encouraged to continue with a follow-up paper.

19. N3429 A C++ Library Solution To Parallelism

Section: 30 [thread] Status: New Submitter: Artur Laksberg Opened: 2012-09-21 Last modified: 2013-04-30

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3429.pdf

Handled by the Concurrency Study Group (SG1).

Wording available:

The paper contains the proposed wording.

20. N3536, N3432 C++ Sized Deallocation

Section: 3.7.4 [basic.stc.dynamic] Status: Ready Submitter: Lawrence Crowl Opened: 2012-09-23 Last modified: 2013-04-30

View other active issues in [basic.stc.dynamic].

View all other issues in [basic.stc.dynamic].

View all issues with Ready status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3536.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3432.html

Reviewed by EWG in Portland 2012, proceeding to CWG.

Wording available:

The paper contains the proposed wording.

21. N3433 Clarifying Memory Allocation

Section: 3.7.4 [basic.stc.dynamic] Status: Open Submitter: Lawrence Crowl Opened: 2012-09-23 Last modified: 2013-04-30

View other active issues in [basic.stc.dynamic].

View all other issues in [basic.stc.dynamic].

View all issues with Open status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3433.html

Reviewed by EWG in Portland 2012, proceeding with a follow-up paper.

Wording available:

The paper contains the proposed wording.

22. N3435 Standardized feature-test macros

Section: 18.1 [support.general] Status: Open Submitter: Clark Nelson Opened: 2012-09-18 Last modified: 2013-04-30

View other active issues in [support.general].

View all other issues in [support.general].

View all issues with Open status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3435.htm

Reviewed by EWG in Portland 2012, proceeding in SG10, Feature Test.

23. N3437 Type Name Strings For C++

Section: 20.9 [meta] Status: New Submitter: Axel Naumann Opened: 2012-09-24 Last modified: 2013-04-30

View other active issues in [meta].

View all other issues in [meta].

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3437.pdf

Not reviewed by EWG yet, to be handled by the Reflection Study Group (SG7).

24. N3441 Call Stack Utilities and std::exception Extension Proposal

Section: 18.8 [support.exception] Status: New Submitter: Aurelian Melinte Opened: 2012-09-20 Last modified: 2013-04-30

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3441.html

26. N3538, N3445 Pass by Const Reference or Value

Section: 8.3.5 [dcl.fct] Status: New Submitter: Lawrence Crowl Opened: 2012-09-23 Last modified: 2013-04-30

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3445.html

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3538.html

27. N3661, N3499 Digit Separators, N3448 Painless Digit Separation

Section: 2.10 [lex.ppnumber] Status: Open Submitter: Daveed Vandevoorde Opened: 2012-09-21 Last modified: 2013-08-27

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3499.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3448.pdf

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3661.html

Reviewed by EWG in Portland 2012, proceeding with a follow-up paper.

Bristol 2013:

Straw poll:

Double radix point as the suffix disambiguator:

SF: 8 F: 5 N: 0 A: 0 SA: 0

Convey to Core, target C++14:

SF: 10 F: 3 N: 0 A: 0 SA: 0

The paper was not adopted in Bristol, because its motion didn't pass.

Wording available:

The paper contains the proposed wording.

28. N3449 Open and Efficient Type Switch for C++

Section: 5.2.7 [expr.dynamic.cast] Status: New Submitter: Bjarne Stroustrup Opened: 2012-09-23 Last modified: 2013-04-30

View all issues with New status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdf

29. N3329 Proposal: static if declaration

Section: 20.9 [meta] Status: Open Submitter: Herb Sutter Opened: 2012-01-10 Last modified: 2013-04-30

View other active issues in [meta].

View all other issues in [meta].

View all issues with Open status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf

Reviewed by EWG in Portland 2012, to be handled by the Concepts Study Group (SG8).

30. [tiny] Efficient/Flexible Access to Argument Packs

Section: 14.5.3 [temp.variadic] Status: Open Submitter: Dave Abrahams Opened: 2012-10-16 Last modified: 2013-04-30

View all issues with Open status.

Discussion:

There are lots of very basic manipulations that are either really hard or impossible to do with argument packs unless you use something that causes a big recursive template instantiation, which is expensive at compile-time and can cause bad error messages. I want to be able to index argument packs with integral constant expressions, "take" or "drop" the first N elements of the pack, etc.

In Bristol 2013: N3493 may solve parts of the problem. The submitter is encouraged to write a paper, and practical examples are desirable.

32. [tiny] Templated constructor accidentally preferred over copy constructor

Section: 13 [over] Status: Open Submitter: Nevin Liber Opened: 2012-10-19 Last modified: 2013-04-30

View all issues with Open status.

Discussion:


struct Silly
{
    template<class... Ts>
    Silly(Ts&&...)
    {}
};

int main()
{
    Silly s;
    Silly t(s);	// Silly::Silly(Ts &&...) [Ts = <Silly &>]
    const Silly u;
    Silly v(u); // calls Silly::Silly(Silly const&)
}
The problem is that users expect the copy constructor to be called in both situations. Note: you do not need variadics for this; it made the example smaller. Also, this issue existed in C++03, but rarely happened in practice because templated parameters were usually declared const T&.

Bristol 2013: Sutton and Gregor proposed various work-arounds, like additional overloads and constraints. Stroustrup asked whether having a copying template have different semantics from a copy constructor isn't an error, and Gregor explained that tuples run into that issue and they have different semantics for the template. The submitter is encouraged to write a paper, and practical examples are desirable.

33. [tiny] contextual bool conversion from scoped enum

Section: 7.2 [dcl.enum] Status: Open Submitter: Jeffrey Yasskin Opened: 2012-10-20 Last modified: 2013-04-30

View all issues with Open status.

Discussion:

In Beman's filesystem code, I found the following problem, which he didn't see because he's been building with MSVC 10: A scoped enum defined at

https://github.com/Beman/filesystem-proposal/blob/master/include/boost/filesystem/operations.hpp#L230

is used like

if (opts & copy_options::skip_existing) ++ct;

at

https://github.com/Beman/filesystem-proposal/blob/master/src/operations.cpp#L773.

This causes an error like:

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

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

Bristol 2013: Stroustrup pointed out that the existing behavior is deliberately trying to avoid supporting anything like this, in order to play safe. He further explained that allowing member functions for scoped enums has been attempted but the attempts failed. Gregor pointed out that not all scoped enums have a zero value, so doing it generally is hard. Stroustrup said he would want to have member functions for enums. Yasskin said he's not interested in writing a paper. Other people are invited to do so.

34. [tiny] Defining hash functions for composite user-defined types is annoying

Section: 17.6.3.4 [hash.requirements] Status: Open Submitter: Matt Austern Opened: 2012-10-23 Last modified: 2013-04-30

View all issues with Open status.

Discussion:

We have a hash function for built-in types and for some standard library types, but we don't have automatically generated hash<> specializations for user-defined types like 

  struct my_type {
    int x;
    std::string y;
    vector<int> z;
  };
Defining a good and efficient hash function for composite types takes a fair amount of work. One consequence is that there are a lot of user-defined types with bad hash functions floating around. One possibility is automatically generating hash<> specializations, but that's tricky. A simpler possibility is providing tools that make it easier for users to do the right thing.

Bristol 2013: Austern explained that he didn't envision syntax to automate the generation of hash operations but thought that this could potentially be solved by a library. Stroustrup and Austern thought that reflection would be another way to solve this. Van Winkel thought that for the generation of such things, it's perhaps desirable that they aren't generated by default but can be generated on demand when a user-defined type requests such generation. The guidance of the EWG is to propose a solution that handles equality operators and other such things in a more general manner.

35. [tiny] Some concise way to generate a unique, unused variable name

Section: 3.4 [basic.lookup] Status: Open Submitter: Jeffrey Yasskin Opened: 2012-10-24 Last modified: 2013-04-30

View all issues with Open status.

Discussion:

Sometimes we want to define a variable that's unused except for its constructor and destructor. lock_guard<mutex> and ScopeGuard are decent examples of this. In C++11, we have to manually name the variable something unique. Sometimes we use _some_name_##__LINE__ (suitably wrapped so the concatenation happens after expanding __LINE__) to try to generate unique names automatically, and gcc/clang have an extension _some_name_##__COUNTER__

http://gcc.gnu.org/onlinedocs/gcc-4.7.2/cpp/Common-Predefined-Macros.html

to allow multiple such variables on the same line. These are pretty verbose and not convenient for casual use. Haskell allows _ (underscore) to stand in for a variable that's not going to be used. Googlemock defines testing::_ to mean "don't care" as an argument, which is similar but not identical.

Bristol 2013: Stroustrup wondered how unique the name needs to be, and wondered whether parallel builds would have problems ensuring the uniqueness. Naumann pointed out that having an unnamed variable is useful also for cases where you don't want the variable's address to be taken etc. Stroustrup and Van Winkel said this is not tiny, and a proper paper is necessary for this issue.

40. [tiny] Relax the allocator requirements on vector so that the small object optimization is allowed

Section: 23.3.6 [vector] Status: Ready Submitter: Nevin Liber Opened: 2012-11-27 Last modified: 2013-04-30

View all issues with Ready status.

Discussion:

I'd like it to be possible to use the small object optimization (embedding up to a fixed number of objects inside the allocator itself) inside a vector.

Bristol 2013: Designated for LEWG.

41. [tiny] In-class explicit specializations forbidden but not partial specializations

Section: 14.7.3 [temp.expl.spec] Status: Ready Submitter: Faisal Vali Opened: 2012-10-27 Last modified: 2013-04-30

View other active issues in [temp.expl.spec].

View all other issues in [temp.expl.spec].

View all issues with Ready status.

Discussion:

I had submitted a DR (727) about this in October 2008 - and it was classified as an extension - I wonder if Spertus' DR (1077) that was also classified as an extension should be considered along with this one. 14.7.3 [temp.expl.spec] paragraph 2 requires that explicit specializations of member templates be declared in namespace scope, not in the class definition. This restriction does not apply to partial specializations of member templates; that is, 

    struct A {
      template<class T> struct B;
      template <class T> struct B<T*> { }; // well-formed
      template <> struct B<int*> { }; // ill-formed
    };
There does not seem to be a good reason for this inconsistency.

Bristol 2013: Defer to Core, with the guidance to reopen the DR mentioned and remove the restriction.

42. [tiny] basic_string(const charT*, size_type, const Allocator&) requires clause too restrictive

Section: 21.4.2 [string.cons] Status: Ready Submitter: Nevin Liber Opened: 2012-12-19 Last modified: 2013-04-30

View all issues with Ready status.

Discussion:

In n3485 21.4.2p6 (basic_string constructors and assignment operators), we have: 

  basic_string(const charT* s, size_type n,
  const Allocator& a = Allocator());
  Requires: s shall not be a null pointer and n < npos.
That requires clause is too restrictive; s can be a null pointer when n==0. A (simplified) use case I have seen: 
  std::string StringFromVector(std::vector<char> const& vc)
  { return std::string(vc.data(), vc.size()); }
Since a conforming implementation can return a null pointer for vc.data() when vc.size() == 0. I don't see any reason to disallow this construct, especially since it takes a Standards expert to see that this is possibly illegal, but not std::string(vc.data(), vc.data() + vc.size()).

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

Bristol 2013: Defer to LEWG.

Wording available:

  Requires: n < npos and either s shall not be a null pointer or n == 0.

43. [tiny] simultaneous iteration with new-style for syntax

Section: 6.5.4 [stmt.ranged] Status: Open Submitter: Gabriel Dos Reis Opened: 2013-01-12 Last modified: 2013-04-30

View all issues with Open status.

Discussion:

The new-style 'for' syntax allows us to dispense with administrative iterator declarations when iterating over a single seuqence. The burden and noise remain, however, when iterating over two or more sequences simultaenously. We should extend the syntax to allow that. E.g. one should be able to write: 

    for (auto& x : v; auto& y : w)
       a = combine(v, w, a);
instead of the noisier 
    auto p1 = v.begin();
    auto q1 = v.end();
    auto p2 = w.begin();
    auto q2 = w.end();
    while (p1 < q1 and p2 < q2) {
       a = combine(*p1, *p2, a);
       ++p1;
       ++p2;
    }

Bristol 2013: Submitter is encouraged to write a paper.

44. [tiny] variadic bind

Section: 20.8.9 [bind] Status: Ready Submitter: Chris Jefferson Opened: 2013-01-25 Last modified: 2013-04-30

View all issues with Ready status.

Discussion:

As more variadic functions work their way into my C++ code, I'm getting increasingly annoyed that there isn't a variadic bind. There is a tiny bit of annoyance on exactly what to use. There seems to me to be 2 sensible choices (other people may have others) 

  1) _args : Use all otherwise unnamed arguments.
  2) _3onwards : All arguments from the 3rd onwards.
I haven't personally found a need for multiple ranges of variadic arguments, or more complicated chopping (such as getting the last few arguments), and I'd want to hopefully keep this simple if possible!

Bristol 2013: Defer to LEWG.

45. [tiny] Type Trait is_range<T>

Section: 20.9.4.3 [meta.unary.prop] Status: Ready Submitter: Nevin Liber Opened: 2013-02-05 Last modified: 2013-04-30

View other active issues in [meta.unary.prop].

View all other issues in [meta.unary.prop].

View all issues with Ready status.

Discussion:

I'd like to have an is_range<T, R = void> type trait, which derives from true_type if and only if T can be used in range-based for, and *__begin is convertible to R (where R == void means don't bother checking this condition).

Bristol 2013: Submitter is encouraged to proceed and present to LWG. Apparently LEWG doesn't handle these.

46. [tiny] Type Trait is_final<T>

Section: 20.9.4.3 [meta.unary.prop] Status: Ready Submitter: Nevin Liber Opened: 2013-02-05 Last modified: 2013-04-30

View other active issues in [meta.unary.prop].

View all other issues in [meta.unary.prop].

View all issues with Ready status.

Discussion:

I'd like to have an is_final<T> type trait, which is true if and only if T is a final type.

Bristol 2013: Submitter is encouraged to proceed and present to LWG. Apparently LEWG doesn't handle these.

48. [tiny] Specializing templates in different namespaces

Section: 14.7.3 [temp.expl.spec] Status: Open Submitter: Mike Spertus Opened: 2013-03-06 Last modified: 2013-04-30

View other active issues in [temp.expl.spec].

View all other issues in [temp.expl.spec].

View all issues with Open status.

Discussion:

This is a proposal to allow specializing templates from within a different namespace. The motivation is that when we declare a new class, it is natural to want to provide associated template specializations. For example, it is really painful that whenever I declare a class, I need to leave my namespace and enter namespace std just to specialize std::less as shown below 

  namespace A {
    namespace B {
      class C {...};
    }
  }

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

  namespace A {
    namespace B {
      ... // Continue working in A::B
    }
  }
Instead, I should be able to specialize std::less without having to break out of my namespace: 
 
  namespace A {
    namespace B {
      class C {...};
      template <>
      struct ::std::less<C> : binary_function <C, C, bool> {
        bool operator() (const C & x, const C & y) const {...}
      };
    ... // Continue working in A::B
    }
  }

Bristol 2013: Stroustrup expressed concern about unqualified name lookup in the specializations, and Voutilainen thought that that just might be the reason why the current rules don't allow it. Gottschling voiced concern about the implementation impact, and Voutilainen suggested asking for a quick review of the overall idea from Spicer. Austern thought that this could be palatable if it's expressed as a set of rewrite rules. Spertus asked about an alternative which is to be able to open another namespace without having to exit the current namespace. This alternative didn't gain success. Spertus to write a paper.

49. N3463 Portable Program Source Files

Section: 2.2 [lex.phases] Status: New Submitter: Beman Dawes Opened: 2012-11-02 Last modified: 2013-04-30

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3463.html

50. N3466 More Perfect Forwarding

Section: 18.1 [support.general] Status: New Submitter: Mike Spertus Opened: 2012-11-03 Last modified: 2013-04-30

View other active issues in [support.general].

View all other issues in [support.general].

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3466.html

51. N3490 ADL Control for C++

Section: 3.4.2 [basic.lookup.argdep] Status: New Submitter: Dave Abrahams Opened: 2012-10-31 Last modified: 2013-04-30

View other active issues in [basic.lookup.argdep].

View all other issues in [basic.lookup.argdep].

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3490.html

52. N3515 Toward Opaque Typedefs for C++1Y

Section: 7.1.3 [dcl.typedef] Status: New Submitter: Walter Brown Opened: 2013-01-11 Last modified: 2013-04-30

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3515.pdf

56. N3583 Exploring constexpr at Runtime

Section: 5.19 [expr.const] Status: Open Submitter: Scott Schurr Opened: 2013-03-13 Last modified: 2013-04-30

View all other issues in [expr.const].

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3583.pdf

Bristol 2013: We won't move forward with this at this time, but we might want to see a followup paper focusing on the trait.

57. N3587 For Loop Exit Strategies

Section: 6.5 [stmt.iter] Status: Open Submitter: Alan Talbot Opened: 2013-03-17 Last modified: 2013-04-30

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3587.pdf

Bristol 2013: Van Winkel pointed out that this allows jumping out of nested loops. Naumann expressed doubt over whether the problem is so big that we need such a big extension to solve it. Van Winkel and Spertus thought that this would likely be a popular feature. Voutilainen thought that it would be beneficial to revisit a lambda solution. Talbot expressed doubt whether that's a suitable solution, syntax-wise and performance-wise. Austern thought that this seems to be in flux, and thought we aren't necessarily ready to choose between the various options. Gottschling thought Vandevoorde's option is nice, since it's still structured. Spertus said he likes the idea of having a control structure be an expression. Austern recommended looking closely at Clause 5 in the follow-up paper.

The author is encouraged to write a follow-up paper.

58. N3595 Simplifying Argument-Dependent Lookup Rules

Section: 3.4.2 [basic.lookup.argdep] Status: Open Submitter: Peter Gottschling Opened: 2013-03-15 Last modified: 2013-04-30

View other active issues in [basic.lookup.argdep].

View all other issues in [basic.lookup.argdep].

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3595.pdf

Bristol 2013: Looked at briefly, the EWG thinks this should be considered alongside other ADL proposals.

59. N3596 Code Reuse in Class Template Specialization

Section: 3.4.2 [basic.lookup.argdep] Status: New Submitter: Peter Gottschling Opened: 2013-03-15 Last modified: 2013-04-30

View other active issues in [basic.lookup.argdep].

View all other issues in [basic.lookup.argdep].

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3596.pdf

60. N3602 Template parameter deduction for constructors

Section: 14.8.2 [temp.deduct] Status: Open Submitter: Mike Spertus Opened: 2013-03-14 Last modified: 2013-04-30

View all issues with Open status.

Discussion:

This issue is split from EWG Issue 9.

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html

Bristol 2013: Reviewed and accepted by EWG, needs redrafting before ready for core.

63. N3614 unwinding_exception

Section: 15.5 [except.special] Status: Open Submitter: Herb Sutter Opened: 2013-03-11 Last modified: 2013-04-30

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3614.pdf

Bristol 2013: Voutilainen pointed out that there are previous proposals on similar facilities (http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2952.html), and that there's existing practice that is different from this proposal (existing practice returns an int, not a bool). Stroustrup thought that he would need convincing examples about the int, and thought that the facility in general needs better motivation. Voutilainen said that it would be best to create a revisions/synthesis paper that covers the existing practice and the previous proposals and improves the motivational examples.

Author is encouraged to revise.

65. N3617 Lifting overload sets into function objects

Section: 20.8.2 [func.require] Status: New Submitter: Philipp Juschka Opened: 2013-03-14 Last modified: 2013-04-30

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3617.htm

66. N3599 Literal operator templates for strings

Section: 2.14.8 [lex.ext] Status: Open Submitter: Richard Smith Opened: 2013-03-13 Last modified: 2013-04-30

View all issues with Open status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3599.html

Bristol 2013:

Straw Poll: Adopt N3599, send to core: SF:2 WF:1 N:6 WA:4 SA:1

No consensus for moving forward as is.

Straw Poll: Revise with additional machinery for compile time string processing

SF: 10 WF: 2 N: 0 WA: 0 SA: 0

Encouragement for Smith and Vandevoorde to revise.

67. [tiny] Unspecialized std::tuple_size should be defined

Section: 20.4.1 [tuple.general] Status: New Submitter: Nevin Liber Opened: 2013-03-19 Last modified: 2013-08-26

View all issues with New status.

Discussion:

In 20.4.1p2, the unspecialized std::tuple_size is undefined. It would be a lot more useful if it were defined as an empty struct; that way, it can be used with enable_if for determining whether or not it is valid to use tuple_size, tuple_element and get on the corresponding data structure.

68. [tiny] C++ DR about global placement array new

Section: 5.3.4 [expr.new] Status: New Submitter: Thomas Koeppke Opened: 2013-04-22 Last modified: 2013-08-26

View all issues with New status.

Discussion:

Basically, I would like to file a Defect Report: The global array placement new, as described in C++11, 5.3.4/10-12, is unusable. The reason for this is that the standard allows the operator to consume an arbitrary amount of memory, which is impossible for the user to learn, and thus impossible to provide. The fix is to remove the ability for placement-new to require more size than required for the array itself to the allocation function.

Current wording, in 5.3.4/12 says: 

    new(2,f) T[5] results in a call of operator new[](sizeof(T)*5+y,2,f)
Here, x and y are non-negative unspecified values representing array allocation overhead; the result of the new-expression will be offset by this amount from the value returned by operator new[].

Unfortunately, the presence of "y" means that it is impossible to pass a usable address to placement-array-new: 

    void * addr = std::malloc(?);
    new (addr) T[10];

In the above, it is impossible to know the required argument for malloc, since the placement-new can ask for sizeof(T) * 10 + y bytes for any y.

The fix would be to remove the possiblity of placement-new requiring more memory for arrays, i.e. insert into 5.3.4/10 something like: 

    A new-expression passes the amount of space requested to the allocation 
    function as the first argument of type std::size_t. That argument shall 
    be no less than the size of the object being created; it may be greater 
    than the size of the object being created only if the object is an array 
    and the new-expression is a default new-expression.

What do you think? I don't think the change could break anything, since nothing could be using placement-array-new at the moment, and it makes sense that a placement version doesn't require extra space, since the caller already knows the array size and has to perform destruction manually anyway.

Mike Miller points out the following:

You're not the first one to notice a problem with this; see

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#476

To summarize, CWG agreed that that's a problem but felt that the resolution was more appropriately handled in EWG, since it requires evaluations of the tradeoffs of various possible options to address it. Your approach, for example, focuses on the placement operator new provided by the library, which simply runs the constructor(s) on a previously-allocated buffer. However, that's not the only use of the placement new syntax, which can pass arbitrary arguments to allocation functions that actually do allocate memory, and it's not clear that none of those will need to add padding similar to the way the standard allocation function does.

69. [tiny] Returning a void expression from a constructor or destructor

Section: 6.6.3 [stmt.return] Status: New Submitter: Richard Smith Opened: 2013-07-02 Last modified: 2013-08-26

View all issues with New status.

Discussion:

A thread on std-discussion[1] has highlighted that 

  return E;

where E has type void is valid in a function with a return type of 'void' but not valid in a constructor or destructor. There is implementation variance here, and we have examples of code which very reasonably wants to use "return E;" in a constructor, from within the expansion of a macro, and fails on some compilers due to this rule. The inconsistency between "return;" and "return void();" seems extremely jarring here, and I'd like to propose that we treat this as a defect.

(I'm not suggesting that we treat constructors and destructors as having a return type of 'void', as was suggested on the thread on std-discussion, but I'm not opposed to it.)

[1] https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/ehqGBMsswjk

70. [tiny] Const in expressions

Section: 5.2 [expr.post] Status: New Submitter: Herb Sutter Opened: 2013-06-06 Last modified: 2013-08-27

View all issues with New status.

Discussion:

Example: 

#include <string>
using namespace std;
int main() {
 const string{ "Hello" };                   // 1: error
 "xyzzy" + const string{"Hello"};           // 2: error
 typedef const string const_string;
 const_string{"Hello"};                     // 3: ok
 "xyzzy" + const_string{"Hello"};           // 4: ok
 unsigned long{0};                          // 5: error
 42ul + unsigned long{0};                   // 6: error

 typedef unsigned long unsigned_long;
 unsigned_long{0};                          // 7: ok
 42ul + unsigned_long{0};                   // 8: ok

}
Sutter says:

The issue is "lines 1 to 8 below should all work." That they don't is just because of the reason Nikolay pointed out using line 1 below as an example:

> The error is purely syntactic: 'const string' is not a simple-type-specifier

Richard Smith points out the following:

I can't comment on what was noticed in the abstract, but I was certainly aware of all the above cases. And the rules make sense to me: function-style casts are supposed to be function-style, and the above error cases doesn't look like a function call (and not just because you've put the paren next to the type in the function-call-like cases, and added an extra space in the other cases!).

I'm not sure exactly what rules you're proposing, but I hope we don't make this valid: 

  struct A { int n; }; // ok, struct definition
  struct A { 0 }; // might now be an expression?

Regarding using a parenthesized type as a work-around, Sutter explained:

I think it needs to be an open EWG issue after all, because as Johannes pointed out the workaround doesn't work because it can't call multi-argument constructors, such as that 

    (const vector<int>)( 1, 2  )
drops the 1 on the floor and creates a vector containing two zeroes. And that it doesn't work for list initializations, such as that 
    (unsigned int){ 1, 2, 3, 4 }   // C compound literal(?!)
doesn't work.

71. N3626 Relaxed switch statement

Section: 6.4.2 [stmt.switch] Status: New Submitter: Zhihao Yuan Opened: 2013-02-02 Last modified: 2013-08-27

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3626.pdf

72. N3635 Towards restrict-like semantics for C++

Section: 8.3.1 [dcl.ptr] Status: New Submitter: M. Wong, R. Silvera, R. Mak, C. Cambly, et al. Opened: 2013-04-29 Last modified: 2013-08-27

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3635.pdf

See also issue 26.

73. N3681 Auto and braced-init lists

Section: 7.1.6.4 [dcl.spec.auto] Status: New Submitter: Ville Voutilainen Opened: 2013-05-02 Last modified: 2013-08-27

View all other issues in [dcl.spec.auto].

View all issues with New status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html