Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2014-08-05 06:13:55
On Tue, 05 Aug 2014 00:07:42 -0700, Roland Bock <rbock_at_[hidden]> wrote:
> On 2014-08-05 02:08, Mostafa wrote:
>> On Mon, 04 Aug 2014 08:39:36 -0700, Roland Bock <rbock_at_[hidden]>
>> 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.
> Sure, that type is a member of T(DefaultConstructible).
> I don't get your argument at all. If you say "this car is green", you
> say both "this car is a member of the set of green things" and "this car
> meets the requirements of being green". It does neither imply that
> "green is the set of green things" (endless recursion) nor does it say
> that "green is a set of being-green-requirements" (also endless
> recursion). Still, everyone knows what is meant without feeling awkward
> about it.
Unfortunately English can be ambiguous, so let's be more precise. When one
says "this car is green" one actually means "this car is a green thing"
(green is being used as a noun, not as an adjective like "green balloon").
That means "this car is a member of GreenThings". If GreenThings were a
set of requirements then that means "this car" is also a requirement,
which obviously it's not. Therefore GreenThings, the concept in this
discussion, is a set of objects that satisfy the requirement of being
> So why not use the term concept in a way that matches what we actually
> do in code?
Because that's a narrow and implementation-dependent point of view. When
we introduce people to classes, hopefully we don't first define them to be
some set of rules for determining the layout of a region of memory, rather
we define them to be nouns; that is it's a communication tool for
expressing programmer intent. By thinking about classes abstractly, we are
able to more easily reason with them, like how UML robustness diagrams can
be used to discover classes and the relationships between them.
FWIW, it might interest you to read this blog on concepts by Bartosz
(Disclaimer: he holds my position and terms your definition "constrained
templates", but his posting is informative in comparing our approaches.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk