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.

4028. std::is_(nothrow_)convertible should be reworded to avoid dependence on the return statement

Section: 21.3.7 [meta.rel] Status: New Submitter: Jiang An Opened: 2023-12-18 Last modified: 2023-12-22

Priority: Not Prioritized

View other active issues in [meta.rel].

View all other issues in [meta.rel].

View all issues with New status.

Discussion:

The current specification for std::is_convertible is sensitive to the requirements for the return statements. As a result, the requirements were accidentally changed by P0135R1 and then changed back by CWG issue 2426. The current revision of P2748 also plans to change the wording for std::is_convertible to avoid actual behavioral changing.

IMO it's better to specify std::is_convertible in a such way that is independent to return statements. The proposed resolution matches what mainstream implementations do, and should resolve LWG 3400(i) together.

Proposed resolution:

This wording is relative to N4971.

  1. Modify 21.3.7 [meta.rel] as indicated:

    Table 49 — Type relationship predicates [tab:meta.rel]
    Template Condition Comments
    […] […] […] 
    template<class From, class To>
struct is_convertible;
    		see below From and To shall be
    complete types, cv void, or arrays of
    unknown bound. 
    template<class From, class To>
struct is_nothrow_convertible;
    		is_convertible_v<From,
    To>     is true and the
    conversion, as defined by
    is_convertible, is known
    not to throw any exceptions
    either both From and To
    are cv void, or the function call
    expression used for specifying is_convertible
    is non-throwing     (7.6.2.7 [expr.unary.noexcept])     		From and To shall be
    complete types, cv void, or arrays of
    unknown bound.
    […] […] […]

    -5- The predicate condition for a template specialization is_convertible<From, To> shall be satisfied if and only if the return expression in the following code would be well-formed, including any implicit conversions to the return type of the function: 

    To test() {
  return declval<From>();
}

    1. (?.1) — either both From and To are cv void, or

    2. (?.2) — To is neither array nor function type and the function call expression conv-dest(declval<From>()) would be well-formed when treated as an unevaluated operand, where conv-dest is a hypothetical function declared as

      void conv-dest(To) noexcept;

      .

    [Note 2: This requirement gives well-defined results for reference types, array types, function types, and cv void. — end note]

    Access checking is performed in a context unrelated to To and From. Only the validity of the immediate context of the expression of the return statement (8.7.4 [stmt.return]) function call expression (7.6.1.3 [expr.call]) (including initialization of the returnedparameter object or reference) is considered.