Proposed resolution:

This wording is relative to N5014.

1. Modify [meta.reflection.extract] as indicated:

   [Drafting note: In bullet (7.1) we apply an additional drive-by fix for the broken "`T` is" construction before the `is_convertible_v` condition]

   template<class T>
     consteval T extract-member-or-function(info r); // exposition only
   

   -?- Given a function type `F`, let the type `F` with `noexcept` be the same type, except that the parameters-and-qualifiers in the noptr-declarator describing the type contain `noexcept(true)`.

   -6- Returns: […]

   -7- Throws: `meta::exception` unless

   1. (7.1) — `r` represents a non-static data member with type X, that is not a bit-field, that is a direct member of class `C`, `T` and `C` are similar types ([conv.qual]), and `T` is is_convertible_v<X C::*, T> is `true`;

   2. (7.2) — `r` represents an implicit object member function with type `F` or `F` with `noexcept` that is a direct member of a class `C`, and `T` is `F C::*`; or

   3. (7.3) — `r` represents a non-member function, static member function, or explicit object member function of function type `F` or `F` with `noexcept`, and `T` is `F*`.

[ 2025-08-27; Reflector poll ]

Set priority to 3 after reflector poll.

"phrase this in terms of the quoted type description in [dcl.fct] (see before bullet 1.6, The type of the declarator-id in D is...)."

This is a follow-up from https://github.com/cplusplus/#8008

In [meta.reflection.extract] paragraph 7, the type "`F noexcept`" is used, presumably with the intent that `noexcept` would be "injected" into the parameters-and-qualifiers of the declarator associated with `F`.

However, the syntax `F noexcept` is ill-formed, and does not have that intended effect. There ought to be a better way to phrase that.