Re: [boost] [Fit]Â formal review - should we propose some parts to Boost.Config/Boost.Core

Subject: Re: [boost] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-03-06 04:59:55

Le 06/03/2016 09:59, Andrey Semashev a écrit :
> On 2016-03-06 05:21, Vicente J. Botet Escriba wrote:
>>
>> Others could be considered also as function.hpp, lambda.hpp and
>> lift.hpp, as the macros are there to workaround some missing language
>> features, but those are much more specialized (Boost.Core?)
>
> I don't think Boost.Core is the right place for them as this library 
> is for small generally useful components used by many libraries. The 
> components you pointed out seem too specialized to me, and Boost.Fit 
> looks like the right place for them.
>
|Andrey, I was thinking in Boost.Core as these are language-like 
emulation features, like e.g. addressof, enable_if, 
explicit_operator_bool, ignorunused, no_exception_support, noncopyanble, 
scoped_enum, typeinfo.

IIUC, BOOST_FIT_STATIC_FUNCTION try to fix a standard Core issue 
(pending issue 2104 in CWG) identified by Eric Nibler, with the a 
solution based on proposal's Eric 
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4381.html). 
The library has also a macro BOOST_FIT_DECLARE_STATIC_VAR to do it for 
any data variable. I would like something that solves this problem in Boost.

BOOST_FIT_STATIC_LAMBDA try to covers the C++17 feature constexpr lambdas.

I suspect that Boost.Hana should have something like that. Louis, could 
you tell us how do you manage with these issues?

IMO, The fiw of those issues is independent from a functional utilities 
library, even if Fit can not work without them.||
This is way I believe that it should be extracted and Boost.Core seems 
the good place to me.

Best,
Vicente
|