P2996 R5 Reflection for C++26

[wg21bot]

P2996R0 Reflection for C++26 (Barry Revzin)

[hanickadot]

SG7 polls at Kona 2023 meeting:

1) We want to block the adoption of P2996R1 for C++26 on waiting for a design that has multiple types of handlers based on reflected entities in addition to having just opaque std::meta::info?

SF/F/N/A/SA 0/0/1/5/27 Consensus against.

2) We want to make sure that in the future operator^ can change resulting types (in future C++ past 26)?

SF/F/N/A/SA 6/15/9/2/3 Consensus. (Not very strong)

3) Forward P2996R1 to EWG and LEWG?

SF/F/N/A/SA 24/6/3/0/0 Unanimous consensus.

Forwarding to EWG.

[JohelEGP]

The result of the second poll is a copy of the first, but the conclusion indicates consensus in the opposite direction.

[wg21bot]

P2996R1 Reflection for C++26 (Barry Revzin, Wyatt Childers, Peter Dimov, Andrew Sutton, Faisal Vali, Daveed Vandevoorde)

[wg21bot]

P2996R2 Reflection for C++26 (Barry Revzin, Wyatt Childers, Peter Dimov, Andrew Sutton, Faisal Vali, Daveed Vandevoorde, Dan Katz)

[hanickadot]

The result of the second poll is a copy of the first, but the conclusion indicates consensus in the opposite direction.

Sorry for slow reaction, I noticed it just now and fixed it from meeting minutes.

[jfbastien]

From today's joint EWG / LEWG discussion in Tokyo, SG16 needs to provide feedback on the papers because strings can be used to represent source code names and Unicode is tricky. @tahonermann I've tagged SG16 for this.

[tahonermann]

Thank you @jfbastien, I'll get a discussion scheduled. Related paper: P1953 (Unicode Identifiers And Reflection) tracked by #690.

[erichkeane]

EWG discussed this at length on Tuesday in Tokyo.

We took a poll to encourage more work, which received unanimous consent.

Extensive feedback was given, we expect to see this again, potentially in a telecon.

SG16 and SG15 both showed interest in discussing this, though the latter can occur asynchronously.

Author has also promised a revision of the paper, so marking needs-revision.

[Bigcheese]

SG15 looked at this paper in Tokyo and had the following thoughts:

• QoI
  • Implementations need to consider how region based diagnostic suppression works with define_class(). We would like to avoid different implementations have different source locations where the class definition exists and where diagnostic supression needs to occur.
  • Implementations need to strongly consider how users can view/debug reified code including via LSP like tools.
• Standard
  • We recommend prioritizing the support for attributes in reification features of reflection as they are widely used for tooling.

We have no blocking concerns.

[inbal2l]

2024-04-23 Library Evolution Telecon

P2996R2: Reflection for C++26

2024-04-23 Library Evolution Telecon Minutes

Champion: Daveed Vandervoode Chair: Inbal Levi Minute Taker: Ben Craig

Summary

We had an introduction (with questions) to the reflection proposal, including the content of the meta:: namespace. No polls were taken.

Next Steps

We had an introduction. Next time (May 7th) we still need to go over substitution and the error mechanism. Plan for next time - we'll finish the presentation and then go over each util in meta:: namespace and approve one by one (or by a small group of close utils).

[tahonermann]

SG16 reviewed P2996R2 during its 2024-04-24 meeting. No polls were taken. The review immediately followed discussion of P1953R0 (Unicode Identifiers And Reflection).

The discussion was focused on the character types and character encodings to use for names returned by functions like name_of(), qualified_name_of(), and display_name_of() and names consumed by data_member_spec() (via the name member of data_member_options_t). No conclusions have been reached yet; discussion will continue during the 2024-05-08 SG16 meeting. Topics to be discussed include:

1. Whether a distinct type should be defined for names as a way to facilitate support for multiple character types and/or encodings.
2. What will be required to print names via std::print() and/or iostreams.
3. Requirements for identifiers supplied in names; C++ requires all identifiers to be in Unicode normalization form C (NFC).

A new revision of the paper will eventually be required to specify details for the above topics.

[inbal2l]

2024-05-07 Library Evolution Telecon

P2996R2: Reflection for C++26

2024-05-07 Library Evolution Telecon Minutes

Champion: Daveed Vandervoode Chair: Inbal Levi Minute Taker: Ben Craig

Summary

POLL: LEWG supports the following implementation strategy (as the first delivery of P2996, may be evolved in a followup paper):

1. Fails to evaluate to a constant (possibly to be evolved into 4 for some of the functions)
2. A vector containing one invalid reflection (like a NaN)
3. std::expected<std::vector, E> holding an error
4. Throw a constexpr exception (the feature is in progress)

(vote for all the options that you support)

Option 1	Option 2	Option 3	Option 4
12	1	3	14

Attendance: 24 # of Authors: 4 Author's Position: (multi votes are possible) 4 x Option 1, 3x Option 4 Outcome: Support for options 1,4

Considering the options for "Substitute" input args:

1. substitute(info, std::span<info const>)
2. substitute(info, std::vector<info const>)

3.  template <range R = span<info const>>
        requires same_as<range_value_t<R>, info>
    consteval info substitute(info, R&&);

POLL: Add range overloads to functions that currently take spans (option 3).

Outcome: No objection to unanimous consent. (Authors will apply to all functions which take a "span" arg and publish a new paper revision)

Next Steps

Authors will add range overload to all functions which take a "span" arg and publish a new paper revision.

Inbal: Next time we see the paper, we will discuss the following:

• Consider the return value (vector) of members_of(info r, Fs… filters);
• Consider the format to pass filters into “members_of(info r, Fs… filters)” (and addition of functions for the common cases)
• Continue review of functions

[tahonermann]

SG16 discussed P2996R2 again during its 2024-05-08 meeting. No polls were taken. The review immediately followed discussion of a draft of P3258R0 (Formatting of charN_t); a paper that has not yet been published.

The discussion of P3258R0 prior to further discussion of P2996R2 was to get a sense of whether the facilities proposed by the former would suffice to meet perceived requirements for the latter; specifically, whether it will suffice to enable names/identifiers provided by reflection facilities to be printed. While such a determination cannot be unequivocally made in the absence of consensus for P3258R0 (which has not yet been sufficiently discussed for SG16 to have taken a position on the proposed design as a whole), the discussion indicated that it likely would be sufficient though support for iostreams would still be desired.

My impression of the emerging consensus for the handling of character encoding matters in reflection facilities is as follows:

1. A dedicated class type should be introduced to represent names. That type should:
   1. Provide translation between an internal representation of a name (that is backed by implementation managed statically allocated storage) and both a char-based string in the ordinary literal encoding and a char8_t-based string in the UTF-8 encoding (with support for additional encodings optionally added at a later time if warranted). These translations must be lossless so that a name provided by reflection facilities can also be consumed by them; conversions must not use transliteration or convert to canonically equivalent characters. If an encoding is unable to accommodate a given name due to lack of representation for some of its characters, an error must be produced (e.g., the program is ill-formed if in a manifestly constant-evaluated context and an exception is thrown otherwise).
   2. Enforce requirements with respect to identifier syntax per [lex.name] (e.g., identifier characters in XID_start and XID_continue and normalized in Unicode NFC).
   3. Have a corresponding std::formatter specialization to enable convenient formatting of names using std::format() and std::print().
   4. Be returned by reflection facilities that provide names.
   5. Be accepted by reflection facilities that consume names.
2. Names should not be provided in an escaped representation due to the potential for such names to be used with interfaces that are not designed to work with such names; e.g., interfaces that provide bindings for other languages.

Additionally, questions were asked regarding whether the reflection facilities should distinguish between names and identifiers, but no positions were expressed or established. The authors are encouraged to consider such matters since they will become relevant when it becomes necessary to reflect names for, e.g., constructors and destructors, conversion operators, overloaded operators, user-defined literals, etc...

[wg21bot]

P2996R3 Reflection for C++26 (Barry Revzin, Wyatt Childers, Peter Dimov, Andrew Sutton, Faisal Vali, Daveed Vandevoorde, Dan Katz)

[inbal2l]

2024-05-28 Library Evolution Telecon

P2996R3: Reflection for C++26

2024-05-28 Library Evolution Telecon Minutes

Champion: Dan Katz Chair: Inbal Levi Minute Taker: Ben Craig

Summary

POLL: We are comfortable with “is_incomplete_type” (and similar functions) allowing behavior such as “instantiating the definition”.

Outcome: No objection to unanimous consent.

POLL: We want to keep the is_incomplete_type (and its ability to observe stateful metaprogramming that depends on completeness) (to be determined by EWG’s decision on the wider topic of stateful metaprogramming).

SF	F	N	A	SA
14	5	1	0	0

Attendance: 30 # of Authors: 4 Author's Position: SFx4 Outcome: Strong consensus in favor

Considering the options for "Substitute" input args:

POLL: Add range overloads to functions that currently take spans (option 3). And remove requires. LEWG is happy with the signatures of name_of, qualified_name_of, display_name_of (pending on SG16’s approval).

Outcome: No objection to unanimous consent (in favor)

Next Steps

LEWG went over and approved:

1. name_of, qualified_name_of, display_name_of (source_location_of) (pending SG16’s approval of return values)
2. is_incomplete_type (pending EWG’s approval of the behavior).
3. Modification of input param as requested by LEWG on (2024-05-07) - modify input param of functions taking a range (alternatives considered were vector, span) into (ranges version):

    template <range R = span<info const>>
        requires same_as<range_value_t<R>, info>
    consteval info substitute(info, R&&);

LEWG also gave the feedback:

• We are comfortable with “is_incomplete_type” (and similar functions) allowing behavior such as “instantiating the definition” (pending EWG’s approval of the behavior).

The authors asked for input on (an email will be sent to LEWG reflector):

• meta implementations in terms of type_trait
• Request for a clear API to query accessible members (and not private ones) (can the user know if the program is doing access bypassing?)

P2996R3 will be seen again in St. Louis, to continue the review of the library API.

[tahonermann]

SG16 will review P2996R3 in the near future, but it won't happen before the St. Louis meeting. @inbal2l, perhaps it would make sense to schedule time for a combined LEWG/SG16 meeting in St. Louis. The paper will need some updates to address SG16 concerns.

[inbal2l]

@tahonermann - sounds good, let's coordinate offline. (Note that we left the final decision on "name_of, qualified_name_of, display_name_of (source_location_of)" functions family to SG16, but we can definitely make this decision during a joint session).

[jfbastien]

Seen in EWG in St Louis:

Poll: P2996R4 — Reflection for C++26, forward to CWG for inclusion in C++26.

SF	F	N	A	SA
20	11	1	0	0

[ben-craig]

2024-06-26 Library Evolution St. Louis Meeting (First Afternoon Session)

P2996R4: Reflection for C++26

2024-06-26 Library Evolution St. Louis Minutes

Champion: Dan Katz Chair: Ben Craig & Robert Leahy Minute Taker: Guy Davidson

Summary

POLL: Remove filtering from the meta::info member query functions

SF	WF	N	WA	SA
10	15	0	0	0

Attendance: 23 + 8 # of Authors: 4 Author Position: 3xWF, 1 abstain Outcome: Unanimous consent

ACTION: Provide wording to update SD8 - to stress we avoid from making guarantees for stability for reflecting on the standard library internals between standard versions.

ACTION: Updated 5.2.1 16.4.5.2.1 [namespace.std] p.7 To provide general non-promise for reflection on the standard lib

__POLL: Remove test_trait from std::meta__

SF	WF	N	WA	SA
5	12	6	1	0

Attendance: 23 + 8 # of Authors: 4 Author Position: 2xN 2xWF Outcome: Consensus in favor

ACTION: Propose a resolution as instructed for the functions: offset_of(...), bit_offset_of(...)

Next Steps

Apply the changes requested, including:

1. Provide wording to update SD8 - to stress we avoid from making guarantees for stability for reflecting on the standard library internals between standard versions.
2. Updated 5.2.1 16.4.5.2.1 [namespace.std] p.7: To provide general non-promise for reflection on the standard lib
3. Remove “filters” from the meta::info member query functions
4. Remove ‘test_trait’ from std::meta (can be added later, but design space is too wide and should be explored separately, in a follow-up paper).
5. Propose a resolution as instructed for the functions: offset_of(...), bit_offset_of(...)

We will continue to review P2996R4 during St. Louis. Next session will continue the discussion on bit_offset_of

[jensmaurer]

CWG 2024-06-27 in St. Louis: Initial partial inspection.

[wg21bot]

P2996R4 Reflection for C++26 (Barry Revzin, Wyatt Childers, Peter Dimov, Andrew Sutton, Faisal Vali, Daveed Vandevoorde, Dan Katz)

[inbal2l]

(NOTE: Issue updates are out of order, this discussion occurred on 2024-06-26)

2024-06-26 Library Evolution St. Louis Meeting (Second Afternoon Session)

2024-06-26 Library Evolution St. Louis Minutes

Champion: Dan Katz Chair: Inbal Levi / Khalil Estell / Tom H (represents SG16) Minute Taker: Ben Craig

Summary

For the functions in R4 under: [meta.reflection.names] Reflection names and locations name_of(info r), qualified_name_of(info r), display_name_of(info r).

display_name_of

Definition: “display_name_of”: used to return implementation defined name (not guaranteed to be identifier)

POLL: “display_name_of” should be named:

Option	Votes
display_name_of (no change)	21
display_string_of	15
diagnostic_string_for	4
diagnostic_representation_of	6

POLL: Make “display_name_of” function:

Option	Votes
fails to be a constant expression (later to possibly be modified into: throw a static exception)	5
return an empty string	7
return nullopt	0
return a new type that can be queried *	1
return non empty implementation defined string	29

* Define a class type that encapsulates names such that unnamed entities, synthesized names, identifers, named operators, constructor/destructor, ... can be differentiated

if the “entity” can’t have a name.

POLL: Make “display_name_of” function:

Option	Votes
fails to be a constant expression (later to possibly be modified into: throw a static exception)	0
return an empty string	9
return nullopt	1
return a new type that can be queried *	1
return non empty implementation defined string	28

* Define a class type that encapsulates names such that unnamed entities, synthesized names, identifers, named operators, constructor/destructor, ... can be differentiated

if the “entity” is unnamed.

name_of

Definition: “name_of”: the unqualified name of an entity

POLL: Make “name_of” function:

Option	Votes
fails to be a constant expression (later to possibly be modified into: throw a static exception)	24
return an empty string	13
return nullopt	3
return a new type that can be queried *	3

* Define a class type that encapsulates names such that unnamed entities, synthesized names, identifers, named operators, constructor/destructor, ... can be differentiated

if the “entity” can’t have a name.

POLL: Make “name_of” function:

Option	Votes
fails to be a constant expression (later to possibly be modified into: throw a static exception)	4
return an empty string	22
return nullopt	10
return a new type that can be queried *	5

* Define a class type that encapsulates names such that unnamed entities, synthesized names, identifers, named operators, constructor/destructor, ... can be differentiated

if the “entity” is unnamed.

Next Steps

We will continue to review "Reflection" during St. Louis. The authors will apply the requested changes and publish an R5 of the paper, which will continue to be reviewed in telecons.

[inbal2l]

2024-06-27 Library Evolution St. Louis Meeting (First Morning Session)

P2996R4: Reflection for C++26

2024-06-27 Library Evolution St. Louis Minutes

Champion: Dan Katz Chair: Inbal Levi & Robert Leahy Minute Taker: Mark H

Summary

ACTION: Consider a model of using traits to avoid ill-formed calls for functions in general for this.

ACTION: Fix the offset_of formula.

ACTION: Change formula from using 8 to using the number of bits in a byte: V - number_of_bits_in_a_bit * offset_of(v) (overruled by the request to reconsider the interface for offset_of in general).

__POLL: LEWG would like the authors of P2996 to explore the direction for offset_of:__

1. Absolute location function (to enable iterating fully): absolute_bit_offset_of
2. “offset_of” function - return struct which holds both: byte_offset, bit_offset (in that order)
3. As in the proposal: bit_offset_of, byte_offset_of (“C interface”)

1	2	3
3	22	6

Attendance: 22 IP + 8 R # of Authors: 3 Outcome: Option 2 got the most support

__POLL: We approve the interface of “is_public, is_protected, is_private” as described in P2996R4 Attendance: 22 IP + 8 R # of Authors: 3 Outcome:__ No objection to unanimous consent.

ACTION: consider adding trait: “is_friend“ (explore either in this paper or in a follow-up one)

ACTION: consider adding a trait “is_overload” (explore either in this paper or in a follow-up one)

Summary: LEWG decided there’s no need to reconsider the name “is_override” and asked for traits (either in this paper or in a follow-up one):

1. “Is_overload”
2. “is_friend”

We also asked that the offset_of interface will be modified, and approved the interface for “is_virtual”, “is_pure_virtual”, “is_override” from P2996R4.

Next Steps

Authors will apply the requested changes and publish P2996R5. Between now and then, we will continue the review on P2996R4 during St. Louis (and in telecons after).

[inbal2l]

2024-06-27 Library Evolution St. Louis Meeting (Second Morning Session)

P2996R4: Reflection for C++26

2024-06-27 Library Evolution St. Louis Minutes

Champion: Dan Katz Chair: Fabio & Ben Minute Taker: Khalil

Summary

List of actions:

1. Phrase note that make sure there are no guarantees for reflected library internals between standard versions (or withing same version with DRs).
2. Add a note about template members do not work unless instantiated (useful to LWG)
3. Remove lambda and the pointer case from is_noexcept
4. Add member qualifiers of functions (authors agree)

POLL: We approve the interface of

• is_deleted
• is_defaulted
• is_explicit
• is_bit_field

Attendance:: 23 IP + 8 R # of Authors:: 4 Outcome: Unanimous consent

POLL: We approve of the interface of:

• is_const
• is_volatile

SF	F	N	A	SA
12	10	0	1	0

Attendance: 23 IP + 8 R Authors's position: 3xSF, F (4 authors) Outcome: Strong Consensus

A: I'd like to see the four qualifier properties together as a group.

POLL: We approve of the interface of:

• is_noexcept with the restricted application to functions and function types.

Attendance:: 23 IP + 8 R # of Authors:: 4 Outcome: Unanimous consent

Next Steps

Authors will apply the requested changes and publish P2996R5. Between now and then, we will continue the review on P2996R4 during St. Louis (and in telecons after).

[inbal2l]

2024-08-11 LEWG Review Status

Functions approved so far:

1. [meta.reflection.substitute]: template <reflection_range R = span<info const>> consteval info substitute(info templ, R&& arguments);
2. [meta.reflection.queries]:
   1. consteval bool is_incomplete_type(info r);
   2. consteval bool is_public(info r);
   3. consteval bool is_protected(info r);
   4. consteval bool is_private(info r);
   5. consteval auto is_virtual(info r) -> bool;
   6. consteval auto is_pure_virtual(info entity) -> bool;
   7. consteval auto is_override(info entity) -> bool;
   8. consteval auto is_deleted(info entity) -> bool;
   9. consteval auto is_defaulted(info entity) -> bool;
   10. consteval auto is_explicit(info entity) -> bool;
   11. consteval auto is_bit_field(info entity) -> bool;
   12. consteval auto is_const(info r) -> bool;
   13. consteval auto is_volatile(info r) -> bool;

Changes requested (should be updated in R5, not yet published as of now)

1. Modify is_noexcept according to the poll taken on 2024-06-27: https://github.com/cplusplus/papers/issues/1668#issuecomment-2248317988
2. Remove test_trait
3. Modify the shape of: offset_of(...), bit_offset_of(...) - turn into a single function offset_of(...) which returns a struct which holds both: byte_offset, bit_offset (in that order)

[inbal2l]

2024-08-13 Library Evolution Telecon

P2996R5: Reflection for C++26

2024-08-13 Library Evolution Telecon Minutes

Champion: Dan Katz Chair: Inbal Levi Minute Taker: Daveed Vandevoodre

Summary

(Polls are in the minutes and are not attached here this time, as they are equivalent to the list below and don't provide additional info over the summary)

We approved the following functions as is:

1. consteval auto has_static_storage_duration(info r) -> bool;
2. consteval auto has_automatic_storage_duration(info r) -> bool;
3. consteval auto has_thread_storage_duration(info r) -> bool;
4. consteval auto is_lvalue_reference_qualified(info r) -> bool;
5. consteval auto is_rvalue_reference_qualified(info r) -> bool;
6. consteval auto is_namespace_member(info entity) -> bool;
7. consteval auto is_namespace(info entity) -> bool;
8. consteval auto is_function(info entity) -> bool;
9. consteval auto is_variable(info entity) -> bool; (with a request to add clarifying example and reference to term)
10. consteval auto is_type(info entity) -> bool;
11. consteval bool is_function_template(info r);
12. consteval bool is_variable_template(info r);
13. consteval bool is_class_template(info r);
14. consteval bool is_alias_template(info r);
15. consteval bool is_conversion_function_template(info r);
16. consteval bool is_operator_function_template(info r);
17. consteval bool is_literal_operator_template(info r);
18. consteval bool is_constructor_template(info r);
19. consteval bool is_concept(info r);
20. consteval bool is_structured_binding(info r);
21. consteval bool is_value(info r); (with a request to add clarifying example and reference to term)
22. consteval bool is_object(info r); (with a request to add clarifying example and reference to term)
23. consteval bool has_template_arguments(info r);
24. consteval bool is_class_member(info r);
25. consteval bool is_namespace_member(info r);
26. consteval bool is_nonstatic_data_member(info r);
27. consteval bool is_static_member(info r);
28. consteval bool is_base(info r);
29. consteval bool is_data_member_spec(info r);
30. consteval bool has_default_member_initializer(info r);
31. consteval bool is_conversion_function(info r);
32. consteval bool is_operator_function(info r);
33. consteval bool is_literal_operator(info r);

We also approved the following function with modification:

34. consteval auto is_complete_type(info entity) -> bool; (in oppose to is_incomplete_type in the paper, with the proper wording change)

ACTIONS:

1. We asked for further investigation by CWG of the terms and results expected for:
   1. consteval auto has_internal_linkage(info r) -> bool;
   2. consteval auto has_module_linkage(info r) -> bool;
   3. consteval auto has_external_linkage(info r) -> bool;
   4. consteval auto has_linkage(info r) -> bool;
   5. consteval auto is_alias(info entity) -> bool; (one option which came up is to split into two separate functions, one covers template aliases)
2. Please add blanket wording for allowing terms modification in speck to result with different values when queried by reflection functions in the future (in addition to previously requested blanket wording which: (1) generally making no promises for reflection on the standard library, and (2) between standard versions).
3. Please add "concepts" to the list returning true for is_template: P2996R4 pnum_141
4. (possible) ACTION: For future paper: add "is_callable" (in addition to the "is_function" approved below).

Next Steps

LEWG will see P2996R5 again, and will continue the review. Next time we will review:

1. Approve changes between R4→R5 (from St. Louis).
2. Continue review starting after: “is_literal_operator”.

LEWG will see in a future revision (Once the authors will apply the feedback from Core):

1. consteval auto has_internal_linkage(info r) -> bool;
2. consteval auto has_module_linkage(info r) -> bool;
3. consteval auto has_external_linkage(info r) -> bool;
4. consteval auto has_linkage(info r) -> bool;
5. consteval auto is_alias(info entity) -> bool;

[wg21bot]

P2996R5 Reflection for C++26 (Barry Revzin, Wyatt Childers, Peter Dimov, Andrew Sutton, Faisal Vali, Daveed Vandevoorde, Dan Katz)

[FabioFracassi]

2024-08-20 Library Evolution Telecon

P2996R5: Reflection for C++26

2024-08-20 Library Evolution Telecon Minutes

Champion: Dan Katz Chair: Fabio Fracassi Minute Taker: Daveed Vandevoorde

Summary

We approved the following functions as is:

1. consteval auto is_template(info r) -> bool
2. consteval auto template_of(info r) -> info
3. consteval auto template_arguments_of(info r) -> vector<info>
4. consteval auto dealias(info r) -> info
5. consteval auto can_substitute(info r, R&& args) -> bool
6. consteval auto is_enumerator(info r) -> bool
7. consteval auto is_constructor(info r) -> bool
8. consteval auto is_default_constructor(info r) -> bool
9. consteval auto is_copy_constructor(info r) -> bool
10. consteval auto is_move_constructor(info r) -> bool
11. consteval auto is_assignment(info r) -> bool
12. consteval auto is_copy_assignment(info r) -> bool
13. consteval auto is_move_assignment(info r) -> bool
14. consteval auto is_destructor(info r) -> bool

We also approved the following function with modification:

15. consteval auto reflect_value(T expr) -> info
16. consteval auto reflect_object(T& expr) -> info
17. consteval auto reflect_function(T& expr) -> info

Change: the requirement on T should be a "Mandate" instead of "Constant When"

18. consteval auto is_special_member(info r) -> bool (changed into: consteval auto is_special_member_function(info r) -> bool)

Next Steps

Authors to apply the following changes:

1. Rename is_special_member to is_special_member_function .
2. Clarify the special member wording wrt template member functions.

For future reviews:

1. Consider whether only elegible member functions should be exposed in template specialization when reviewing "members_of" function set (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2996r5.html#meta.reflection.member.queries-reflection-member-queries)
2. Considering the decision in the previous section, consider adding is_elegible to query the eligibility of an overload (assuming exposed).

We will continue review on meta.reflection.queries section (note there have been some reordering of functions)