Barrett Adair wrote:
On Tue, Apr 4, 2017 at 11:52 AM, Klemens Morgenstern via Boost <boost@lists.boost.org> wrote: ...
Additionally I felt, that there are a few to many algorithms, I would've expected the library to only provide an argument tuple so I can manipulate that with fusion, hana or whatever. Now I guess tha variadic C parameter is the reason, but that can only be pushed to the end anyway. So I'm not sure why the library would've just go with std::tuple and let some other tool do the rest.
This was also one of my first thoughts when I looked at the library - that's another example of an ad-hoc metaprogramming library inside another library that we hopefully can avoid at some point. But...
Good point. These were some of the last features I added to the library, and perhaps the most indulgent. I'm not opposed to removing them.
... it's not as simple as that, because just getting a std::tuple isn't very convenient in this case because of member pointers and the corresponding first argument they add to the tuple. In some scenarios this is fine, in others one would probably want to manipulate just the argument list. Either way, having just the ability to replace the argument list with another std::tuple (or another L<T...>) would probably be enough. Perhaps provide two 'get' functions and two 'replace' functions, one that includes the class in the tuple and one that doesn't. The library could also define a special "varargs" type and include that in the tuple as the last argument when the function is C-variadic.