Re: [boost] New library? CallableTraits

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]. First, I'll get my most important questions out of the way (feel free to respond to only this paragraph). Before I reformat my reference documentation to match that of TypeTraits, I would like to know whether this would be a fruitful endeavor. Are any of the features added in this fork worth keeping in Boost.TypeTraits? If so, which features (if any) need to be removed, renamed, or re-designed? All of the features documented in my non-Boost reference documentation [2] are present in this fork, albeit in a Boost-ified form (e.g. `std::integral_constant` is now `boost::integral_constant`). I'm using `std::tuple` for a couple of things, where the MPL would have better backwards compatibility. The same is true for my (sometimes polyfilled) usage of `std::disjunction` and friends, which could be replaced by `or_`, etc. However, TypeTraits currently has a "no MPL dependencies" promise. Thoughts? I'm certain that my headers will need additional configuration to be included on the older compilers that Boost.TypeTraits still supports to varying degrees. For this reason, I haven't yet put any of my features into the top-level `type_traits.hpp` header. I've done a pretty good job of configuring my headers for C++11-compliant(ish) compilers, but I've completely ignored GCC < 4.8, Clang < 3.5, and Visual Studio < 2015. Other compiler vendors are ignored. Suggestions for easing this transition? I greatly increased the number of example programs. Boost.TypeTraits already has a few, but I don't see a Jamfile. Is there any CI on these? On a side note, is there any interest in having CMake/Travis/Appveyor support added to the TypeTraits tests/examples, particularly for the GitHub mirror? If these new features are added to `type_traits.hpp`, clients are going to experience a dip in compile-time performance. Is this an argument in favor of submitting CallableTraits as a standalone library? Cheers, Barrett Adair [1] https://github.com/badair/type_traits/tree/feature/callable_traits [2] http://badair.github.io/callable_traits/doc/html/callable_traits/reference.h...