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

Revised 2013-03-12 at 15:03:58 UTC

Reference ISO/IEC IS 14882:2003(E)

Also see:

• Table of Contents for all evolution issues.
• Index by Section for all evolution issues.
• Index by Status for all evolution issues.
• Evolution Defect Reports List
• Evolution Closed Issues List

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.

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 Defect Reports List for issues considered defects and Evolution Closed Issues List for issues considered closed.

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

• R01: 2013-03-18 pre-Bristol mailing
  • Summary:
    • 47 open issues, up by 47.
    • 1 closed issues, up by 1.
    • 48 issues total, up by 48.
  • Details:
    • Added the following NAD issue: 39.
    • Added the following 32 New issues: 2, 5, 8, 10, 11, 12, 14, 15, 17, 19, 23, 24, 26, 28, 30, 31, 32, 33, 34, 35, 36, 37, 38, 40, 41, 42, 43, 44, 45, 46, 47, 48.
    • Added the following 9 Open issues: 4, 9, 16, 18, 21, 22, 25, 27, 29.
    • Added the following 6 Ready issues: 1, 3, 6, 7, 13, 20.

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:

• Consensus may have not yet have been reached as to how to deal with the issue.
• Informal consensus may have been reached, but the EWG awaits exact resolution for review.
• The EWG wishes to consult additional technical experts before proceeding.
• The issue may require further study.

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 Defect Report's Proposed 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 only issues which are truly defects in the Standard move to the formal ISO DR status.

Active Issues

1. N3386 Return type deduction for normal functions

Section: 7.1.6.4 [dcl.spec.auto] Status: Ready Submitter: Jason Merrill Opened: 2012-03-27 Last modified: 2013-03-09

View all issues with Ready status.

Discussion:

Reviewed by EWG in Portland 2012, proceeding to CWG.

Wording available:

The paper contains the proposed wording.

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-03-09

View all issues with New status.

Discussion:

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-03-09

View all issues with Ready status.

Discussion:

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-03-09

View all issues with Open status.

Discussion:

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-03-09

View all issues with New status.

Discussion:

Wording available:

The paper contains the proposed wording.

6. N3401 Generating move operations (elaborating on Core 1402)

Section: 12.8 [class.copy] Status: Ready Submitter: Ville Voutilainen Opened: 2012-09-21 Last modified: 2013-03-09

View all issues with Ready status.

Discussion:

Reviewed by EWG in Portland 2012, proceeding to CWG.

Wording available:

The related Core issue contains the proposed wording.

7. N3402 User-defined Literals for Standard Library Types

Section: 20.1 [utilities.general] Status: Ready Submitter: Peter Sommerlad Opened: 2012-09-08 Last modified: 2013-03-09

View all issues with Ready status.

Discussion:

Reviewed by EWG in Portland 2012, binary literals to be added into the core language, the rest of the paper is on LWG's plate. The binary literals are proceeding to CWG.

Wording available:

The paper contains the Library wording, Dennett has written the Core wording for binary literals.

8. N3403 Use Cases for Compile-Time Reflection

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

View all issues with New status.

Discussion:

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

9. N3405 Template Tidbits

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

View all issues with Open status.

Discussion:

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

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-03-09

View other active issues in [library].

View all other issues in [library].

View all issues with New status.

Discussion:

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-03-09

View other active issues in [intro.multithread].

View all other issues in [intro.multithread].

View all issues with New status.

Discussion:

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-03-09

View other active issues in [meta].

View all other issues in [meta].

View all issues with New status.

Discussion:

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

13. N3412 Runtime-sized arrays with automatic storage duration (revision 2)

Section: 3.9 [basic.types] Status: Ready Submitter: Jens Maurer Opened: 2012-09-19 Last modified: 2013-03-09

View all issues with Ready status.

Discussion:

Reviewed by EWG in Portland 2012, proceeding to CWG. The library part is N2648 C++ Dynamic Arrays, and that part is proceeding to LWG.

Wording available:

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

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

View other active issues in [temp.param].

View all other issues in [temp.param].

View all issues with New status.

Discussion:

Wording available:

15. N3416 Packaging Parameter Packs

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

View other active issues in [temp.param].

View all other issues in [temp.param].

View all issues with New status.

Discussion:

16. N3418 Proposal for Generic (Polymorphic) Lambda Expressions

Section: 5.1.2 [expr.prim.lambda] Status: Open Submitter: Faisal Vali Opened: 2012-09-21 Last modified: 2013-03-09

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

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

View all issues with Open status.

Discussion:

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

17. N3419 Vector loops and Parallel Loops

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

View other active issues in [intro.multithread].

View all other issues in [intro.multithread].

View all issues with New status.

Discussion:

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-03-09

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

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

View all issues with Open status.

Discussion:

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-03-09

View all issues with New status.

Discussion:

Handled by the Concurrency Study Group (SG1).

Wording available:

The paper contains the proposed wording.

20. N3432 C++ Sized Deallocation

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

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

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

View all issues with Ready status.

Discussion:

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-03-09

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

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

View all issues with Open status.

Discussion:

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-03-09

View all issues with Open status.

Discussion:

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-03-09

View other active issues in [meta].

View all other issues in [meta].

View all issues with New status.

Discussion:

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-03-09

View all issues with New status.

Discussion:

25. N3444 Relaxing syntactic constraints on constexpr function definitions

Section: 5.19 [expr.const] Status: Open Submitter: Richard Smith Opened: 2012-09-21 Last modified: 2013-03-09

View other active issues in [expr.const].

View all other issues in [expr.const].

View all issues with Open status.

Discussion:

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

26. 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-03-09

View all issues with New status.

Discussion:

27. N3448 Painless Digit Separation

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

View all issues with Open status.

Discussion:

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

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-03-09

View all issues with New status.

Discussion:

29. N3329 Proposal: static if declaration

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

View other active issues in [meta].

View all other issues in [meta].

View all issues with Open status.

Discussion:

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: New Submitter: Dave Abrahams Opened: 2012-10-16 Last modified: 2013-03-09

View all issues with New 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.

31. [tiny] constexpr functions must work at runtime

Section: 5.19 [expr.const] Status: New Submitter: Dave Abrahams Opened: 2012-10-16 Last modified: 2013-03-09

View other active issues in [expr.const].

View all other issues in [expr.const].

View all issues with New status.

Discussion:

constexpr functions are crippled by the fact that they have to be valid at runtime. Things that are tantalizingly close but you can't quite do include returning a type that depends on the /value/ of a function parameter:

  constexpr auto ptr_array(int N) -> int(*)[N]
  { ... }

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

Section: 13 [over] Status: New Submitter: Nevin Liber Opened: 2012-10-19 Last modified: 2013-03-09

View all issues with New 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&)
}

33. [tiny] contextual bool conversion from scoped enum

Section: 7.2 [dcl.enum] Status: New Submitter: Jeffrey Yasskin Opened: 2012-10-20 Last modified: 2013-03-09

View all issues with New 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

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

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

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

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

Section: 17.6.3.4 [hash.requirements] Status: New Submitter: Matt Austern Opened: 2012-10-23 Last modified: 2013-03-09

View all issues with New 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;
  };

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

Section: 3.4 [basic.lookup] Status: New Submitter: Jeffrey Yasskin Opened: 2012-10-24 Last modified: 2013-03-09

View all issues with New 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

36. [tiny] no way to say "prefer this implicit conversion over that"

Section: 12.3 [class.conv] Status: New Submitter: Jeffrey Yasskin Opened: 2012-10-24 Last modified: 2013-03-09

View all issues with New status.

Discussion:

If a type has two implicit conversions, and I call a function with overloads for both target types, there's no way to disambiguate short of writing the conversion explicitly or adding another overload. It would be nice to be able to extend the partial order on conversions.

37. [tiny] Logical xor operator

Section: 5 [expr] Status: New Submitter: Alisdair Meredith Opened: 2012-10-28 Last modified: 2013-03-09

View all issues with New status.

Discussion:

I have a low-priority issue for adding the (neglected) logical-xor operator, ^^. This has traditionally been dismissed as un-necessary, as it is equivalent to boolean operator!=, and there is no short-circuiting benefit to justify adding it. However, contextual conversions to 'bool' are handled specially for logical operators, and in that context it would be completing a hole in the language. I wish I had a better example, but pulling from the standard library:

   function<void()> a;
   function<void()> b;
   assert(a != b);  // does not compile
   assert(a ^^ b);  // would compile, and assert!

38. [tiny] Core issue 1542

Section: 5.17 [expr.ass] Status: New Submitter: Mike Miller Opened: 2012-11-02 Last modified: 2013-03-09

View all issues with New status.

Discussion:

In Portland, CWG categorized a number of issues as "extension," which I presume you will automatically look at for potential EWG involvement once the new revision of the issues list is out. I did want to mention one issue for which we will be resolving part and referring the other part to EWG: issue 1542 raises the question of whether the narrowing rules make sense for a compound assignment, e.g.,

    char c;
    c += {1};

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

Section: 23.3.6 [vector] Status: New Submitter: Nevin Liber Opened: 2012-11-27 Last modified: 2013-03-09

View all issues with New 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.

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

Section: 14.7.3 [temp.expl.spec] Status: New Submitter: Faisal Vali Opened: 2012-10-27 Last modified: 2013-03-09

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

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

View all issues with New 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
    };

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

Section: 21.4.2 [string.cons] Status: New Submitter: Nevin Liber Opened: 2012-12-19 Last modified: 2013-03-09

View all issues with New 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.

  std::string StringFromVector(std::vector<char> const& vc)
  { return std::string(vc.data(), vc.size()); }

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: New Submitter: Gabriel Dos Reis Opened: 2013-01-12 Last modified: 2013-03-09

View all issues with New 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);

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

44. [tiny] variadic bind

Section: 20.8.9 [bind] Status: New Submitter: Chris Jefferson Opened: 2013-01-25 Last modified: 2013-03-09

View all issues with New 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.

45. [tiny] Type Trait is_range

Section: 20.9.4.3 [meta.unary.prop] Status: New Submitter: Nevin Liber Opened: 2013-02-05 Last modified: 2013-03-09

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

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

View all issues with New 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).

46. [tiny] Type Trait is_final

Section: 20.9.4.3 [meta.unary.prop] Status: New Submitter: Nevin Liber Opened: 2013-02-05 Last modified: 2013-03-09

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

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

View all issues with New 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.

47. [tiny] Fix the relation operators on standard templated types

Section: 17 [library] Status: New Submitter: Nevin Liber Opened: 2013-02-05 Last modified: 2013-03-09

View other active issues in [library].

View all other issues in [library].

View all issues with New status.

Discussion:

In C++11, all the containers, pair, tuple, etc. always have the relation operators defined for them (==, !=, <, >, <=, >=), even if the contained type does not have them; they just fail to compile if one tries to invoke them. It would be better if those operators were SFINAEed out, so that generic code can then detect it and apply alternate strategies.

A use case I've have for this is when holding stateless objects that don't normally have the relation operators defined for them.

48. [tiny] Specializing templates in different namespaces

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

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

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

View all issues with New 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
    }
  }

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