Rostistlav Khlebnikov will present it to LWG.
Jason Liu is also interested in attending and participating to the discussion.

P0792R4 function_ref: a non-owning reference to a Callable (Vittorio Romeo)

P0792R5 function_ref: a non-owning reference to a Callable (Vittorio Romeo)

This was not adopted for C++20. Removing the "C++20" label.

LWG started this review in July (catching up on the notes).

https://wiki.edg.com/bin/view/Wg21summer2020/P0792R5-20200731

Will continue review when author is available.

P2265R0: Renaming any_invocable

P0288R7: any_invocable

P0792R5: function_ref

2020-12-08 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Kevlin Henney

Minute Taker: Ben Craig

Start: 2020-12-08 10:09 Pacific

Kevlin's ordered preferences for the facility in P0288 (any_invocable):
0. move_only_function.

1. move_function.
2. movable_function.

Note that the order Kevlin wrote in P2265 is incorrect; the above is the right version.

Other options for the facility in P0288 (any_invocable):

• any_invocable (status quo).
• unique_function.
• any_function.

What type-erased facilities use the any naming pattern?

• any.
• any_invocable (proposed).
• any_executor (proposed).

We also have the option of adding aliases to make function consistent with whatever we choose.

We should at least have consensus that function, function_ref, and any_invocable should be consistently named.

Should we name this for what it is or what it contains?

If we decide to not call the move-only function wrapper in P0288 any_invocable, that will have implications for everything else that is currently following the any pattern.

POLL: The facilities introduced in P0288 and P0792 should have function in their names.

Attendance: 38

Outcome: Weak consensus in favor.

Existing precedent and policy for the any-prefix naming pattern.

• P1851.
• P2148 (not adopted yet).

POLL: Type-erasing wrappers for concepts should follow the any_${CONCEPTNAME} naming pattern.

Attendance: 36

Outcome: That has no consensus.

POLL: Type-erasing wrappers should have an any prefix.

Attendance: 36

Outcome: That has no consensus.

Somebody from the against camp should write a paper about this (ideally proposing an alternative guideline).

POLL: The facility in P0792 should be named:

Attendance: 35

Outcome: We agree that the facility in P0792 should be called function_ref.

That probably means we feel type erasure does not imply any (although any may imply type erasure).

POLL: The facility in P0288 should be named:

Attendance: 34

Outcome: We need to make a decision for the name of P0288 (any_invocable) facility and there's no clear favorite. We'll conduct an electronic poll in the next voting cycle on the name for the P0288 facility in which participants will vote once on their preferred option. If anyone would like to suggest a new name for consideration for said poll, they should write a paper similar to P2265.

End: 11:46

Summary

We had a lively discussion with excellent turnout on naming, focused on the facilities in P0288 (any_invocable) and P0792 (function_ref), but covering broader topics and policy, including:

• Should we name facilities for what they hold or what they are?
• How should we name type-erased wrappers in general?
• How should we name type-erased wrappers that hold a concept?

It is not clear whether we have consensus on the answers to any of these questions.

One of the underlying challenges is this discussion is different views regarding what kind and degree of consistency do we desire for the names of these facilities and future facilities like them. Some wish for these facilities to be named and thought of as wrappers for the concepts they hold. Others wish for names that reflect pre-concept existing practice and precedent, such as function.

Some expressed concerns about possible confusion caused by the name any_invocable. For example, the distinction between any_invocable (a type-erasing wrapper which takes a function signature as a template parameter) and invocable (which takes the potentially-invocable type followed by a set of argument types as a parameter). Additionally, there were questions about whether users would understand the distinction between any_invocable and function given the names.

We also briefly discussed the possibility of introducing type aliases for function that would be consistent with proposed new naming schemes.

Outcome

Most of us seem to believe that, at the very least, the facilities in P0288 (any_invocable) and the P0792 (function_ref) should be consistently named with respect to each other. We had consensus that the name for the facility in P0792 (function_ref) should be function_ref and that the for the facility in P0288 (any_invocable) should have function in the name. None of the names for the P0288 facility achieved consensus, but the one name considered that did not have function in it (any_invocable) had the greatest opposition. This suggests that a possible route to consensus would be a name for the P0288 facility that contains function but was not considered during this discussion.

We need to make a decision for the name of P0288 (any_invocable) facility and there's no clear favorite. We'll conduct an electronic poll in the next voting cycle on the name for the P0288 facility in which participants will vote once on their preferred option. If anyone would like to suggest a new name for consideration for said poll, they should write a paper similar to P2265.

Other type-erased facilities using any as a prefix should take note of the lack of consensus demonstrated in today's discussion.

LWG reviewed this in Kona 2022 and requested changes.

https://wiki.edg.com/bin/view/Wg21kona2022/LWG20221111-LM

LWG reviewed P0792R13 today.

Poll: Forward P0792R13 for C++26, at some future plenary.

P0792R12 function_ref: a non-owning reference to a Callable (Vittorio Romeo, Zhihao Yuan, Jarrad Waterloo)

P0792R13 function_ref: a non-owning reference to a Callable (Vittorio Romeo, Zhihao Yuan, Jarrad Waterloo)

P0792R14 function_ref: a non-owning reference to a Callable (Vittorio Romeo, Zhihao Yuan, Jarrad Waterloo)

Approved in Varna 2023 and applied to the draft (cplusplus/draft#6304)