Topic: what makes a Concept a Concept?
Author: najjarchedy@gmail.com
Date: Sun, 18 Sep 2016 15:05:39 -0700 (PDT)
Raw View
------=_Part_196_1361037645.1474236339277
Content-Type: multipart/alternative;
boundary="----=_Part_197_1903939084.1474236339277"
------=_Part_197_1903939084.1474236339277
Content-Type: text/plain; charset=UTF-8
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
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1fc1c369-a709-41b0-bcd6-5fc01e814a5a%40isocpp.org.
------=_Part_197_1903939084.1474236339277
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>i started writing an article/documentation about Conce=
pts by at a point in time when i started giving examples and saying if this=
is a=C2=A0 Concept or a simple Constraint, i found my self enable to answe=
r the question why this is a concept ?<br>according to CPPCoreGuideline exa=
mple :Addable is not a Concept because it violates the Commutativity proper=
ty of Addition.that's okay, but what makes EquallyComparable or Regular=
a Concept?<br><br>Addable is defined like so:<br><br><pre><code><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">concept</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Add=
able</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> has_plus</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">>;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><br><br><br>=
thx<br><br><br></code></pre><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1fc1c369-a709-41b0-bcd6-5fc01e814a5a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1fc1c369-a709-41b0-bcd6-5fc01e814a5a=
%40isocpp.org</a>.<br />
------=_Part_197_1903939084.1474236339277--
------=_Part_196_1361037645.1474236339277--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 18 Sep 2016 17:01:43 -0700 (PDT)
Raw View
------=_Part_337_563691606.1474243303860
Content-Type: multipart/alternative;
boundary="----=_Part_338_1323418928.1474243303860"
------=_Part_338_1323418928.1474243303860
Content-Type: text/plain; charset=UTF-8
On Sunday, September 18, 2016 at 6:05:39 PM UTC-4, 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:
>
> template<typename T> concept bool Addable = has_plus<T>;
>
>
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
<https://en.wikipedia.org/wiki/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.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1fe5b03d-5251-4d0b-b6f8-b7ffdd88e3f3%40isocpp.org.
------=_Part_338_1323418928.1474243303860
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, September 18, 2016 at 6:05:39 PM UTC-4, najja..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br>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=C2=A0 =
Concept or a simple Constraint, i found my self enable to answer the questi=
on why this is a concept ?<br>according to CPPCoreGuideline example :Addabl=
e is not a Concept because it violates the Commutativity property of Additi=
on.that's okay, but what makes EquallyComparable or Regular a Concept?<=
br><br>Addable is defined like so:<br><br><pre><code><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008=
">template</span><span style=3D"color:#660"><</span><span style=3D"color=
:#008">typename</span><span style=3D"color:#000"> T</span><span style=3D"co=
lor:#660">></span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#008">concept</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#008">bool</span><span style=3D"color:#000"> </span><span style=3D"color=
:#606">Addable</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">=3D</span><span style=3D"color:#000"> has_plus</span><span style=3D=
"color:#660"><</span><span style=3D"color:#000">T</span><span style=3D"c=
olor:#660">>;</span><span style=3D"color:#000"><br></span></div></code><=
/div></code><br></pre></div></blockquote><div><br>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=
..<br><br>That being said, what has primacy in a formal discussion is the fo=
rmal standard. In this case, the Concepts TS standard. In that standard, it=
defines "concept" as a constexpr variable/function that evaluate=
s to a `bool` based on its template parameters.<br><br>The Core Guideline i=
n question is not saying that `Addable` is not a "concept". It=
9;s saying that it's not a <i>good concept</i>. (or, as they put it, a =
"true concept", just like "<a href=3D"https://en.wikipedia.o=
rg/wiki/No_true_scottsman">no true Scottsman</a>"...) That the way it =
constraints its parameter is not in accord with what the user will think `A=
ddable` actually means based on its name. Much like you might say that a pa=
rticular base class isn't a good=20
representation of a polymorphic interface; it's still a base class, jus=
t
not a very good one even if it works.<br><br>The guideline is talking abou=
t concepts that represent something more than just "this set of operat=
ions won't provoke a compile error". It should actually state some=
thing about the type(s) in question. `Addable` doesn't really say anyth=
ing more than "this operation will work".<br><br>As an example, c=
onsider the Range TS's `Regular` concept. It specifies that a `Regular =
type` is copy/moveable, default-constructible, copy/move assignable, swappa=
ble, destructible, and can be equality compared. These are all different co=
nstraints. But when you put them together, what do you have?<br><br>`Regula=
r` defines a type that has a <i>value</i> (for the most part).<br><br><i>Th=
at</i> is what the Core Guidelines is talking about when it says "true=
concept". Not merely an arbitrary ball of constraints that fit whatev=
er function implementation you're writing at the time. It's talking=
about something with a real meaning, such that the series of constraints a=
re simply testing adherence to that meaning.<br><br>That's the differen=
ce between `Addable` and `Number`: the former just tests if there's an =
`operator+`; the latter actually <i>says something</i> about the type.<br><=
br>A good concept is supposed to be more than the sum of its parts.<br></di=
v></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1fe5b03d-5251-4d0b-b6f8-b7ffdd88e3f3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1fe5b03d-5251-4d0b-b6f8-b7ffdd88e3f3=
%40isocpp.org</a>.<br />
------=_Part_338_1323418928.1474243303860--
------=_Part_337_563691606.1474243303860--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Sun, 18 Sep 2016 19:35:07 -0700
Raw View
On 9/18/16 3:05 PM, najjarchedy@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
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7484c940-1c69-7223-c83d-da89e6b87cbb%40rrsd.com.
.
Author: najjarchedy@gmail.com
Date: Mon, 19 Sep 2016 10:15:44 -0700 (PDT)
Raw View
------=_Part_1668_846661339.1474305344126
Content-Type: multipart/alternative;
boundary="----=_Part_1669_1458044428.1474305344127"
------=_Part_1669_1458044428.1474305344127
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
@Nicol Bolas :Okay fair enough: what you are saying is that the language=20
doesn't offer mechanism to distinguish between *Simple Constraints*{"not=20
good concept"} and *Concept*(and that's sth obvious from the provided=20
mechanisms), for the language it's just the same. but, @Nicol Bolas &=20
Robert Ramey, at the same time when reading papers(design papers) about=20
Concepts we find Designers talking about the idea of *Syntactic and=20
Semantic requirments*.
for example M. Bjane Stroustrap is saying that Concept are Constraints plus=
=20
"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=20
> algorithm=E2=80=99s
> syntactic and semantic requirements
>
and also :
Constraints are necessary building blocks
> of concepts. Semantic properties are represented as axioms. We summarize=
=20
> our
> approach: concepts =3D constraints + axioms.=20
>
=20
fundamental paper of concept design:
A concept is a predicate that expresses a set of requirements on types.=20
> These requirements
> consist of syntactic requirements, which what related types, literals,=20
> operations, and expressions
> are available, and semantic requirements that give meaning to the require=
d=20
> syntax and also
> provide complexity guarantees
>
the documentation is divided in part for beginners with just the purpose=
=20
of using the language feature in some General understanding of=20
Concepts,(and the basic definition is Concepts are requirement on template=
=20
arguments)and a part to advanced Devers to understand the idea behind=20
concept.
but what i understand is that there is no formal definition of a=20
concept(not from mechanism perspective), in some way we can say that what=
=20
could make a Concept is the universality of imposed Constraints for all=20
C++ programmers(library algo, ...), Regularity is a fundamental property of=
=20
types passed to STL Algorithms.
P.S.: sorry for the wrong forum. the two section starts with ISO C++=20
Stand... .
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f2e808a0-5204-4ba8-b6c3-4fb96367ce39%40isocpp.or=
g.
------=_Part_1669_1458044428.1474305344127
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div dir=3D"ltr">@Nicol Bolas :Okay fair enough: what =
you are saying is that the language doesn't offer mechanism to distingu=
ish between <i>Simple Constraints</i>{"not good concept"} and <b>=
Concept</b>(and that's sth obvious from the provided mechanisms), for t=
he language it's just the same. but, @Nicol Bolas & Robert Ramey, a=
t the same time when reading papers(design papers) about Concepts we find D=
esigners talking about the idea of <b>Syntactic and <u>Semantic </u>requirm=
ents</b>.<br>for example M. Bjane Stroustrap is saying that Concept are Con=
straints plus "axioms", and the semantic part of this definition =
is axioms.<br>here are some citations from B.S and others intresting papers=
:<br>B.S.:<br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: =
1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">con=
straints are predicates on static<br>properties of a type, and concepts are=
abstract specifications of an algorithm=E2=80=99s<br>syntactic and semanti=
c requirements<br></blockquote><div><br>and also :<br><br><blockquote style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;" class=3D"gmail_quote">Constraints are necessary building=
blocks<br>of concepts. Semantic properties are represented as axioms. We s=
ummarize our<br>approach: concepts =3D constraints + axioms. <br></blockquo=
te><div>=C2=A0</div></div><div>=C2=A0fundamental paper of concept design:<b=
r><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px soli=
d rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">A concept i=
s a predicate that expresses a set of requirements on types. These requirem=
ents<br>consist of syntactic requirements, which what related types, litera=
ls, operations, and expressions<br>are available, and semantic requirements=
that give meaning to the required syntax and also<br>provide complexity gu=
arantees<br></blockquote><div><br>the documentation is=C2=A0 divided in par=
t for beginners with just the purpose of using the language feature in some=
General understanding of Concepts,(and the basic definition is Concepts ar=
e requirement=C2=A0 on template arguments)and a part to advanced Devers to =
understand the idea behind concept.<br><br>but what i understand is that th=
ere is no formal definition of a concept(not from mechanism=C2=A0 perspecti=
ve), in some way we can say that what could make a Concept is the universal=
ity of imposed=C2=A0 Constraints for all C++ programmers(library algo, ...)=
, Regularity is a fundamental property of types passed to STL Algorithms.<b=
r><br>P.S.: sorry for the wrong forum. the two section starts with ISO C++ =
Stand... .<br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f2e808a0-5204-4ba8-b6c3-4fb96367ce39%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f2e808a0-5204-4ba8-b6c3-4fb96367ce39=
%40isocpp.org</a>.<br />
------=_Part_1669_1458044428.1474305344127--
------=_Part_1668_846661339.1474305344126--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 19 Sep 2016 14:46:01 -0700 (PDT)
Raw View
------=_Part_633_312509556.1474321561840
Content-Type: multipart/alternative;
boundary="----=_Part_634_1927302503.1474321561840"
------=_Part_634_1927302503.1474321561840
Content-Type: text/plain; charset=UTF-8
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.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/efb963ae-6ff8-442d-a57c-ab67e7156131%40isocpp.org.
------=_Part_634_1927302503.1474321561840
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, September 19, 2016 at 1:15:44 PM UTC-4, najja..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br><div dir=3D"ltr">@Nicol Bolas :Okay fair enough: what you are sayi=
ng is that the language doesn't offer mechanism to distinguish between =
<i>Simple Constraints</i>{"not good concept"} and <b>Concept</b>(=
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 t=
ime when reading papers(design papers) about Concepts we find Designers tal=
king about the idea of <b>Syntactic and <u>Semantic </u>requirments</b>.<br=
></div></div></blockquote><div><br>Yes, and if you read the initial papers =
on Uniform Initialization, it was supposed to cover all forms of initializa=
tion, such that you would never need to use () to construct a type again.<b=
r><br>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.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/efb963ae-6ff8-442d-a57c-ab67e7156131%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/efb963ae-6ff8-442d-a57c-ab67e7156131=
%40isocpp.org</a>.<br />
------=_Part_634_1927302503.1474321561840--
------=_Part_633_312509556.1474321561840--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Thu, 22 Sep 2016 18:49:06 -0700
Raw View
> 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=E2=80=99s
> syntactic and semantic requirements
Maybe - but that would be quite different than the way the term=20
"Concepts" was was first used in 1995 when Stepenov make the first STL=20
and the term became popular. This only goes to show the pitfalls of=20
coining one's own vocabulary/definitions in cases like this.
As we can see above, the meaning of the term "Concepts" is even more=20
muddled than when if was first used in this context. It's my view that=20
usage of the term is confusing (as it is here) and is best avoided. I=20
still believe that "Type Requirements" best captures the current meaning=20
of the idea.
Robert R
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/49f10911-a960-6a4f-2f47-ccbdbc8d0f81%40rrsd.com.
.