Boost logo

Boost :

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2014-08-04 20:08:49

On Mon, 04 Aug 2014 08:39:36 -0700, Roland Bock <rbock_at_[hidden]> wrote:

> 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.

I understand that some may have a problem with such a definition because
it does not have an immediate programmatic counterpart. That is we can
only implement concept checks, hence Boost.ConceptChecks, and not concepts
themselves in C++. But I view concepts not as a programmatic tool but as a
communication tool for conveying programmer intent.

The main reason I hold this view is because it's easier to think in terms
of sets of types than in terms of sets of type requirements. For example,

ShapeConcept := { T | T has the method "void display() const" defined }
TriangleConcept :=
   { T | T models Shape and T has the following methods defined:
         "Edge edgeOne()", "Edge edgeTwo()", "Edge edgeThree()" }

// T models ShapeConcept
template <typename T>
void Display(T & t);

It's obvious that if U models a TriangleConcept then Display(u) for an
object u of type U is well-formed. (That's because TriangleConcept is a
subset of ShapeConcept and U is a member of the latter.) Note that this is
similar to the relationship between types and objects. Conceptually types
are sets of objects and a subtype contains a subset of the objects of its

Now, let's try reworking the above example in terms of sets of type
requirements instead. The TriangleConcept then is a refinement of
ShapeConcept if the TriangleConcept is a superset of the ShapeConcept. But
that's counter-intuitive because the number of types that satisfy the
TriangleConcept is less than the number of types that satisfy ShapeConcept.

Additionally, if concepts were sets of type requirements than the phrase
"T is DefaultConstructible" reads awkwardly, it almost sounds as if T were
a type requirement itself, when we actually mean to say that T satisfies
the requirements of default constructibility. And the language "x
satisfies abc" usually connotates set membership.

> This also reflects the normal meaning of the word concept, see for
> instance

??? From the above link:
"1.4 Philosophy An idea or mental image which corresponds to some distinct
entity or class of entities, or to its essential features, or determines
the application of a term (especially a predicate), and thus plays a part
in the use of reason or language."


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