Casey Carter

Created on 2018-04-10.00:00:00, last changed 2018-08-22.12:55:05.


Date: 2018-08-22.12:55:05

Proposed resolution:

This wording is relative to N4741.

  1. In [meta.unary.prop] Table 42, change the Precondition text for is_assignable, is_trivially_assignable, and is_nothrow_assignable as follows:
    remove_cvref_t<T> and remove_cvref_t<U> shall be complete types, cv void, or arrays of unknown bound.
  2. In [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:
    remove_cvref_t<T> shall be a complete type, cv void, or an array of unknown bound.
Date: 2018-08-22.12:55:05

[ 2018-08 Batavia Monday issue discussion ]

Issues 2797, 2939, 3022, and 3099 are all closely related. Walter to write a paper resolving them.

Date: 2018-04-16.18:17:22

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:

  • is_copy_assignable<T>, equivalent to is_assignable<T&, const T&>,
  • is_move_assignable<T>, equivalent to is_assignable<T&, T>,
  • is_trivially_assignable<T, U>, equivalent to is_assignable<T, U> && /* magic */,
  • is_trivially_copy_assignable<T>, equivalent to is_assignable<T&, const T&> && /* magic */,
  • is_trivially_move_assignable<T>, equivalent to is_assignable<T&, T> && /* magic */,
  • is_nothrow_assignable<T, U>, equivalent to is_assignable<T, U> && noexcept(declval<T>() = declval<U>()),
  • is_nothrow_copy_assignable<T>, equivalent to is_assignable<T&, const T&> && noexcept(declval<T&>() = declval<const T&>()),
  • is_nothrow_move_assignable<T>, equivalent to is_assignable<T&, T> && noexcept(declval<T&>() = declval<T>()), and

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.

Date User Action Args
2018-08-22 12:55:05adminsetmessages: + msg10096
2018-04-10 20:38:51adminsetmessages: + msg9815
2018-04-10 00:00:00admincreate