Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P0288 any_invocable #400

Closed
wg21bot opened this issue Jun 23, 2019 · 16 comments · Fixed by cplusplus/draft#5013
Closed

P0288 any_invocable #400

wg21bot opened this issue Jun 23, 2019 · 16 comments · Fixed by cplusplus/draft#5013

Comments

@wg21bot
Copy link
Collaborator

@wg21bot wg21bot commented Jun 23, 2019

P0288R4 any_invocable (Ryan McDougall, Matt Calabrese)

@wg21bot wg21bot added this to the 2019-07 milestone Jun 23, 2019
@jensmaurer jensmaurer removed the LEWG label Jun 28, 2019
@mclow mclow added the C++20 label Jul 8, 2019
@tituswinters
Copy link
Collaborator

@tituswinters tituswinters commented Jul 15, 2019

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

@jensmaurer jensmaurer removed this from the 2019-07 milestone Aug 23, 2019
@jensmaurer jensmaurer added this to the 2019-11 milestone Aug 23, 2019
@wg21bot
Copy link
Collaborator Author

@wg21bot wg21bot commented Oct 15, 2019

P0288R5 any_invocable (Matt Calabrese, Ryan McDougall)

@mclow mclow removed the C++20 label Nov 3, 2019
@mclow
Copy link

@mclow mclow commented Nov 3, 2019

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

@JeffGarland
Copy link
Member

@JeffGarland JeffGarland commented Feb 17, 2020

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

@JeffGarland
Copy link
Member

@JeffGarland JeffGarland commented Jul 24, 2020

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
Copy link
Member

@jensmaurer jensmaurer commented Aug 25, 2020

P0228R6 any_invocable (Matt Calabrese, Ryan McDougall)

@wg21bot
Copy link
Collaborator Author

@wg21bot wg21bot commented Sep 23, 2020

P0288R7 any_invocable (Ryan McDougall, Matt Calabrese)

@wg21bot wg21bot added this to the 2020-telecon milestone Sep 23, 2020
@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Dec 8, 2020

Reclaimed by Library Evolution for name polling.

@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Dec 8, 2020

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.

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.

  • P1851.
  • P2148 (not adopted yet).

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:

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

@jensmaurer jensmaurer removed this from the 2020-telecon milestone Dec 28, 2020
@jensmaurer jensmaurer added this to the 2021-telecon milestone Dec 28, 2020
@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Jan 5, 2021

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.

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
Copy link
Collaborator

@brycelelbach brycelelbach commented Mar 12, 2021

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
Copy link
Collaborator Author

@wg21bot wg21bot commented Jul 30, 2021

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

@JeffGarland
Copy link
Member

@JeffGarland JeffGarland commented Aug 20, 2021

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
Copy link
Member

@JeffGarland JeffGarland commented Sep 18, 2021

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
Copy link
Collaborator Author

@wg21bot wg21bot commented Sep 20, 2021

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

@wg21bot
Copy link
Collaborator Author

@wg21bot wg21bot commented Oct 26, 2021

Adopted 2021-10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

8 participants