I believe that "C++ Concept" was originally defined by the following web page or writing contemporary to it. https://www.sgi.com/tech/stl/stl_introduction.html . A relevent quote is "One very important question to ask about any template function, not just about STL algorithms, is what the set of types is that may correctly be substituted for the formal template parameters. Clearly, for example, int* or double* may be substituted for find's formal template parameter InputIterator. " I don't think we want to alter this definition. It's not formal (in the mathematical sense), but it's not ambiguous in our context. My complaint isn't the definition - it's the phrase/word that was chosen to embody the idea. The word chosen was "Concepts" which, in my view has led to all sorts of confusion to the casual reader - as most of are when we read documentation. So my view is that we would be better served by using the term "type requirements" and/or "type constraints" rather than the word "Concepts". That's all. Of course people can and will continue to use the word "Concept" in the way they have been. But that doesn't prohibit me from using the phrase "type constraint" from referring to the original idea. It's somewhat off topic, but I'm going to take the opportunity to point out https://www.sgi.com/tech/stl/doc_introduction.html . I've come to believe that C++ libraries - in particular parameterized types, are best described by the documentation approach embodied in this link. It is sufficiently formal where it has to be - but not so formal that one gets too bogged down. I've made a big point of this inhttp://rrsd.com/blincubator.com/requirements_documentation/ . My criticism of the HANA documentation is really that it fails to follow this format and content. One of the objections raised to my criticism is that this form of documentation is in some sense not modern, specific to STL, or in some way not a good model for all C++ libraries. It is this idea which I reject - totally. Library authors would be best served by producing this form of documentation (concurrently with code) and not spend any time re-inventing their own documentation form. Use this one and spend your time on coding! Another interesting quote is: "Concepts are not a part of the C++ language; there is no way to declare a concept in a program, or to declare that a particular type is a model of a concept. " But today we have the boost concept library which while it doesn't make concepts part of the language itself provides a library which permits type requirements to be specified as part of the code and checked at compile time. But with C++11 it's much more interesting. I just came upon: http://en.cppreference.com/w/cpp/concept which echoes my views on the whole subject. I don't have the C++11 spec - but I'm assuming/hoping that these type requirements are part of it. This section only defines the named type requirements. But wait!!!! there's more !!! For A good number of the concepts - example DefaultConstructable http://en.cppreference.com/w/cpp/concept/DefaultConstructible -there exists a constexpr function such as http://en.cppreference.com/w/cpp/types/is_default_constructible . So in this case we DO have concepts built into the language (libraries). Making a concept checking class would be as simple is: template<class T> struct DefaultConstructible { static_assert(std::is_default_constructible<T>::value, "Class is not default constructible"); }; Making a new concept class is pretty simple - leave as an excursive for the reader But wait - there's even more!!!! if there were a type trait defined for each concept - we would have type dispatching based on named type requirements - example std::enable_ifstd::is_default_constructible<T> void f(const T &t); So f would be declared for a type T if and only if T were DefaultConstructible. Basically, this implements most of the functionality in Boost Concept Checking and also Concepts Lite today - and in a way which dovetails with what is (in my view) the preferred documentation approach. 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. This is the direction we (Boost and all of C++) need to go. That is, we've known what to do for some time we just have to start doing more. Robert Ramey -- 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.