
Small correction: These are not constexpr functions, they are template structs with a value.
Why does that matter? An integral constant type trait is the common way to define a concept predicate in C++, and it has many advantages over constexpr functions(which are quite limited).
This works, if f is a template itself, but not if it is a function inside a template like this:
template<typename T> struct X { typename std::enable_ifstd::is_default_constructible<T::value, void>::type f(); };
Well, actually you can if you use a default template parameter:
template<typename T>
struct X
{
template
Now, the cool thing about the (hopefully) soon to be arriving Concept Lite is, that even that will work
Most of functionality of Concepts Lite can already can be done in C++, currently. It adds some syntatic sugar(which is not bad), and it trades in specialization for clever overloading.
It makes for a coherent and complete system from coding to documentation. Since most of this is "form filling" it's easy, mechanical and almost guaranteed to be correct. It certainly is a good foundation. It might get a bit more complex if you have variadic templates and/or constraints for the current set of parameters. For instance, "no type must occur more than once in the parameter list"
Well, checking "no type must occur more than once in the parameter list" should be very possible to check. Actually, one of the big limitations of the current way to check type requirements(that includes both Boost.ConceptCheck and Concepts Lite) is that you can't check for template members or for template functions. It is possible to check for a function or member function that is callable with a certain parameters, but it is not possible to check in general(like how you can check for a template class). However, language limitations of checking for certain type requirements should not limit the documentation of those requirements. Although, it may be wise to avoid building requirements around those limitations. Regards, Paul Fultz II -- View this message in context: http://boost.2283326.n4.nabble.com/Concepts-Definition-Was-GSoC-Boost-Hana-F... Sent from the Boost - Dev mailing list archive at Nabble.com.