Subject: Re: [boost] [CallableTraits] The formal review begins today
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2017-04-04 16:52:23
Am 03.04.2017 um 08:45 schrieb Louis Dionne via Boost:
> Dear Boost community,
> The formal review of Barrett Adair's CallableTraits library begins today,
> April 3rd, and ends on April 12th.
> CallableTraits is a C++11 library for the inspection, synthesis, and
> decomposition of callable types. CallableTraits aims to be the "complete
> type manipulation facility for function types" mentioned in the final
> paragraph of C++17 proposal P0172, and removes the need for template
> specializations for different function signatures.
> You can find the documentation of the library here:
> and the GitHub repository here:
> We encourage your participation in this review. At a minimum, kindly state:
> - Whether you believe the library should be accepted into Boost, and
> conditions for acceptance if any
Yes it should be.
> - Your name
> - Your knowledge of the problem domain
I've implemented similar things by hand several times,including in
> You are strongly encouraged to also provide additional information:
> - What is your evaluation of the library's:
> * Design
Seems fine, though I have a few remarks:
I would've expected a make_fn and make_mem_fn function, with which one
could construct a type from a return type and an std::tuple of the
arguments. That can be easily done manually but I would've expected that
in this library.
Additionally I felt, that there are a few to many algorithms, I would've
expected the library to only provide an argument tuple so I can
manipulate that with fusion, hana or whatever. Now I guess tha variadic
C parameter is the reason, but that can only be pushed to the end
anyway. So I'm not sure why the library would've just go with std::tuple
and let some other tool do the rest.
In addition, what about call conventions? Afaik those are part of the
signature on windows, or at least can be.
Well I had one use case where I needed them
but I thought I'll mention it.
> * Implementation
> * Documentation
Seems fine to me. Though there's one thing that needs to be adressed,
which is: what about overloaded functions and more importantly,
> * Tests
Looked at a few files, seem solid.
> * Usefulness
Very useful, that really safes much boiler-plate code. Given the
complexity it makes sense to have a custom library instead of adding it
> - Did you attempt to use the library?
> - How much effort did you put into your evaluation of the review?
About one hour, reading the doc looking at a few tests.