Subject: Re: [boost] New library? CallableTraits
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-06-30 16:01:25
On 6/29/2016 11:12 PM, Barrett Adair wrote:
> On Mon, Jun 20, 2016 at 9:52 PM, Barrett Adair <barrettellisadair_at_[hidden]>
>> On Mon, May 16, 2016 at 3:34 PM, Jesse Williamson <jesse_at_[hidden]> wrote:
>>> On Sun, May 15, 2016 at 6:13 AM, Louis Dionne <ldionne.2_at_[hidden]>
>>>>> 1. Is there any interest in reviewing a future version of this for
>>>>> inclusion in Boost?
>>>> I think so. I've also heard a couple of people say that they needed
>>>> functionality this week in Aspen, so I imagine this would be a useful
>>>> addition to Boost. In the long term, I think we need something similar
>>>> (perhaps a subset of CallableTraits) in the standard.
>>> Throwing in my two bits here, I absolutely agree that ultimately the
>>> type_traits header should provide something
>>> allowing this sort of introspection.
>>>>> 2. If so, does this belong in its own library, or should it be
>>>>> into Boost.TypeTraits or something similar?
>>>> No strong opinion here, though it might be a bit large for an
> addition to
>>>> Boost.TypeTraits? In all cases, if there's a review of the library,
> you can
>>>> count on me to submit one.
>>> I guess not a /strong/ opinion, but I would like to see it just be
>>> part of Boost Type Traits. It feels like something
>>> that we should be able to do in a single library?
>> I agree that Boost.TypeTraits is the best place for these features. Would
> a formal review be in order if CallableTraits is not going to be submitted
> as a standalone library?
> Since I haven't received a response to my last post, I decided to go ahead
> and start moving the CallableTraits code into a Boost.TypeTraits fork today
I think you should create Callable Traits as its own library rather than
try to integrate it with Type Traits. It will be easier that way to
submit your library for review. If it is reviewed and accepted it is
possible then to integrate it with Type Traits if that is the direction
you or reviewers feel you should go. It is much easier to get a library
reviewed and accepted on its own than to have it be part of something
else from the beginning. It should also be easier for you to design your
library separately rather than be part of something else.
I also feel that you should be as specific as possible as to what level
of C++ callabole traits supports. It is possible to design a library
where certain features are only available for a certain level of C++
support while other features require a different level of C++ support.
But if you specify that your library on the whole needs C++14 on up in
one place and C++11 on up in another place, it is just going to confuse
the end-user. That's why it is important to be specific. It is perfectly
acceptable to have a Boost library support only specific levels of C++
and/or specific compilers that support those levels. But it is very
important to tell people what compiler and/or level of C++ support they
will need to use your library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk