P0792 function_ref: a non-owning reference to a Callable

[jensmaurer]

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

https://issues.isocpp.org/show_bug.cgi?id=340

Titus Winters 2018-03-17 11:19:18 UTC Discussed in http://wiki.edg.com/bin/view/Wg21jacksonville2018/P0792

Forward paper as-is to LWG for C++20? SF F N A SA 3 9 3 0 0

[mclow]

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

[wg21bot]

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

[wg21bot]

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

[mclow]

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

[JeffGarland]

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.

[brycelelbach]

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.

[brycelelbach]

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]

@JeffGarland this should no longer be blocked, at least by Library Evolution.

[jensmaurer]

LWG review 2020-07 https://wiki.edg.com/bin/view/Wg21summer2020/P0792R5-20200731 (paper updates pending)

LEWG directed in 2018-06 "fully support the Callable concept at the potential cost of sizeof(function_ref) >= sizeof(void(*)()) * 2" https://wiki.edg.com/bin/view/Wg21rapperswil2018/P0792 but there are reservations https://lists.isocpp.org/lib-ext/2019/07/12086.php

@JeffGarland , @jwakely , what's the exact status here? Do you expect an update of the paper for the comments from LWG 2020-07 ? If not, is this ready to be re-discussed in LWG?

[wg21bot]

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

[jensmaurer]

Marking as LEWG to consolidate the design direction.

[wg21bot]

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

[wg21bot]

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

[nliber]

2022-02-15 Library Evolution Telecon

P0792R7: function_ref

2022-02-15 Library Evolution Telecon Minutes

Chair: Nevin Liber

Champion: Zhihao Yuan

Minute Taker: Ben Craig

POLL: In P0792R7, we should eliminate the difference between initializing function_ref from a function and initializing function_ref from a function pointer as presented in P0792R7

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
5	12	2	0	0

Attendance: 31

# of Authors: 2

Author Position: 2x SF

Outcome: Strong consensus

__POLL: Modify P0792R7 to disable conversion assignment from non function pointers, while copy assignment from function_ref remains.__

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

Attendance: 31

# of Authors: 2

Author Position: 2 x WF

Outcome: Consensus

__POLL: We want to make construction of function_ref from a member pointer to be ill-formed (option B2 in P0792R7)__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
2	8	6	1	1

Attendance: 32

# of Authors: 2

Author Position: WF

Outcome: Consensus

A: disturbs forwarding cases that won't dangle. Protection goes overboard.

SA: Don't see material difference between member pointers and general function objects, and this inconsistency is harmful.

POLL: Apply the above changes to P0792 and forward the paper to LWG for C++23.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
4	15	1	1	0

Attendance: 32

# of Authors: 2

Author Position: 2x SF

Outcome: Consensus

WA: Same comment as SA in previous poll

N: Making late changes to design at this late in C++23, which is disturbing for a vocabulary type. Doesn't rise to the level of opposing.

Next Steps

Modify P0792R7 to disable conversion assignment from non-function pointers, adopt option B2 (make construction of a function_ref from a member pointer ill-formed), and forward the paper to LWG for C++23.

[wg21bot]

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

[brycelelbach]

2022-05 Library Evolution Electronic Poll Outcomes

__POLL: Return [P0792R8] function_ref to Library Working Group for C++23, classified as an addition ([P0592R4] bucket 3 item).__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
11	10	1	1	1

Consensus in favor.

[wg21bot]

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

[JeffGarland]

Re-target to C++26, LWG is out of time for c++23.

[brycelelbach]

2022-07 Library Evolution Electronic Poll Outcomes

__Poll 1.3: Return [P0792R10] function_ref to Library Working Group for C++23, classified as an addition ([P0592R4] bucket 3 item).__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
16	7	1	1	1

Outcome: Consensus in favor.

[wg21bot]

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

[billy-baker]

2022-11-09 10:00 to 11:30 UTC-10 Kona Library Evolution Meeting

P0792R11: function_ref

2022-11-09 10:00 to 11:30 UTC-10 Kona Library Evolution Minutes

Champion: Vittorio Romeo (remote)

Chair: Billy Baker & Fabio Fracassi

Minute Taker: Steve Downey

__POLL: Send P0792R11 (function_ref) to LWG for C++23 classified as B3 to be confirmed with electronic polling.__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
5	7	3	5	4

Attendance: 21 (in person) + 16 (remote)

# of Authors: 2

Author Position: SF, WF

Outcome: No consensus.

Next Steps

P0792R11 (function_ref) will return to Library for C++26.

[JeffGarland]

LWG reviewed this in Kona 2022 and requested changes.

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

[jwakely]

LWG reviewed P0792R13 today.

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

F	N	A
8	0	1

[wg21bot]

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

[wg21bot]

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

[wg21bot]

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

[jwakely]

Approved in Varna 2023 and applied to the draft (https://github.com/cplusplus/draft/issues/6304)