LEWG is OK with the idea of removing the requirement that the invocable T is movable, given the suggestion that it can be worded to allow in-place construction, so long as any_invocable is still movable.

Remove the requirement for the underlying invocable T to be movable.
(any_invocable is still moveable but not copyable)
SF F N A SA
10 3 7 1 0

P0288R5 any_invocable (Matt Calabrese, Ryan McDougall)

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

LWG small group review in Prague -- feedback given to author, expecting updates.

July 24th LWG review of D0288R6. Additional changes requested and discussed with author.

https://wiki.edg.com/pub/Wg21summer2020/LibraryWorkingGroup/0288-current-draft.html

Notes from meeting:
https://wiki.edg.com/bin/view/Wg21summer2020/D0288R6-20200724

P0228R6 any_invocable (Matt Calabrese, Ryan McDougall)

P0288R7 any_invocable (Ryan McDougall, Matt Calabrese)

Reclaimed by Library Evolution for name polling.

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.

P2265R0: any_invocable and function_ref Naming and Headers

2021-01-05 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Minute Taker: Ben Craig

Start: 2021-01-05 10:08 Pacific

What headers should any_invocable and function_ref live in?

• Option 0 (Status Quo):
  • any_invocable in <any_invocable> and <functional>.
  • function_ref in <functional>.
  • function is in <functional>.
• Option 1:
  • any_invocable in <functional>.
  • function_ref in <functional>.
  • function is in <functional>.
• Option 2:
  • any_invocable in <any_invocable> and <functional>.
  • function_ref in <function_ref> and <functional>.
  • function is in <functional>.
• Option 3:
  • any_invocable, function_ref, and function in a new header <x> and
    in <functional>.

Separate into multiple two questions:

• Should including <functional> include any_invocable and function_ref?
• Should any_invocable and function_ref be in (a) new header(s)?

POLL: Including <functional> should include any_invocable and function_ref.

Attendance: 32

Outcome: That has consensus.

POLL: There should be one or more new headers that allow fine-grained inclusion of any_invocable, function_ref, and/or function.

Attendance: 32

Outcome: That has no consensus.

Ask if anyone is writing additional papers on any_invocable/function_ref naming.

Do we want to block delivery of these features over the names?

Do we want to block delivery of these features until we establish clear guidelines for naming typed erased things?

Do we want to block delivery of these features until we establish clear guidelines for naming things in general?

Poll the names together.

POLL: We must establish a general policy for naming typed-erased facilities before naming the facilities in P0288 and P0792.

Attendance: 32

Outcome: That has consensus against.

POLL: Given that we have consensus that the P0792 facility should be named function_ref, the P0288 facility should be named (vote once for your preference):

Attendance: 32

POLL: Given that we have consensus that the P0792 facility should be named function_ref, the P0288 facility should be named (vote once for your preference):

Attendance: 32

POLL: Change P0288 by renaming any_invocable to move_only_function and placing the facility in <functional> instead of adding a new header, and then send the revised paper to electronic polling to be advanced to LWG for C++23 as a Bucket 3 (addition) item.

Attendance: 32

# of Authors: 1

Author Position: Abstained

Outcome: That has strong consensus. There will be an electronic poll with the above question (likely with an added reference to P2265) on the next electronic polling period.

End: 11:28

Summary

We continued our discussion of what name we should give to the new function wrapper facilities in P0288 (any_invocable) and P0792 (function_ref). As in our previous discussion, we talked a lot about broader naming policies, both in general and for type-erased facilities. We feel it's important for Library Evolution to discuss and establish such policies (even if the policy is to have no prescribed pattern), however we do not want to hold up the progress of P0288 and P0792. In the end, we had consensus for the papers to proceed forward with the names move_only_function (for P0288) and function_ref (for P0792).

We also discussed which headers should provide any_invocable and function_ref. The introduction of new fine-grained headers was considered for the purpose of encapsulation and reducing compile times, but in the end we didn't have consensus to add any new headers. Our preference is for both any_invocable and function_ref to be in <functional>; this is already the status quo for function_ref.

Outcome

We did not make any changes to P0792 (function_ref), so it will return LWG immediately.

We will take an electronic poll on the changing P0288 by renaming any_invocable to move_only_function (as per P2265) and placing the facility in <functional> instead of a new header, and then advancing the revised paper to LWG for C++23 classified as an addition (P0592R4 bucket 3 item).

2021 Winter Library Evolution Polls

P2333: 2021 Winter Library Evolution Poll Outcomes

POLL 1: Modify P0288R7 (any_invocable) by renaming any_invocable to move_only_function (as per P2265R0 Renaming any_invocable) and placing the facility in <functional> instead of adding a new header, and then send the revised paper to LWG for C++23, classified as an addition (P0592R4 bucket 3 item).

Outcome: Consensus in favor.

Outcome

Modify P0288R7 (any_invocable) by renaming any_invocable to move_only_function (as per P2265R0 Renaming any_invocable) and placing the facility in <functional> instead of adding a new header, and then send the revised paper to LWG for C++23, classified as an addition (P0592R4 bucket 3 item).

God willing, this will be the last time Library Evolution forwards P0288 to Library.

P0288R8 move_only_function (was any_invocable) (Ryan McDougall, Matt Calabrese)

This was seen 2021-08-20 by LWG full group and approved for C++23 pending 3 editorial updates to be confirmed.

https://wiki.edg.com/bin/view/Wg21telecons2021/P0288-20210820

The too be published in next mailing version is on the LWG wiki -- making this ready to move at the plenary.

https://wiki.edg.com/pub/Wg21telecons2021/LibraryWorkingGroup/D0288R8_move_only_function.html

P0288R9 move_only_function (was any_invocable) (Matt Calabrese, Ryan McDougall)

Adopted 2021-10.