3099. is_assignable<Incomplete&, Incomplete&>

Section: 21.3.3 [meta.type.synop] Status: Open Submitter: Casey Carter Opened: 2018-04-10 Last modified: 2024-08-21

Priority: 2

View other active issues in [meta.type.synop].

View all other issues in [meta.type.synop].

View all issues with Open status.

Discussion:

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.

[2020-02-14, Prague]

LWG discussions. Set priority to 2.

[2023-06-12; Varna]

P1285R0 is related to this issue.

Previous resolution [SUPERSEDED]:

This wording is relative to N4741.

  1. In 21.3.5.4 [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 21.3.5.4 [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.

[2024-08-21; Jonathan provides improved wording]

During LWG telecon review Tomasz pointed out that we don't always require a complete type for the right operand of an assignment. Given T::operator=(U&) we should be able to give a correct answer for is_assignable<T&, U&> whether of not U is complete. This also affects e.g. is_constructible<T, U&> if T::T(U&) exists.

So for the examples above, remove_cvref_t<U> is not needed to give a correct answer. However, if T::operator=(U&) does not exist, then we do need U to be complete so we can tell if there is an implicit conversion sequence to T or another type that can be assigned to T. We do not know how to solve this problem, and it's broader than just is_assignable. It was suggested to make an incremental improvement to is_assignable and open a new issue for the broader issue.

Proposed resolution:

This wording is relative to N4988.

  1. In 21.3.5.4 [meta.unary.prop] Table 51, change the Precondition text for is_assignable, is_trivially_assignable, and is_nothrow_assignable as follows:
    remove_cvref_t<T> and U shall be complete types, cv void, or arrays of unknown bound.
  2. In 21.3.5.4 [meta.unary.prop] Table 51, 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.