Description
As mentioned in #28, error messages are often unreadable, mostly due to SFINAE error messages: pieces of the library like hybrid_adapter expect function call operators with SFINAE conditions to discriminate between valid and invalid calls. However, that expectation makes for unreadable SFINAE error messages whenever a sorter is called with bad parameters even in the normal case, while static assertions would make better error messages.
Here is an idea: it may be possible to put the SFINAE condition in a member calling_condition trait (pick a better name later) that would return whether the passed types satisfy the condition to call the sorter. If I'm not mistaken, this would allow to use this condition for the SFINAE required in hybrid_adapter and other contexts that need it, but still get nice static assertions instead if the sorter is called directly. It would not solve every problem, but it would make for better error messages when calling sorters directly.
This calling_condition trait would of course be accessible from sorter_traits, and would always be std::true_type for sorters that don't explicitly specify it.
Now that I think about it again, the SFINAE condition is still required for std::is_invocable: it would be a shame to tell that a sorter is callable with a set of parameters, but that actually calling it with these parameters make it static_assert. Apparently, static assertions don't make is_invocable fail, which is a bit of a problem.
A solution would be to rename the calling_condition above in a sorter_traits<Sorter>::template is_invocable_with<Args...> that sorters can reimplement to add additional information, but it doesn't solve the std::is_invocable problem, and users still have to add an extra template keyword, which isn't very cool...