Proposed resolution:

This wording is relative to N4971.

1. Modify [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 ([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 ([stmt.return]) function call expression ([expr.call]) (including initialization of the returnedparameter object or reference) is considered.

[ 2025-10-17; Reflector poll. ]

Set priority to 2 after reflector poll.

"I think the P/R is either insufficient or redundant: either remove the words "To is neither array nor function type and" (because they are unnecessary assuming the P/R's definition of `conv-dest` must be well-formed) or else add "To is neither cv void nor array nor function type" (because the P/R's definition of `conv-dest` remains ill-formed in cases like is_convertible_v<int, void>."

"Might need to revisit the hack added to [stmt.return] by P2748R5."

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 together.