What will C++17 be without concepts?

In support of Ville's point: why not introduce ourselves to Concepts the other way around by releasing them into the wild (thus exposing it to more scrutiny), and **then** conceptifying STL with more experience. Wouldn't STL with Concepts only benefit from it?

It is much easier to understand concepts and constraints than enable_if and SFINAE.

"programmers are aching to get the language feature into their hands"

What basis do you have for making such a statement? If one takes a look a Boost Libraries there is the Boost Concept Checking Library. Very few of the other boost libraries make use of it. Now you're going to say that that's because it's not powerful enough. I don't think that's the case. But if one looks through documentation of Boost Libraries, very few have concepts defined for their function/type type parameters. How many programmers have ever used enable_if - maybe 200 on the planet earth? I don't know. But I can't see you you make the above statement.

Any one who needs this will be able to make do with a work around until this is released in the normal way.

And (beside the point) when programmers do start to use the overload facility will be abused to create every more clever, unreadable code which depends on unseen declarations.

Robert Ramey

Please, give me concepts - asap!

Every time I want to constrain my library interfaces I have to struggle with enable_if and stuff. Even though I may pretend to understand what I am doing, my colleagues who might be forced to maintain these libs don't. A conceptified STL is not required to improve this situation. And for the record: our customers or development partners don't accept dependencies on Boost at our library-APIs.

A leap of faith vs proof. I think I'd rather wait for the proof (of at least a partly conceptified STL).