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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-03-06 06:27:09

On 2016-03-06 12:59, Vicente J. Botet Escriba wrote:
> 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.

I don't mind having that in Boost (in fact, I welcome it) but these 
tools are specific to functional domain, AFAIU. I think Boost.Phoenix 
has something similar as well. Maybe, if there's a common ground in 
these tools, they should all be unified and extracted to a new separate 
library.