Details
-
Task
-
Resolution: Done
-
P2: Important
-
None
-
None
-
13
-
29b65c98e7 (qt/qtbase/dev) 29b65c98e7 (qt/tqtc-qtbase/dev) 29b65c98e7 (qt/tqtc-qtbase/6.4), fc5f43eea (dev)
-
Team B Foundation Sprint 57, Team B Foundation Sprint 58
Description
There are many function_ref implementations out there (from the top of my head: llvm, boost, abseil). *DO NOT LOOK AT ANY OF THEM* if you want to take this ticket. Only use the spec in wg21.link/p0792. Reviewers can then compare to existing implementations and remark on potential bugs.
We're in dire need for a function_ref that isn't const std::function&. Instead of spending time tracking 3rd-party code, we should just code one down based on the spec inĀ wg21.link/p0792 and keep it updated as P0792 progresses through the committee.
QTestLib needs it in semi-public API (backend of QCOMPARE_XX macros), but QTestLib isn't under BC constraints. QML needs it in private API only, so we need something like q20 - public, but explicitly excluded from BC/SC guarantees, or, indeed, continued presence in the code base.
Since it's not clear that P0792 will be adopted for C++23, we should place it into q23. I suggest to place it into namespace qxp in qxpfunctional.h instead: xp for e_XP_erimental (these namespaces are designed to allow s/qNN::/std::/ later on without the need to reformat surrounding code, that's why they have to be three character long, cf. q20).