Document number:  N3770
Date:  2013-10-14
Reply to:  William M. Miller
 Edison Design Group, Inc.
 wmm@edg.com

 Alisdair Meredith
 lwgchair@gmail.com









C++ CD Comment Status

Rev. 1

This document summarizes the status of WG21 following the 2013-09 (Chicago) meting in addressing National Body comments on Committee Draft document N3690. It does not contain the results of the Library Working Group deliberations, which have not yet been fully processed.

In total, 85 comments were received. To date, 24 have been accepted as proposed, 1 have been accepted with modifications, 11 have been rejected, and 49 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.


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        
CH 2        
CH 3        
CH 4 LWG        
CH 5 CWG accepted    1772   
CH 6 CWG accepted    1762   
CH 7 LWG        
CH 8 LWG        
CH 9 LWG        
ES 1 CWG accepted       
ES 2 LWG        
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    1717   
ES 8 CWG accepted  2013-09-28    N3778 
ES 9 CWG rejected       
ES 10 CWG accepted  2013-09-28    N3760 
ES 11 LWG        
ES 12 LWG        
ES 13 LWG        
ES 14 LWG        
ES 15 editor        
ES 16 LWG        
ES 17 LWG        
ES 18 LWG        
ES 19 LWG        
FI 1 CWG accepted       
FI 2 LWG        
FI 3 CWG rejected       
FI 4 CWG rejected    1670   
FI 5 CWG rejected       
FI 6 CWG rejected       
FI 7 LWG        
FI 8 CWG rejected       
FI 9 LWG        
FI 10 LWG        
FI 11 LWG        
FI 12 CWG rejected       
FI 13 CWG accepted  2013-09-28    N3760 
FI 14 LWG        
FI 15 CWG     1776   
FI 16 LWG        
GB 1 CWG accepted    1759   
GB 2 CWG accepted    1787   
GB 3 CWG accepted    1760   
GB 4 CWG modified    1786   
GB 5 LWG        
GB 6 editor rejected       
GB 7 LWG        
GB 8 LWG        
GB 9 LWG        
GB 10 LWG        
GB 11 editor accepted       
GB 12 LWG        
NL 1 CWG accepted  2013-09-28    N3781 
US 1 editor rejected       
US 2 CWG accepted       
US 3 CWG     1441   
US 4 CWG        
US 5 LWG     2075   
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 accepted    1768   
US 10 CWG accepted    1761   
US 11 CWG rejected       
US 12 CWG rejected       
US 13 CWG accepted    1579   
US 14 LWG        
US 15 LWG        
US 16 LWG     2118   
US 17 LWG        
US 18 LWG        
US 19 LWG     2232   
US 20 LWG        
US 21 LWG        
US 22 LWG        
US 23 LWG        
US 24 LWG        
US 25 LWG        
US 26 LWG        
US 27 LWG        
US 28 LWG        

UNRESOLVED COMMENTS:

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

ID Responsible Issue
CH 1  
CH 2  
CH 3  
FI 15 CWG 1776 
US 3 CWG 1441 
US 4 CWG  
ES 15 editor  
CH 4 LWG  
CH 7 LWG  
CH 8 LWG  
CH 9 LWG  
ES 2 LWG  
ES 11 LWG  
ES 12 LWG  
ES 13 LWG  
ES 14 LWG  
ES 16 LWG  
ES 17 LWG  
ES 18 LWG  
ES 19 LWG  
FI 2 LWG  
FI 7 LWG  
FI 9 LWG  
FI 10 LWG  
FI 11 LWG  
FI 14 LWG  
FI 16 LWG  
GB 5 LWG  
GB 7 LWG  
GB 8 LWG  
GB 9 LWG  
GB 10 LWG  
GB 12 LWG  
US 5 LWG 2075 
US 14 LWG  
US 15 LWG  
US 16 LWG 2118 
US 17 LWG  
US 18 LWG  
US 19 LWG 2232 
US 20 LWG  
US 21 LWG  
US 22 LWG  
US 23 LWG  
US 24 LWG  
US 25 LWG  
US 26 LWG  
US 27 LWG  
US 28 LWG  

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.          
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.        
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.        
ES 1   N3674 still includes many unsolved core issues   Solve all the issues identified in N3674.   CWG    ACCEPTED  
ES 2   N3687 still includes many unsolved library issues   Solve all the issues identified in N3687.   LWG     
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     
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     
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<...>.   LWG     
US 4 1.9, 1.10   Resolve CWG issues 1441, 1466, 1470 on concurrency. (lower priority).     CWG     
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   
US 5 1.10, 29.4, 29.6.5   Resolve LWG issue 2075 on concurency.     LWG  2075   
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  
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  
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  
ES 9 5.1.2   Closure objects are never literal types   Consider allowing the generation of literal closure objects.   CWG    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  
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  
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  
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     
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     
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     
ES 11 20.4.2.4 ¶ 5-6   forward_as_tuple is not currently constexpr   Make forward_as_tuple constexpr.   LWG     
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     
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     
US 16 20.9.1.3   Resolve LWG issue 2118 on unique_ptr.     LWG  2118   
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     
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     
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     
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   
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     
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     
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     
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     
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     
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     
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     
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     
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     
US 22 27.4.1 ¶ 4   Enable standard stream synchronization.   See N3535, N3665, N3678   LWG     
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     
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     
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     
US 27 30   Resolve LWG issues 2080, 2097, 2100, 2104, 2120, 2135, 2142, 2185, 2186, 2190 on threads.     LWG     
US 28 30   Resolve LWG issues 2095, 2098, 2140, 2202 on threads. (lower priority)     LWG     
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     
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     
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     
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     
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     
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   
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     
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     
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     
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     
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     
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     
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