Boost logo

Boost :

Subject: Re: [boost] [CallableTraits] The formal review begins today
From: Peter Dimov (lists_at_[hidden])
Date: 2017-04-05 13:04:25

Barrett Adair wrote:
> On Tue, Apr 4, 2017 at 11:52 AM, Klemens Morgenstern via Boost
> <boost_at_[hidden]> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at