Some Boost.Graph algorithms return one of their optional named function parameters. If the user doesn't specify the parameter, then the default return type must necessarily be different. This metafunction is needed to help facilitate computation of such a return type without resorting to decltype(), which not all compilers support.
The code generation macros are supposed to support parameter-dependent return types, but it turns out that they currently don't really do that. This commit fixes the issue.
These are breaking changes to PR #66.
* Remove are_tagged_arguments_mp11 and is_argument_pack_mp11. They were reviewed as redundant.
* Remove MP11 support for ArgumentPack models for now. (This feature relied on templates that were not supposed to be specialized.)
* Add are_tagged_arguments_mp11 and is_argument_pack_mp11 metafunctions when Boost.MP11 is usable.
* Predicate requirements can be encoded as Boost.MP11-style quoted metafunctions as well as by MPL binary metafunction classes.
* Argument packs qualify as Boost.MP11-style lists as well as MPL sequences.
* Internal components and test programs use Boost.MP11 and C++11 type traits vice MPL and Boost.TypeTraits when Boost.MP11 is usable.
Decouple the compose() function and the BOOST_PARAMETER_NO_SPEC_* code generation macros from BOOST_PARAMETER_MAX_ARITY for older compilers so their generated functions can take in more arguments.
Also move BOOST_PARAMETER_TEMPLATE_KEYWORD macro definition to <boost/parameter/template_keyword.hpp>, but #include this new header file in <boost/parameter/name.hpp> for backward compatibility.
<boost/parameter/aux_/template_keyword.hpp>
* Apply a modified version of David Abrahams' patch from <https://svn.boost.org/trac10/ticket/2793> which eliminates the need to wrap function types in boost::function or std::function instantiations.
"test/function_type_tpl_param.cpp"
* Demonstrate that keyword types generated by BOOST_PARAMETER_TEMPLATE_KEYWORD now store function types as-is without wrapping them in boost::function or std::function instantiations.
"doc/reference.rst"
"doc/html/reference.html"
* Add BOOST_PARAMETER_DISABLE_PERFECT_FORWARDING as a configuration macro.
* Mention by what libraries other macros which are not a part of Parameter itself are defined.
* Mention which non-Boost.Parameter macros can be altered to affect the Boost.Parameter configuration.
User library tests have been reporting numerous failures due to internal compiler errors that occur when perfect forwarding is unsupported. Setting BOOST_PARAMETER_EXPONENTIAL_OVERLOAD_THRESHOLD_ARITY to zero eliminates these failures. By doing this in Boost.Parameter, we relieve user code of the burden of doing this in their end. The trade-off is that our own tests need to define BOOST_PARAMETER_EXPONENTIAL_OVERLOAD_THRESHOLD_ARITY explicitly in order to take advantage of the benefits of not having to wrap boost::ref() or std::ref() around non-const lvalues. As this was always a C++03 workaround, the change should be worth the trade-off.
On an unrelated note, Travis Cl just deprecated "sudo: false". See <https://blog.travis-ci.com/2018-10-04-combining-linux-infrastructures>.
Upon approval and merging of this commit, replace the definition of BOOST_PARAMETER_NESTED_KEYWORD in <boost/accumulators/accumulators_fwd.hpp> with #include <boost/parameter/nested_keyword.hpp>.
Also upgrade boost::parameter::aux::arg_list, boost::parameter::aux::tagged_argument, and boost::parameter::aux::tagged_argument_rref to model the MPL Associative Sequence concept.
* Replace calls to boost::forward with calls to std::forward.
<boost/parameter/config.hpp>
* Relax perfect forwarding requirements so that msvc-12.0 passes muster.
<boost/parameter/parameters.hpp>
* Use boost::mpl::vector if neither boost::fusion::list nor boost::fusion::deque are true variadic MPL sequences.
.travis.yml
appveyor.yml
* Remove test configurations of compilers that fail perfect forwarding requirements.
* Consolidate for fewer jobs.
1. The end of section 3.2.1 of the current home page tutorial notes "that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues." Add code to eliminate this problem. As a positive side effect, Boost.Parameter-enabled functions and constructors are no longer bound by BOOST_PARAMETER_MAX_ARITY on compilers that support perfect forwarding. User code can now check for this support by detecting the configuration macro BOOST_PARAMETER_HAS_PERFECT_FORWARDING, or manually turn off this support by defining the configuration macro BOOST_PARAMETER_DISABLE_PERFECT_FORWARDING. See "test/evaluate_category.cpp" and "test/preprocessor_eval_category.cpp" for example usage.
2. Add parameter category qualifiers "consume" and "move_from"(current qualifiers are "in", "out", "in_out", and "forward") based on http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters.
3. Update documentation to reflect the above changes.
Add parameter category qualifier "forward" (current qualifiers are "in", "out", and "in_out") based on http://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters. Add new usage syntax BOOST_PARAMETER_NAME((object-name), namespace-name) qualifier(tag-name)) and BOOST_PARAMETER_NAME(qualifier(name)). (Existing code that uses qualifiers directly and correctly with BOOST_PARAMETER_FUNCTION and other code generation macros should remain unaffected for now, so no breaking changes.) The reason for the change in usage is to enable applying of parameter category constraints to Boost.Parameter-enabled functions and constructors invoked through argument composition. (Otherwise, it is currently possible to use argument composition to bypass parameter category constraints applied in BOOST_PARAMETER_FUNCTION et. al.) See "test/compose.cpp" for example usage.
* Add code generation macros BOOST_PARAMETER_FUNCTION_CALL_OPERATOR and BOOST_PARAMETER_CONST_FUNCTION_CALL_OPERATOR to <boost/parameter/preprocessor.hpp>.
* Also, add documentation for BOOST_PARAMETER_CONST_MEMBER_FUNCTION, BOOST_PARAMETER_BASIC_FUNCTION, BOOST_PARAMETER_BASIC_MEMBER_FUNCTION, and BOOST_PARAMETER_BASIC_CONST_MEMBER_FUNCTION.
Document that boost::parameter::required, boost::parameter::optional, and boost::parameter::deduced are defined in their own header files, which are in turn #included by <boost/parameter/parameters.hpp>.
