Le 06/03/2016 09:59, Andrey Semashev a
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
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
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
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.