Proposed resolution:

This wording is relative to N4920.

1. Edit [propagate_const.requirements] as indicated:

   -1- T shall be a cv-unqualified pointer-to-object type an object pointer type or a cv-unqualified class type for which decltype(*declval<T&>()) is an lvalue reference to object type; otherwise the program is ill-formed.

   -2- If T is an array type, reference type, pointer to function type or pointer to (possibly cv-qualified) void, then the program is ill-formed.

   -3- [Note: propagate_const<const int*> is well-formed but propagate_const<int* const> is not. — end note]

2. Edit [propagate_const.class_type_requirements] as indicated:

   -1- If T is class type then it shall satisfy the following requirements. In this sub-clause t denotes a non-constan lvalue of type T, ct is a const T& bound to t, element_type denotes an object type. denotes as_const(t).

[ 2022-11-12 Approved at November 2022 meeting in Kona. Status changed: Voting → WP. ]

[ 2022-10-19; Reflector poll ]

Set status to "Tentatively Ready" after eight votes in favour in reflector poll.

[ 2022-10-12; Jonathan provides improved wording ]

[ 2018-07-20 Priority set to 3 after reflector discussion ]

Previous resolution [SUPERSEDED]:

This wording is relative to N4758.

1. Edit [propagate_const.class_type_requirements] as indicated:

   -1- If T is class type then it shall satisfy the following requirements. In this sub-clause t denotes a non-const lvalue of type T, ct is a const T& bound to tas_const(t), element_type denotes an object type.

Addresses: fund.ts.v3

In the LFTSv3 prospective-working-paper N4758, [propagate_const.class_type_requirements] uses a strange turn of phrase:

"In this sub-clause, t denotes a non-const lvalue of type T, ct is a const T& bound to t, […]"

The last bit is strange: "ct is a const T& bound to t" is not how we usually say things. The specification-variables usually denote values, and values can't be references. Perhaps we could just say, "ct is as_const(t)"?