Boost logo

Boost :

Subject: Re: [boost] New library? CallableTraits
From: Barrett Adair (barrettellisadair_at_[hidden])
Date: 2016-05-16 15:32:24

On Sun, May 15, 2016 at 8:13 AM, Louis Dionne <ldionne.2_at_[hidden]> wrote:
> Barrett Adair <barrettellisadair <at>> writes:
>> (snip)
> > 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.

This is great to hear.

> > 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
> count on me to submit one.

Also great!

> > 3. What you like to see added, removed, renamed, or redesigned?
> Here are a few comments on the documentation and the library itself:
> - IMO, the overview should include explanations in running text rather
> just comments in the code. Or if you want to keep code only, which
might be
> a good idea, I would make it a bit shorter. Do not try to show all the
> features and details of the library; this is just an overview.

I've updated the introduction so that it begins with a simple, terse
overview [1]. Is this a step in the right direction?

> - The Java-style interface example is _huge_, and IMO it doesn't fit into
> example at the beginning of the documentation. It might be better to
> it as an appendix.

That's a good point. I've moved it to the end of the documentation for now.

> - The library documents many concepts, but it seems to me that they are
> really concepts as we usually mean in C++. To me, most of them are just
> vocabulary terms (that could e.g. appear in a glossary). When I
> concepts in a library, I usually design my concepts as some kind of
> hierarchy with semantic properties that allow me to describe a few key
> types of objects. Instead, I see some "concepts" in CallableTraits as
> glossary terms without semantics. For example, instead of the
> concept, you could have a "Function pointer" entry in a glossary.

Hmm, that's another good point. I will think about this suggestion, and
I'll change the name of the section at the very least.

I came up with the concept "members" idea while writing the reference
documentation - I think it will make the reference section easier to write
and comprehend. However, I may be completely off-base about this.

> - Suggestion: use `replace_at` instead of `overwrite_at`?
> - A few metafunctions have the `_at` suffix; is this necessary?

I renamed `overwrite_at` to `replace_args`. I did the same for the other
`_at` metafunctions.

> - Instead of `can_invoke`, something like `is_invokable` might be better?
> Querying traits often start with `is_`.

It seems that this offers similar functionality to C++17's `is_callable`,
but it might be worth keeping around for those who are stuck with older
compilers/std libraries. I may actually rename this to `is_callable` and
then remove CallableTraits' existing `is_callable` trait.

> > I'd say CallableTraits is about 85% finished. Here's what's left:
> > * Add INVOKE semantics to a couple of things for consistency (arity,
> > * Remove unused/undocumented code
> > * Account for transaction_safe and C++17 noexcept
> > * Finish/test the calling convention features
> > * Finish/update the reference documentation
> Finishing the reference documentation is, IMO, the #1 priority if others
> express interest towards the library and you want to make it part of
> I don't think a formal review can take place before the documentation is
> done, but you might want to wait to see if there's interest before
> a lot of time in the documentation.

Yes, definitely. Part of my reasoning for bringing this to the mailing list
at this stage is that I'll be much more motivated to finish the reference
docs in a timely manner if people are interested in adding this to Boost.

Yesterday I committed the code changes for INVOKE consistency, and removed
a lot of unused code.

Thanks for your detailed response.



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