Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Roland Bock (rbock_at_[hidden])
Date: 2014-08-04 11:39:36

On 2014-08-04 13:32, Mostafa wrote:
> On Thu, 31 Jul 2014 10:54:59 -0700, Robert Ramey <ramey_at_[hidden]> 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