search

cplusplus / papers

ISO/IEC JTC1 SC22 WG21 paper scheduling and management
646 stars 18 forks source link

P0288 any_invocable #400

Closed wg21bot closed 3 years ago

wg21bot commented 5 years ago

P0288R4 any_invocable (Ryan McDougall, Matt Calabrese)

tituswinters commented 5 years ago

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

wg21bot commented 5 years ago

P0288R5 any_invocable (Matt Calabrese, Ryan McDougall)

mclow commented 4 years ago

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

JeffGarland commented 4 years ago

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

JeffGarland commented 4 years ago

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

jensmaurer commented 4 years ago

P0228R6 any_invocable (Matt Calabrese, Ryan McDougall)

wg21bot commented 4 years ago

P0288R7 any_invocable (Ryan McDougall, Matt Calabrese)

brycelelbach commented 3 years ago

Reclaimed by Library Evolution for name polling.

brycelelbach commented 3 years ago

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):

  1. move_only_function.
  2. move_function.
  3. 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):

What type-erased facilities use the any naming pattern?

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.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
11 8 7 5 2

Attendance: 38

Outcome: Weak consensus in favor.

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

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

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
8 8 7 8 2

Attendance: 36

Outcome: That has no consensus.

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

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
2 6 12 7 3

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:

Name Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against Outcome
function_ref 12 13 4 1 2 Consensus in favor.
invocable_ref 4 7 8 6 4 No consensus.
any_function_ref 0 1 7 8 13 Consensus against.
any_invocable_ref 2 3 2 9 13 Consensus against.

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:

Name Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against Outcome
move_only_function 4 8 8 4 4 No consensus.
move_function 1 5 4 5 12 Consensus against.
movable_function 2 8 5 5 8 No consensus.
any_invocable 4 2 1 10 10 Consensus against.
unique_function 2 8 4 5 8 No consensus.
any_function 4 13 1 7 4 No consensus.

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:

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.

brycelelbach commented 3 years ago

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?

Separate into multiple two questions:

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

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
10 5 4 5 0

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.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
2 6 7 5 1

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.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
1 1 5 7 9

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):

Name Votes
move_only_function 10
movable_function 2
any_function 6

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):

Name Votes
move_only_function 15
any_function 6

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.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
6 14 1 0 0

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

brycelelbach commented 3 years ago

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).__

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
9 13 4 1 2

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.

wg21bot commented 3 years ago

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

JeffGarland commented 3 years ago

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

F A N
8 0 0
JeffGarland commented 3 years ago

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

wg21bot commented 3 years ago

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

wg21bot commented 3 years ago

Adopted 2021-10.