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.