On Tue, Aug 20, 2013 at 6:11 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
His argument is that the definition of concepts and their association with types is not rigid and formal anymore. It's just any constant boolean expression. It's not a bug, it's a feature.
It's not a "bug" or "feature," it's a design choice that makes it difficult or impossible to add proper template definition checking in the future and it also makes writing template definitions that use the concept more difficult than the 0x approach. In ConceptsLite, rather than dealing with a direct list of associated functions (including their parameter list and explicit return type) and associated types, you instead have to deduce everything from usage requirements if you are to actually check a template definition or write any code that slightly deviates from the precisely written usage specification. Programmers are used to writing functions where their parameter types correspond to a type specification and 0x concepts was extremely similar to that. You look at a concept definition much like you would a type definition, see its functions and types, and you are set. In terms of the compiler, it also means a direct route for doing template definition checking since an archetype can be easily created from a C++0x concept definition and checking a template definition is a matter of the compiler just instantiating that template with the archetype. ConceptsLite, on the other hand, deals with usage requirements in the manner that we were forced to with SFINAE (simple expression validity and direct compile-time constant expression checking). You now have to deduce accepted use from the validity of various expressions. You also no longer have automatically deduced associated types. Archetype generation also becomes non-trivial making it no surprise that template definition checking isn't tackled by ConceptsLite. Keep in mind that C++0x concepts had this "informal" way to add concept requirements, too. Again, that it existed wasn't a bug just like the ConceptsLite approach isn't a "bug," but its usage is limited and you wouldn't want to base all concepts around it, especially if you expect to have properly checked template definitions. You use it when your concept has a requirement other than an associated function or associated type that is able to be checked at compile-time. In C++0x concepts it was the std::True concept and took a bool as a parameter (as opposed to a type, which is what most programmers are more familiar with regarding concepts). When the bool is true, the concept is modeled. When the bool is false, the concept is not modeled. This allows you to have any compile-time constant expression as a concept requirement (just put a requires True< your_constexpr_or_metafunction_check_here >; in a concept's definition). In other words, if you really wanted to, you could exploit this functionality to do complete ConceptsLite-style usage requirements by just taking advantage of template overloads and specializations that utilize SFINAE and referencing them in a std::True requirement. Would anyone recommend that? No. The problem is that this very general functionality acts pretty much as an opaque barrier when it comes to proper archetype generation, and in turn, makes it difficult to properly check template definitions. In ConceptsLite, that barrier is less opaque, but still suffers from problems already talked about both here and elsewhere. ConceptsLite "puts off" the possibility of checking concept definitions to some time in the future, but if people thought that the checking of definitions was too complicated in 0x, then I find it extremely hard to believe that anything will come out of ConceptsLite template definition checking, which is a more complicated problem. C++0x concepts was a complex feature, however it was extremely well thought out and even had a working model for template definition checking. The rational course of action once C++0x concepts was removed, given that it was even in the working paper and had a working model, would have been to simply scale things back. Rather than doing that, though, ConceptsLite essentially throws everything out the window using the excuse of C++0x concepts being too complicated as a means to push an entirely different design, while certain others involved in C++0x concepts moved on to other things. For a much more sensible course of action than ConceptsLite, see Doug's paper from earlier this year, which just scales back C++0x concepts without sacrificing its most important parts: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3629.pdf -- -Matt Calabrese