P0288 any_invocable · Issue #400 · cplusplus/papers · GitHub
source link: https://github.com/cplusplus/papers/issues/400
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
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
.
move_function
.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.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK