Re: [boost] New library? CallableTraits

On 6/29/2016 11:12 PM, Barrett Adair wrote:

On Mon, Jun 20, 2016 at 9:52 PM, Barrett Adair wrote:

...

On Mon, May 16, 2016 at 3:34 PM, Jesse Williamson wrote:

...

On Sun, May 15, 2016 at 6:13 AM, Louis Dionne

wrote:

...

...

...

...

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

similar

...

...

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 incorporated 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?

(snip)

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?

(snip)

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 [1].

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. snipped...