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

On Tue, 05 Aug 2014 00:07:42 -0700, Roland Bock wrote:

On 2014-08-05 02:08, Mostafa wrote:

...

On Mon, 04 Aug 2014 08:39:36 -0700, Roland Bock wrote:

[snip]

...

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

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 Milewski: http://bartoszmilewski.com/2010/06/24/c-concepts-a-postmortem/ (Disclaimer: he holds my position and terms your definition "constrained templates", but his posting is informative in comparing our approaches.) Mostafa