Boost logo

Boost :

Subject: Re: [boost] New library? CallableTraits
From: Barrett Adair (barrettellisadair_at_[hidden])
Date: 2016-06-29 23:12:37

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

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

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?

Barrett Adair


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