Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at