Document number:  N3903
Date:  2014-03-03
Reply to:  William M. Miller
 Edison Design Group, Inc.
 wmm@edg.com










C++ CD Comment Status

Rev. 6

This document summarizes the status of WG21 after the 2014-02 (Issaquah) meeting in addressing National Body comments on Committee Draft document N3690.

In total, 85 comments were received. To date, 39 have been accepted as proposed, 21 have been accepted with modifications, 25 have been rejected, and 0 remain to be addressed. The detailed breakdown:

This document consists of three tables. The first is a table of contents, listing each issue by National Body and comment number and giving its current status. The second is a list of all as-yet unresolved comments, sorted by the responsible party. The third is a comprehensive listing of all the comments received in the same order and with roughly the same organization as in document N3733; the “Disposition” field gives the response, as well as any explanatory comments provided by the responsible party. The comments have been slightly modified for formatting and convenience of reference; any substantive changes are unintentional, and N3733 is the definitive repository of the content of comments. The official Record of Response to the comments is found in document N3956, which supersedes the content of this document.


SORTED LISTING OF COMMENTS:

In the following table, the “Date” field represents the date on which the Committee affirmed the listed disposition.

ID Responsible Disposition Date Issue Document
CH 1 accepted       
CH 2 accepted  2013-09-28     
CH 3 modified  2013-09-28    N3776 
CH 4 LWG modified  2013-09-28     
CH 5 CWG accepted  2014-02-15  1772   
CH 6 CWG accepted  2014-02-15  1762   
CH 7 LWG modified       
CH 8 LWG accepted  2013-09-28    N3779 
CH 9 LWG rejected       
ES 1 CWG modified       
ES 2 LWG modified       
ES 3 CWG accepted  2013-09-28    N3781 
ES 4 CWG accepted  2013-09-28    N3781 
ES 5 CWG accepted  2013-09-28    N3781 
ES 6 CWG accepted  2013-09-28    N3781 
ES 7 CWG accepted  2014-02-15  1717   
ES 8 CWG accepted  2013-09-28    N3778 
ES 9 CWG rejected    1629   
ES 10 CWG accepted  2013-09-28    N3760 
ES 11 LWG accepted  2013-09-28  2275   
ES 12 LWG modified  2013-09-28     
ES 13 LWG rejected       
ES 14 LWG rejected    2232   
ES 15 editor accepted  2013-09-28     
ES 16 LWG accepted  2014-02-15  2299   
ES 17 LWG accepted  2013-09-28  2300   
ES 18 LWG rejected       
ES 19 LWG modified       
FI 1 CWG modified       
FI 2 LWG modified       
FI 3 CWG rejected       
FI 4 CWG rejected    1670   
FI 5 CWG rejected       
FI 6 CWG rejected       
FI 7 LWG rejected       
FI 8 CWG rejected       
FI 9 LWG modified  2013-09-28     
FI 10 LWG modified  2013-09-28     
FI 11 LWG rejected       
FI 12 CWG rejected       
FI 13 CWG accepted  2013-09-28    N3760 
FI 14 LWG modified  2013-09-28    N3776 
FI 15 CWG rejected    1776   
FI 16 LWG rejected       
GB 1 CWG accepted  2014-02-15  1759  N3914 
GB 2 CWG accepted  2014-02-15  1787  N3914 
GB 3 CWG accepted  2014-02-15  1760   
GB 4 CWG modified  2014-02-15  1786  N3914 
GB 5 LWG rejected    2297   
GB 6 editor rejected       
GB 7 LWG accepted  2013-09-28     
GB 8 LWG modified  2013-09-28     
GB 9 LWG accepted  2013-09-28  2249   
GB 10 LWG accepted  2013-09-28  2018   
GB 11 editor accepted       
GB 12 LWG accepted  2013-09-28    N3776 
NL 1 CWG accepted  2013-09-28    N3781 
US 1 editor rejected       
US 2 CWG accepted       
US 3 CWG accepted  2014-02-15  1441  N3910 
US 4 CWG modified  2014-02-15     
US 5 LWG accepted  2014-02-15  2075  N3927 
US 6 CWG accepted  2013-09-28    N3781 
US 7 CWG accepted  2013-09-28    N3778 
US 8 CWG accepted  2013-09-28    N3760 
US 9 CWG modified  2013-09-28  1768   
US 10 CWG modified  2013-09-28  1761   
US 11 CWG rejected       
US 12 CWG rejected       
US 13 CWG accepted  2014-02-15  1579   
US 14 LWG accepted       
US 15 editor accepted       
US 16 LWG modified    2118   
US 17 LWG rejected       
US 18 LWG accepted  2013-09-28  2298   
US 19 LWG rejected    2232   
US 20 LWG rejected       
US 21 LWG modified       
US 22 LWG rejected       
US 23 LWG accepted       
US 24 LWG accepted  2013-09-28    N3776 
US 25 LWG rejected       
US 26 LWG modified  2013-09-28    N3776 
US 27 LWG accepted       
US 28 LWG modified       

UNRESOLVED COMMENTS:

The following table lists the comments for which no resolution has yet been proposed.

ID Responsible Issue

ALL COMMENTS

The Canadian CD comments are not contained in this document but can be found in N3771.

ID Ref Comment Proposed Resolution Owner Issue Disposition
CH 1   The active issues on the issues lists (WG21 N3674, N3682 and N3687) shall be addressed before the standard becomes final.         ACCEPTED  
CH 2   C++14 is intended to be a bugfix release with minor new features.   Remove any new feature if it negatively affects the quality of the standard.       ACCEPTED

The optional and dynarray features will be moved from the Standard to Technical Specifications.  
CH 3   C++14 is intended to be a bugfix release with minor new features.   Introduce no breaking changes for C++14. This applies specifically to 30.3.1 (~thread()) and 30.6.8 (~future() for asyncs).This also applies to constexpr nonconst member functions, but for this case the CH NB support is not unanimous.       ACCEPTED with MODIFICATIONS

The comments regarding ~thread and ~future were accepted. There was no consensus to change the specification of constexpr as suggested.

See paper N3776.  
ES 1   N3674 still includes many unsolved core issues   Solve all the issues identified in N3674.   CWG    ACCEPTED with MODIFICATIONS

Many issues have been resolved. The unresolved issues remain in the active issues list for resolution in a future revision of the Standard.  
ES 2   N3687 still includes many unsolved library issues   Solve all the issues identified in N3687.   LWG    ACCEPTED with MODIFICATIONS

Many issues have been resolved. The remaining issues remain in the active issues list for resolution in a future revision of the Standard.  
NL 1   Reconsider adding digit separators, for example as proposed in N3661.     CWG    ACCEPTED

See paper N3781.  
US 14 (library)   Address open LWG Issues   Appropriate action would include making changes to the CD, identifying an issue as not requiring a change to the CD, or deferring the issue to a later point in time.   LWG    ACCEPTED  
FI 14 30.6   It is unfortunate that futures sometimes block in their destructor and sometimes don't. There have been recommendations to move the futures when unsure, and make sure get() is invoked before the destructor. However, not having a certainly blocking-future in the standard leads to proliferation of custom solutions to the same problem. Similarly, the lack of a certainly-non-blocking future leads to such proliferation.   It seems more future types should be added to establish reasonable semantics. Note that we do not support changing the return type of std::async due to these issues - breaking std::async in any way is harmful to users who already use it for what it was designed, and don't return the futures from it so that there would be confusion about the blocking.   LWG    ACCEPTED with MODIFICATIONS

The behavior of ~future() with std::async was documented.

See paper N3776.  
US 1 All Clauses   In lists of specifications, the use of anonymous bullets makes it difficult (in correspondence and speech) to refer to individual list items. Moreover, the longer the list, the greater the opportunity to mistake the structure, most especially in the presence of bullets in sublists.   In all lists of bulleted items, provide a distinct numbered or lettered identification in place of each bullet. Because paragraphs are already numbered, it seems best to use letters for top-level list items within paragraphs and then to use Roman numerals for any sublist items. (A few parts of the Standard already do this.)   editor    REJECTED

We believe this is, in principle, a good suggestion, but the scope of this change makes it more appropriate to explore the options for enumeration of bullets in the next revision prior to the issuance of a Committee Draft.  
US 15 All Library Clauses   Given the adoption of N3655, it is possible to rephrase uses of the type traits throughout and thus both simplify and clarify the text.   Replace each occurrence of the form cv typename typetrait<...>::type or the form cv typetrait<...>::type by cv typetrait_t<...>.   editor    ACCEPTED  
US 4 1.9, 1.10   Resolve CWG issues 1441, 1466, 1470 on concurrency. (lower priority).     CWG    ACCEPTED with MODIFICATIONS

The Committee agreed to address issues 1441 and 1466; issue 1470 was categorized as being “not a defect.” See N3910 and N3914.  
US 3 1.9, 1.10   The current standard accidentally and gratuitously restricts signal handlers much more than was originally intended. Conforming signal handlers cannot even use local variables. They cannot use atomic variables to avoid undefined behaviour as was originally intended.   Correct misstatements, and clarify that atomic<T> operations can be used to communicate with signal handlers, and that objects last modified before a signal handler was installed can be safely examined in a signal handler, e.g. by adopting N3633 or a refinement.   CWG  1441  ACCEPTED

See paper N3910.  
US 5 1.10, 29.4, 29.6.5   Resolve LWG issue 2075 on concurency.     LWG  2075  ACCEPTED

See paper N3927.  
FI 1 1-16   All Core issues with priorities zero or one up to and including the Core Issues List published in the pre-Chicago mailing shall be resolved   As viewed fit by the Core Working Group   CWG    ACCEPTED with MODIFICATIONS

Many issues have been resolved. The unresolved issues remain in the active issues list for resolution in a future revisioni of the Stnadard.  
US 2 1-16   The active issues identified in WG21 N3539, C++ Standard Core Language Active Issues, must be addressed and appropriate action taken.   Appropriate action would include making changes to the CD, identifying an issue as not requiring a change to the CD, or deferring the issue to a later point in time.   CWG    ACCEPTED  
US 6 2.14   Provide digit separators.   See N3661.   CWG    ACCEPTED

See paper N3781.  
ES 3 2.14.2   Reconsider adding digit separators for integer decimal literals.   Add digit separators for integer decimal literals as specified in N3661. No counter-example has been presented for integer octal literals.   CWG    ACCEPTED

See paper N3781.  
ES 4 2.14.2   Add digit separators for integer binary literals.   No interaction has been identified with digit separators for binary literals   CWG    ACCEPTED

See paper N3781.  
ES 5 2.14.2   Reconsider adding digit separators for integer octal literals   Add digit separators for integer octal literals as specified in N3661. No counter-example has been presented for integer octal literals.   CWG    ACCEPTED

See paper N3781.  
ES 6 2.14.2   Reconsider adding digit separator for integer hexadecimal literals   A different solution can be evaluated for the conflicting case of digit separators in hexadecimal literals. This case could be solved by using a different prefix to indicate the presence of digit separators.   CWG    ACCEPTED

See paper N3781.  
ES 7 2.14.2 ¶ Tab 6   Header of last columns says: Octal or hexadecimal constant This does not include binary constants   Modify accordingly table header.   CWG  1717  ACCEPTED  
GB 1 2.14.5 ¶ 8   The string literal u8"À" (that is, u8"\u00c0") creates a const char[3] initialized by { 0xc3, 0x80, 0 }. However, char is not guaranteed to be able to represent 0x80.   Change type of u8 string literals to unsigned char, or require signed char to be able to represent 0x80.   CWG  1759  ACCEPTED

See paper N3914.  
ES 8 3.7.4   Member operator delete[] may take a second parameter indicating the size of the object to be deallocated. However, global operator delete[] does not support this variant.   Provide a global operator delete[] with an optional size parameter along the lines of N3663.   CWG    ACCEPTED

See paper N3778.  
GB 2 4.1 ¶ 2   Reconsider resolution of core issue 616. Under core issue 616, certain lvalue-to-rvalue conversions on uninitialized objects of type unsigned char provide an unspecified value with defined behavior. That is extremely harmful for optimizers, since they must distinguish between a specific unspecified value (which would compare equal to itself, after being copied into another variable) and a fully-uninitialized value.   Further restrict loads of uninitialized unsigned char such that the value can only be stored, and the result of storing it is to make the destination contain an indeterminate value.   CWG  1787  ACCEPTED

See paper N3914.  
ES 9 5.1.2   Closure objects are never literal types   Consider allowing the generation of literal closure objects.   CWG  1629  REJECTED

There was no consensus for the suggested change.  
GB 3 5.1.2 ¶ 11   The access of the non-static data member declared for an init-capture is not specified.   Make the init-capture field unnamed, like other captures.   CWG  1760  ACCEPTED  
GB 4 5.3.4 ¶ 8   We are concerned that the change in N3664 may change a small memory leak into a large one. Consider
class P {
  int x;
};
class Q {
public:
   Q(){ throw 42; }
private:
   int x[LARGE_NUMBER];
};
{
   P* p1 = new P();
   Q* q1 = new Q(); // bang :-(
   // don't get here
   delete q1;
   delete p1;
}
We fear, if the freedom of N3664 is exercised, that this code block leaks a memory of size at least sizeof(P) + sizeof(Q). The C++11 code would only leak the allocation for p1, of size closer to sizeof(P). This could result in programs with an insignificant memory leak becoming ones with a more serious leak.  
  CWG  1786  ACCEPTED with MODIFICATIONS

See paper N3914.  
ES 10 7.6   [[deprecated]] attribute is missing from the CD.   Apply N3394 to the CD.   CWG    ACCEPTED

See paper N3760.  
US 8 7.6   Paper N3394, "[[deprecated]] attribute," was intended to be included in the CD, but it was unintentionally omitted due to administrative issues.   Incorporate the changes from that paper for the final draft.   CWG    ACCEPTED

See paper N3760.  
US 10 8.3.4 ¶ 1   The next bullet item appears to the reference the "Size of an object" limit in Annex B. However, in many implementations, object size limits on the stack are quite different from other object size limits, and the limit is very dynamic (especially in the presence of recursion). A check against an fixed (and arbitrary) limit will only cover a subset of the size values that are problematic. In total, we throw on:
  • negative values and zero (first bullet)
  • object sizes above the limit
We do not throw for:
  • object sizes which can be allocated successfully
  • object sizes which cannot be allocated successfully on the stack, but are less than the object size limit
The second item creates significant unpredictability for programmers. Existing VLA implementations for C and C++ lack fully deterministic stack size checks. Obtaining stack is fairly difficult in widely deployed environments (both in terms of availability of the metric and high-performance access to it). An exact check against the dynamic limit is difficult to implement, and would not even cover other causes of stack overflow.  
Do not check at runtime whether the allocated array would exceed the implementation-defined limit on object size.   CWG  1761  ACCEPTED with MODIFICATIONS

The feature was moved from the Standard to a Technical Specification.  
US 9 8.3.4 ¶ 1   The draft currently requires that if a runtime bound evaluates to 0 at run-time, and exception is thrown. This means that correct C99 code that is also well-formed C++14 code, and has worked fine under the widespread VLA extensions to C++, will fail at runtime; affected code was encountered immediately after the proposal was implemented in G++. A check for negative values makes sense and can be avoided by the programmer by using an unsigned type for the expression. The check against 0 would still be required by the current draft, and is not required by typical VLA usage (because the code deals correctly with this boundary case). It is also surprising because operator new[] lacks such a check.
This is a VERY CRITICAL ISSUE..  
Allow an array of runtime bound that evaluates to 0 at run-time.   CWG  1768  ACCEPTED with MODIFICATIONS

The feature was moved from the Standard to a Technical Specification.  
US 11 8.3.4, etc.   Two distinct terms of art, bound and extent, are now used to denote an array's number of elements. For both consistency and improved technical accuracy, a single term of art should be adopted and used throughout the standard.   Because extent is the user-visible term used in the Library's interface, its consistent use would avoid breaking existing programs. See the wording proposed in N3549.   CWG    REJECTED

The term “bound” is widely used and understood and provides a point of compatibility with C for features shared by both languages. There was no consensus to make this change.  
CH 4 8.3.4, 23.3.4   VLAs without dynarray is giving wrong direction, and dynarray without full allocator support is just wrong.   Add full allocator support to dynarray or remove both, dynarray and VLAs completely.   LWG    ACCEPTED with MODIFICATIONS

The feature will be moved from the Standard to a Technical Specification.  
CH 5 8.4.1 ¶ 8   It's unclear from the text that __func__ is allowed in non function context lambda expressions, i.e., namespace level lambda expressions in initializers.   Specify that __func__ is allowed in such contexts.   CWG  1772  ACCEPTED  
US 12 12.8 ¶ 31   std::move inhibits copy elision, and so can be a pessimization   Ignore calls to std::move, std::move_if_noexcept, and casts to rvalue reference type when determining whether copy elision is permitted   CWG    REJECTED

There was no consensus for the suggested change.  
US 13 12.8 ¶ 32   Returning a local variable should always imply move semantics.   In return statement, when the expression is the name of a non-volatile automatic object, the expression should be treated as an rvalue for purposes of overload resolution, even if it does not have the same cv-unqualified type as the function return type.   CWG  1579  ACCEPTED  
CH 6 13.5.8 ¶ 8  
float operator ""E(const char*);// OK
should be
float operator ""E(const char*);// OK, but reserved
                                // (17.6.4.3.5) [usrlit.suffix]
 
Change the example accordingly.   CWG  1762  ACCEPTED  
FI 2 17-30   All Library issues up to and including the Library Issues List published in the pre-Chicago mailing shall be resolved   As viewed fit by the Library Working Group   LWG    ACCEPTED with MODIFICATIONS

Many issues have been resolved. The unresolved issues remain in the active issues list for resolution in a future revision of the Standard.  
GB 5 20.2.3 ¶ 1   The wording describes example code including the call of a move constructor, but there is no requirement stated that T be move constructible.   We would like to add a new Para 1 before existing paragraph:
Requires: Type T shall be MoveConstructible (Table 20) and MoveAssignable (Table 22).
However the MoveAssignable concept currently does not cover cases where the source and destination types may differ.  
LWG  2297  REJECTED

The requirements are implicit, according to 17.5.1.4 paragraph 4. Repeating them here would be redundant.  
ES 11 20.4.2.4 ¶ 5-6   forward_as_tuple is not currently constexpr   Make forward_as_tuple constexpr.   LWG  2275  ACCEPTED  
CH 7 20.5.1 ¶ 2   The example uses the names index_sequence and make_index_sequence whereas the following sections define integer_sequence and make_integer_sequence.   Change the names in the example accordingly.   LWG    ACCEPTED with MODIFICATIONS

The current wording is correct. A clarifying note will be added.  
ES 12 20.6.4   Without operator != users need to evaluate expressions like !(a==b) instead of (a!=b)   Add operator!= for optional<T>   LWG    ACCEPTED with MODIFICATIONS

The feature will be moved from the Standard to a Technical Specification.  
US 16 20.9.1.3   Resolve LWG issue 2118 on unique_ptr.     LWG  2118  ACCEPTED with MODIFICATIONS

There was no consensus for a change at this time. However, the issue remains open on the active issues list for resolution in a future revision of the Standard.  
ES 13 20.10.11.2   Polymorphic function wrappers do not take move-only callable types in their constructor.   Provide a mechanism to pass move-only callable types to polymorphic function wrappers.   LWG    REJECTED

There was no consensus to add this new feature at this time.  
US 17 20.10.11.2 & 30.6.9   Provide a way to pass a packaged_task<T()> to a function accepting function<void()> or another type-erasing callable-wrapper. This is important for concurrency constructs where we need to pass tasks between threads using queues. These queues must store a type general enough to represent any task, which includes a task for filling in a future<>. However, function<> currently doesn't accept move-only types like packaged_task<>, so it's not sufficient for the value-type of these queues.   Either change function<> to accept move-only callable types, probably by refcounting the callable, or provide a separate class to turn a move-only callable into a copyable callable.   LWG    REJECTED

There was no consensus to add this new feature at this time.  
US 18 20.11.4.3 ¶ 6   The trait is_constructible<T, Args...> is defined in terms of a helper template, create<>, that is identical to std::declval<> except for the latter's noexcept clause.   If the absence of noexcept is critical to this definition, insert a Note of explanation; otherwise, excise create<> and reformulate in terms of declval<> the definition of is_constructible.   LWG  2298  ACCEPTED  
US 19 21.2.3   Resolve LWG issue 2232   Proposed Change: Add constexpr to char_traits functions. As a second- best option, resolve LWG issue 2013 to allow libraries to do this as an extension.   LWG  2232  REJECTED

There was no consensus for this change. Concerns were expressed regarding efficient portable implementation.  
ES 14 21.2.3.1, 21.2.3.2, 21.2.3.3, 21.2.3.4   The following functions are not constexpr in char_traits specializations for char, char16_t, char32_t, and wchar_t:
compare()
length()
find()
However, with the addition N3652 a recursive implementation is not needed. Thus they can be easily and efficiently made constexpr.  
Make those functions constexpr for the mentioned specializations.   LWG  2232  REJECTED

There was no consensus for this change. Concerns were expressed regarding efficient portable implementation.  
GB 6 22.4.1   17.5.2.3 [objects.within.classes] defines the use of “exposition only” in the library:
The declarations for such member objects and the definitions of related member types are followed by a comment that ends with exposition only,
22.4.1 [category.ctype] has members which are preceded (not followed) by a comment ending “exposition only”. and 28.12.1 [re.regiter] and 28.12.2 [re.tokiter]  
Reformat to follow 17.25.2.3   editor    REJECTED

The use of “exposition only” in [category.ctype] applies to constants, not members, and the members themselves are explicitly not exposition-only members. Therefore, the formatting rules laid out in [objects.within.classes] do not apply in this case.  
GB 7 23.2.1 ¶ 4   Table 98 refers to a and b without defining them. Obviously they are the same as in Tables 96 and 97 but paragraph 23.2.1 / 4 fails to mention Table 98.   Add Table 98 to the scope of paragraph 23.2.1 / 4: In Tables 96, 97 and 98, X denotes ...   LWG    ACCEPTED  
ES 15 23.2.4 ¶ 8   Terminology for table 102 states that u denotes an identifier, yet u is not further referred to.   Delete “, u denotes an identifier.”   editor    ACCEPTED  
ES 16 23.2.4 ¶ 8   The condition “X::key_compare::is_transparent exists” does not specify that the type be publicly accessible.   Consider the public accessibility of X::key_compare::is_transparent and whether its potential inaccesibility should be banned for a compliant key_compare type.   LWG  2299  ACCEPTED  
GB 8 23.3.4   The current spec for std::dynarray is contradictory and broken, these open issues should be addressed:   See related LWG issues at http://cplusplus.github.io/LWG/lwg-active.html   LWG    ACCEPTED with MODIFICATIONS

The feature will be moved from the Standard to a Technical Specification.  
ES 17 23.4.4.5, 23.4.5.4   Sections are redundant with general associative container requirements at 23.2.4, table 102.   Delete sections.   LWG  2300  ACCEPTED  
ES 18 24.4   Current standard stream does not provide a mechanism for synchronized I/O   Provide a simple mechanism for performing synchronized I/O in multithreaded environments. See N3678   LWG    REJECTED

There was no consensus for this change.  
US 20 26   The Bristol meeting postponed consideration of N3648 because it was assumed that, if adopted, the proposal could be issued in some future Technical Specification. However, N3648 proposes to merge ISO/IEC 29124 into C++14, and it is unclear whether this would even be possible in a TS. Further, such merger is time-sensitive, since ISO/IEC 29124 will be up for review in 2015 and, if merged into C++14, can be retired (“withdrawn”) at that time.   Review and adopt for C++14 the proposal in N3648 (or in a successor document, if any).   LWG    REJECTED

There was no consensus for this change.  
CH 8 26.4   Specify user-defined literals for standard complex types.   Accept ISO/IEC JTC1 SC22 WG21 N3660 with the modification to use operator""if for complex.   LWG    ACCEPTED

See paper N3779.  
US 22 27.4.1 ¶ 4   Enable standard stream synchronization.   See N3535, N3665, N3678   LWG    REJECTED

There was no consensus for this change.  
GB 9 27.9.2 ¶ Tab 134   C11 no longer defines the dangerous gets() function. Even if we still refer to C99, which includes gets(), it would be preferable to strike std::gets() from <cstdio>  
  • Remove gets from Table 134 and Table 153.
  • Add a note to [c.files] saying the C function gets() is not part of C++
  • Add the removal of gets to Annex C.3.
 
LWG  2249  ACCEPTED  
GB 10 28.7 ¶ 12   The current wording is totally broken. Even if the whole proposed resolution at http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2018 isn't accepted the “bitwise or” part must be fixed.   Accept the proposed resolution.   LWG  2018  ACCEPTED  
GB 11 28.12 ¶ 1, 2   17.5.2.3 [objects.within.classes] defines the use of “exposition only” in the library:
The declarations for such member objects and the definitions of related member types are followed by a comment that ends with exposition only,
28.12.1 [re.regiter] and 28.12.2 [re.tokiter] have members which are preceded (not followed) by a comment ending “exposition only”.  
Reformat to follow 17.25.2.3   editor    ACCEPTED  
US 23 29   Resolve LWG issues 2130, 2138, 2159, 2165 on atomics.     LWG    ACCEPTED

Library issue 2165 is addressed by core language issue 1778.  
US 27 30   Resolve LWG issues 2080, 2097, 2100, 2104, 2120, 2135, 2142, 2185, 2186, 2190 on threads.     LWG    ACCEPTED  
US 28 30   Resolve LWG issues 2095, 2098, 2140, 2202 on threads. (lower priority)     LWG    ACCEPTED with MODIFICATIONS

Issues 2098 and 2140 have been addressed. The other two issues have been left open for possible future action.  
ES 19 30.3.1.3   std::thread destructor calls terminate() if the thread has not been joined. Changing this behaviour is unacceptable for existing code.   A different compatible class or wrapper should be provided to support RAII pattern and joining on destruction.   LWG    ACCEPTED with MODIFICATIONS

The Committee agreed not to change the referenced behavior, but there was no consensus for introducing an RAII wrapper.  
US 25 30.3.1.3   (Small defect) It is a defect that the thread destructor calls terminate() if the thread has not been joined. Thread is an RAII type and if the user is required to explicitly call .join() or similar in all cases if it has not been called already, this should be done automatically.   A resolution along the lines of that proposed in paper WG21/N3636 or similar would be acceptable.   LWG    REJECTED

There was no consensus for this change.  
US 24 30.6   (Severe defect) Like iterators, futures are essential vocabulary types whose major benefit is to permit composability between various providers (containers, async launchers) and consumers (algorithms, async consumers). To be usable as such, they must work predictably. It is a serious defect that ~future and ~shared_future might block unpredictably, depending only on whether the provider was launched with std::async. In all cases in the standard except where the provider is launched with std::async, ~future does not block; if it is launched with std::async, it may block. We understand there are desirable reasons to block (such as to achieve structured resource lifetime control) and not block (such as to achieve responsive nonblocking concurrency), but this decision should be up to each consumer of a given future to select explicitly, not baked inscrutably into an unpredictably dual-mode single future object whose consumer cannot select the appropriate behavior and furthermore the current workarounds to do so are effectively unusable. Futures may or may not block in their destructor, depending on how they were created. Many clients must rely on one behavior or the other, making it impossible to use futures as the general communication mechanism they would like to be.   A resolution along the lines of that proposed in paper WG21/N3637 or similar would be acceptable.   LWG    ACCEPTED

See paper N3776.  
GB 12 30.6.6 ¶ 9   Make it explicit that ~future and ~shared_future may block if the future originates from std::async.   Add notes to 30.6.6p9, 30.6.6p10, 30.6.7p11, 30.6.7p12 and 30.6.7p14 after the “releases any shared state” part of the effects saying
[Note: If this is the last reference to the shared state from a call to std::async with a policy of std::launch::async, then this will wait for the async task to complete (30.6.8p5) —end note]
Add a note to the first bullet of 30.6.4p5:
[Note: this may cause the function that released the shared state to block if this is the last reference to the shared state from a call to std::async with a policy of std::launch::async (30.6.8p5) —end note]
 
LWG    ACCEPTED

See paper N3776.  
US 26 30.6.8   Deprecate std::async due to the inability to reconcile the blocking semantics of the destructor of the returned values with the growing expected semantics of std::future's destruction. The problems of this inconsistency are outlined in N3630, but the solutions there didn't work. Another solution was proposed in N3637 which also did not satisfy people. Thus, we request to simply deprecate the problematic feature without changing any behavior in the library, and pave a path forward with new functionality that addresses these concerns.   Mark std::async as deprecated to help discourage its use and to reconcile the necessity of advising programmers to never pass or return the std::future received from std::async across an interface boundary. Change either 3.6.6p9 to specify that the std::future destructor does not block except when the value is one returned by the deprecated std::async function (or change 3.6.4p5 to specify the equivalent in terms of the shared state).   LWG    ACCEPTED with MODIFICATIONS

The behavior of ~future() with std::async was documented.

See paper N3776.  
FI 15 3.8 ¶ 7   See https://groups.google.com/a/isocpp.org/d/msg/std-proposals/93ebFsxCjvQ/myxPG6o_9pkJ
It seems that the restrictions of class types with reference members potentially cause a very hard implementation problem. It's palatable to re-fetch pointers and references, but how does one refresh a named reference to storage that was destroyed and re-initialized with placement new? In Ivchenkov's example, is it sufficient to destroy the storage_ union and re-initialize the whole union, instead of just its value member?  
Clarify what poor programmers need to do if they want to destroy+placement-new-initialize an object of class type, avoiding problems with reference members. Alternatively, consider the solutions presented by Ivchenkov. Our preference leans towards the direction of solutions 5 and 6.   CWG  1776  REJECTED

The Committee did not feel that this issue could be safely resolved in time for this revision of the Standard. However, it remains open for resolution in a future revision of the Standard.  
FI 6 12.1 ¶ 8   In a function returning void, return E; where E is of type void is permitted. In contrast, for constructors and destructors, this is not allowed, which is an arbitrary restriction for a corner case.   Remove the prohibition for return E; where E is of type void in constructors and destructors.   CWG    REJECTED

There was no consensus for the suggested change.  
CH 9 D.7   strstream is dangerous to use and the interface does not fulfill current library requirements.   Delete D.7 from the standard.
The CH NB is aware that this proposed change conflicts with the comment to not introduce any breaking changes. So the CH NB support for this comment is not unanimous.  
LWG    REJECTED

There was no consensus to remove this feature at this time.  
FI 13 7.6.1   It seems that a [deprecated] attribute fell between the cracks in the EWG->CWG workflow.   Flush the pipeline and add the [deprecated] attribute as proposed in N3394.   CWG    ACCEPTED

See paper N3760.  
FI 3 7.1.6.4 ¶ 6   As proposed in N3681, an auto specifier should not result in an initializer_list when used with a braced-init-list.   Adopt the solution proposed in N3681, make auto not deduce an initializer_list from a braced-init-list of a single element, make auto with a braced-init-list of multiple elements ill-formed   CWG    REJECTED

There was no consensus for the suggested change.  
FI 4 7.1.6.4 ¶ 2   Function return type deduction also covers conversion functions, that is operator auto. This is undesirable, because the whole point of a conversion function is to have an explicit (not implicitly deduced) return type. Also, only a single operator auto conversion function can exist in a class, limiting its utility.   Exclude conversion functions from return type deduction. Strike conversion-function-id from paragraph 2.   CWG  1670  REJECTED

There was no consensus for the suggested change. The corresponding core language issue, 1670, remains open to clarify the handling or reconsider the decision in a future revision of the Standard.  
FI 5 7.1.6.4 ¶ 2   Function return type deduction avoids the need to repeat the function body to specify the return type in function templates, e.g. the -> decltype(x1+x2) below is redundant:
 template<class T>
 auto f(T x1, T x2) -> decltype(x1+x2) { return x1+x2; }
However, that syntax does not cover exception specifications, again necessitating to repeat the function body:
 template<class T>
 auto f(T x1, T x2) noexcept(noexcept(x1+x2)) { return x1+x2; }
The specification machinery is readily available with core issue 1351, and the concerns about instantiating definitions to determine properties of the declaration have already been addressed with the introduction of function return type deduction.  
Reconsider noexcept(auto), or extend the meaning of auto return types to cause exception specification deduction, or find another syntactic means to express deduction of exception specifications.   CWG    REJECTED

There was no consensus for the suggested change at this time, but there was interest in exploring the possibility for a future revision.  
FI 8 5.1.2   A closure object is not of a literal type, the function call operator of a closure object type is not ever constexpr. These restrictions mean that lambdas cannot be used in constant expression. It seems unfortunate that lambdas and constant expressions do not work together. One of the benefits of relaxing the restrictions of constant expressions was that that relaxation allows writing template code that can be constexpr but is not sub-optimal at run-time and vice versa. It would seem reasonable to allow lambdas to be used in such code.   Allow lambdas to be used in constant expressions, if the captures of the lambda are of literal type, and if the call operator of the closure object type fulfils the requirements for a constant expression otherwise.   CWG    REJECTED

There was no consensus for the suggested change.  
FI 9 20.6.8   It is unacceptable that optional doesn't have an operator!=.   Define operator!= as the negation of operator==   LWG    ACCEPTED with MODIFICATIONS

The feature will be moved from the Standard to a Technical Specification.  
FI 10 20.6.8   It is unacceptable that optional doesn't have operator>, operator<= etc. relational operators in addition to operator<.   Define relational operators as they are defined for tuple and containers. In addition, adopt FI 7 to add a specialization of std::less for optional<T*>.   LWG    ACCEPTED with MODIFICATIONS

The feature will be moved from the Standard to a Technical Specification.  
FI 7 20.3.3, 20.4.2.9, 23.2.1, 10.10.5   std::less is specialized for pointer types so that it yields a total ordering. It seems that utility classes and containers in the library fail to establish the same total ordering, so eg. tuple<T*> or pair<T*, U*> or vector<T*> will not have a guaranteed total ordering, since there's no std::less specialization for them and the default std::less will invoke operator< which will use the operator< of the underlying type, hence failing to establish a total ordering.   Specialize std::less for pair, tuple, optional and containers for pointer types.   LWG    REJECTED

There was no consensus for this change at this time.  
FI 16 18.6 ¶ 1   According to N3396, “In this example, not only is an implementation of C++11 not required to allocate properly-aligned memory for the array, for practical purposes it is very nearly required to do the allocation incorrectly; in any event, it is certainly required to perform the allocation by a process that does not take the specified alignment value into account.” This represents a hole in the support for alignment in the language, which really needs to be filled.   Adopt the solution in N3396.   LWG    REJECTED

There was no consensus for this change.  
FI 12 14.5.6.2   In [c++std-ext-14217], Andrew Sutton writes:
If I have two functions:
template<typename... Args> void f() { }      // #1
template<typename T, typename U> void f() { } // #2
Should overload resolution be able to distinguish these? What I want is this:
f<int, int>() // Calls #2
f<char>() // Calls #1
f<int, char, float>() // Calls #1
What I get is, “no matching function” (using an older revision of GCC-4.8). I haven't thoroughly searched the standard for an answer, but I suspect the answer will also be “no”. If those are template parameters reflect function parameters, then the overloads can be distinguished.
template<typename... Args> void f(Args...);
template<typename T, typename U> void f(T, U);
It seems like this fact could be extended to non-deduced arguments as well. Just curious. The question/proposal would seemingly allow metaprogramming techniques that, in conjunction with decltype, allow extracting types from packs without having to resort to traits-like classes with nested typedefs.  
Make non-deduced function templates with pack arguments less viable than function templates without packs, that is, partially order currently equal/ambiguous candidates so that a pack is a worse match than no pack.   CWG    REJECTED

There was no consensus for a change in this revision of the Standard, but the idea is not ruled out for a future revision.  
FI 11 30.3.1.3 ¶ 1   It is most unfortunate that there is no RAII thread type in the standard. The lack of it leads to proliferation of custom solutions.   We do not support modifying ~thread to join; it has shipped in C++11, and people rely on the terminate() in it. It would be better to introduce a thread_guard that joins the underlying thread automatically upon destruction of the guard.   LWG    REJECTED

There was no consensus for introducing an RAII thread type.  
US 7 3.7, 5.3, 12.5, 17.6, 18.6, Annex C   Enable sized deallocation.   See N3663   CWG    ACCEPTED

See paper N3778.  
US 21 26.5, Annex D, etc.   The Bristol meeting postponed consideration of N3647 because it was assumed that, if adopted, the proposal could be issued in some future Technical Specification. However, N3647 proposes some deprecations, and it is unclear what it would mean to issue any deprecation in TS form.   Review and adopt for C++14 at least the deprecations proposed by N3647 (or by a successor document, if any). Preferably adopt the entire document, as its proposals are intertwined.   LWG    ACCEPTED with MODIFICATIONS

The deprecations will be added to the Standard.