boostorg / callable_traits Goto Github PK

We're about halfway there right now.

This is easy to implement.

Add the following metafunctions:

• push_args_front<T, Args...>
• push_args_back<T, Args...>
• pop_args_front<T, ElementCount>
• pop_args_back<T, ElementCount>
• insert_args<T, Index, Args...>

• has_member_qualifiers
• is_const_member
• is_volatile_member
• is_cv_member
• is_lvalue_reference_member
• is_rvalue_reference_member
• add_member_const
• add_member_volatile
• add_member_cv
• add_member_lvalue_reference
• add_member_rvalue_reference
• remove_member_const
• remove_member_volatile
• remove_member_cv
• remove_member_reference
• remove_member_lvalue_reference
• remove_member_rvalue_reference
• remove_all_member_qualifiers

The names in CallableTraits are based on the paper http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0172r0.html.

Currently the CallableTraits implementation applies this logic to function objects' operator(), but these names do not make this behavior obvious at all. Either separate that behavior into new traits, or rename these to make more sense.

Also, address "has" vs. "is", "qualifiers" on some but not others, etc.

Consider _t and _v like the standard library... :(

The documentation should describe how a SimpleFunction can be created by passing an std::tuple as the first template argument to apply_return.

noexcept becomes part of the function type in C++17.

Not particularly straightforward for cross platform development.Will likely have to allow users to specify which calling conventions to enable via macro definitions, a la Boost.Bind.

Currently, this causes a compiler error. Instead, we should simply return std::false_type

Metafunctions that alias a function pointer type or a PMF type generally need this note

• remove_member_lvalue_reference
• remove_member_rvalue_reference
• remove_all_member_qualifiers

It would be a cool feature were it only consistent with std::invoke, which is more strict. This is accomplished in general.hpp and normalize_reference.hpp. Should this functionality be removed, or simply separated? Either way, it should probably not remain in its current state, since CallableTraits will probably be expected to be consistent with std::invoke.

Reasons I'm asking:

• names like push_arg_front don't imply that multiple types can be pushed (they can)
• names like push_args_front put too much emphasis on the fact that multiple types can be pushed
• callable_traits::push_front is too generic
• callable_traits::parms::push_front or something like that might be nice.

Thoughts?

These came in with recent commits.

I wish I had a use for this, because I think it's cool.

This will make the reference documentation much less wooden, so that we can use T -> Args... psuedocode instead of resorting to standard-ese such as "When T is a MemberFunctionPointer, let Args... represent the parameter types in the signature of T...".

The Headers section should be used for categorical grouping. The reference sections should be ordered alphabetically.