
On 2014-08-04 13:32, Mostafa wrote:
On Thu, 31 Jul 2014 10:54:59 -0700, Robert Ramey
wrote: Eric Niebler-4 wrote
On 07/29/2014 05:14 PM, Niall Douglas wrote:
I'm all for Concepts as in compiler enforced ones, and I'll add them to AFIO when and only when C++ gets them. But for documentation they don't help.
Wow, I couldn't disagree more. I can't imagine how the standard algorithms would be specified without the use of concepts like "RandomAccessIterator", for instance. Clustering requirements into meaningful abstractions and assigning them names makes it possible to document library interfaces without an explosion of verbosity and repetition.
+10
Usage of concepts is greatly:
a) misunderstood b) misunderestimated as to their value in design AND documentation d) The word "concepts" is a big contributor to the problem - substitute "type requirements" or "type constraints" for concepts.
-1 to the above term substitutions for concepts. Type requirements/type constrains are not concepts. The reason concepts are misunderstood is because they have not been well defined. FWIW, here's my take on how they should be defined:
Concepts are sets of types whose membership are compile-time determinable. I think you are mistaken. A concept is a set of requirements, not a set of types that fullfill these requirements.
This also reflects the normal meaning of the word concept, see for instance http://www.oxforddictionaries.com/definition/english/concept