what makes a Concept a Concept?

[najja...@gmail.com]

i started writing an article/documentation about Concepts by at a point in time when i started giving examples and saying if this is a  Concept or a simple Constraint, i found my self enable to answer the question why this is a concept ?
according to CPPCoreGuideline example :Addable is not a Concept because it violates the Commutativity property of Addition.that's okay, but what makes EquallyComparable or Regular a Concept?

Addable is defined like so:

template<typename T> concept bool Addable = has_plus<T>;



thx

[Nicol Bolas]

This isn't really an appropriate question for this forum, as it's not discussing a proposed change to the language so much as an interpretation of the ideas behind one.

That being said, what has primacy in a formal discussion is the formal standard. In this case, the Concepts TS standard. In that standard, it defines "concept" as a constexpr variable/function that evaluates to a `bool` based on its template parameters.

The Core Guideline in question is not saying that `Addable` is not a "concept". It's saying that it's not a good concept. (or, as they put it, a "true concept", just like "no true Scottsman"...) That the way it constraints its parameter is not in accord with what the user will think `Addable` actually means based on its name. Much like you might say that a particular base class isn't a good representation of a polymorphic interface; it's still a base class, just not a very good one even if it works.

The guideline is talking about concepts that represent something more than just "this set of operations won't provoke a compile error". It should actually state something about the type(s) in question. `Addable` doesn't really say anything more than "this operation will work".

As an example, consider the Range TS's `Regular` concept. It specifies that a `Regular type` is copy/moveable, default-constructible, copy/move assignable, swappable, destructible, and can be equality compared. These are all different constraints. But when you put them together, what do you have?

`Regular` defines a type that has a value (for the most part).

That is what the Core Guidelines is talking about when it says "true concept". Not merely an arbitrary ball of constraints that fit whatever function implementation you're writing at the time. It's talking about something with a real meaning, such that the series of constraints are simply testing adherence to that meaning.

That's the difference between `Addable` and `Number`: the former just tests if there's an `operator+`; the latter actually says something about the type.

A good concept is supposed to be more than the sum of its parts.

[Robert Ramey]

On 9/18/16 3:05 PM, najja...@gmail.com wrote:
>
> i started writing an article/documentation about Concepts by at a point
> in time when i started giving examples and saying if this is a Concept
> or a simple Constraint, i found my self enable to answer the question
> why this is a concept ?
> according to CPPCoreGuideline example :Addable is not a Concept because
> it violates the Commutativity property of Addition.that's okay, but what
> makes EquallyComparable or Regular a Concept?
>
> Addable is defined like so:
>

This has been bugging me for years. Concept is a very ill chosen word
to describe what it is and has lead to much confusion and made the
"concept" exceedingly difficult to understand.

When every you see the word "Concept" in the context of C++ types
mentally substitute the words "Type Requirements". This will clarify
things immensely.

Now define type requirements as the list of legal expressions which may
include the type in question.

It's that simple.

Of course this opens the way to abominations like "Sortable". Before
anyone asks, the definition of "Sortable<T>" would be:

a type T is "Sortable" if, when placed in a suitable container, the
container can be sorted..., which obviously make no sense.

Robert Ramey

[najja...@gmail.com]

@Nicol Bolas :Okay fair enough: what you are saying is that the language doesn't offer mechanism to distinguish between Simple Constraints{"not good concept"} and Concept(and that's sth obvious from the provided mechanisms), for the language it's just the same. but, @Nicol Bolas & Robert Ramey, at the same time when reading papers(design papers) about Concepts we find Designers talking about the idea of Syntactic and Semantic requirments.
for example M. Bjane Stroustrap is saying that Concept are Constraints plus "axioms", and the semantic part of this definition is axioms.
here are some citations from B.S and others intresting papers:
B.S.:

constraints are predicates on static
properties of a type, and concepts are abstract specifications of an algorithm’s
syntactic and semantic requirements

and also :

Constraints are necessary building blocks
of concepts. Semantic properties are represented as axioms. We summarize our
approach: concepts = constraints + axioms.

 

 fundamental paper of concept design:

A concept is a predicate that expresses a set of requirements on types. These requirements
consist of syntactic requirements, which what related types, literals, operations, and expressions
are available, and semantic requirements that give meaning to the required syntax and also
provide complexity guarantees

the documentation is  divided in part for beginners with just the purpose of using the language feature in some General understanding of Concepts,(and the basic definition is Concepts are requirement  on template arguments)and a part to advanced Devers to understand the idea behind concept.

but what i understand is that there is no formal definition of a concept(not from mechanism  perspective), in some way we can say that what could make a Concept is the universality of imposed  Constraints for all C++ programmers(library algo, ...), Regularity is a fundamental property of types passed to STL Algorithms.

P.S.: sorry for the wrong forum. the two section starts with ISO C++ Stand... .

[Nicol Bolas]

On Monday, September 19, 2016 at 1:15:44 PM UTC-4, najja...@gmail.com wrote:

@Nicol Bolas :Okay fair enough: what you are saying is that the language doesn't offer mechanism to distinguish between Simple Constraints{"not good concept"} and Concept(and that's sth obvious from the provided mechanisms), for the language it's just the same. but, @Nicol Bolas & Robert Ramey, at the same time when reading papers(design papers) about Concepts we find Designers talking about the idea of Syntactic and Semantic requirments.

Yes, and if you read the initial papers on Uniform Initialization, it was supposed to cover all forms of initialization, such that you would never need to use () to construct a type again.

It didn't work out that way. The same goes here. No plan survives first contact with the enemy. And however much Bjarne wanted concepts-as-a-language-feature to include semantic constraints, it hasn't worked out that way.

[Robert Ramey]

> Robert Ramey, at the same time when reading papers(design papers) about

> Concepts we find Designers talking about the idea of *Syntactic and
> _Semantic _requirments*.

> for example M. Bjane Stroustrap is saying that Concept are Constraints
> plus "axioms", and the semantic part of this definition is axioms.
> here are some citations from B.S and others intresting papers:
> B.S.:
>
> constraints are predicates on static
> properties of a type, and concepts are abstract specifications of an
> algorithm’s
> syntactic and semantic requirements

Maybe - but that would be quite different than the way the term
"Concepts" was was first used in 1995 when Stepenov make the first STL
and the term became popular. This only goes to show the pitfalls of
coining one's own vocabulary/definitions in cases like this.

As we can see above, the meaning of the term "Concepts" is even more
muddled than when if was first used in this context. It's my view that
usage of the term is confusing (as it is here) and is best avoided. I
still believe that "Type Requirements" best captures the current meaning
of the idea.

Robert R