Doc. no.	N4422
Date:	2015-04-10
Project:	Programming Language C++
Reply to:	Ville Voutilainen <ville.voutilainen@gmail.com>

C++ Standard Evolution Completed Issues List (Revision R11)

Revised 2015-04-10 at 16:04:35 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 Active Issues List
Evolution Closed Issues List

This document contains only evolution issues which have been closed by the Evolution Working Group (EWG) after being found to be acceptable extensions to the standard. That is, issues which have a status of DR, TC1, WP, C++11, or Resolved. See the Evolution Closed Issues List for issues closed as non-defects. See the Evolution Active Issues List for active issues and more information. The introductory material in that document also applies to this document.

Revision History

R11: 2015-04-10 pre-Lenexa mailing
- Summary:
  - 98 open issues, up by 13.
  - 79 closed issues, down by 1.
  - 177 issues total, up by 12.
- Details:
  - Added the following 12 New issues: 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177.
  - Changed the following 14 issues from WP to C++14: 1, 3, 6, 7, 16, 18, 20, 21, 25, 27, 46, 61, 62, 64.
  - Changed the following issue from WP to Open: 13.
R10: 2014-10-29 post-Urbana mailing
- Summary:
  - 85 open issues, up by 6.
  - 80 closed issues, up by 20.
  - 165 issues total, up by 26.
- Details:
  - Added the following 6 NAD issues: 140, 144, 145, 150, 156, 157.
  - Added the following New issue: 146.
  - Added the following 13 Open issues: 141, 142, 143, 148, 149, 151, 152, 153, 158, 159, 160, 162, 163.
  - Added the following 2 Ready issues: 164, 165.
  - Added the following 4 WP issues: 147, 154, 155, 161.
  - Changed the following issue from New to NAD: 138.
  - Changed the following issue from Open to NAD: 114.
  - Changed the following 2 issues from New to Open: 129, 137.
  - Changed the following issue from Ready to Open: 81.
  - Changed the following issue from New to Ready: 139.
  - Changed the following issue from Open to Ready: 72.
  - Changed the following 4 issues from Open to WP: 63, 82, 113, 126.
  - Changed the following 4 issues from Ready to WP: 80, 119, 121, 131.
R09: 2014-10-09 pre-Urbana mailing
- Summary:
  - 79 open issues, up by 5.
  - 60 closed issues, up by 0.
  - 139 issues total, up by 5.
- Details:
  - Added the following 4 New issues: 135, 137, 138, 139.
  - Added the following Open issue: 136.
R08: 2014-07-02 post-Rapperswil mailing
- Summary:
  - 74 open issues, down by 12.
  - 60 closed issues, up by 27.
  - 134 issues total, up by 15.
- Details:
  - Added the following 3 NAD issues: 124, 132, 133.
  - Added the following 3 New issues: 128, 129, 130.
  - Added the following 5 Open issues: 120, 122, 125, 126, 127.
  - Added the following 2 Ready issues: 121, 131.
  - Added the following 2 Resolved issues: 123, 134.
  - Changed the following 2 issues from New to Dup: 77, 103.
  - Changed the following 14 issues from New to NAD: 70, 85, 89, 90, 91, 95, 99, 100, 104, 105, 109, 110, 112, 117.
  - Changed the following 11 issues from New to Open: 88, 92, 96, 98, 101, 102, 106, 108, 113, 116, 118.
  - Changed the following issue from WP to Open: 22.
  - Changed the following 2 issues from New to Ready: 111, 119.
  - Changed the following 2 issues from New to Resolved: 8, 67.
  - Changed the following 4 issues from Ready to Resolved: 40, 42, 44, 45.
  - Changed the following issue from Ready to WP: 46.
R07: 2014-05-20 pre-Rapperswil mailing
- Summary:
  - 86 open issues, up by 6.
  - 33 closed issues, up by 0.
  - 119 issues total, up by 6.
- Details:
  - Added the following 5 New issues: 115, 116, 117, 118, 119.
  - Added the following Open issue: 114.
R06: 2014-02-21 post-Issaquah mailing
- Summary:
  - 80 open issues, up by 31.
  - 33 closed issues, up by 3.
  - 113 issues total, up by 34.
- Details:
  - Added the following 3 NAD issues: 87, 97, 107.
  - Added the following 26 New issues: 83, 85, 88, 89, 90, 91, 92, 93, 94, 95, 96, 98, 99, 100, 101, 102, 103, 104, 105, 106, 108, 109, 110, 111, 112, 113.
  - Added the following 3 Open issues: 82, 84, 86.
  - Added the following 2 Ready issues: 80, 81.
R05: 2014-01-17 pre-Issaquah mailing
- Summary:
  - 49 open issues, up by 3.
  - 30 closed issues, up by 0.
  - 79 issues total, up by 3.
- Details:
  - Added the following 3 New issues: 77, 78, 79.
  - Changed the following issue from New to Open: 72.
  - Changed the following issue from Ready to Open: 41.
R04: 2013-10-11 post-Chicago mailing
- Summary:
  - 46 open issues, down by 9.
  - 30 closed issues, up by 12.
  - 76 issues total, up by 3.
- Details:
  - Added the following 3 Open issues: 74, 75, 76.
  - Changed the following 4 issues from New to NAD: 12, 68, 69, 73.
  - Changed the following 2 issues from Open to NAD: 32, 33.
  - Changed the following 6 issues from New to Open: 2, 17, 19, 23, 52, 71.
  - Changed the following 4 issues from Open to WP: 18, 21, 22, 27.
  - Changed the following 2 issues from Ready to WP: 3, 20.
R03: 2013-08-27 pre-Chicago mailing
- Summary:
  - 55 open issues, up by 7.
  - 18 closed issues, up by 0.
  - 73 issues total, up by 7.
- Details:
  - Added the following 7 New issues: 67, 68, 69, 70, 71, 72, 73.
R02: 2013-05-06 post-Bristol mailing
- Summary:
  - 49 open issues, up by 2.
  - 18 closed issues, up by 17.
  - 67 issues total, up by 19.
- Details:
  - Added the following 3 NAD issues: 53, 54, 55.
  - Added the following 6 New issues: 49, 50, 51, 52, 59, 65.
  - Added the following 7 Open issues: 56, 57, 58, 60, 63, 66, 66.
  - Added the following 3 WP issues: 61, 62, 64.
  - Changed the following 5 issues from New to NAD: 31, 36, 37, 38, 47.
  - Changed the following 8 issues from New to Open: 14, 30, 32, 33, 34, 35, 43, 48.
  - Changed the following 6 issues from New to Ready: 40, 41, 42, 44, 45, 46.
  - Changed the following 2 issues from Open to WP: 16, 25.
  - Changed the following 4 issues from Ready to WP: 1, 6, 7, 13.
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.

Completed Issues

1. N3638, N3582, N3386 Return type deduction for normal functions

Section: 7.1.6.4 [dcl.spec.auto] Status: C++14 Submitter: Jason Merrill Opened: 2012-03-27 Last modified: 2015-04-02

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

View all issues with C++14 status.

Discussion:

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

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

Reviewed by EWG in Portland 2012, proceeding to CWG.

Accepted into the Working Draft in Bristol 2013, as N3638.

Wording available:

The paper contains the proposed wording.

3. N3760, N3394 [[deprecated]] attribute

Section: 7.6 [dcl.attr] Status: C++14 Submitter: Alberto Ganesh Barbati Opened: 2012-06-12 Last modified: 2015-04-02

View all issues with C++14 status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html

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

Reviewed by EWG in Portland 2012, proceeding to CWG.

Adopted in Chicago 2013

Wording available:

The paper contains the proposed wording.

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

Section: 12.8 [class.copy] Status: C++14 Submitter: Ville Voutilainen Opened: 2012-09-21 Last modified: 2015-04-02

View all other issues in [class.copy].

View all issues with C++14 status.

Discussion:

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

Reviewed by EWG in Portland 2012, proceeding to CWG.

Accepted into the Working Draft in Bristol 2013, as N3667.

Wording available:

The related Core issue contains the proposed wording.

7. N3642, N3468, N3402 User-defined Literals for Standard Library Types, N3472 Binary Literals in the C++ Core Language

Section: 2.14.2 [lex.icon] Status: C++14 Submitter: Peter Sommerlad Opened: 2012-09-08 Last modified: 2015-04-02

View all issues with C++14 status.

Discussion:

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

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

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

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.

Accepted into the Working Draft in Bristol 2013, as N3642.

N3472 also accepted into the Working Draft in Bristol 2013.

Wording available:

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

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

Section: 18 [language.support] Status: Resolved Submitter: Mike Spertus Opened: 2012-09-22 Last modified: 2015-04-02

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

16. N3649, N3560, N3559, N3418 Proposal for Generic (Polymorphic) Lambda Expressions

Section: 5.1.2 [expr.prim.lambda] Status: C++14 Submitter: Faisal Vali Opened: 2012-09-21 Last modified: 2015-04-02

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

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

View all issues with C++14 status.

Discussion:

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

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

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

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

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

Accepted into the Working Draft in Bristol 2013, as N3649.

Bristol 2013: Do not re-open proposals 2.1 and 2.2 in N3560, they are considered NAD. The proposals 2.3 and 2.4 are covered by N3649.

18. N3424 Lambda Correctness and Usability Issues

Section: 5.1.2 [expr.prim.lambda] Status: C++14 Submitter: Herb Sutter Opened: 2012-09-23 Last modified: 2015-04-02

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

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

View all issues with C++14 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.

Init-captures in C++14 provide the necessary facilities for capturing 'this' and class members, voted into the WP in Bristol 2013.

20. N3778, N3663, N3536, N3432 C++ Sized Deallocation

Section: 3.7.4 [basic.stc.dynamic] Status: C++14 Submitter: Lawrence Crowl Opened: 2012-09-23 Last modified: 2015-04-02

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

View all issues with C++14 status.

Discussion:

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

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.

Adopted in the Chicago 2013 meeting as N3778.

21. N3664, N3537, N3433 Clarifying Memory Allocation

Section: 3.7.4 [basic.stc.dynamic] Status: C++14 Submitter: Lawrence Crowl Opened: 2012-09-23 Last modified: 2015-04-02

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

View all issues with C++14 status.

Discussion:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3537.html

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.

Adopted in Bristol 2013

Wording available:

The paper contains the proposed wording.

25. N3652, N3597, N3598, N3444 Relaxing syntactic constraints on constexpr function definitions

Section: 5.19 [expr.const] Status: C++14 Submitter: Richard Smith Opened: 2012-09-21 Last modified: 2015-04-02

View all other issues in [expr.const].

View all issues with C++14 status.

Discussion:

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

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

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

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

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

Accepted into the Working Draft in Bristol 2013, as N3652.

27. N3781 Single-Quotation-Mark as a Digit Separator, N3661, N3499 Digit Separators, N3448 Painless Digit Separation

Section: 2.10 [lex.ppnumber] Status: C++14 Submitter: Daveed Vandevoorde Opened: 2012-09-21 Last modified: 2015-04-02

View all issues with C++14 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

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

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.

Adopted in Chicago 2013, as N3781.

Wording available:

The paper contains the proposed wording.

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

Section: 23.3.6 [vector] Status: Resolved Submitter: Nevin Liber Opened: 2012-11-27 Last modified: 2015-04-02

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

Filed as LEWG Bug 38, closing as Resolved on the EWG side.

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

Section: 21.4.2 [string.cons] Status: Resolved Submitter: Nevin Liber Opened: 2012-12-19 Last modified: 2015-04-02

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

Filed as LEWG Bug 39, closing as Resolved on the EWG side.

Wording available:

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

44. [tiny] variadic bind

Section: 20.8.9 [bind] Status: Resolved Submitter: Chris Jefferson Opened: 2013-01-25 Last modified: 2015-04-02

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

Filed as LEWG Bug 40, closing as Resolved on the EWG side.

45. [tiny] Type Trait is_range<T>

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

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

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

Filed as LEWG Bug 41, closing as Resolved on the EWG side.

46. [tiny] Type Trait is_final<T>

Section: 20.9.4.3 [meta.unary.prop] Status: C++14 Submitter: Nevin Liber Opened: 2013-02-05 Last modified: 2015-04-02

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

View all issues with C++14 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.

Voted into C++14 in Issaquah 2014 as the resolution of LWG issue 2112.

61. N3653, N3605 Member initializers and aggregates

Section: 8.5.1 [dcl.init.aggr] Status: C++14 Submitter: Ville Voutilainen Opened: 2013-03-15 Last modified: 2015-04-02

View all other issues in [dcl.init.aggr].

View all issues with C++14 status.

Discussion:

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

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

Accepted into the Working Draft in Bristol 2013, as N3653.

62. N3648, N3610 Generic lambda-capture initializers, supporting capture-by-move

Section: 5.1.2 [expr.prim.lambda] Status: C++14 Submitter: Ville Voutilainen Opened: 2013-03-15 Last modified: 2015-04-02

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

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

View all issues with C++14 status.

Discussion:

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

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

Accepted into the Working Draft in Bristol 2013, as N3648.

63. N4152 uncaught_exceptions, N3614 unwinding_exception

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

View all issues with WP status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4152.pdf

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.

In Chicago 2013, Voutilainen said he plans to work on this issue and create a follow-up paper for C++17.

Adopted into the working draft in Urbana, as N4259.

64. N3651, N3615 Constexpr Variable Templates, N3552 Introducing Object Aliases

Section: 14.1 [temp.param] Status: C++14 Submitter: Gabriel Dos Reis Opened: 2013-03-18 Last modified: 2015-04-02

View other active issues in [temp.param].

View all other issues in [temp.param].

View all issues with C++14 status.

Discussion:

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

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

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

Accepted into the Working Draft in Bristol 2013, as N3651.

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

Section: 20.4.1 [tuple.general] Status: Resolved Submitter: Nevin Liber Opened: 2013-03-19 Last modified: 2015-04-02

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

This should go to LEWG.

Filed as LEWG Bug 42, closing as Resolved on the EWG side.

80. N3846 Extending static_assert

Section: 7 [dcl.dcl] Status: WP Submitter: Walter E. Brown Opened: 2014-01-01 Last modified: 2015-04-02

View all issues with WP status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3846.pdf

Issaquah 2014: EWG discussed the paper, and found preference towards option 3, which allows implementations to use useful messages, but doesn't force them to document what they provide, so it was seen superior to the other alternatives. The proposal is expected to go forward to Core, and it has wording already.

Adopted into the working draft in Urbana,as N3928.

Wording available:

The paper contains the proposed wording.

82. N4180 SG5 Transactional Memory Support for C++ Update, N3919, N3859, N3718 Transactional Memory Support for C++

Section: 1.10 [intro.multithread] Status: WP Submitter: M. Wong, V. Luchangco, J. Maurer, M. Moir, et al. Opened: 2014-01-20 Last modified: 2015-04-02

View other active issues in [intro.multithread].

View all other issues in [intro.multithread].

View all issues with WP status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4180.pdf

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3919.pdf

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3859.pdf

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

Issaquah 2014: EWG discussed the paper, and found consensus to move the proposal forward to a Technical Specification.

Accepted for creation of a Technical Specification in Urbana, as N4272 and N4265.

113. N4196 Attributes for namespaces and enumerators, [tiny] Core issue 1657, Attributes for namespaces and enumerators

Section: 7.3.1 [namespace.def] Status: WP Submitter: Richard Smith Opened: 2013-08-26 Last modified: 2015-04-02

View all issues with WP status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4196.html

See Core issue 1657.

Issaquah 2014: EWG wants to point out that it's important to remember to consider inline namespaces and anonymous namespaces, and that the rationale for both namespaces and enumerators is [[deprecated]].

Discussed in Rapperswil 2014. Smith is encouraged to write a proposal for EWG review, EWG expects to send it towards CWG without much ado.

Adopted into the working draft in Urbana, as N4266.

119. N4197 Adding u8 character literals, [tiny] Why no u8 character literals?

Section: 2.14.3 [lex.ccon] Status: WP Submitter: Richard Smith Opened: 2014-04-14 Last modified: 2015-04-02

View all issues with WP status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4197.html

The discussion thread started at [c++std-ext-14798].

We have five encoding-prefixes for string-literals (none, L, u8, u, U) but only four for character literals -- the missing one is u8 for character literals.

This matters for implementations where the narrow execution character set is not ASCII. In such a case, u8 character literals would provide an ideal way to write character literals with guaranteed ASCII encoding (the single-code-unit u8 encodings are exactly ASCII), but... we don't provide them. Instead, the best one can do is something like this:

  char x_ascii = { u'x' };

... where we'll get a narrowing error if the codepoint doesn't fit in a 'char'. (Note that this is not quite the same as u8'x', which would give us an error if the codepoint was not representable as a single code unit in UTF-8.)

Is there a good reason for omitting this (useful and natural) functionality?

Discussed in Rapperswil 2014. EWG considers this to be an improvement, and encourages the author to take a proposal with wording to CWG. It's expected that Smith can do so without a separate EWG review.

Voted into the working draft in Urbana, as N4267.

121. N4086, N3981 Removing trigraphs??!, N4210 IBM comment on preparing for a Trigraph-adverse future in C++17

Section: 2.2 [lex.phases] Status: WP Submitter: Richard Smith Opened: 2014-05-06 Last modified: 2015-04-02

View all other issues in [lex.phases].

View all issues with WP status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4086.html

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4210.pdf

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3981.html

Wording available:

The paper contains the proposed wording.

Discussed in Rapperswil 2014. IBM continues to oppose.

Straw poll:

SF 9, WF 6, N 6, WA 3, SA 2.

Another poll, no neutral option:

SF 10, WF 9, WA 3, SA 3.

Deprecate/Remove/Status Quo, three-way poll:

5/16/6. Removal is still by far the strongest.

The proposal goes forward to CWG. CWG has already reviewed it and designated it ready for voting in Urbana.

Adopted into the working draft in Urbana, as N4086.

123. N3990 Adding Standard Circular Shift operators for computer integers

Section: 5 [expr] Status: Resolved Submitter: D. Gutson, A. Bustamante Opened: 2014-05-08 Last modified: 2015-04-02

View all other issues in [expr].

View all issues with Resolved status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3990.pdf

Wording available:

The paper contains the proposed wording.

Discussed in Rapperswil 2014.

EWG was unanimously against having an operator for this, and recommended taking the idea up with the Numerics SG and then with LWG. Closing as resolved, Vandevoorde sent a heads-up to the Numerics reflector.

126. N4230 Nested namespace definition (revision 2), N4116 Nested Namespace Definition (rev 1), N4026 Nested namespace definition

Section: 3.3.6 [basic.scope.namespace] Status: WP Submitter: Robert Kawulak Opened: 2014-05-23 Last modified: 2015-04-02

View all issues with WP status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4230.html

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4116.pdf

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4026.html

Discussed in Rapperswil 2014.

Straw poll, the full facility (JUST the basic syntactic sugar, no attributes, no aliases, no inline):

SF: 11 F: 5 N: 3 A: 0 SA: 0

The guidance is to provide only the basic syntactic sugar, no attributes, no aliases. Initial wording is necessary before this can proceed to Core. It is expected that EWG will review a revised paper before CWG will review the wording.

Adopted into the working draft in Urbana, as N4266.

131. N4051 Allow typename in a template template parameter

Section: 14.1 [temp.param] Status: WP Submitter: Richard Smith Opened: 2014-05-26 Last modified: 2015-04-02

View other active issues in [temp.param].

View all other issues in [temp.param].

View all issues with WP status.

Discussion:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4051.html

Discussed in Rapperswil 2014, approved by acclamation, ready to go to CWG. CWG already reviewed it and designated it ready for voting in Urbana.

Adopted into the working draft in Urbana, as N4051.

134. [tiny] Core closed issues with a previous extension status

Section: 1 [intro] Status: Resolved Submitter: Ville Voutilainen Opened: 2014-07-01 Last modified: 2015-04-10

View other active issues in [intro].

View all other issues in [intro].

View all issues with Resolved status.

Discussion:

13 extern "C" for Parameters of Function Templates -> request Core to close as NAD, Daveed says aliases with linkage are the solution. 1463 will be opened as an EWG issue to solve this.

203 Type of address-of-member expression -> new EWG issue, 89. The EWG issue is NAD, too late for a breaking change, instruct CWG to also close as NAD.

230 Calls to pure virtual functions -> Instruct Core to close 230 as NAD. Pure virtual functions can be called by non-virtual calls only, and it is by design that virtual calls should never resolve to the definition of a pure virtual function. The behaviour is undefined because implementations aren't required to prevent ending up in the pure virtual function definition. That is also by design.

622 Relational comparisons of arbitrary pointers -> new EWG issue, 91. The issue is NAD -> instruct CWG to do the same.

623 Use of pointers to deallocated storage -> Instruct Core to close 623 as WP. The behavior is implementation-defined rather than undefined in the current working draft, and thus the requirements are no longer draconian. 312, which was resolved as DRWP points to 623, so also close 623 as DRWP.

755 Generalized lambda-captures -> Instruct Core to close 755 as WP. Generalized lambda-captures are in C++14.

822 Additional contexts for template aliases -> new EWG issue, 95. -> issue is NAD, suggest CWG also closes as NAD.

947 Deducing type template arguments from default function arguments -> Open an EWG issue, 97, for 947, immediately close as NAD, explaining that the group doesn't think it's generally implementable. Leave the door open (but not the issue :)) for a restricted implementation.

1259 Deleting a POD via a pointer to base -> new EWG issue, 99. -> issue is NAD, suggest CWG closes as NAD.

1272 Implicit definition of static data member of const literal type -> new EWG issue, 100. -> issue is NAD, suggest CWG closes as NAD.

1461 Narrowing conversions to bit-fields -> Instruct Core to close 1461 as NAD. It would break existing code and EWG doesn't consider the breakage to be worth it. Vandevoorde pointed out valid existing code that initializes bitfields (even with one bit) with -1.

1474 User-defined literals and <inttypes.h> format macros -> Instruct Core to close 1474 as NAD. The fix would be to remove UDLs.

1519 Conflicting default and variadic constructors -> Open an EWG issue for 1519, 107. Mark as NAD, there is a work-around and Concepts Lite will make the work-around much easier.

1564 Template argument deduction from an initializer list -> new EWG issue, 109. -> issue is NAD, suggest CWG closes as NAD as well.

1586 Naming a destructor via decltype -> new EWG issue, 112. -> issue is NAD, suggest CWG closes as NAD as well.

1657 Attributes for namespaces and enumerators -> Open an EWG issue for 1657, 113. Remember to consider inline namespaces and anon namespaces. Rationale for both namespaces and enumerators is [[deprecated]].

1754 Declaration of partial specialization of static data member template -> new EWG issue, 132 (NAD, lack of motivation for the change)

1798 exception-specifications of template arguments -> new EWG issue, 133 (NAD, insufficient motivation for a change, no desire to have exception specifications in the type system, paper requested if there's desire to reopen)

1833 friend declarations naming implicitly-declared member functions

Straw poll, Rapperswil 2014, NAD?

SF 3 - WF 7 - N 7 - WA 2 - SA 0

-> instruct CWG to close as NAD, EWG didn't find sufficient motivation for the extension suggested.