This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 21.3.3 [meta.type.synop] Status: New Submitter: Casey Carter Opened: 2018-04-10 Last modified: 2023-06-12
View other active issues in [meta.type.synop].
View all other issues in [meta.type.synop].
View all issues with New status.
LWG 2939 suggests that the the preconditions of the type traits need reevaluation. This issue focuses specifically on is_assignable and, by extension, its variants:
We note a discrepancy: is_copy_assignable<T> requires T to be a complete type, but the equivalent form is_assignable<T&, const T&> does not. The requirement for is_copy_assignable<T> seems sensible, since there's no way to determine whether or not the assignment declval<T&>() = declval<const T&>() is well-formed when T is incomplete. It seems that the same argument should apply to all of the above "assignable" traits, and that they must require that the referent type is complete when given a reference type parameter to be implementable.
[2018-08 Batavia Monday issue discussion]
Issues 2797, 2939, 3022, and 3099 are all closely related. Walter to write a paper resolving them.
LWG discussions. Set priority to 2.
P1285R0 is related to this issue.
This wording is relative to N4741.
- In 188.8.131.52 [meta.unary.prop] Table 42, change the Precondition text for is_assignable, is_trivially_assignable, and is_nothrow_assignable as follows:T and U shall be complete types,
cvvoid, or arrays of unknown bound.
- In 184.108.40.206 [meta.unary.prop] Table 42, change the Precondition text for is_copy_assignable, is_move_assignable, is_trivially_copy_assignable, is_trivially_move_assignable, is_nothrow_copy_assignable, and is_nothrow_move_assignable as follows:T shall be a complete type,
cvvoid, or an array of unknown bound.