Re: [boost] [CallableTraits] The formal review begins today

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:
>
>   http://badair.github.io/callable_traits/doc/html/index.html
>
> and the GitHub repository here:
>
>   https://github.com/badair/callable_traits
>
> 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
Klemens Morgenstern
> - Your knowledge of the problem domain

I've implemented similar things by hand several times,including in 
boost.dll 
(https://github.com/apolukhin/Boost.DLL/blob/develop/include/boost/dll/detail/get_mem_fn_type.hpp)

>
> 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 
(https://github.com/apolukhin/Boost.DLL/blob/develop/include/boost/dll/detail/ctor_dtor.hpp) 
but I thought I'll mention it.

>   * Implementation
Didn't check.
>   * Documentation
Seems fine to me. Though there's one thing that needs to be adressed, 
which is: what about overloaded functions and more importantly, 
overloaded operator()?

>   * 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 
to type_traits.
> - Did you attempt to use the library?
No
> - How much effort did you put into your evaluation of the review?
About one hour, reading the doc looking at a few tests.