So their primary function is to make template error messages more readable, by giving tools to the programmer to be more specific when defining template types?

I really need to see a comparison with examples that shows that it's interesting to use, if I remember template metaprogramming was not an intended use, so are concepts redirecting the language to saner places ?

It seems like it could be beneficial for certain specific software like math software (maybe AI or language software ?), but other than that I feel very unable to grasp concepts. Maybe a CS teacher could explain it better to me. Again, can't wait for Effective C++ to cover those, but a slight introduction would not hurt :)

Concepts were supposed to be one of the big features of C++11. They weren't going to make templates more efficient, but they would make working with templates a little easier. Eventually, they became unwieldy, and they made compilation times much worse. The Committee had the pressure to ship and fix it later that Hoare talked about in his Turing Award lecture ( http://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf ).

Surprisingly, they resisted Hoare's "mad dash" and deferred concepts. This article is about a stripped-down version of concepts that was accepted into the upcoming version of C++. It's supposed to have most of the benefits of the C++11 proposal, without the complexity.

But I have to admit that the main benefits are better error messages, explicit comments in code of what a template requires, and an additional syntax for declaring/defining templates. The C++11 proposal was more exciting, but there was a question of whether it went too far.

Any summary on what was omitted? I'm not a C++ programmer so going to the source wouldn't help me much, but I'd love to know.

I hadn't followed the original proposal closely, so I can't give a complete list. One feature I know about, that was implementable but very expensive, was the ability to specify multiple ways that a type could match a concept. For instance, a Sortable concept could mean the type has an operator<, or could be passed to the function compare(). I'm sure there was a way to handle cases where a type had both. But then, if you had a type with a method, say lessThan(), you could somehow specify that was an acceptable operator<, and then use anything that relied on the Sortable concept. As far as I know, that isn't in "concepts light."

Constraints on template types are useful outside of metaprogramming proper. For example, the standard library already specifies classes of iterators dependent on e.g. the direction(s) in which they may be advanced.

>So their primary function is to make template error messages more readable

Self documenting code and compiler verified contracts are what makes static typing worth the bother.

They also should improve compile times for those who use type_traits extensively.

So, if I'm reading the Wiki article right, this is C++'s version of Java's <T extends SomeInterface>?

In a way, yes. Other similar language features include traits in Rust and typeclasses in Haskell, in my understanding.

Also Scala's view bounds where a type is accepted if it's implicitly convertible to the required interface.