Topic: Why don't concepts look like and get called like functions?
Author: gmisocpp@gmail.com
Date: Wed, 24 Oct 2018 18:09:52 -0700 (PDT)
Raw View
------=_Part_156_547975175.1540429792304
Content-Type: multipart/alternative;
boundary="----=_Part_157_741733329.1540429792305"
------=_Part_157_741733329.1540429792305
Content-Type: text/plain; charset="UTF-8"
A few thoughts on Concepts:
As Concepts have evolved, I have found it difficult to get a handle on what
Concepts actually are.
i.e.: Are Concepts functions, types, or something else?
Bjarne's CppCon 2018 talk "Concepts: The Future of Generic Programming"
answers that question clearly.
In his talk, Bjarne says:
* Concepts are NOT types of types. They are NOT type classes.
* Concepts can take more than one argument.
* Concept is a specification of what one or more types can do.
At around 1:06:30 in his talk Bjarne says:
* "it's just like defining functions, you *ARE* DEFINING FUNCTIONS".
So I want to ask:
-----
If concepts ARE functions why don't they look like functions?
Perhaps they should?
-----
The Concepts defined in Bjarne's talk look more like variable definitions
*defined* in what feels (to me) like an odd mix of logic and type like
syntax:
template<typename X> using Value_type = X::value_type;
template<typename X> using Iterator_of = X::iterator;
template<typename For, typename For2, typename Out>
concept Mergable =
ForwardIterator<For>
&& ForwardIterator<For2>
&& OutputIterator<Out>
&& Assignable<Value_type<For>,Value_type<Out>>
&& Assignable<Value_type<For2>,Value_type<Out>>
&& Comparable<Value_type<For>,Value_type<For2>>;
The above looks like a variable definition. If it is not, then is it right
that it looks like one?
It's a definition, with conditional logic et al. i.e it uses &&. etc. like
an inline function.
So why are we defining it NOT using function like snytax?
Why is this a good thing?
I find this function as a variable thing confusing to coming to terms with
what Concepts actually are.
If Concepts ARE functions as Bjarne says, why shouldn't they look and be
composed using functional notation?
It seems I'm not alone in this feeling. J. Monnon proposes this:
Type functions and beyond
An exploration of type functions and concept functions
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html
He says: "This document proposes to extend functions to let them operate
directly on types and concepts.
The goal is to allow writing metaprogramming in the most intuitive and
consistent way with the rest of the language."
J. Monnon says:
Here is an example of a type function:
ForwardIterator IteratorType(typename T) {
// In a type function, an `if` behaves as a `if constexpr`.
if (Container(T)) // `Container` is a concept
return T::iterator;
else if (Array(T)) // `Array` is a concept
return Decay(T);
}
// On call site:
typename I = IteratorType(C);
J. Monnon says:
"A type function is always executed at compile-time. Here, it takes a type
T and returns another type that models the ForwardIterator concept. Type
functions allow a natural and straightforward notation to manipulate types."
This also justifies his comment which I emphasise: // In a type function,
an `if` behaves as a `if constexpr`.
At this time, I agree with J. Monnon's proposal. I find it intuitive and
insightful if I understand it correctly.
If J. Monnon's paper has been discussed at any length anywhere, can someone
please tell me the outcome?
His proposal appeared on Reddit at one point but attracted a near zero
response there, which stunned me.
I'd certainly like to see more commentary on that proposal here before the
next Standards meeting that is imminent.
I may be wrong, but doesn't the D language go this route also? What is so
wrong with that approach that C++ goes it's own way?
There is more I would like to say about Concepts such as why I hate the
syntax as currently proposed.
But for now, I'd really like to focus this discussion on the main elements
I've raised.
1. If concepts ARE functions, why aren't we defining and using them with
function like syntax? And using () not <>.
2. It seems J. Monnon's proposal is making the same point as I am, only
much better? Can we please address all that he proposes?
3. I feel a more formal response to J. Monnon's paper from the main
proponents of Concepts as currently defined should be made before concepts
get wired in any further in it's current direction?
I know many people would like Concepts be the marquee feature of C++20, but
to me Concepts still seem quite away from where I'd like them to be.
Even Bjarne can only 'begrudgingly live' with the current syntax.
All this flux and begrudging really doesn't suggest to me that Concepts are
ready to go for C++20.
This is even before any of my comments or J. Monnon's paper is taken into
account.
Right now, I feel that if Modules and Coroutines were the only main
features that hit for C++20, I'd be happy with that.
If people can explain why my comments are on the mark or misplaced and what
the issues are with J. Monnon's proposal, I'd be grateful.
Thanks
--
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/ae920b87-e062-4b2c-b74c-ae3067d3c604%40isocpp.org.
------=_Part_157_741733329.1540429792305
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>A few thoughts on Concepts:</div><div><br></div><div>=
As Concepts have evolved, I have found it difficult to get a handle on what=
Concepts actually are.<br>i.e.: Are Concepts functions, types, or somethin=
g else?</div><div><br></div><p>Bjarne's CppCon 2018 talk "Concepts=
: The Future of Generic Programming" answers that question clearly.<br=
>In his talk, Bjarne says:<br>* Concepts are NOT types of types. They are N=
OT type classes.<br>* Concepts can take more than one argument.<br>* Concep=
t is a specification of what one or more types can do.</p><p>At around 1:06=
:30 in his talk Bjarne says:<br>* "it's just like defining functio=
ns, you *ARE* DEFINING FUNCTIONS".</p><div><br></div><div>So I want to=
ask:</div><p>-----<br>If concepts ARE functions why don't they look li=
ke functions?<br>Perhaps they should?<br>-----</p><div><br></div><div>The C=
oncepts defined in Bjarne's talk look more like variable definitions *d=
efined* in what feels (to me) like an odd mix of logic and type like syntax=
:</div><p>template<typename X> using Value_type =3D X::value_type;<br=
>template<typename X> using Iterator_of =3D X::iterator;</p><p>templa=
te<typename For, typename For2, typename Out><br>concept Mergable =3D=
<br>=C2=A0=C2=A0=C2=A0 ForwardIterator<For><br>=C2=A0=C2=A0=C2=A0 &am=
p;& ForwardIterator<For2><br>=C2=A0=C2=A0=C2=A0 && Output=
Iterator<Out><br>=C2=A0=C2=A0=C2=A0 && Assignable<Value_ty=
pe<For>,Value_type<Out>><br>=C2=A0=C2=A0=C2=A0 && As=
signable<Value_type<For2>,Value_type<Out>><br>=C2=A0=C2=
=A0=C2=A0 && Comparable<Value_type<For>,Value_type<For2=
>>;</p><div><br></div><div>The above looks like a variable definition=
.. If it is not, then is it right that it looks like one?<br>It's a defi=
nition, with conditional logic et al. i.e it uses &&. etc. like an =
inline function.<br></div><div>So why are we defining it NOT using function=
like snytax?<br>Why is this a good thing?</div><div><br></div><div>I find =
this function as a variable thing confusing to coming to terms with what Co=
ncepts actually are.</div><div><br>If Concepts ARE functions as Bjarne says=
, why shouldn't they look and be composed using functional notation?</d=
iv><div><br></div><div>It seems I'm not alone in this feeling. J. Monno=
n proposes this:<br>Type functions and beyond<br>An exploration of type fun=
ctions and concept functions<br><a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2018/p0844r0.html">http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2018/p0844r0.html</a></div><p>He says: "This document pr=
oposes to extend functions to let them operate directly on types and concep=
ts.<br>The goal is to allow writing metaprogramming in the most intuitive a=
nd consistent way with the rest of the language."</p><p>J. Monnon says=
:</p><p>Here is an example of a type function:<br>=C2=A0=C2=A0=C2=A0 Forwar=
dIterator IteratorType(typename T) {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 // In a type function, an `if` behaves as a `if constexpr`.<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (Container(T))=C2=A0 // `Cont=
ainer` is a concept<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 return T::iterator;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 else if (Array(T)) // `Array` is a concept<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return Decay(T);<br>=C2=A0=C2=
=A0=C2=A0 }</p><p>=C2=A0=C2=A0=C2=A0 // On call site:<br>=C2=A0=C2=A0=C2=A0=
typename I =3D IteratorType(C);</p><div><br></div><div>J. Monnon says:<br>=
"A type function is always executed at compile-time. Here, it takes a =
type T and returns another type that models the ForwardIterator concept. Ty=
pe functions allow a natural and straightforward notation to manipulate typ=
es."</div><div><br></div><div>This also justifies his comment which I =
emphasise: // In a type function, an `if` behaves as a `if constexpr`.</div=
><div><br></div><div>At this time, I=C2=A0agree with J. Monnon's propos=
al. I find it intuitive and insightful if I understand it correctly.<br>If =
J. Monnon's paper has been discussed at any length anywhere, can someon=
e please tell me the outcome?</div><div>His proposal=C2=A0appeared on Reddi=
t at one point but attracted a near zero response there, which stunned me.<=
br>I'd certainly like to see more commentary on that proposal here befo=
re the next Standards meeting that is imminent.</div><div><br></div><div>I =
may be wrong, but doesn't the D language go this route also? What is so=
wrong with that approach=C2=A0that C++ goes it's own way?</div><div><b=
r></div><div>There is more I would like to say about Concepts such as why I=
hate the syntax as currently proposed.<br>But for now, I'd really like=
to focus this discussion on the main elements I've raised.<br>1. If co=
ncepts ARE functions, why aren't we defining and using them with functi=
on like syntax? And using () not <>.<br>2. It seems J. Monnon's p=
roposal is making the same point as I am, only much better? Can we please a=
ddress all that he proposes?<br>3. I feel a more formal response to J. Monn=
on's paper from the main proponents of Concepts as currently defined sh=
ould be made before concepts get wired in any further in it's current d=
irection?</div><div><br></div><div>I know many people would like Concepts b=
e the marquee feature of C++20, but to me Concepts=C2=A0still seem quite aw=
ay from where I'd like them to be.<br>Even Bjarne can only 'begrudg=
ingly live' with the current syntax.<br>All this flux and begrudging re=
ally doesn't suggest to me that Concepts are ready to go for C++20.<br>=
This is even before any of my comments or J. Monnon's paper is taken in=
to account.</div><div><br></div><div>Right now, I feel that if Modules and =
Coroutines were the only main features that hit for C++20, I'd be happy=
with that.<br>If people can=C2=A0explain why my comments are on the mark o=
r misplaced=C2=A0and what the issues are with=C2=A0J. Monnon's proposal=
,=C2=A0I'd be grateful.</div><div><br></div><div>Thanks</div><div><br><=
/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/ae920b87-e062-4b2c-b74c-ae3067d3c604%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ae920b87-e062-4b2c-b74c-ae3067d3c604=
%40isocpp.org</a>.<br />
------=_Part_157_741733329.1540429792305--
------=_Part_156_547975175.1540429792304--
.
Author: mihailnajdenov@gmail.com
Date: Thu, 25 Oct 2018 00:04:06 -0700 (PDT)
Raw View
------=_Part_191_1673856816.1540451046278
Content-Type: multipart/alternative;
boundary="----=_Part_192_167129538.1540451046278"
------=_Part_192_167129538.1540451046278
Content-Type: text/plain; charset="UTF-8"
On Thursday, October 25, 2018 at 4:09:52 AM UTC+3, gmis...@gmail.com wrote:
>
> A few thoughts on Concepts:
>
> As Concepts have evolved, I have found it difficult to get a handle on
> what Concepts actually are.
> i.e.: Are Concepts functions, types, or something else?
>
> Bjarne's CppCon 2018 talk "Concepts: The Future of Generic Programming"
> answers that question clearly.
> In his talk, Bjarne says:
> * Concepts are NOT types of types. They are NOT type classes.
> * Concepts can take more than one argument.
> * Concept is a specification of what one or more types can do.
>
> At around 1:06:30 in his talk Bjarne says:
> * "it's just like defining functions, you *ARE* DEFINING FUNCTIONS".
>
> So I want to ask:
>
> -----
> If concepts ARE functions why don't they look like functions?
> Perhaps they should?
> -----
>
> The Concepts defined in Bjarne's talk look more like variable definitions
> *defined* in what feels (to me) like an odd mix of logic and type like
> syntax:
>
> template<typename X> using Value_type = X::value_type;
> template<typename X> using Iterator_of = X::iterator;
>
> template<typename For, typename For2, typename Out>
> concept Mergable =
> ForwardIterator<For>
> && ForwardIterator<For2>
> && OutputIterator<Out>
> && Assignable<Value_type<For>,Value_type<Out>>
> && Assignable<Value_type<For2>,Value_type<Out>>
> && Comparable<Value_type<For>,Value_type<For2>>;
>
> The above looks like a variable definition. If it is not, then is it right
> that it looks like one?
> It's a definition, with conditional logic et al. i.e it uses &&. etc. like
> an inline function.
> So why are we defining it NOT using function like snytax?
> Why is this a good thing?
>
If you dig the history of Concepts - they were allowed to be defined as
functions, though used the same way as today.
And until literally an year ago, the were like a variable, one had to add
bool before the name.
Right now the syntax does not have *anything *superficial, which is an
improvement.
What Bjarne meant was two things - if you have complex logic you extract
ito a function, or chop it in multiple functions. He meant composition.
He repeated it, this time in the meaning that they are ultimately functions
that take type and return bool (pass/no-pass).
>
> I find this function as a variable thing confusing to coming to terms with
> what Concepts actually are.
>
It is best to think of Concepts as, well, Concepts, a type-consternating
construct that is instantiated as templated variable,
but the compiler uses it as function returning bool
Instead of
requires something<T>()
you can
requires Something<T>
All in all, a care is taken to streamline Concepts as much as possible.
>
> If Concepts ARE functions as Bjarne says, why shouldn't they look and be
> composed using functional notation?
>
> It seems I'm not alone in this feeling. J. Monnon proposes this:
> Type functions and beyond
> An exploration of type functions and concept functions
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html
>
> He says: "This document proposes to extend functions to let them operate
> directly on types and concepts.
> The goal is to allow writing metaprogramming in the most intuitive and
> consistent way with the rest of the language."
>
> J. Monnon says:
>
> Here is an example of a type function:
> ForwardIterator IteratorType(typename T) {
> // In a type function, an `if` behaves as a `if constexpr`.
> if (Container(T)) // `Container` is a concept
> return T::iterator;
> else if (Array(T)) // `Array` is a concept
> return Decay(T);
> }
>
> // On call site:
> typename I = IteratorType(C);
>
>
Now this is something *completely *different - note how the function
returns a different type, not a bool
This proposal is adding type *transformation *machinery, in contrast to
Concepts which are type *filtering *machinery
> J. Monnon says:
> "A type function is always executed at compile-time. Here, it takes a type
> T and returns another type that models the ForwardIterator concept. Type
> functions allow a natural and straightforward notation to manipulate types."
>
> This also justifies his comment which I emphasise: // In a type function,
> an `if` behaves as a `if constexpr`.
>
> At this time, I agree with J. Monnon's proposal. I find it intuitive and
> insightful if I understand it correctly.
> If J. Monnon's paper has been discussed at any length anywhere, can
> someone please tell me the outcome?
> His proposal appeared on Reddit at one point but attracted a near zero
> response there, which stunned me.
> I'd certainly like to see more commentary on that proposal here before the
> next Standards meeting that is imminent.
>
> I may be wrong, but doesn't the D language go this route also? What is so
> wrong with that approach that C++ goes it's own way?
>
> There is more I would like to say about Concepts such as why I hate the
> syntax as currently proposed.
> But for now, I'd really like to focus this discussion on the main elements
> I've raised.
> 1. If concepts ARE functions, why aren't we defining and using them with
> function like syntax? And using () not <>.
> 2. It seems J. Monnon's proposal is making the same point as I am, only
> much better? Can we please address all that he proposes?
> 3. I feel a more formal response to J. Monnon's paper from the main
> proponents of Concepts as currently defined should be made before concepts
> get wired in any further in it's current direction?
>
> I know many people would like Concepts be the marquee feature of C++20,
> but to me Concepts still seem quite away from where I'd like them to be.
> Even Bjarne can only 'begrudgingly live' with the current syntax.
> All this flux and begrudging really doesn't suggest to me that Concepts
> are ready to go for C++20.
> This is even before any of my comments or J. Monnon's paper is taken into
> account.
>
> Right now, I feel that if Modules and Coroutines were the only main
> features that hit for C++20, I'd be happy with that.
> If people can explain why my comments are on the mark or misplaced and
> what the issues are with J. Monnon's proposal, I'd be grateful.
>
Modules and Coroutines don't have good chances for 20.
The main new features will be Concepts and Contracts.
Your comments are perfectly valid and people teaching C++ should take them
into account - the fact people can be confused about variable vs function.
As for J. M, proposal - we must see how this would compare with Reflections
as Reflection will also be able to "emit code" and "return a type".
>
> Thanks
>
>
--
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/bffc5427-9959-47b0-9e89-852d4430b6e3%40isocpp.org.
------=_Part_192_167129538.1540451046278
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, October 25, 2018 at 4:09:52 AM UTC+3,=
gmis...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div>A few thoughts on Concepts:</div><div><br></div><div>As Co=
ncepts have evolved, I have found it difficult to get a handle on what Conc=
epts actually are.<br>i.e.: Are Concepts functions, types, or something els=
e?</div><div><br></div><p>Bjarne's CppCon 2018 talk "Concepts: The=
Future of Generic Programming" answers that question clearly.<br>In h=
is talk, Bjarne says:<br>* Concepts are NOT types of types. They are NOT ty=
pe classes.<br>* Concepts can take more than one argument.<br>* Concept is =
a specification of what one or more types can do.</p><p>At around 1:06:30 i=
n his talk Bjarne says:<br>* "it's just like defining functions, y=
ou *ARE* DEFINING FUNCTIONS".</p><div><br></div><div>So I want to ask:=
</div><p>-----<br>If concepts ARE functions why don't they look like fu=
nctions?<br>Perhaps they should?<br>-----</p><div><br></div><div>The Concep=
ts defined in Bjarne's talk look more like variable definitions *define=
d* in what feels (to me) like an odd mix of logic and type like syntax:</di=
v><p>template<typename X> using Value_type =3D X::value_type;<br>temp=
late<typename X> using Iterator_of =3D X::iterator;</p><p>template<=
;typename For, typename For2, typename Out><br>concept Mergable =3D<br>=
=C2=A0=C2=A0=C2=A0 ForwardIterator<For><br>=C2=A0=C2=A0=C2=A0 &&a=
mp; ForwardIterator<For2><br>=C2=A0=C2=A0=C2=A0 && OutputIter=
ator<Out><br>=C2=A0=C2=A0=C2=A0 && Assignable<Value_type&l=
t;For>,<wbr>Value_type<Out>><br>=C2=A0=C2=A0=C2=A0 && A=
ssignable<Value_type<For2>,<wbr>Value_type<Out>><br>=C2=
=A0=C2=A0=C2=A0 && Comparable<Value_type<For>,<wbr>Value_t=
ype<For2>>;</p><div><br></div><div>The above looks like a variable=
definition. If it is not, then is it right that it looks like one?<br>It&#=
39;s a definition, with conditional logic et al. i.e it uses &&. et=
c. like an inline function.<br></div><div>So why are we defining it NOT usi=
ng function like snytax?<br>Why is this a good thing?</div></div></blockquo=
te><div><br></div><div>If you dig the history of Concepts - they were allow=
ed to be defined as functions, though used the same way as today.</div><div=
>And until literally an year ago, the were like a variable, one had to add =
bool before the name.</div><div><br></div><div>Right now the syntax does no=
t have <i>anything </i>superficial, which is an improvement.=C2=A0</div><di=
v><br></div><div>What Bjarne meant was two things - if you have complex log=
ic you extract ito a function, or chop it in multiple functions. He meant c=
omposition.=C2=A0</div><div>He repeated it, this time in the meaning that t=
hey are ultimately functions that take type and return bool (pass/no-pass).=
</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><br></div><div>I find this function as a vari=
able thing confusing to coming to terms with what Concepts actually are.</d=
iv></div></blockquote><div><br></div><div>It is best to think of Concepts a=
s, well, Concepts, a type-consternating construct that is instantiated as t=
emplated variable,</div><div>=C2=A0but the compiler uses it as function ret=
urning bool</div><div><br></div><div>Instead of=C2=A0</div><div>requires so=
mething<T>()</div><div>you can</div><div>requires Something<T><=
br></div><div>=C2=A0</div><div><br></div><div>All in all, a care is taken t=
o streamline Concepts as much as possible.=C2=A0</div><div><br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><br>If Concepts ARE functions as Bjarne says, why shouldn't they lo=
ok and be composed using functional notation?</div><div><br></div><div>It s=
eems I'm not alone in this feeling. J. Monnon proposes this:<br>Type fu=
nctions and beyond<br>An exploration of type functions and concept function=
s<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p08=
44r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0844r0.html\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNEFr_9YGZO5BDdyaSw7BW7ttm0_LQ';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%=
2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0844r0.html\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNEFr_9YGZO5BDdyaSw7BW7ttm0_LQ';return true;">htt=
p://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2018/<wbr>p0844r0.html=
</a></div><p>He says: "This document proposes to extend functions to l=
et them operate directly on types and concepts.<br>The goal is to allow wri=
ting metaprogramming in the most intuitive and consistent way with the rest=
of the language."</p><p>J. Monnon says:</p><p>Here is an example of a=
type function:<br>=C2=A0=C2=A0=C2=A0 ForwardIterator IteratorType(typename=
T) {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // In a type function, =
an `if` behaves as a `if constexpr`.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 if (Container(T))=C2=A0 // `Container` is a concept<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return T::iterato=
r;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else if (Array(T)) // `Arr=
ay` is a concept<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 return Decay(T);<br>=C2=A0=C2=A0=C2=A0 }</p><p>=C2=A0=C2=A0=C2=
=A0 // On call site:<br>=C2=A0=C2=A0=C2=A0 typename I =3D IteratorType(C);<=
/p><div><br></div></div></blockquote><div><br></div><div>Now this is someth=
ing <i>completely </i>different - note how the function returns a different=
type, not a bool</div><div><br></div><div>This proposal=C2=A0 is adding ty=
pe <i>transformation </i>machinery,=C2=A0 in contrast to=C2=A0 Concepts whi=
ch are type <i>filtering </i>machinery</div><div><br></div><div><br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div></div><div>J. Monnon says:<br>"A type function is always execu=
ted at compile-time. Here, it takes a type T and returns another type that =
models the ForwardIterator concept. Type functions allow a natural and stra=
ightforward notation to manipulate types."</div><div><br></div><div>Th=
is also justifies his comment which I emphasise: // In a type function, an =
`if` behaves as a `if constexpr`.</div><div><br></div><div>At this time, I=
=C2=A0agree with J. Monnon's proposal. I find it intuitive and insightf=
ul if I understand it correctly.<br>If J. Monnon's paper has been discu=
ssed at any length anywhere, can someone please tell me the outcome?</div><=
div>His proposal=C2=A0appeared on Reddit at one point but attracted a near =
zero response there, which stunned me.<br>I'd certainly like to see mor=
e commentary on that proposal here before the next Standards meeting that i=
s imminent.</div><div><br></div><div>I may be wrong, but doesn't the D =
language go this route also? What is so wrong with that approach=C2=A0that =
C++ goes it's own way?</div><div><br></div><div>There is more I would l=
ike to say about Concepts such as why I hate the syntax as currently propos=
ed.<br>But for now, I'd really like to focus this discussion on the mai=
n elements I've raised.<br>1. If concepts ARE functions, why aren't=
we defining and using them with function like syntax? And using () not <=
;>.<br>2. It seems J. Monnon's proposal is making the same point as =
I am, only much better? Can we please address all that he proposes?<br>3. I=
feel a more formal response to J. Monnon's paper from the main propone=
nts of Concepts as currently defined should be made before concepts get wir=
ed in any further in it's current direction?</div><div><br></div><div>I=
know many people would like Concepts be the marquee feature of C++20, but =
to me Concepts=C2=A0still seem quite away from where I'd like them to b=
e.<br>Even Bjarne can only 'begrudgingly live' with the current syn=
tax.<br>All this flux and begrudging really doesn't suggest to me that =
Concepts are ready to go for C++20.<br>This is even before any of my commen=
ts or J. Monnon's paper is taken into account.</div></div></blockquote>=
<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div>Right now, I feel that if Modules and Coroutines we=
re the only main features that hit for C++20, I'd be happy with that.<b=
r>If people can=C2=A0explain why my comments are on the mark or misplaced=
=C2=A0and what the issues are with=C2=A0J. Monnon's proposal,=C2=A0I=
9;d be grateful.</div></div></blockquote><div><br></div><div>Modules and Co=
routines don't have good chances for 20.=C2=A0</div><div>The main new f=
eatures will be Concepts and Contracts.=C2=A0</div><div><br></div><div>Your=
comments are perfectly valid and people teaching C++ should take them into=
account - the fact people can be confused about variable vs function.</div=
><div><br></div><div>As for J. M, proposal - we must see how this would com=
pare with Reflections as Reflection will also be able to "emit code&qu=
ot; and "return a type".</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>Thanks</di=
v><div><br></div></div></blockquote></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/bffc5427-9959-47b0-9e89-852d4430b6e3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bffc5427-9959-47b0-9e89-852d4430b6e3=
%40isocpp.org</a>.<br />
------=_Part_192_167129538.1540451046278--
------=_Part_191_1673856816.1540451046278--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sat, 27 Oct 2018 13:27:57 -0700 (PDT)
Raw View
------=_Part_1293_1543572160.1540672078085
Content-Type: multipart/alternative;
boundary="----=_Part_1294_805556285.1540672078086"
------=_Part_1294_805556285.1540672078086
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, gmis...@gmail.com wrote=
:
>
> A few thoughts on Concepts:
>
> As Concepts have evolved, I have found it difficult to get a handle on=20
> what Concepts actually are.
> i.e.: Are Concepts functions, types, or something else?
>
Something else.
=20
> Bjarne's CppCon 2018 talk "Concepts: The Future of Generic Programming"=
=20
> <https://www.youtube.com/watch?v=3DHddFGPTAmtU> answers that question=20
> clearly.
>
> In his talk, Bjarne says:
> * Concepts are NOT types of types. They are NOT type classes.
>
Well, they sort-of are. To a first approximation, they're predicates (type=
=20
-> bool), which can be understood as partitions of the set of all types.
For any type T, either T is-a Range or T is-not-a Range. So the set of=20
Ranges is a subset of the set of all possible types.
BUT! Look closer and there are at least three caveats.
(1) Concepts have deep structure known as "normal form"; see below.
(2) Concepts don't have to map (type -> bool); you can have multi-parameter=
=20
concepts such as ConvertibleTo<T,U>, which are not as easily to gloss as=20
predicates over single types. (But darned if the Concepts TS doesn't try!=
=20
For any type T, either T is-a ConvertibleTo<U> or T is-not-a=20
ConvertibleTo<U>.)
(3) Concepts don't have to accept types at all. For example, you can make a=
=20
concept that maps (int -> bool).
template<int V>
concept EvenValue =3D ((V % 2) =3D=3D 0);
I don't think this kind of concept is useful in real code (I'd prefer this=
=20
kind of concept be kicked out of the Working Draft before C++2a is=20
shipped). But you definitely can't by any mental gymnastics claim that=20
concept `EvenValue` is a "type function" or a "type of types" or anything=
=20
remotely like that.
At around 1:06:30 in his talk Bjarne says:
> * "it's just like defining functions, you *ARE* DEFINING FUNCTIONS".
>
I believe that was an ad-lib not to be taken 100% literally. To a first=20
approximation, a concept like Mergeable is a function mapping an ordered=20
tuple of types to a bool. But that doesn't mean that *all concepts ever*=20
must be thought of as functions.
That way lies functional programming and madness. ;)
[...]
> The Concepts defined in Bjarne's talk look more like variable definitions=
=20
> *defined* in what feels (to me) like an odd mix of logic and type like=20
> syntax:
>
> template<typename X> using Value_type =3D X::value_type;
> template<typename X> using Iterator_of =3D X::iterator;
>
> template<typename For, typename For2, typename Out>
> concept Mergable =3D
> ForwardIterator<For>
> && ForwardIterator<For2>
> && OutputIterator<Out>
> && Assignable<Value_type<For>,Value_type<Out>>
> && Assignable<Value_type<For2>,Value_type<Out>>
> && Comparable<Value_type<For>,Value_type<For2>>;
>
> The above looks like a variable definition. If it is not, then is it righ=
t=20
> that it looks like one?
> It's a definition, with conditional logic et al. i.e it uses &&. etc. lik=
e=20
> an inline function.
> So why are we defining it NOT using function like snytax?
> Why is this a good thing?
>
Because of the first caveat I listed above: Concepts are not *just*=20
predicates. They are logical predicates with deep structure, described by=
=20
their *normal form*. For example, there is no special relationship between=
=20
the variable templates
template<class T> inline constexpr bool is_scalar_v =3D=20
std::is_scalar<T>::value;
template<class T> inline constexpr bool is_integral_v =3D is_scalar_v<T=
>=20
&& std::is_integral<T>::value;
but there is a very special relationship between the concept( template)s
template<class T> concept is_scalar_c =3D std::is_scalar<T>::value;
template<class T> concept is_integral_c =3D is_scalar_c<T> &&=20
std::is_integral<T>::value;
The special relationship is called *subsumption*, and we say that=20
is_integral_c<X> *subsumes* is_scalar_c<X>.
If it weren't for subsumption, there would be no fundamental difference=20
between a concept and a variable template of type `bool`.
The compiler determines the subsumption relationships between concepts by=
=20
cracking open their definitions and peering inside. The definitions are=20
cracked open *only* along the boundaries of the logical `&&` and `||`=20
operators. So it is critically important that the definition of a concept=
=20
be a single logical expression. If a concept were allowed to be expressed=
=20
as a function body, the compiler wouldn't be able to crack it open, lift it=
=20
into *normal form*, and figure out the *subsumption* relationships between=
=20
this concept and all the other concepts in your program.
Figuring out these relationships is important to the compiler because these=
=20
relationships affect overload resolution.
Please see my CppCon 2018 talk "Concepts as she is spoke"=20
<https://www.youtube.com/watch?v=3DCXn02MPkn8Y> for a truly painful amount =
of=20
information on how Concepts are different from plain old variable templates=
..
[...]
> 1. If concepts ARE functions, why aren't we defining and using them with=
=20
> function like syntax? And using () not <>.
>
I hope my answers above have pointed the way on this one.
=20
> 2. It seems J. Monnon's proposal is making the same point as I am, only=
=20
> much better? Can we please address all that he proposes?
>
I think P0844 "Type functions and beyond"=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html> is=
=20
thought-provoking. It's very large, though, which I believe is why it's=20
targeted at SG7 Compile-Time Programming (formerly SG7 Reflection).
P0844 major section 3, "Concepts introducing types," seems to ignore the=20
existence of non-type concepts in the Working Draft. Perhaps there should=
=20
be a concerted effort to *kick non-type concepts out of the Working Draft*=
=20
in order to gain some freedom of motion for these recurring theories of=20
"concepts =3D=3D types of types."
I do not believe that P0844 is making the same points (or, asking for=20
clarification on the same points) as you are. I have only skimmed P0844,=20
but it does not seem to be engaging with Concepts-as-they-are at all; it=20
seems to be trying to reuse Concepty words to refer to elements of the=20
author's more na=C3=AFve "types of types" theory.
(More na=C3=AFve is not necessarily bad! I think C++2a Concepts is *far* t=
oo=20
much of an experts-only feature, and we could use a lot more naivet=C3=A9 i=
n=20
this area.)
3. I feel a more formal response to J. Monnon's paper from the main=20
> proponents of Concepts as currently defined should be made before concept=
s=20
> get wired in any further in it's current direction?
>
> I know many people would like Concepts be the marquee feature of C++20,=
=20
> but to me Concepts still seem quite away from where I'd like them to be.
> Even Bjarne can only 'begrudgingly live' with the current syntax.
> All this flux and begrudging really doesn't suggest to me that Concepts=
=20
> are ready to go for C++20.
>
FWIW, I agree with your conclusion.
The question is, do C++2a Concepts need wholesale kicking-out, as happened=
=20
in C++11? or can they be rescued by judicious cuts?
The other question is, can anyone stop Concepts at this point or are the=20
wise people getting out of the way of the train? (Cynic says: observe the=
=20
recent formation of EWGI and LEWGI for those people tired of engaging with=
=20
C++2a issues and eager to move on to C++2b.)
=E2=80=93Arthur
--=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/9f8f8811-f1cb-4f4b-b4fb-15dfa8568881%40isocpp.or=
g.
------=_Part_1294_805556285.1540672078086
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, gmis..=
..@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"><div>A few thoughts on Concepts:</div><div><br></div><div>As Concepts =
have evolved, I have found it difficult to get a handle on what Concepts ac=
tually are.<br>i.e.: Are Concepts functions, types, or something else?</div=
></div></blockquote><div><br></div><div>Something else.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><a hr=
ef=3D"https://www.youtube.com/watch?v=3DHddFGPTAmtU">Bjarne's CppCon 20=
18 talk "Concepts: The Future of Generic Programming"</a> answers=
that question clearly.<br></div><p>In his talk, Bjarne says:<br>* Concepts=
are NOT types of types. They are NOT type classes.<br></p></div></blockquo=
te><div><br></div><div>Well, they sort-of are. To a first approximation, th=
ey're predicates (type -> bool), which can be understood as partitio=
ns of the set of all types.</div><div>For any type T, either T is-a Range o=
r T is-not-a Range. So the set of Ranges is a subset of the set of all poss=
ible types.</div><div>BUT! Look closer and there are at least three caveats=
..</div><div>(1) Concepts have deep structure known as "normal form&quo=
t;; see below.</div><div>(2) Concepts don't have to map (type -> boo=
l); you can have multi-parameter concepts such as ConvertibleTo<T,U>,=
which are not as easily to gloss as predicates over single types. (But dar=
ned if the Concepts TS doesn't try! For any type T, either T is-a Conve=
rtibleTo<U> or T is-not-a ConvertibleTo<U>.)</div><div>(3) Conc=
epts don't have to accept types at all. For example, you can make a con=
cept that maps (int -> bool).</div><div><br></div><div>=C2=A0 =C2=A0 tem=
plate<int V></div><div>=C2=A0 =C2=A0 concept EvenValue =3D ((V % 2) =
=3D=3D 0);</div><div><br></div><div>I don't think this kind of concept =
is useful in real code (I'd prefer this kind of concept be kicked out o=
f the Working Draft before C++2a is shipped). But you definitely can't =
by any mental gymnastics claim that concept `EvenValue`=C2=A0is a "typ=
e function" or a "type of types" or anything remotely like t=
hat.</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><p>At around 1:06:30 in his talk Bjarne says:<br=
>* "it's just like defining functions, you *ARE* DEFINING FUNCTION=
S".</p></div></blockquote><div><br></div><div>I believe that was an ad=
-lib not to be taken 100% literally. To a first approximation, a concept li=
ke Mergeable is a function mapping an ordered tuple of types to a bool. But=
that doesn't mean that <i>all concepts ever</i> must be thought of as =
functions.</div><div>That way lies functional programming and madness. ;)</=
div><div><br></div><div>[...]</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>The Concepts defined in Bjarne's talk look =
more like variable definitions *defined* in what feels (to me) like an odd =
mix of logic and type like syntax:<br></div><p>template<typename X> u=
sing Value_type =3D X::value_type;<br>template<typename X> using Iter=
ator_of =3D X::iterator;</p><p>template<typename For, typename For2, typ=
ename Out><br>concept Mergable =3D<br>=C2=A0=C2=A0=C2=A0 ForwardIterator=
<For><br>=C2=A0=C2=A0=C2=A0 && ForwardIterator<For2><br=
>=C2=A0=C2=A0=C2=A0 && OutputIterator<Out><br>=C2=A0=C2=A0=C2=
=A0 && Assignable<Value_type<For>,<wbr>Value_type<Out&g=
t;><br>=C2=A0=C2=A0=C2=A0 && Assignable<Value_type<For2>=
;,<wbr>Value_type<Out>><br>=C2=A0=C2=A0=C2=A0 && Comparabl=
e<Value_type<For>,<wbr>Value_type<For2>>;</p><div><br></d=
iv><div>The above looks like a variable definition. If it is not, then is i=
t right that it looks like one?<br>It's a definition, with conditional =
logic et al. i.e it uses &&. etc. like an inline function.<br></div=
><div>So why are we defining it NOT using function like snytax?<br>Why is t=
his a good thing?</div></div></blockquote><div><br></div><div>Because of th=
e first caveat I listed above: Concepts are not <i>just</i> predicates. The=
y are logical predicates with deep structure, described by their <i>normal =
form</i>. For example, there is no special relationship between the variabl=
e templates</div><div><br></div><div>=C2=A0 =C2=A0 template<class T> =
inline constexpr bool is_scalar_v =3D std::is_scalar<T>::value;</div>=
<div>=C2=A0 =C2=A0 template<class T> inline constexpr bool is_integra=
l_v =3D is_scalar_v<T> && std::is_integral<T>::value;</=
div><div><br></div><div>but there is a very special relationship between th=
e concept( template)s</div><div><br></div><div><div>=C2=A0 =C2=A0 template&=
lt;class T> concept is_scalar_c =3D std::is_scalar<T>::value;</div=
><div>=C2=A0 =C2=A0 template<class T> concept is_integral_c =3D is_sc=
alar_c<T> && std::is_integral<T>::value;</div></div><di=
v><br></div><div>The special relationship is called <i>subsumption</i>, and=
we say that is_integral_c<X> <i>subsumes</i> is_scalar_c<X>.</=
div><div>If it weren't for subsumption, there would be no fundamental d=
ifference between a concept and a variable template of type `bool`.</div><d=
iv><br></div><div>The compiler determines the subsumption relationships bet=
ween concepts by cracking open their definitions and peering inside. The de=
finitions are cracked open <i>only</i> along the boundaries of the logical =
`&&` and `||` operators. So it is critically important that the def=
inition of a concept be a single logical expression. If a concept were allo=
wed to be expressed as a function body, the compiler wouldn't be able t=
o crack it open, lift it into <i>normal form</i>, and figure out the <i>sub=
sumption</i> relationships between this concept and all the other concepts =
in your program.</div><div><br></div><div>Figuring out these relationships =
is important to the compiler because these relationships affect overload re=
solution.</div><div><br></div><div>Please see my CppCon 2018 talk <a href=
=3D"https://www.youtube.com/watch?v=3DCXn02MPkn8Y">"Concepts as she is=
spoke"</a> for a truly painful amount of information on how Concepts =
are different from plain old variable templates.</div><div><br></div><div>[=
....]</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>1. If concepts ARE functions, why aren't we defining and using them w=
ith function like syntax? And using () not <>.<br></div></div></block=
quote><div><br></div><div>I hope my answers above have pointed the way on t=
his one.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div>2. It seems J. Monnon's proposal is making the s=
ame point as I am, only much better? Can we please address all that he prop=
oses?<br></div></div></blockquote><div><br></div><div>I think <a href=3D"ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html">P0844 &=
quot;Type functions and beyond"</a> is thought-provoking. It's ver=
y large, though, which I believe is why it's targeted at SG7 Compile-Ti=
me Programming (formerly SG7 Reflection).</div><div>P0844 major section 3, =
"Concepts introducing types," seems to ignore the existence of no=
n-type concepts in the Working Draft. Perhaps there should be a concerted e=
ffort to <i>kick non-type concepts out of the Working Draft</i> in order to=
gain some freedom of motion for these recurring theories of "concepts=
=3D=3D types of types."</div><div>I do not believe that P0844 is maki=
ng the same points (or, asking for clarification on the same points) as you=
are. I have only skimmed P0844, but it does not seem to be engaging with C=
oncepts-as-they-are at all; it seems to be trying to reuse Concepty words t=
o refer to elements of the author's more na=C3=AFve "types of type=
s" theory.</div><div>(More na=C3=AFve is not necessarily bad! =C2=A0I =
think C++2a Concepts is <i>far</i> too much of an experts-only feature, and=
we could use a lot more naivet=C3=A9 in this area.)</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>3. I feel =
a more formal response to J. Monnon's paper from the main proponents of=
Concepts as currently defined should be made before concepts get wired in =
any further in it's current direction?</div><div><br></div><div>I know =
many people would like Concepts be the marquee feature of C++20, but to me =
Concepts=C2=A0still seem quite away from where I'd like them to be.<br>=
Even Bjarne can only 'begrudgingly live' with the current syntax.<b=
r>All this flux and begrudging really doesn't suggest to me that Concep=
ts are ready to go for C++20.<br></div></div></blockquote><div><br></div><d=
iv>FWIW, I agree with your conclusion.</div><div>The question is, do C++2a =
Concepts need wholesale kicking-out, as happened in C++11? or can they be r=
escued by judicious cuts?</div><div>The other question is, can anyone stop =
Concepts at this point or are the wise people getting out of the way of the=
train? (Cynic says: observe the recent formation of EWGI and LEWGI for tho=
se people tired of engaging with C++2a issues and eager to move on to C++2b=
..)</div><div><br></div><div>=E2=80=93Arthur</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/9f8f8811-f1cb-4f4b-b4fb-15dfa8568881%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9f8f8811-f1cb-4f4b-b4fb-15dfa8568881=
%40isocpp.org</a>.<br />
------=_Part_1294_805556285.1540672078086--
------=_Part_1293_1543572160.1540672078085--
.
Author: mihailnajdenov@gmail.com
Date: Sun, 28 Oct 2018 03:44:32 -0700 (PDT)
Raw View
------=_Part_1295_1328710690.1540723472113
Content-Type: multipart/alternative;
boundary="----=_Part_1296_898936977.1540723472114"
------=_Part_1296_898936977.1540723472114
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Arthur,=20
If you don't think value concepts should not be in, then you should write a=
=20
paper - it is probably worth a careful investigation.=20
Should be noted, Concepts are *template argument filters* and as such=20
people will argue that for consistency alone it is worth having concepts=20
over values
simply because template arguments can be values as well.
That said, concepts over values might have outlived their usefulness with=
=20
the introduction of static assert, constexpr if and contracts.
An investigating where exactly they are still useful will be nice to have,=
=20
if for no other reason then teachability.=20
=20
On Saturday, October 27, 2018 at 11:27:58 PM UTC+3, Arthur O'Dwyer wrote:
>
> On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, gmis...@gmail.com=20
> wrote:
>>
>> A few thoughts on Concepts:
>>
>> As Concepts have evolved, I have found it difficult to get a handle on=
=20
>> what Concepts actually are.
>> i.e.: Are Concepts functions, types, or something else?
>>
>
> Something else.
> =20
>
>> Bjarne's CppCon 2018 talk "Concepts: The Future of Generic Programming"=
=20
>> <https://www.youtube.com/watch?v=3DHddFGPTAmtU> answers that question=20
>> clearly.
>>
>> In his talk, Bjarne says:
>> * Concepts are NOT types of types. They are NOT type classes.
>>
>
> Well, they sort-of are. To a first approximation, they're predicates (typ=
e=20
> -> bool), which can be understood as partitions of the set of all types.
> For any type T, either T is-a Range or T is-not-a Range. So the set of=20
> Ranges is a subset of the set of all possible types.
> BUT! Look closer and there are at least three caveats.
> (1) Concepts have deep structure known as "normal form"; see below.
> (2) Concepts don't have to map (type -> bool); you can have=20
> multi-parameter concepts such as ConvertibleTo<T,U>, which are not as=20
> easily to gloss as predicates over single types. (But darned if the=20
> Concepts TS doesn't try! For any type T, either T is-a ConvertibleTo<U> o=
r=20
> T is-not-a ConvertibleTo<U>.)
> (3) Concepts don't have to accept types at all. For example, you can make=
=20
> a concept that maps (int -> bool).
>
> template<int V>
> concept EvenValue =3D ((V % 2) =3D=3D 0);
>
> I don't think this kind of concept is useful in real code (I'd prefer thi=
s=20
> kind of concept be kicked out of the Working Draft before C++2a is=20
> shipped). But you definitely can't by any mental gymnastics claim that=20
> concept `EvenValue` is a "type function" or a "type of types" or anything=
=20
> remotely like that.
>
>
> At around 1:06:30 in his talk Bjarne says:
>> * "it's just like defining functions, you *ARE* DEFINING FUNCTIONS".
>>
>
> I believe that was an ad-lib not to be taken 100% literally. To a first=
=20
> approximation, a concept like Mergeable is a function mapping an ordered=
=20
> tuple of types to a bool. But that doesn't mean that *all concepts ever*=
=20
> must be thought of as functions.
> That way lies functional programming and madness. ;)
>
> [...]
>
>> The Concepts defined in Bjarne's talk look more like variable definition=
s=20
>> *defined* in what feels (to me) like an odd mix of logic and type like=
=20
>> syntax:
>>
>> template<typename X> using Value_type =3D X::value_type;
>> template<typename X> using Iterator_of =3D X::iterator;
>>
>> template<typename For, typename For2, typename Out>
>> concept Mergable =3D
>> ForwardIterator<For>
>> && ForwardIterator<For2>
>> && OutputIterator<Out>
>> && Assignable<Value_type<For>,Value_type<Out>>
>> && Assignable<Value_type<For2>,Value_type<Out>>
>> && Comparable<Value_type<For>,Value_type<For2>>;
>>
>> The above looks like a variable definition. If it is not, then is it=20
>> right that it looks like one?
>> It's a definition, with conditional logic et al. i.e it uses &&. etc.=20
>> like an inline function.
>> So why are we defining it NOT using function like snytax?
>> Why is this a good thing?
>>
>
> Because of the first caveat I listed above: Concepts are not *just*=20
> predicates. They are logical predicates with deep structure, described by=
=20
> their *normal form*. For example, there is no special relationship=20
> between the variable templates
>
> template<class T> inline constexpr bool is_scalar_v =3D=20
> std::is_scalar<T>::value;
> template<class T> inline constexpr bool is_integral_v =3D is_scalar_v=
<T>=20
> && std::is_integral<T>::value;
>
> but there is a very special relationship between the concept( template)s
>
> template<class T> concept is_scalar_c =3D std::is_scalar<T>::value;
> template<class T> concept is_integral_c =3D is_scalar_c<T> &&=20
> std::is_integral<T>::value;
>
> The special relationship is called *subsumption*, and we say that=20
> is_integral_c<X> *subsumes* is_scalar_c<X>.
> If it weren't for subsumption, there would be no fundamental difference=
=20
> between a concept and a variable template of type `bool`.
>
> The compiler determines the subsumption relationships between concepts by=
=20
> cracking open their definitions and peering inside. The definitions are=
=20
> cracked open *only* along the boundaries of the logical `&&` and `||`=20
> operators. So it is critically important that the definition of a concept=
=20
> be a single logical expression. If a concept were allowed to be expressed=
=20
> as a function body, the compiler wouldn't be able to crack it open, lift =
it=20
> into *normal form*, and figure out the *subsumption* relationships=20
> between this concept and all the other concepts in your program.
>
> Figuring out these relationships is important to the compiler because=20
> these relationships affect overload resolution.
>
> Please see my CppCon 2018 talk "Concepts as she is spoke"=20
> <https://www.youtube.com/watch?v=3DCXn02MPkn8Y> for a truly painful amoun=
t=20
> of information on how Concepts are different from plain old variable=20
> templates.
>
> [...]
>
>> 1. If concepts ARE functions, why aren't we defining and using them with=
=20
>> function like syntax? And using () not <>.
>>
>
> I hope my answers above have pointed the way on this one.
> =20
>
>> 2. It seems J. Monnon's proposal is making the same point as I am, only=
=20
>> much better? Can we please address all that he proposes?
>>
>
> I think P0844 "Type functions and beyond"=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html> is=
=20
> thought-provoking. It's very large, though, which I believe is why it's=
=20
> targeted at SG7 Compile-Time Programming (formerly SG7 Reflection).
> P0844 major section 3, "Concepts introducing types," seems to ignore the=
=20
> existence of non-type concepts in the Working Draft. Perhaps there should=
=20
> be a concerted effort to *kick non-type concepts out of the Working Draft=
*=20
> in order to gain some freedom of motion for these recurring theories of=
=20
> "concepts =3D=3D types of types."
> I do not believe that P0844 is making the same points (or, asking for=20
> clarification on the same points) as you are. I have only skimmed P0844,=
=20
> but it does not seem to be engaging with Concepts-as-they-are at all; it=
=20
> seems to be trying to reuse Concepty words to refer to elements of the=20
> author's more na=C3=AFve "types of types" theory.
> (More na=C3=AFve is not necessarily bad! I think C++2a Concepts is *far*=
too=20
> much of an experts-only feature, and we could use a lot more naivet=C3=A9=
in=20
> this area.)
>
> 3. I feel a more formal response to J. Monnon's paper from the main=20
>> proponents of Concepts as currently defined should be made before concep=
ts=20
>> get wired in any further in it's current direction?
>>
>> I know many people would like Concepts be the marquee feature of C++20,=
=20
>> but to me Concepts still seem quite away from where I'd like them to be.
>> Even Bjarne can only 'begrudgingly live' with the current syntax.
>> All this flux and begrudging really doesn't suggest to me that Concepts=
=20
>> are ready to go for C++20.
>>
>
> FWIW, I agree with your conclusion.
> The question is, do C++2a Concepts need wholesale kicking-out, as happene=
d=20
> in C++11? or can they be rescued by judicious cuts?
> The other question is, can anyone stop Concepts at this point or are the=
=20
> wise people getting out of the way of the train? (Cynic says: observe the=
=20
> recent formation of EWGI and LEWGI for those people tired of engaging wit=
h=20
> C++2a issues and eager to move on to C++2b.)
>
> =E2=80=93Arthur
>
--=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/17eb2726-8feb-4cdf-a58e-43d6dc81549a%40isocpp.or=
g.
------=_Part_1296_898936977.1540723472114
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Arthur,=C2=A0<div>If you don't think value concepts sh=
ould not be in, then you should write a paper - it is probably worth a care=
ful investigation.=C2=A0<div><br></div><div>Should be noted, Concepts are <=
i>template argument filters</i> and as such people will argue that for cons=
istency alone it is worth having concepts over values</div><div>simply beca=
use template arguments can be values as well.</div><div><br></div><div>That=
said,=C2=A0concepts over values might have outlived their usefulness with =
the introduction of static assert, constexpr if and contracts.</div><div><b=
r></div><div>An investigating where exactly they are still useful will be n=
ice to have, if for no other reason then teachability.=C2=A0<br><div>=C2=A0=
<br><br>On Saturday, October 27, 2018 at 11:27:58 PM UTC+3, Arthur O'Dw=
yer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On =
Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, <a>gmis...@gmail.com</a> w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>A few th=
oughts on Concepts:</div><div><br></div><div>As Concepts have evolved, I ha=
ve found it difficult to get a handle on what Concepts actually are.<br>i.e=
..: Are Concepts functions, types, or something else?</div></div></blockquot=
e><div><br></div><div>Something else.</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div><a href=3D"https://www.youtu=
be.com/watch?v=3DHddFGPTAmtU" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'https://www.youtube.com/watch?v\x3dHddFGPTAmtU';r=
eturn true;" onclick=3D"this.href=3D'https://www.youtube.com/watch?v\x3=
dHddFGPTAmtU';return true;">Bjarne's CppCon 2018 talk "Concept=
s: The Future of Generic Programming"</a> answers that question clearl=
y.<br></div><p>In his talk, Bjarne says:<br>* Concepts are NOT types of typ=
es. They are NOT type classes.<br></p></div></blockquote><div><br></div><di=
v>Well, they sort-of are. To a first approximation, they're predicates =
(type -> bool), which can be understood as partitions of the set of all =
types.</div><div>For any type T, either T is-a Range or T is-not-a Range. S=
o the set of Ranges is a subset of the set of all possible types.</div><div=
>BUT! Look closer and there are at least three caveats.</div><div>(1) Conce=
pts have deep structure known as "normal form"; see below.</div><=
div>(2) Concepts don't have to map (type -> bool); you can have mult=
i-parameter concepts such as ConvertibleTo<T,U>, which are not as eas=
ily to gloss as predicates over single types. (But darned if the Concepts T=
S doesn't try! For any type T, either T is-a ConvertibleTo<U> or =
T is-not-a ConvertibleTo<U>.)</div><div>(3) Concepts don't have t=
o accept types at all. For example, you can make a concept that maps (int -=
> bool).</div><div><br></div><div>=C2=A0 =C2=A0 template<int V></d=
iv><div>=C2=A0 =C2=A0 concept EvenValue =3D ((V % 2) =3D=3D 0);</div><div><=
br></div><div>I don't think this kind of concept is useful in real code=
(I'd prefer this kind of concept be kicked out of the Working Draft be=
fore C++2a is shipped). But you definitely can't by any mental gymnasti=
cs claim that concept `EvenValue`=C2=A0is a "type function" or a =
"type of types" or anything remotely like that.</div><div><br></d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<p>At around 1:06:30 in his talk Bjarne says:<br>* "it's just like=
defining functions, you *ARE* DEFINING FUNCTIONS".</p></div></blockqu=
ote><div><br></div><div>I believe that was an ad-lib not to be taken 100% l=
iterally. To a first approximation, a concept like Mergeable is a function =
mapping an ordered tuple of types to a bool. But that doesn't mean that=
<i>all concepts ever</i> must be thought of as functions.</div><div>That w=
ay lies functional programming and madness. ;)</div><div><br></div><div>[..=
..]</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The C=
oncepts defined in Bjarne's talk look more like variable definitions *d=
efined* in what feels (to me) like an odd mix of logic and type like syntax=
:<br></div><p>template<typename X> using Value_type =3D X::value_type=
;<br>template<typename X> using Iterator_of =3D X::iterator;</p><p>te=
mplate<typename For, typename For2, typename Out><br>concept Mergable=
=3D<br>=C2=A0=C2=A0=C2=A0 ForwardIterator<For><br>=C2=A0=C2=A0=C2=A0=
&& ForwardIterator<For2><br>=C2=A0=C2=A0=C2=A0 && Ou=
tputIterator<Out><br>=C2=A0=C2=A0=C2=A0 && Assignable<Valu=
e_type<For>,<wbr>Value_type<Out>><br>=C2=A0=C2=A0=C2=A0 &=
;& Assignable<Value_type<For2>,<wbr>Value_type<Out>><=
br>=C2=A0=C2=A0=C2=A0 && Comparable<Value_type<For>,<wbr>V=
alue_type<For2>>;</p><div><br></div><div>The above looks like a va=
riable definition. If it is not, then is it right that it looks like one?<b=
r>It's a definition, with conditional logic et al. i.e it uses &&am=
p;. etc. like an inline function.<br></div><div>So why are we defining it N=
OT using function like snytax?<br>Why is this a good thing?</div></div></bl=
ockquote><div><br></div><div>Because of the first caveat I listed above: Co=
ncepts are not <i>just</i> predicates. They are logical predicates with dee=
p structure, described by their <i>normal form</i>. For example, there is n=
o special relationship between the variable templates</div><div><br></div><=
div>=C2=A0 =C2=A0 template<class T> inline constexpr bool is_scalar_v=
=3D std::is_scalar<T>::value;</div><div>=C2=A0 =C2=A0 template<cl=
ass T> inline constexpr bool is_integral_v =3D is_scalar_v<T> &=
;& std::is_integral<T>::value;</div><div><br></div><div>but there=
is a very special relationship between the concept( template)s</div><div><=
br></div><div><div>=C2=A0 =C2=A0 template<class T> concept is_scalar_=
c =3D std::is_scalar<T>::value;</div><div>=C2=A0 =C2=A0 template<c=
lass T> concept is_integral_c =3D is_scalar_c<T> && std::i=
s_integral<T>::value;</div></div><div><br></div><div>The special rela=
tionship is called <i>subsumption</i>, and we say that is_integral_c<X&g=
t; <i>subsumes</i> is_scalar_c<X>.</div><div>If it weren't for su=
bsumption, there would be no fundamental difference between a concept and a=
variable template of type `bool`.</div><div><br></div><div>The compiler de=
termines the subsumption relationships between concepts by cracking open th=
eir definitions and peering inside. The definitions are cracked open <i>onl=
y</i> along the boundaries of the logical `&&` and `||` operators. =
So it is critically important that the definition of a concept be a single =
logical expression. If a concept were allowed to be expressed as a function=
body, the compiler wouldn't be able to crack it open, lift it into <i>=
normal form</i>, and figure out the <i>subsumption</i> relationships betwee=
n this concept and all the other concepts in your program.</div><div><br></=
div><div>Figuring out these relationships is important to the compiler beca=
use these relationships affect overload resolution.</div><div><br></div><di=
v>Please see my CppCon 2018 talk <a href=3D"https://www.youtube.com/watch?v=
=3DCXn02MPkn8Y" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'https://www.youtube.com/watch?v\x3dCXn02MPkn8Y';return true;" o=
nclick=3D"this.href=3D'https://www.youtube.com/watch?v\x3dCXn02MPkn8Y&#=
39;;return true;">"Concepts as she is spoke"</a> for a truly pain=
ful amount of information on how Concepts are different from plain old vari=
able templates.</div><div><br></div><div>[...]</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>1. If concepts ARE functions, why ar=
en't we defining and using them with function like syntax? And using ()=
not <>.<br></div></div></blockquote><div><br></div><div>I hope my an=
swers above have pointed the way on this one.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>2. It seems J. Monno=
n's proposal is making the same point as I am, only much better? Can we=
please address all that he proposes?<br></div></div></blockquote><div><br>=
</div><div>I think <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2018/p0844r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.o=
rg%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0844r0.html\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNEFr_9YGZO5BDdyaSw7BW7ttm0_LQ';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww=
..open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0844r0.html\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFr_9YGZO5BDdyaSw7BW7ttm0_LQ';ret=
urn true;">P0844 "Type functions and beyond"</a> is thought-provo=
king. It's very large, though, which I believe is why it's targeted=
at SG7 Compile-Time Programming (formerly SG7 Reflection).</div><div>P0844=
major section 3, "Concepts introducing types," seems to ignore t=
he existence of non-type concepts in the Working Draft. Perhaps there shoul=
d be a concerted effort to <i>kick non-type concepts out of the Working Dra=
ft</i> in order to gain some freedom of motion for these recurring theories=
of "concepts =3D=3D types of types."</div><div>I do not believe =
that P0844 is making the same points (or, asking for clarification on the s=
ame points) as you are. I have only skimmed P0844, but it does not seem to =
be engaging with Concepts-as-they-are at all; it seems to be trying to reus=
e Concepty words to refer to elements of the author's more na=C3=AFve &=
quot;types of types" theory.</div><div>(More na=C3=AFve is not necessa=
rily bad! =C2=A0I think C++2a Concepts is <i>far</i> too much of an experts=
-only feature, and we could use a lot more naivet=C3=A9 in this area.)</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>3. I feel a more formal response to J. Monnon's paper from the main =
proponents of Concepts as currently defined should be made before concepts =
get wired in any further in it's current direction?</div><div><br></div=
><div>I know many people would like Concepts be the marquee feature of C++2=
0, but to me Concepts=C2=A0still seem quite away from where I'd like th=
em to be.<br>Even Bjarne can only 'begrudgingly live' with the curr=
ent syntax.<br>All this flux and begrudging really doesn't suggest to m=
e that Concepts are ready to go for C++20.<br></div></div></blockquote><div=
><br></div><div>FWIW, I agree with your conclusion.</div><div>The question =
is, do C++2a Concepts need wholesale kicking-out, as happened in C++11? or =
can they be rescued by judicious cuts?</div><div>The other question is, can=
anyone stop Concepts at this point or are the wise people getting out of t=
he way of the train? (Cynic says: observe the recent formation of EWGI and =
LEWGI for those people tired of engaging with C++2a issues and eager to mov=
e on to C++2b.)</div><div><br></div><div>=E2=80=93Arthur</div></div></block=
quote></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/17eb2726-8feb-4cdf-a58e-43d6dc81549a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/17eb2726-8feb-4cdf-a58e-43d6dc81549a=
%40isocpp.org</a>.<br />
------=_Part_1296_898936977.1540723472114--
------=_Part_1295_1328710690.1540723472113--
.
Author: gmisocpp@gmail.com
Date: Sun, 28 Oct 2018 23:08:19 -0700 (PDT)
Raw View
------=_Part_1504_358101168.1540793299380
Content-Type: multipart/alternative;
boundary="----=_Part_1505_118542956.1540793299381"
------=_Part_1505_118542956.1540793299381
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sunday, October 28, 2018 at 9:27:58 AM UTC+13, Arthur O'Dwyer wrote:
>
> On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, gmis...@gmail.com=20
> wrote:
>>
>> A few thoughts on Concepts:
>>
>> As Concepts have evolved, I have found it difficult to get a handle on=
=20
>> what Concepts actually are.
>> i.e.: Are Concepts functions, types, or something else?
>>
>
> Something else.
> =20
>
>> Bjarne's CppCon 2018 talk "Concepts: The Future of Generic Programming"=
=20
>> <https://www.youtube.com/watch?v=3DHddFGPTAmtU> answers that question=20
>> clearly.
>>
>> In his talk, Bjarne says:
>> * Concepts are NOT types of types. They are NOT type classes.
>>
>
> Well, they sort-of are. To a first approximation, they're predicates (typ=
e=20
> -> bool), which can be understood as partitions of the set of all types.
> For any type T, either T is-a Range or T is-not-a Range. So the set of=20
> Ranges is a subset of the set of all possible types.
> BUT! Look closer and there are at least three caveats.
> (1) Concepts have deep structure known as "normal form"; see below.
> (2) Concepts don't have to map (type -> bool); you can have=20
> multi-parameter concepts such as ConvertibleTo<T,U>, which are not as=20
> easily to gloss as predicates over single types. (But darned if the=20
> Concepts TS doesn't try! For any type T, either T is-a ConvertibleTo<U> o=
r=20
> T is-not-a ConvertibleTo<U>.)
> (3) Concepts don't have to accept types at all. For example, you can make=
=20
> a concept that maps (int -> bool).
>
> template<int V>
> concept EvenValue =3D ((V % 2) =3D=3D 0);
>
> I don't think this kind of concept is useful in real code (I'd prefer thi=
s=20
> kind of concept be kicked out of the Working Draft before C++2a is=20
> shipped). But you definitely can't by any mental gymnastics claim that=20
> concept `EvenValue` is a "type function" or a "type of types" or anything=
=20
> remotely like that.
>
>
> At around 1:06:30 in his talk Bjarne says:
>> * "it's just like defining functions, you *ARE* DEFINING FUNCTIONS".
>>
>
> I believe that was an ad-lib not to be taken 100% literally. To a first=
=20
> approximation, a concept like Mergeable is a function mapping an ordered=
=20
> tuple of types to a bool. But that doesn't mean that *all concepts ever*=
=20
> must be thought of as functions.
> That way lies functional programming and madness. ;)
>
See I think it can be taken pretty much 100% literally.
From what I can tell, a Concept is 100% a constexpr function. A=20
concept function verifies that a given list of types (passed to that=20
function) passed to it conform to a specification - as defined by the logic=
=20
of that function. The name of the function signifies what the concept is.
The function returns true if the types passed to the function meet the=20
requirements of logic of the function and false if they do not.
There may be more to how the compiler deals with such a function, but it=20
seems to me that this minimum I've described above is true.
Can we agree this far?
If a concrete type is passed to a function as a parameter whose type is=20
constrained by a Concept, the Concept function is called with the concrete=
=20
type and if it returns false, it yields a compilation error.
If a concrete type is returned from a function and assigned to a Concept=20
variable the same check is performed. I'm sure this is reasonably off base=
=20
but it seems like the gist of things. If this is correct or not though=20
isn't the core of anything to me though. It's just how I'm visualizing it=
=20
at the moment before I understand this more and subsumption and all of that=
..
Why does thinking of all concepts as functions madness? Because it seems to=
=20
me that's exactly what all concepts as currently discussed are. They ALL=20
seem to be constexpr functions that take a list of types and return bool to=
=20
indicate the types satisfy the concept or they don't. What more is there=20
and where is the madness?
=20
>
> [...]
>
>> The Concepts defined in Bjarne's talk look more like variable definition=
s=20
>> *defined* in what feels (to me) like an odd mix of logic and type like=
=20
>> syntax:
>>
>> template<typename X> using Value_type =3D X::value_type;
>> template<typename X> using Iterator_of =3D X::iterator;
>>
>> template<typename For, typename For2, typename Out>
>> concept Mergable =3D
>> ForwardIterator<For>
>> && ForwardIterator<For2>
>> && OutputIterator<Out>
>> && Assignable<Value_type<For>,Value_type<Out>>
>> && Assignable<Value_type<For2>,Value_type<Out>>
>> && Comparable<Value_type<For>,Value_type<For2>>;
>>
>> The above looks like a variable definition. If it is not, then is it=20
>> right that it looks like one?
>> It's a definition, with conditional logic et al. i.e it uses &&. etc.=20
>> like an inline function.
>> So why are we defining it NOT using function like snytax?
>> Why is this a good thing?
>>
>
> Because of the first caveat I listed above: Concepts are not *just*=20
> predicates. They are logical predicates with deep structure, described by=
=20
> their *normal form*. For example, there is no special relationship=20
> between the variable templates
>
> template<class T> inline constexpr bool is_scalar_v =3D=20
> std::is_scalar<T>::value;
> template<class T> inline constexpr bool is_integral_v =3D is_scalar_v=
<T>=20
> && std::is_integral<T>::value;
>
> but there is a very special relationship between the concept( template)s
>
> template<class T> concept is_scalar_c =3D std::is_scalar<T>::value;
> template<class T> concept is_integral_c =3D is_scalar_c<T> &&=20
> std::is_integral<T>::value;
>
> The special relationship is called *subsumption*, and we say that=20
> is_integral_c<X> *subsumes* is_scalar_c<X>.
> If it weren't for subsumption, there would be no fundamental difference=
=20
> between a concept and a variable template of type `bool`.
>
> The compiler determines the subsumption relationships between concepts by=
=20
> cracking open their definitions and peering inside. The definitions are=
=20
> cracked open *only* along the boundaries of the logical `&&` and `||`=20
> operators. So it is critically important that the definition of a concept=
=20
> be a single logical expression. If a concept were allowed to be expressed=
=20
> as a function body, the compiler wouldn't be able to crack it open, lift =
it=20
> into *normal form*, and figure out the *subsumption* relationships=20
> between this concept and all the other concepts in your program.
>
> Figuring out these relationships is important to the compiler because=20
> these relationships affect overload resolution.
>
> Please see my CppCon 2018 talk "Concepts as she is spoke"=20
> <https://www.youtube.com/watch?v=3DCXn02MPkn8Y> for a truly painful amoun=
t=20
> of information on how Concepts are different from plain old variable=20
> templates.
>
> [...]
>
>> 1. If concepts ARE functions, why aren't we defining and using them with=
=20
>> function like syntax? And using () not <>.
>>
>
> I hope my answers above have pointed the way on this one.
>
Not yet no, sorry. But the discussion is helpful to me all the same so=20
thank you.
I can see the topic of subsumption complicates the conversation though.=20
However the subsumption etc. is seems to be an additive aspect to the basic=
=20
fact that a concept IS a constexpr bool function, regardless of whatever=20
extra rules come into effect after that or around that.
=20
>
>> 2. It seems J. Monnon's proposal is making the same point as I am, only=
=20
>> much better? Can we please address all that he proposes?
>>
>
> I think P0844 "Type functions and beyond"=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html> is=
=20
> thought-provoking. It's very large, though, which I believe is why it's=
=20
> targeted at SG7 Compile-Time Programming (formerly SG7 Reflection).
> P0844 major section 3, "Concepts introducing types," seems to ignore the=
=20
> existence of non-type concepts in the Working Draft. Perhaps there should=
=20
> be a concerted effort to *kick non-type concepts out of the Working Draft=
*=20
> in order to gain some freedom of motion for these recurring theories of=
=20
> "concepts =3D=3D types of types."
> I do not believe that P0844 is making the same points (or, asking for=20
> clarification on the same points) as you are. I have only skimmed P0844,=
=20
> but it does not seem to be engaging with Concepts-as-they-are at all; it=
=20
> seems to be trying to reuse Concepty words to refer to elements of the=20
> author's more na=C3=AFve "types of types" theory.
> (More na=C3=AFve is not necessarily bad! I think C++2a Concepts is *far*=
too=20
> much of an experts-only feature, and we could use a lot more naivet=C3=A9=
in=20
> this area.)
>
> 3. I feel a more formal response to J. Monnon's paper from the main=20
>> proponents of Concepts as currently defined should be made before concep=
ts=20
>> get wired in any further in it's current direction?
>>
>> I know many people would like Concepts be the marquee feature of C++20,=
=20
>> but to me Concepts still seem quite away from where I'd like them to be.
>> Even Bjarne can only 'begrudgingly live' with the current syntax.
>> All this flux and begrudging really doesn't suggest to me that Concepts=
=20
>> are ready to go for C++20.
>>
>
> FWIW, I agree with your conclusion.
> The question is, do C++2a Concepts need wholesale kicking-out, as happene=
d=20
> in C++11? or can they be rescued by judicious cuts?
> The other question is, can anyone stop Concepts at this point or are the=
=20
> wise people getting out of the way of the train? (Cynic says: observe the=
=20
> recent formation of EWGI and LEWGI for those people tired of engaging wit=
h=20
> C++2a issues and eager to move on to C++2b.)
>
> =E2=80=93Arthur
>
I think P0844 "Type functions and beyond"=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html> seem=
s=20
to reach far and very consistently given that reach and it keeps the=20
programming function based. My thoughts on Concepts is that it's syntax is=
=20
unappealing with the angle bracket fest and the auto Concept x; versus=20
Concept x storm.
I think Concept definitions need to retain a similar functional feel and=20
that means exposing Concepts to look more like the functions and enabling=
=20
them to be defined more like that. Or at least it's not clear to me why we=
=20
can't and shouldn't go further down that road.
In other words, why this from=20
https://en.cppreference.com/w/cpp/language/constraints):
template <class T>
concept Semiregular =3D DefaultConstructible<T> &&
CopyConstructible<T> && Destructible<T> && CopyAssignable<T> &&
requires(T a, size_t n) { =20
requires Same<T*, decltype(&a)>; // nested: "Same<...> evaluates to=20
true"
{ a.~T() } noexcept; // compound: "a.~T()" is a valid expression that=
=20
doesn't throw
requires Same<T*, decltype(new T)>; // nested: "Same<...> evaluates to=
=20
true"
requires Same<T*, decltype(new T[n])>; // nested
{ delete new T }; // compound
{ delete new T[n] }; // compound
};
instead of something like this:
concept Semiregular(T)
{
require DefaultConstructible(T) && CopyConstructible(T) &&=20
Destructible(T) && CopyAssignable(T);
with (T a, size_t n) {=20
...
};
}
To me, Concepts as defined obfuscates a function as a variable=20
definition. But if it is a function it remains unclear to me why it should=
=20
not look a function and be able to be called like one and in that I=20
think that would connect more with the style that P040844 reaches for.
As it stands I feel with Concepts, Reflection and Metaclasses all coming=20
along, putting in Concepts so far ahead of these other features might mean=
=20
that Concepts will not fit together well them. My comments are aimed at=20
revealing that fact (or not) and if Concepts should wait to avoid that but=
=20
also at understanding Concepts.=20
Bjarne talks about remember the Vasa, but I'm worried that ironically=20
Concepts might be that extra level of guns on deck that we are not ready=20
for just yet.
Hopefully I am wrong about much of this. I don't want those working on=20
Concepts don't feel I'm knocking their work. I am appreciative of their=20
efforts. Hopefully this discussion helps even if it just helps me=20
understand Concepts better and get on-board with them.
Thanks
--=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/04c3ef3d-4950-47bf-9e32-6d48247a095e%40isocpp.or=
g.
------=_Part_1505_118542956.1540793299381
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, October 28, 2018 at 9:27:58 AM UTC+13, =
Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On W=
ednesday, October 24, 2018 at 9:09:52 PM UTC-4, <a>gmis...@gmail.com</a> wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
1px; border-left-style: solid;"><div dir=3D"ltr"><div>A few thoughts on Co=
ncepts:</div><div><br></div><div>As Concepts have evolved, I have found it =
difficult to get a handle on what Concepts actually are.<br>i.e.: Are Conce=
pts functions, types, or something else?</div></div></blockquote><div><br><=
/div><div>Something else.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-c=
olor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;=
"><div dir=3D"ltr"><div><a onmousedown=3D"this.href=3D'https://www.yout=
ube.com/watch?v\x3dHddFGPTAmtU';return true;" onclick=3D"this.href=3D&#=
39;https://www.youtube.com/watch?v\x3dHddFGPTAmtU';return true;" href=
=3D"https://www.youtube.com/watch?v=3DHddFGPTAmtU" target=3D"_blank" rel=3D=
"nofollow">Bjarne's CppCon 2018 talk "Concepts: The Future of Gene=
ric Programming"</a> answers that question clearly.<br></div><p>In his=
talk, Bjarne says:<br>* Concepts are NOT types of types. They are NOT type=
classes.<br></p></div></blockquote><div><br></div><div>Well, they sort-of =
are. To a first approximation, they're predicates (type -> bool), wh=
ich can be understood as partitions of the set of all types.</div><div>For =
any type T, either T is-a Range or T is-not-a Range. So the set of Ranges i=
s a subset of the set of all possible types.</div><div>BUT! Look closer and=
there are at least three caveats.</div><div>(1) Concepts have deep structu=
re known as "normal form"; see below.</div><div>(2) Concepts don&=
#39;t have to map (type -> bool); you can have multi-parameter concepts =
such as ConvertibleTo<T,U>, which are not as easily to gloss as predi=
cates over single types. (But darned if the Concepts TS doesn't try! Fo=
r any type T, either T is-a ConvertibleTo<U> or T is-not-a Convertibl=
eTo<U>.)</div><div>(3) Concepts don't have to accept types at all=
.. For example, you can make a concept that maps (int -> bool).</div><div=
><br></div><div>=C2=A0 =C2=A0 template<int V></div><div>=C2=A0 =C2=A0=
concept EvenValue =3D ((V % 2) =3D=3D 0);</div><div><br></div><div>I don&#=
39;t think this kind of concept is useful in real code (I'd prefer this=
kind of concept be kicked out of the Working Draft before C++2a is shipped=
). But you definitely can't by any mental gymnastics claim that concept=
`EvenValue`=C2=A0is a "type function" or a "type of types&q=
uot; or anything remotely like that.</div><div><br></div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-=
left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; b=
order-left-style: solid;"><div dir=3D"ltr"><p>At around 1:06:30 in his talk=
Bjarne says:<br>* "it's just like defining functions, you *ARE* D=
EFINING FUNCTIONS".</p></div></blockquote><div><br></div><div>I believ=
e that was an ad-lib not to be taken 100% literally. To a first approximati=
on, a concept like Mergeable is a function mapping an ordered tuple of type=
s to a bool. But that doesn't mean that <i>all concepts ever</i> must b=
e thought of as functions.</div><div>That way lies functional programming a=
nd madness. ;)</div></div></blockquote><div><br></div><div>See I think it c=
an be taken pretty much 100% literally.</div><div><br></div><div>From what =
I can tell,=C2=A0a Concept=C2=A0is=C2=A0100% a constexpr function.=C2=A0A c=
oncept=C2=A0function=C2=A0verifies that a given=C2=A0list of types (passed =
to that function) passed to it conform to a specification - as defined by t=
he logic of that function. The name of the function signifies what the conc=
ept is.<br>The function returns true if the types passed to the function me=
et the requirements of logic of the function and false if they do not.</div=
><div><br></div><div>There=C2=A0may be=C2=A0more to=C2=A0how the=C2=A0compi=
ler deals with such a function, but it seems to me that this minimum I'=
ve described above is true.</div><div>Can we agree this far?</div><div><br>=
</div><div>If=C2=A0a concrete type is passed to a function as a parameter w=
hose type is constrained by a Concept, the Concept function is called with =
the concrete type and if it returns false, it yields a compilation error.<b=
r>If a concrete type is returned from a function and assigned to a Concept =
variable the same check is performed. I'm sure this is=C2=A0reasonably =
off base but it seems like the gist of things. If this is correct or not th=
ough isn't the core of anything to me though. It's just how I'm=
visualizing it at the moment before I understand this more=C2=A0and subsum=
ption and all of that.</div><div><br></div><div>Why does thinking of all co=
ncepts as functions madness? Because it seems to me that's exactly what=
all concepts as currently discussed are. They ALL seem to be constexpr fun=
ctions that take a list of types and return bool to indicate the types sati=
sfy the concept or they don't. What more is there and where is the madn=
ess?</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: =
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div=
dir=3D"ltr"><div><br></div><div>[...]</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color=
: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><d=
iv dir=3D"ltr"><div>The Concepts defined in Bjarne's talk look more lik=
e variable definitions *defined* in what feels (to me) like an odd mix of l=
ogic and type like syntax:<br></div><p>template<typename X> using Val=
ue_type =3D X::value_type;<br>template<typename X> using Iterator_of =
=3D X::iterator;</p><p>template<typename For, typename For2, typename Ou=
t><br>concept Mergable =3D<br>=C2=A0=C2=A0=C2=A0 ForwardIterator<For&=
gt;<br>=C2=A0=C2=A0=C2=A0 && ForwardIterator<For2><br>=C2=A0=
=C2=A0=C2=A0 && OutputIterator<Out><br>=C2=A0=C2=A0=C2=A0 &am=
p;& Assignable<Value_type<For>,<wbr>Value_type<Out>><=
br>=C2=A0=C2=A0=C2=A0 && Assignable<Value_type<For2>,<wbr>=
Value_type<Out>><br>=C2=A0=C2=A0=C2=A0 && Comparable<Va=
lue_type<For>,<wbr>Value_type<For2>>;</p><div><br></div><div=
>The above looks like a variable definition. If it is not, then is it right=
that it looks like one?<br>It's a definition, with conditional logic e=
t al. i.e it uses &&. etc. like an inline function.<br></div><div>S=
o why are we defining it NOT using function like snytax?<br>Why is this a g=
ood thing?</div></div></blockquote><div><br></div><div>Because of the first=
caveat I listed above: Concepts are not <i>just</i> predicates. They are l=
ogical predicates with deep structure, described by their <i>normal form</i=
>. For example, there is no special relationship between the variable templ=
ates</div><div><br></div><div>=C2=A0 =C2=A0 template<class T> inline =
constexpr bool is_scalar_v =3D std::is_scalar<T>::value;</div><div>=
=C2=A0 =C2=A0 template<class T> inline constexpr bool is_integral_v =
=3D is_scalar_v<T> && std::is_integral<T>::value;</div>=
<div><br></div><div>but there is a very special relationship between the co=
ncept( template)s</div><div><br></div><div><div>=C2=A0 =C2=A0 template<c=
lass T> concept is_scalar_c =3D std::is_scalar<T>::value;</div><di=
v>=C2=A0 =C2=A0 template<class T> concept is_integral_c =3D is_scalar=
_c<T> && std::is_integral<T>::value;</div></div><div><b=
r></div><div>The special relationship is called <i>subsumption</i>, and we =
say that is_integral_c<X> <i>subsumes</i> is_scalar_c<X>.</div>=
<div>If it weren't for subsumption, there would be no fundamental diffe=
rence between a concept and a variable template of type `bool`.</div><div><=
br></div><div>The compiler determines the subsumption relationships between=
concepts by cracking open their definitions and peering inside. The defini=
tions are cracked open <i>only</i> along the boundaries of the logical `&am=
p;&` and `||` operators. So it is critically important that the definit=
ion of a concept be a single logical expression. If a concept were allowed =
to be expressed as a function body, the compiler wouldn't be able to cr=
ack it open, lift it into <i>normal form</i>, and figure out the <i>subsump=
tion</i> relationships between this concept and all the other concepts in y=
our program.</div><div><br></div><div>Figuring out these relationships is i=
mportant to the compiler because these relationships affect overload resolu=
tion.</div><div><br></div><div>Please see my CppCon 2018 talk <a onmousedow=
n=3D"this.href=3D'https://www.youtube.com/watch?v\x3dCXn02MPkn8Y';r=
eturn true;" onclick=3D"this.href=3D'https://www.youtube.com/watch?v\x3=
dCXn02MPkn8Y';return true;" href=3D"https://www.youtube.com/watch?v=3DC=
Xn02MPkn8Y" target=3D"_blank" rel=3D"nofollow">"Concepts as she is spo=
ke"</a> for a truly painful amount of information on how Concepts are =
different from plain old variable templates.</div><div><br></div><div>[...]=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>1. If concepts ARE=
functions, why aren't we defining and using them with function like sy=
ntax? And using () not <>.<br></div></div></blockquote><div><br></div=
><div>I hope my answers above have pointed the way on this one.</div></div>=
</blockquote><div><br></div><div>Not yet no,=C2=A0sorry.=C2=A0But the discu=
ssion is helpful to me all the same so thank you.</div><div>I can see the t=
opic of subsumption complicates the conversation though. However the subsum=
ption etc.=C2=A0is=C2=A0seems to be an additive aspect to the basic fact th=
at a concept IS a constexpr bool=C2=A0function, regardless of whatever extr=
a rules come into effect after that or around that.</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-=
left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; b=
order-left-style: solid;"><div dir=3D"ltr"><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; b=
order-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-s=
tyle: solid;"><div dir=3D"ltr"><div>2. It seems J. Monnon's proposal is=
making the same point as I am, only much better? Can we please address all=
that he proposes?<br></div></div></blockquote><div><br></div><div>I think =
<a onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2=
F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0844r0.=
html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFr_9YGZO5BDdyaSw7BW7ttm0_LQ&#=
39;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018=
%2Fp0844r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFr_9YGZO5BDdyaSw7B=
W7ttm0_LQ';return true;" href=3D"http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2018/p0844r0.html" target=3D"_blank" rel=3D"nofollow">P0844 &q=
uot;Type functions and beyond"</a> is thought-provoking. It's very=
large, though, which I believe is why it's targeted at SG7 Compile-Tim=
e Programming (formerly SG7 Reflection).</div><div>P0844 major section 3, &=
quot;Concepts introducing types," seems to ignore the existence of non=
-type concepts in the Working Draft. Perhaps there should be a concerted ef=
fort to <i>kick non-type concepts out of the Working Draft</i> in order to =
gain some freedom of motion for these recurring theories of "concepts =
=3D=3D types of types."</div><div>I do not believe that P0844 is makin=
g the same points (or, asking for clarification on the same points) as you =
are. I have only skimmed P0844, but it does not seem to be engaging with Co=
ncepts-as-they-are at all; it seems to be trying to reuse Concepty words to=
refer to elements of the author's more na=C3=AFve "types of types=
" theory.</div><div>(More na=C3=AFve is not necessarily bad! =C2=A0I t=
hink C++2a Concepts is <i>far</i> too much of an experts-only feature, and =
we could use a lot more naivet=C3=A9 in this area.)</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-=
left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; b=
order-left-style: solid;"><div dir=3D"ltr"><div>3. I feel a more formal res=
ponse to J. Monnon's paper from the main proponents of Concepts as curr=
ently defined should be made before concepts get wired in any further in it=
's current direction?</div><div><br></div><div>I know many people would=
like Concepts be the marquee feature of C++20, but to me Concepts=C2=A0sti=
ll seem quite away from where I'd like them to be.<br>Even Bjarne can o=
nly 'begrudgingly live' with the current syntax.<br>All this flux a=
nd begrudging really doesn't suggest to me that Concepts are ready to g=
o for C++20.<br></div></div></blockquote><div><br></div><div>FWIW, I agree =
with your conclusion.</div><div>The question is, do C++2a Concepts need who=
lesale kicking-out, as happened in C++11? or can they be rescued by judicio=
us cuts?</div><div>The other question is, can anyone stop Concepts at this =
point or are the wise people getting out of the way of the train? (Cynic sa=
ys: observe the recent formation of EWGI and LEWGI for those people tired o=
f engaging with C++2a issues and eager to move on to C++2b.)</div><div><br>=
</div><div>=E2=80=93Arthur</div></div></blockquote><div><br></div><div>I th=
ink <a onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%=
3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp084=
4r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFr_9YGZO5BDdyaSw7BW7ttm0_=
LQ';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F=
2018%2Fp0844r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFr_9YGZO5BDdya=
Sw7BW7ttm0_LQ';return true;" href=3D"http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2018/p0844r0.html" target=3D"_blank" rel=3D"nofollow">P084=
4 "Type functions and beyond"</a>=C2=A0seems to reach far and ver=
y consistently given that reach and it keeps the programming function based=
.. My thoughts on Concepts is that it's syntax is unappealing=C2=A0with =
the angle bracket fest=C2=A0and the=C2=A0auto Concept x; versus Concept x=
=C2=A0storm.</div><div><br></div><div>I think Concept definitions=C2=A0need=
to retain=C2=A0a similar=C2=A0functional feel and that means exposing Conc=
epts to look more like the functions and enabling them to be defined more l=
ike that. Or at least it's not clear to me why we can't and shouldn=
't=C2=A0go further down that road.</div><div><br></div><div>In other wo=
rds, why this from <a href=3D"https://en.cppreference.com/w/cpp/language/co=
nstraints">https://en.cppreference.com/w/cpp/language/constraints</a>):</di=
v><div>template <class T><br>concept Semiregular =3D DefaultConstruct=
ible<T> &&<br>=C2=A0=C2=A0=C2=A0 CopyConstructible<T> &=
amp;& Destructible<T> && CopyAssignable<T> &&am=
p;<br>requires(T a, size_t n) {=C2=A0 <br>=C2=A0=C2=A0=C2=A0 requires Same&=
lt;T*, decltype(&a)>;=C2=A0 // nested: "Same<...> evaluat=
es to true"<br>=C2=A0=C2=A0=C2=A0 { a.~T() } noexcept;=C2=A0 // compou=
nd: "a.~T()" is a valid expression that doesn't throw<br>=C2=
=A0=C2=A0=C2=A0 requires Same<T*, decltype(new T)>; // nested: "=
Same<...> evaluates to true"<br>=C2=A0=C2=A0=C2=A0 requires Same=
<T*, decltype(new T[n])>; // nested<br>=C2=A0=C2=A0=C2=A0 { delete ne=
w T };=C2=A0 // compound<br>=C2=A0=C2=A0=C2=A0 { delete new T[n] }; // comp=
ound<br>};</div><div>instead of something like this:</div><div>concept Semi=
regular(T)<br>{<br>=C2=A0=C2=A0=C2=A0 require DefaultConstructible(T) &=
& CopyConstructible(T) && Destructible(T) && CopyAssign=
able(T);<br>=C2=A0=C2=A0=C2=A0 with (T a, size_t n) {=C2=A0</div><div>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...<br></div><div>=C2=A0=C2=A0=C2=A0 };<b=
r>}</div><div><br></div><div>To me, Concepts as defined obfuscates a=C2=A0f=
unction as a variable definition.=C2=A0But if=C2=A0it is=C2=A0a function it=
remains unclear to me why it should not look=C2=A0a function=C2=A0and be a=
ble to be called like one and in that I think=C2=A0that would connect more =
with the style that P040844 reaches for.</div><div><br></div><div>As it sta=
nds=C2=A0I feel=C2=A0with Concepts, Reflection and Metaclasses all coming a=
long, putting in Concepts=C2=A0so far ahead of these other features=C2=A0mi=
ght mean that Concepts=C2=A0will not fit together well them.=C2=A0My commen=
ts are aimed at revealing that fact (or not) and if=C2=A0Concepts should wa=
it to avoid that but also at understanding Concepts.=C2=A0</div><div><br></=
div><div>Bjarne talks about remember the Vasa,=C2=A0but I'm worried tha=
t ironically Concepts might be that extra level of guns on deck that we are=
not ready for just yet.<br></div><div><br></div><div>Hopefully I am wrong =
about much of this. I don't want those working on Concepts don't fe=
el I'm knocking their work. I am appreciative of their efforts.=C2=A0Ho=
pefully this discussion=C2=A0helps even if it just=C2=A0helps me understand=
Concepts better and get on-board with them.</div><div><br></div><div>Thank=
s</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/04c3ef3d-4950-47bf-9e32-6d48247a095e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/04c3ef3d-4950-47bf-9e32-6d48247a095e=
%40isocpp.org</a>.<br />
------=_Part_1505_118542956.1540793299381--
------=_Part_1504_358101168.1540793299380--
.
Author: mihailnajdenov@gmail.com
Date: Mon, 29 Oct 2018 02:21:25 -0700 (PDT)
Raw View
------=_Part_479_1193262745.1540804885465
Content-Type: multipart/alternative;
boundary="----=_Part_480_947842359.1540804885466"
------=_Part_480_947842359.1540804885466
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Things are simple - yes they are functions, they don't use curly braces=20
because types are passed using the angle brackets
There is little need to change this and it consistent with old behavior.=20
The only divination is removing tokens that are 100% redundant - the bool=
=20
return type and the empty parenthesizes that call the function.
As for "but this is not a function but a variable", well, *so are lambdas*
.. =20
=20
The problem with "Type functions and beyond" is they introduces a new=20
language. Talking about the Vasa this *vastly *more heavyweight then "few=
=20
more guns"=20
And even if we have this new language, the syntax will not be less verbose=
=20
as far as concepts are concerned, because the verbosity comes from the=20
expressions that must be valid - one way or another you must type that out.=
=20
As said, what Type functions introduce is type transformation, this however=
=20
will be handled by reflection and *it will also be function based*
The difference is - it will not introduce a new language - it will have=20
converting expression that turn *types into objects *and use normal=20
constexpr functions to transform these objects, then another expression to=
=20
convert the object into a type.=20
Again no new language!=20
Will this affect Concepts as well - might be, but only the definition, not=
=20
the usage as we want types passed to the concepts, without the need to=20
convert that type to an object. =20
In other words Concept<T> will remain correct and preferred even after=20
functions based reflection and their possible use in Concepts
On Monday, October 29, 2018 at 8:08:19 AM UTC+2, gmis...@gmail.com wrote:
>
>
>
> On Sunday, October 28, 2018 at 9:27:58 AM UTC+13, Arthur O'Dwyer wrote:
>>
>> On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, gmis...@gmail.com=20
>> wrote:
>>>
>>> A few thoughts on Concepts:
>>>
>>> As Concepts have evolved, I have found it difficult to get a handle on=
=20
>>> what Concepts actually are.
>>> i.e.: Are Concepts functions, types, or something else?
>>>
>>
>> Something else.
>> =20
>>
>>> Bjarne's CppCon 2018 talk "Concepts: The Future of Generic Programming"=
=20
>>> <https://www.youtube.com/watch?v=3DHddFGPTAmtU> answers that question=
=20
>>> clearly.
>>>
>>> In his talk, Bjarne says:
>>> * Concepts are NOT types of types. They are NOT type classes.
>>>
>>
>> Well, they sort-of are. To a first approximation, they're predicates=20
>> (type -> bool), which can be understood as partitions of the set of all=
=20
>> types.
>> For any type T, either T is-a Range or T is-not-a Range. So the set of=
=20
>> Ranges is a subset of the set of all possible types.
>> BUT! Look closer and there are at least three caveats.
>> (1) Concepts have deep structure known as "normal form"; see below.
>> (2) Concepts don't have to map (type -> bool); you can have=20
>> multi-parameter concepts such as ConvertibleTo<T,U>, which are not as=20
>> easily to gloss as predicates over single types. (But darned if the=20
>> Concepts TS doesn't try! For any type T, either T is-a ConvertibleTo<U> =
or=20
>> T is-not-a ConvertibleTo<U>.)
>> (3) Concepts don't have to accept types at all. For example, you can mak=
e=20
>> a concept that maps (int -> bool).
>>
>> template<int V>
>> concept EvenValue =3D ((V % 2) =3D=3D 0);
>>
>> I don't think this kind of concept is useful in real code (I'd prefer=20
>> this kind of concept be kicked out of the Working Draft before C++2a is=
=20
>> shipped). But you definitely can't by any mental gymnastics claim that=
=20
>> concept `EvenValue` is a "type function" or a "type of types" or anythin=
g=20
>> remotely like that.
>>
>>
>> At around 1:06:30 in his talk Bjarne says:
>>> * "it's just like defining functions, you *ARE* DEFINING FUNCTIONS".
>>>
>>
>> I believe that was an ad-lib not to be taken 100% literally. To a first=
=20
>> approximation, a concept like Mergeable is a function mapping an ordered=
=20
>> tuple of types to a bool. But that doesn't mean that *all concepts ever*=
=20
>> must be thought of as functions.
>> That way lies functional programming and madness. ;)
>>
>
> See I think it can be taken pretty much 100% literally.
>
> From what I can tell, a Concept is 100% a constexpr function. A=20
> concept function verifies that a given list of types (passed to that=20
> function) passed to it conform to a specification - as defined by the log=
ic=20
> of that function. The name of the function signifies what the concept is.
> The function returns true if the types passed to the function meet the=20
> requirements of logic of the function and false if they do not.
>
> There may be more to how the compiler deals with such a function, but it=
=20
> seems to me that this minimum I've described above is true.
> Can we agree this far?
>
> If a concrete type is passed to a function as a parameter whose type is=
=20
> constrained by a Concept, the Concept function is called with the concret=
e=20
> type and if it returns false, it yields a compilation error.
> If a concrete type is returned from a function and assigned to a Concept=
=20
> variable the same check is performed. I'm sure this is reasonably off bas=
e=20
> but it seems like the gist of things. If this is correct or not though=20
> isn't the core of anything to me though. It's just how I'm visualizing it=
=20
> at the moment before I understand this more and subsumption and all of th=
at.
>
> Why does thinking of all concepts as functions madness? Because it seems=
=20
> to me that's exactly what all concepts as currently discussed are. They A=
LL=20
> seem to be constexpr functions that take a list of types and return bool =
to=20
> indicate the types satisfy the concept or they don't. What more is there=
=20
> and where is the madness?
>
> =20
>
>>
>> [...]
>>
>>> The Concepts defined in Bjarne's talk look more like variable=20
>>> definitions *defined* in what feels (to me) like an odd mix of logic an=
d=20
>>> type like syntax:
>>>
>>> template<typename X> using Value_type =3D X::value_type;
>>> template<typename X> using Iterator_of =3D X::iterator;
>>>
>>> template<typename For, typename For2, typename Out>
>>> concept Mergable =3D
>>> ForwardIterator<For>
>>> && ForwardIterator<For2>
>>> && OutputIterator<Out>
>>> && Assignable<Value_type<For>,Value_type<Out>>
>>> && Assignable<Value_type<For2>,Value_type<Out>>
>>> && Comparable<Value_type<For>,Value_type<For2>>;
>>>
>>> The above looks like a variable definition. If it is not, then is it=20
>>> right that it looks like one?
>>> It's a definition, with conditional logic et al. i.e it uses &&. etc.=
=20
>>> like an inline function.
>>> So why are we defining it NOT using function like snytax?
>>> Why is this a good thing?
>>>
>>
>> Because of the first caveat I listed above: Concepts are not *just*=20
>> predicates. They are logical predicates with deep structure, described b=
y=20
>> their *normal form*. For example, there is no special relationship=20
>> between the variable templates
>>
>> template<class T> inline constexpr bool is_scalar_v =3D=20
>> std::is_scalar<T>::value;
>> template<class T> inline constexpr bool is_integral_v =3D=20
>> is_scalar_v<T> && std::is_integral<T>::value;
>>
>> but there is a very special relationship between the concept( template)s
>>
>> template<class T> concept is_scalar_c =3D std::is_scalar<T>::value;
>> template<class T> concept is_integral_c =3D is_scalar_c<T> &&=20
>> std::is_integral<T>::value;
>>
>> The special relationship is called *subsumption*, and we say that=20
>> is_integral_c<X> *subsumes* is_scalar_c<X>.
>> If it weren't for subsumption, there would be no fundamental difference=
=20
>> between a concept and a variable template of type `bool`.
>>
>> The compiler determines the subsumption relationships between concepts b=
y=20
>> cracking open their definitions and peering inside. The definitions are=
=20
>> cracked open *only* along the boundaries of the logical `&&` and `||`=20
>> operators. So it is critically important that the definition of a concep=
t=20
>> be a single logical expression. If a concept were allowed to be expresse=
d=20
>> as a function body, the compiler wouldn't be able to crack it open, lift=
it=20
>> into *normal form*, and figure out the *subsumption* relationships=20
>> between this concept and all the other concepts in your program.
>>
>> Figuring out these relationships is important to the compiler because=20
>> these relationships affect overload resolution.
>>
>> Please see my CppCon 2018 talk "Concepts as she is spoke"=20
>> <https://www.youtube.com/watch?v=3DCXn02MPkn8Y> for a truly painful amou=
nt=20
>> of information on how Concepts are different from plain old variable=20
>> templates.
>>
>> [...]
>>
>>> 1. If concepts ARE functions, why aren't we defining and using them wit=
h=20
>>> function like syntax? And using () not <>.
>>>
>>
>> I hope my answers above have pointed the way on this one.
>>
>
> Not yet no, sorry. But the discussion is helpful to me all the same so=20
> thank you.
> I can see the topic of subsumption complicates the conversation though.=
=20
> However the subsumption etc. is seems to be an additive aspect to the bas=
ic=20
> fact that a concept IS a constexpr bool function, regardless of whatever=
=20
> extra rules come into effect after that or around that.
>
> =20
>>
>>> 2. It seems J. Monnon's proposal is making the same point as I am, only=
=20
>>> much better? Can we please address all that he proposes?
>>>
>>
>> I think P0844 "Type functions and beyond"=20
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html>=
=20
>> is thought-provoking. It's very large, though, which I believe is why it=
's=20
>> targeted at SG7 Compile-Time Programming (formerly SG7 Reflection).
>> P0844 major section 3, "Concepts introducing types," seems to ignore the=
=20
>> existence of non-type concepts in the Working Draft. Perhaps there shoul=
d=20
>> be a concerted effort to *kick non-type concepts out of the Working=20
>> Draft* in order to gain some freedom of motion for these recurring=20
>> theories of "concepts =3D=3D types of types."
>> I do not believe that P0844 is making the same points (or, asking for=20
>> clarification on the same points) as you are. I have only skimmed P0844,=
=20
>> but it does not seem to be engaging with Concepts-as-they-are at all; it=
=20
>> seems to be trying to reuse Concepty words to refer to elements of the=
=20
>> author's more na=C3=AFve "types of types" theory.
>> (More na=C3=AFve is not necessarily bad! I think C++2a Concepts is *far=
* too=20
>> much of an experts-only feature, and we could use a lot more naivet=C3=
=A9 in=20
>> this area.)
>>
>> 3. I feel a more formal response to J. Monnon's paper from the main=20
>>> proponents of Concepts as currently defined should be made before conce=
pts=20
>>> get wired in any further in it's current direction?
>>>
>>> I know many people would like Concepts be the marquee feature of C++20,=
=20
>>> but to me Concepts still seem quite away from where I'd like them to be=
..
>>> Even Bjarne can only 'begrudgingly live' with the current syntax.
>>> All this flux and begrudging really doesn't suggest to me that Concepts=
=20
>>> are ready to go for C++20.
>>>
>>
>> FWIW, I agree with your conclusion.
>> The question is, do C++2a Concepts need wholesale kicking-out, as=20
>> happened in C++11? or can they be rescued by judicious cuts?
>> The other question is, can anyone stop Concepts at this point or are the=
=20
>> wise people getting out of the way of the train? (Cynic says: observe th=
e=20
>> recent formation of EWGI and LEWGI for those people tired of engaging wi=
th=20
>> C++2a issues and eager to move on to C++2b.)
>>
>> =E2=80=93Arthur
>>
>
> I think P0844 "Type functions and beyond"=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html> se=
ems=20
> to reach far and very consistently given that reach and it keeps the=20
> programming function based. My thoughts on Concepts is that it's syntax i=
s=20
> unappealing with the angle bracket fest and the auto Concept x; versus=20
> Concept x storm.
>
> I think Concept definitions need to retain a similar functional feel and=
=20
> that means exposing Concepts to look more like the functions and enabling=
=20
> them to be defined more like that. Or at least it's not clear to me why w=
e=20
> can't and shouldn't go further down that road.
>
> In other words, why this from=20
> https://en.cppreference.com/w/cpp/language/constraints):
> template <class T>
> concept Semiregular =3D DefaultConstructible<T> &&
> CopyConstructible<T> && Destructible<T> && CopyAssignable<T> &&
> requires(T a, size_t n) { =20
> requires Same<T*, decltype(&a)>; // nested: "Same<...> evaluates to=
=20
> true"
> { a.~T() } noexcept; // compound: "a.~T()" is a valid expression tha=
t=20
> doesn't throw
> requires Same<T*, decltype(new T)>; // nested: "Same<...> evaluates t=
o=20
> true"
> requires Same<T*, decltype(new T[n])>; // nested
> { delete new T }; // compound
> { delete new T[n] }; // compound
> };
> instead of something like this:
> concept Semiregular(T)
> {
> require DefaultConstructible(T) && CopyConstructible(T) &&=20
> Destructible(T) && CopyAssignable(T);
> with (T a, size_t n) {=20
> ...
> };
> }
>
> To me, Concepts as defined obfuscates a function as a variable=20
> definition. But if it is a function it remains unclear to me why it shoul=
d=20
> not look a function and be able to be called like one and in that I=20
> think that would connect more with the style that P040844 reaches for.
>
> As it stands I feel with Concepts, Reflection and Metaclasses all coming=
=20
> along, putting in Concepts so far ahead of these other features might mea=
n=20
> that Concepts will not fit together well them. My comments are aimed at=
=20
> revealing that fact (or not) and if Concepts should wait to avoid that bu=
t=20
> also at understanding Concepts.=20
>
> Bjarne talks about remember the Vasa, but I'm worried that ironically=20
> Concepts might be that extra level of guns on deck that we are not ready=
=20
> for just yet.
>
> Hopefully I am wrong about much of this. I don't want those working on=20
> Concepts don't feel I'm knocking their work. I am appreciative of their=
=20
> efforts. Hopefully this discussion helps even if it just helps me=20
> understand Concepts better and get on-board with them.
>
> Thanks
>
--=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/0b563669-ad01-4386-b08c-ae9c964b2247%40isocpp.or=
g.
------=_Part_480_947842359.1540804885466
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Things are simple - yes they are functions, they don't=
use curly braces because<i> </i>types are passed using the angle brackets<=
div><br></div><div>There is little need to change this and it consistent wi=
th old behavior. The only divination is removing tokens that are 100% redun=
dant -=C2=A0 the bool return type and the empty parenthesizes that call the=
function.</div><div><br></div><div>As for "but this is not a function=
but a variable", well, <i>so are lambdas</i>.=C2=A0=C2=A0</div><div>=
=C2=A0</div><div><br><br>The problem with=C2=A0=C2=A0"Type functions a=
nd beyond" is they introduces a new language. Talking about the Vasa t=
his <i>vastly </i>more heavyweight then "few more guns"=C2=A0</di=
v><div><br></div><div>And even if we have this new language, the syntax wil=
l not be less verbose as far as concepts are concerned, because the verbosi=
ty comes from the expressions that must be valid - one way or another you m=
ust type that out.=C2=A0</div><div><br></div><div>As said, what Type functi=
ons introduce is type transformation, this however will be handled by refle=
ction and <i>it=C2=A0will also be function based</i></div><div>The differen=
ce is - it will not introduce a new language - it will have converting expr=
ession that turn <i>types into objects </i>and use normal constexpr functio=
ns to transform these objects, then another expression to convert the objec=
t into a type.=C2=A0</div><div>Again no new language!=C2=A0</div><div><br><=
/div><div>Will this affect Concepts as well - might be, but only the defini=
tion, not the usage as we want types passed to the concepts, without the ne=
ed to convert that type to an object.=C2=A0 =C2=A0</div><div>In other words=
Concept<T> will remain correct and preferred even after functions ba=
sed reflection and their possible use in Concepts</div><div><br><br><br>On =
Monday, October 29, 2018 at 8:08:19 AM UTC+2, gmis...@gmail.com wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>On Sunday,=
October 28, 2018 at 9:27:58 AM UTC+13, Arthur O'Dwyer wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;=
border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:=
solid"><div dir=3D"ltr">On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4,=
<a>gmis...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>A fe=
w thoughts on Concepts:</div><div><br></div><div>As Concepts have evolved, =
I have found it difficult to get a handle on what Concepts actually are.<br=
>i.e.: Are Concepts functions, types, or something else?</div></div></block=
quote><div><br></div><div>Something else.</div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;b=
order-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:s=
olid"><div dir=3D"ltr"><div><a href=3D"https://www.youtube.com/watch?v=3DHd=
dFGPTAmtU" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#=
39;https://www.youtube.com/watch?v\x3dHddFGPTAmtU';return true;" onclic=
k=3D"this.href=3D'https://www.youtube.com/watch?v\x3dHddFGPTAmtU';r=
eturn true;">Bjarne's CppCon 2018 talk "Concepts: The Future of Ge=
neric Programming"</a> answers that question clearly.<br></div><p>In h=
is talk, Bjarne says:<br>* Concepts are NOT types of types. They are NOT ty=
pe classes.<br></p></div></blockquote><div><br></div><div>Well, they sort-o=
f are. To a first approximation, they're predicates (type -> bool), =
which can be understood as partitions of the set of all types.</div><div>Fo=
r any type T, either T is-a Range or T is-not-a Range. So the set of Ranges=
is a subset of the set of all possible types.</div><div>BUT! Look closer a=
nd there are at least three caveats.</div><div>(1) Concepts have deep struc=
ture known as "normal form"; see below.</div><div>(2) Concepts do=
n't have to map (type -> bool); you can have multi-parameter concept=
s such as ConvertibleTo<T,U>, which are not as easily to gloss as pre=
dicates over single types. (But darned if the Concepts TS doesn't try! =
For any type T, either T is-a ConvertibleTo<U> or T is-not-a Converti=
bleTo<U>.)</div><div>(3) Concepts don't have to accept types at a=
ll. For example, you can make a concept that maps (int -> bool).</div><d=
iv><br></div><div>=C2=A0 =C2=A0 template<int V></div><div>=C2=A0 =C2=
=A0 concept EvenValue =3D ((V % 2) =3D=3D 0);</div><div><br></div><div>I do=
n't think this kind of concept is useful in real code (I'd prefer t=
his kind of concept be kicked out of the Working Draft before C++2a is ship=
ped). But you definitely can't by any mental gymnastics claim that conc=
ept `EvenValue`=C2=A0is a "type function" or a "type of type=
s" or anything remotely like that.</div><div><br></div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><p>At around 1:06:30 in his talk Bjarne s=
ays:<br>* "it's just like defining functions, you *ARE* DEFINING F=
UNCTIONS".</p></div></blockquote><div><br></div><div>I believe that wa=
s an ad-lib not to be taken 100% literally. To a first approximation, a con=
cept like Mergeable is a function mapping an ordered tuple of types to a bo=
ol. But that doesn't mean that <i>all concepts ever</i> must be thought=
of as functions.</div><div>That way lies functional programming and madnes=
s. ;)</div></div></blockquote><div><br></div><div>See I think it can be tak=
en pretty much 100% literally.</div><div><br></div><div>From what I can tel=
l,=C2=A0a Concept=C2=A0is=C2=A0100% a constexpr function.=C2=A0A concept=C2=
=A0function=C2=A0verifies that a given=C2=A0list of types (passed to that f=
unction) passed to it conform to a specification - as defined by the logic =
of that function. The name of the function signifies what the concept is.<b=
r>The function returns true if the types passed to the function meet the re=
quirements of logic of the function and false if they do not.</div><div><br=
></div><div>There=C2=A0may be=C2=A0more to=C2=A0how the=C2=A0compiler deals=
with such a function, but it seems to me that this minimum I've descri=
bed above is true.</div><div>Can we agree this far?</div><div><br></div><di=
v>If=C2=A0a concrete type is passed to a function as a parameter whose type=
is constrained by a Concept, the Concept function is called with the concr=
ete type and if it returns false, it yields a compilation error.<br>If a co=
ncrete type is returned from a function and assigned to a Concept variable =
the same check is performed. I'm sure this is=C2=A0reasonably off base =
but it seems like the gist of things. If this is correct or not though isn&=
#39;t the core of anything to me though. It's just how I'm visualiz=
ing it at the moment before I understand this more=C2=A0and subsumption and=
all of that.</div><div><br></div><div>Why does thinking of all concepts as=
functions madness? Because it seems to me that's exactly what all conc=
epts as currently discussed are. They ALL seem to be constexpr functions th=
at take a list of types and return bool to indicate the types satisfy the c=
oncept or they don't. What more is there and where is the madness?</div=
><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,20=
4);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><br=
></div><div>[...]</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-=
left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>The Concepts =
defined in Bjarne's talk look more like variable definitions *defined* =
in what feels (to me) like an odd mix of logic and type like syntax:<br></d=
iv><p>template<typename X> using Value_type =3D X::value_type;<br>tem=
plate<typename X> using Iterator_of =3D X::iterator;</p><p>template&l=
t;typename For, typename For2, typename Out><br>concept Mergable =3D<br>=
=C2=A0=C2=A0=C2=A0 ForwardIterator<For><br>=C2=A0=C2=A0=C2=A0 &&a=
mp; ForwardIterator<For2><br>=C2=A0=C2=A0=C2=A0 && OutputIter=
ator<Out><br>=C2=A0=C2=A0=C2=A0 && Assignable<Value_type&l=
t;For>,<wbr>Value_type<Out>><br>=C2=A0=C2=A0=C2=A0 && A=
ssignable<Value_type<For2>,<wbr>Value_type<Out>><br>=C2=
=A0=C2=A0=C2=A0 && Comparable<Value_type<For>,<wbr>Value_t=
ype<For2>>;</p><div><br></div><div>The above looks like a variable=
definition. If it is not, then is it right that it looks like one?<br>It&#=
39;s a definition, with conditional logic et al. i.e it uses &&. et=
c. like an inline function.<br></div><div>So why are we defining it NOT usi=
ng function like snytax?<br>Why is this a good thing?</div></div></blockquo=
te><div><br></div><div>Because of the first caveat I listed above: Concepts=
are not <i>just</i> predicates. They are logical predicates with deep stru=
cture, described by their <i>normal form</i>. For example, there is no spec=
ial relationship between the variable templates</div><div><br></div><div>=
=C2=A0 =C2=A0 template<class T> inline constexpr bool is_scalar_v =3D=
std::is_scalar<T>::value;</div><div>=C2=A0 =C2=A0 template<class =
T> inline constexpr bool is_integral_v =3D is_scalar_v<T> &&am=
p; std::is_integral<T>::value;</div><div><br></div><div>but there is =
a very special relationship between the concept( template)s</div><div><br><=
/div><div><div>=C2=A0 =C2=A0 template<class T> concept is_scalar_c =
=3D std::is_scalar<T>::value;</div><div>=C2=A0 =C2=A0 template<cla=
ss T> concept is_integral_c =3D is_scalar_c<T> && std::is_=
integral<T>::value;</div></div><div><br></div><div>The special relati=
onship is called <i>subsumption</i>, and we say that is_integral_c<X>=
<i>subsumes</i> is_scalar_c<X>.</div><div>If it weren't for subs=
umption, there would be no fundamental difference between a concept and a v=
ariable template of type `bool`.</div><div><br></div><div>The compiler dete=
rmines the subsumption relationships between concepts by cracking open thei=
r definitions and peering inside. The definitions are cracked open <i>only<=
/i> along the boundaries of the logical `&&` and `||` operators. So=
it is critically important that the definition of a concept be a single lo=
gical expression. If a concept were allowed to be expressed as a function b=
ody, the compiler wouldn't be able to crack it open, lift it into <i>no=
rmal form</i>, and figure out the <i>subsumption</i> relationships between =
this concept and all the other concepts in your program.</div><div><br></di=
v><div>Figuring out these relationships is important to the compiler becaus=
e these relationships affect overload resolution.</div><div><br></div><div>=
Please see my CppCon 2018 talk <a href=3D"https://www.youtube.com/watch?v=
=3DCXn02MPkn8Y" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D'https://www.youtube.com/watch?v\x3dCXn02MPkn8Y';return true;" o=
nclick=3D"this.href=3D'https://www.youtube.com/watch?v\x3dCXn02MPkn8Y&#=
39;;return true;">"Concepts as she is spoke"</a> for a truly pain=
ful amount of information on how Concepts are different from plain old vari=
able templates.</div><div><br></div><div>[...]</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-c=
olor:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div d=
ir=3D"ltr"><div>1. If concepts ARE functions, why aren't we defining an=
d using them with function like syntax? And using () not <>.<br></div=
></div></blockquote><div><br></div><div>I hope my answers above have pointe=
d the way on this one.</div></div></blockquote><div><br></div><div>Not yet =
no,=C2=A0sorry.=C2=A0But the discussion is helpful to me all the same so th=
ank you.</div><div>I can see the topic of subsumption complicates the conve=
rsation though. However the subsumption etc.=C2=A0is=C2=A0seems to be an ad=
ditive aspect to the basic fact that a concept IS a constexpr bool=C2=A0fun=
ction, regardless of whatever extra rules come into effect after that or ar=
ound that.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204)=
;border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid"><div dir=3D"ltr"><div>2. It seems J. Monnon's=
proposal is making the same point as I am, only much better? Can we please=
address all that he proposes?<br></div></div></blockquote><div><br></div><=
div>I think <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
018/p0844r0.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjt=
c1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0844r0.html\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNEFr_9YGZO5BDdyaSw7BW7ttm0_LQ';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0844r0.html\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEFr_9YGZO5BDdyaSw7BW7ttm0_LQ';return tru=
e;">P0844 "Type functions and beyond"</a> is thought-provoking. I=
t's very large, though, which I believe is why it's targeted at SG7=
Compile-Time Programming (formerly SG7 Reflection).</div><div>P0844 major =
section 3, "Concepts introducing types," seems to ignore the exis=
tence of non-type concepts in the Working Draft. Perhaps there should be a =
concerted effort to <i>kick non-type concepts out of the Working Draft</i> =
in order to gain some freedom of motion for these recurring theories of &qu=
ot;concepts =3D=3D types of types."</div><div>I do not believe that P0=
844 is making the same points (or, asking for clarification on the same poi=
nts) as you are. I have only skimmed P0844, but it does not seem to be enga=
ging with Concepts-as-they-are at all; it seems to be trying to reuse Conce=
pty words to refer to elements of the author's more na=C3=AFve "ty=
pes of types" theory.</div><div>(More na=C3=AFve is not necessarily ba=
d! =C2=A0I think C++2a Concepts is <i>far</i> too much of an experts-only f=
eature, and we could use a lot more naivet=C3=A9 in this area.)</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid"><div dir=3D"ltr"><div>3. I feel a more formal res=
ponse to J. Monnon's paper from the main proponents of Concepts as curr=
ently defined should be made before concepts get wired in any further in it=
's current direction?</div><div><br></div><div>I know many people would=
like Concepts be the marquee feature of C++20, but to me Concepts=C2=A0sti=
ll seem quite away from where I'd like them to be.<br>Even Bjarne can o=
nly 'begrudgingly live' with the current syntax.<br>All this flux a=
nd begrudging really doesn't suggest to me that Concepts are ready to g=
o for C++20.<br></div></div></blockquote><div><br></div><div>FWIW, I agree =
with your conclusion.</div><div>The question is, do C++2a Concepts need who=
lesale kicking-out, as happened in C++11? or can they be rescued by judicio=
us cuts?</div><div>The other question is, can anyone stop Concepts at this =
point or are the wise people getting out of the way of the train? (Cynic sa=
ys: observe the recent formation of EWGI and LEWGI for those people tired o=
f engaging with C++2a issues and eager to move on to C++2b.)</div><div><br>=
</div><div>=E2=80=93Arthur</div></div></blockquote><div><br></div><div>I th=
ink <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p084=
4r0.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc2=
2%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0844r0.html\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNEFr_9YGZO5BDdyaSw7BW7ttm0_LQ';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2=
Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0844r0.html\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNEFr_9YGZO5BDdyaSw7BW7ttm0_LQ';return true;">P084=
4 "Type functions and beyond"</a>=C2=A0seems to reach far and ver=
y consistently given that reach and it keeps the programming function based=
.. My thoughts on Concepts is that it's syntax is unappealing=C2=A0with =
the angle bracket fest=C2=A0and the=C2=A0auto Concept x; versus Concept x=
=C2=A0storm.</div><div><br></div><div>I think Concept definitions=C2=A0need=
to retain=C2=A0a similar=C2=A0functional feel and that means exposing Conc=
epts to look more like the functions and enabling them to be defined more l=
ike that. Or at least it's not clear to me why we can't and shouldn=
't=C2=A0go further down that road.</div><div><br></div><div>In other wo=
rds, why this from <a href=3D"https://en.cppreference.com/w/cpp/language/co=
nstraints" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.cppreference.com%2Fw%2F=
cpp%2Flanguage%2Fconstraints\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHasRvm=
9d9rdm4hlb7vG42igSpKKA';return true;" onclick=3D"this.href=3D'https=
://www.google.com/url?q\x3dhttps%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fla=
nguage%2Fconstraints\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHasRvm9d9rdm4h=
lb7vG42igSpKKA';return true;">https://en.cppreference.com/w/<wbr>cpp/la=
nguage/constraints</a>):</div><div>template <class T><br>concept Semi=
regular =3D DefaultConstructible<T> &&<br>=C2=A0=C2=A0=C2=A0 =
CopyConstructible<T> && Destructible<T> && Copy=
Assignable<T> &&<br>requires(T a, size_t n) {=C2=A0 <br>=C2=
=A0=C2=A0=C2=A0 requires Same<T*, decltype(&a)>;=C2=A0 // nested:=
"Same<...> evaluates to true"<br>=C2=A0=C2=A0=C2=A0 { a.~T=
() } noexcept;=C2=A0 // compound: "a.~T()" is a valid expression =
that doesn't throw<br>=C2=A0=C2=A0=C2=A0 requires Same<T*, decltype(=
new T)>; // nested: "Same<...> evaluates to true"<br>=C2=
=A0=C2=A0=C2=A0 requires Same<T*, decltype(new T[n])>; // nested<br>=
=C2=A0=C2=A0=C2=A0 { delete new T };=C2=A0 // compound<br>=C2=A0=C2=A0=C2=
=A0 { delete new T[n] }; // compound<br>};</div><div>instead of something l=
ike this:</div><div>concept Semiregular(T)<br>{<br>=C2=A0=C2=A0=C2=A0 requi=
re DefaultConstructible(T) && CopyConstructible(T) && Destr=
uctible(T) && CopyAssignable(T);<br>=C2=A0=C2=A0=C2=A0 with (T a, s=
ize_t n) {=C2=A0</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...<br></di=
v><div>=C2=A0=C2=A0=C2=A0 };<br>}</div><div><br></div><div>To me, Concepts =
as defined obfuscates a=C2=A0function as a variable definition.=C2=A0But if=
=C2=A0it is=C2=A0a function it remains unclear to me why it should not look=
=C2=A0a function=C2=A0and be able to be called like one and in that I think=
=C2=A0that would connect more with the style that P040844 reaches for.</div=
><div><br></div><div>As it stands=C2=A0I feel=C2=A0with Concepts, Reflectio=
n and Metaclasses all coming along, putting in Concepts=C2=A0so far ahead o=
f these other features=C2=A0might mean that Concepts=C2=A0will not fit toge=
ther well them.=C2=A0My comments are aimed at revealing that fact (or not) =
and if=C2=A0Concepts should wait to avoid that but also at understanding Co=
ncepts.=C2=A0</div><div><br></div><div>Bjarne talks about remember the Vasa=
,=C2=A0but I'm worried that ironically Concepts might be that extra lev=
el of guns on deck that we are not ready for just yet.<br></div><div><br></=
div><div>Hopefully I am wrong about much of this. I don't want those wo=
rking on Concepts don't feel I'm knocking their work. I am apprecia=
tive of their efforts.=C2=A0Hopefully this discussion=C2=A0helps even if it=
just=C2=A0helps me understand Concepts better and get on-board with them.<=
/div><div><br></div><div>Thanks</div></div></blockquote></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/0b563669-ad01-4386-b08c-ae9c964b2247%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0b563669-ad01-4386-b08c-ae9c964b2247=
%40isocpp.org</a>.<br />
------=_Part_480_947842359.1540804885466--
------=_Part_479_1193262745.1540804885465--
.