Make LIFT_FUNCTION more modular

[andralex]

Per the discussion at https://twitter.com/incomputable/status/1623722860610039809

[rollbear]

Thanks Andrei,

I'm a little bit confused. Is there a reason for not going with the simpler:

diff --git a/include/lift.hpp b/include/lift.hpp
index 39cfdc6..fa2a570 100644
--- a/include/lift.hpp
+++ b/include/lift.hpp
@@ -26,7 +26,7 @@

 #define LIFT_FWD(x) std::forward<decltype(x)>(x)

-#define LIFT_FUNCTION(lift_func) [](auto&& ... p) LIFT_THRICE(lift_func(LIFT_FWD(p)...))
+#define LIFT_FUNCTION(...) [](auto&& ... p) LIFT_THRICE(__VA_ARGS__(LIFT_FWD(p)...))
 #ifndef LIFT
 #define LIFT LIFT_FUNCTION
 #endif

Also, an added test case or two would've been nice.

[andralex]

@rollbear you mean why use a variadic macro for LIFT_FUNCTION? Consider a call such as LIFT_FUNCTION(Widget<int, int>::fun). From the compiler's point of view, Widget<int, int>::fun is a single entity. But the preprocessor does not "pair" angle brackets correctly so it thinks you are invoking LIFT_FUNCTION with two arguments, Widget<int and int>::fun. If the macro is defined with one parameter, that'll be a preprocessing error. If you use ... instead, the macro will accept everything and expand correctly.

[andralex]

Anyway, the gist of this PR is the intentional obfuscation for achieving some sort of modularity for macro names. You don't want to pollute the perilous macro namespace with names you don't plan to export (such as LIFT_THRICE of LIFT_FWD.

[rollbear]

Thanks Andrei!