Niall Douglas wrote
So tl;dr; I am really saying the time for concepts - whatever they are to whoever's definition - isn't here yet.
I would disagree. The whole STL library is based on "concepts". That is, all template parameter have explicit requirements. This is true now and has always been so. It's true that compiler support for verification of all the type requirements which someone might come up with falls short of perfection. But as a practical matter, most type requirements are pretty simple and easily supported with current type traits. For example, type requirements for template<class T> quick_sort(iterator<T> begin, iterator<T> end) are easily stated AND enforced: BOOST_CONCEPT_REQUIRES((Swappable<T>); BOOST_CONCEPT_REQUIRES((StrictWeakOrdering<T>)); This is useful right now. And few library authors even explicitly state their type requirements - much less include them in code. This could change in a month - and it will if I have anything to say about it. There is absolutely no advantage to not doing this.
Let's get a few concept programming libraries based on a Concepts Lite compiler around first. Let's not dig ourselves now into a straightjacket we later regret.
I've included a table which maps boost concept library macros to the concept lite syntax. see http://rrsd.com/blincubator.com/advice_concepts/ "Future Compatibility". Concepts lite is not really relevant here. It won't change the landscape in any way. Library authors aren't failing to explicitly define and enforce their type requirements because they lack compiler support for this. They're doing it because we don't demand that we do so. 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.