Topic: Clarification needed on Concepts (and Contracts?)
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Mon, 19 Jun 2017 06:42:03 -0700 (PDT)
Raw View
------=_Part_3248_1748010695.1497879723821
Content-Type: multipart/alternative;
boundary="----=_Part_3249_200018429.1497879723822"
------=_Part_3249_200018429.1497879723822
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello Folks,
Reading P0587R0=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0587r0.pdf> (that=
=20
talks about in what way Concepts might have to be refined),
two questions came to my mind, that have not been adressed by any Papers I=
=20
read about Concepts in C++:
1. *Allowing concepts to be passed as template parameters.*=20
A potential syntax (as touched in P0587R0) has to take that into account=20
that, If we want to allow *concepts to be passed as template parameters,*
we don=E2=80=99t want to ambiguate this case with *constraining template pa=
rameters=20
with concepts*.
=20
With Concepts Lite TS, I would intuitively write a template taking a=20
concept as template parameter as:
template<
template<typename> concept MyConstraint
> struct WhateverClass{
template<MyConstraint T> // Use the passed concept here just as =E2=80=
=9Cnormal=E2=80=9D
WhateverClass(T arg){ /* =E2=80=A6 */ }
};
This is not (yet) allowed but I did not find anyone that even considered it=
..
Hopefully, I have not missed something.
=20
=20
1. *How do we make clear if a concept is a value or type constraint?*=20
Cited from the paper:
*Conversely, given:*
*template<int N> concept bool Even =3D N % 2 =3D=3D 0;*
*This seems quite reasonable (if perhaps not all that useful):*
*template<Even N> void f() {*
*constexpr Even X =3D N;*
*}*
*Note that in this case, values of type Even are ontologically at the *
*=E2=80=9Cvalue**=E2=80=9D level not at the **=E2=80=9Ctype**=E2=80=9D*
*level because it is a concept constraining a value (non-type template=20
parameter), not a concept*
*constraining a type.*
=20
There is a problem with that: How do we know what type of template=20
parameter f() actually takes?
Does it refer to a type that is Even? Does it refer to a type =E2=80=98Even=
=E2=80=99, does=20
it refer to an Even value (if yes, what type?) and how do we know, Even is=
=20
a concept?
We don=E2=80=99t.
=20
If we only can know e.g. the underlying data type (here int) of a concepts=
=20
use (see *template<Even N> void f()*) by looking at its definition, this=20
design is significantly flawed.
What my Idea here was is: what if we relax the value constraint with auto=
=20
(this makes the value constraint reusable and overloadable), see
template<auto N> concept bool Even =3D N % 2 =3D=3D 0;
=20
and mention an explicit type (or auto, depending on what we want) at the=20
point of use?
template<Even int N> void f() {
constexpr Even int X =3D N;
}
This would turn out rather intuitive, doesn=E2=80=99t it?
=20
=3D> Outcome: Rather than perceiving Even as a constrained Datatype, we can=
=20
perceive it as a property that we can enforce on the domain of a given type=
..
But hey! This is nothing but a contract!
=20
*[Start note **=E2=80=93*
In Analogy to the above example:
template<Regular typename T> struct{};
This now makes pretty clear what=E2=80=99s going on here.
*-- End note]*
=20
I think a great goal we should discuss is merging contracts and concepts=20
together since they portrait the same idea.
The only difference is that one does it at compile time and the other one=
=20
at runtime (a little bit overgeneralized, but that=E2=80=99s the basic idea=
, isn=E2=80=99t=20
it?).
=20
If my argument is not clear already, consider the following combined=20
Example:
void f( Positive float m ){
}
void f( NonNull char* dest ){
}
template<
Arbitrary typename T,
Positive int m,
Positive int n
>=20
void f( Symmetric std::matrix<T,m,n> m ){
}
=20
=3D> We should try to combine them somehow in a hybrid compiletime/runtime=
=20
mechanism or else we have a great redundancy between contracts and=20
concepts. (IMO)
=20
=20
These are just a few Ideas that I have not seen anyone talk about. Therfore=
=20
I'd like to do that now.
=20
I=E2=80=99d be happy to hear from you!
=20
Kind Regards,
Jakob
=20
--=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/0656d3ef-2a9e-4026-b537-9cbe53c5452e%40isocpp.or=
g.
------=_Part_3249_200018429.1497879723822
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hello Folks,</div><div><br></div><div>Reading=C2=A0<a=
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0587r0.pd=
f">P0587R0</a>=C2=A0(that talks about in what way Concepts might have to be=
refined),</div><div>two questions came to my mind, that have not been adre=
ssed by any Papers I read about Concepts in C++:</div><div><b><br></b></div=
><ol style=3D"" start=3D"1" type=3D"1">
<li class=3D"MsoNormal" style=3D"margin-left:-18.0pt;mso-list:l0 level1 lf=
o1"><b>Allowing concepts to be passed as template
parameters.<o:p></o:p></b></li>
</ol>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">A potential syntax (as =
touched in P0587R0) has to take
that into account that, If we want to allow <b>concepts to be passed as
template parameters,</b><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">we don<span style=3D"fo=
nt-family:
"Times New Roman",serif">=E2=80=99</span>t want to ambiguate this=
case with <b>constraining
template parameters with concepts</b>.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">With Concepts Lite TS, =
I would
intuitively write a template taking a concept as template parameter as:<o:p=
></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">template<<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><spa=
n style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium";=
background:silver;
mso-highlight:silver">template<typename> concept MyConstraint<o:p></o=
:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">>
struct WhateverClass{<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">=C2=A0=C2=A0
template<MyConstraint T> // Use the passed concept here just as =E2=
=80=9Cnormal=E2=80=9D<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">=C2=A0=C2=A0
WhateverClass(T arg){ /* =E2=80=A6 */ }<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">};</span><span style=3D"font-size:10.0pt"><o:p></o:p></span></p=
>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This is not (yet) allow=
ed but I
did not find anyone that even considered it.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Hopefully, I have not m=
issed
something.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<ol style=3D"margin-top:0cm" start=3D"2" type=3D"1">
<li class=3D"MsoNormal" style=3D"margin-left:-18.0pt;mso-list:l0 level1 lf=
o1"><b>How
do we make clear if a concept is a value or type constraint?<o:p></o:p=
></b></li>
</ol>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Cited from the paper:<o=
:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><br></i></p><p class=
=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>Conversely, given:<o:p></o:p=
></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">template<int
N> concept bool Even =3D N % 2 =3D=3D 0;</span></i><i><span style=3D"fon=
t-size:10.0pt;
font-family:"Source Code Pro Medium""><o:p></o:p></span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>This seems quite rea=
sonable
(if perhaps not all that useful):<o:p></o:p></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">template<Even
N> void f() {<o:p></o:p></span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt;text-indent:36.0pt"><i><=
span style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium&quo=
t;;background:silver;
mso-highlight:silver">constexpr Even X =3D N;<o:p></o:p></span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">}</span></i><i><span style=3D"font-size:10.0pt;font-family:&quo=
t;Source Code Pro Medium""><o:p></o:p></span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>Note that in this ca=
se, values
of type Even are ontologically at the </i><i><span style=3D"font-family:&qu=
ot;Times New Roman",serif">=E2=80=9C</span>value</i><i><span style=3D"=
font-family:"Times New Roman",serif">=E2=80=9D</span> level not a=
t the </i><i><span style=3D"font-family:"Times New Roman",serif">=
=E2=80=9C</span>type</i><i><span style=3D"font-family:"Times New Roman=
",serif">=E2=80=9D</span><o:p></o:p></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>level because it is =
a concept
constraining a value (non-type template parameter), not a concept<o:p></o:p=
></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>constraining a type.=
<o:p></o:p></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">There is a problem with=
that: How
do we know what type of template parameter <span style=3D"font-family:"=
;Source Code Pro Medium";
background:silver;mso-highlight:silver">f()</span> actually takes?<o:p></o:=
p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Does it refer to a type=
that is
Even? Does it refer to a type <span style=3D"font-family:"Times New Ro=
man",serif">=E2=80=98</span>Even<span style=3D"font-family:"Times=
New Roman",serif">=E2=80=99</span>, does it refer to an Even
value (if yes, what type?) and how do we know, Even is a concept?<o:p></o:p=
></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">We don<span style=3D"fo=
nt-family:
"Times New Roman",serif">=E2=80=99</span>t.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">If we only can know e.g=
.. the
underlying data type (here <span style=3D"font-size:10.0pt;font-family:&quo=
t;Source Code Pro Medium";
background:silver;mso-highlight:silver">int</span>) of a concepts use (see =
<i><span style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium=
";background:silver;
mso-highlight:silver">template<<span style=3D"color:red">Even N</span>&g=
t; void
f()</span></i>) by looking at its definition, this design is significantly
flawed.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">What my Idea here was i=
s: what if
we relax the value constraint with auto (this makes the value constraint
reusable and <span style=3D"color:red">overloadable</span>), see<o:p></o:p>=
</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">template<auto
N> concept bool Even =3D N % 2 =3D=3D 0;</span><span style=3D"font-size:=
10.0pt;
font-family:"Source Code Pro Medium""><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">and mention an explicit=
type (or
auto, depending on what we want) at the point of use?<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">template<Even
<span style=3D"color:red">int </span>N> void f() {<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><spa=
n style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium";=
background:silver;
mso-highlight:silver">constexpr Even <span style=3D"color:red">int </span>X=
=3D N;<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">}</span><span style=3D"font-size:10.0pt;font-family:"Sourc=
e Code Pro Medium""><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This would turn out rat=
her
intuitive, doesn<span style=3D"font-family:"Times New Roman",seri=
f">=E2=80=99</span>t it?<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=3D> Outcome: Rather=
than
perceiving <span style=3D"font-size:10.0pt;font-family:"Source Code Pr=
o Medium";
background:silver;mso-highlight:silver">Even</span><span style=3D"font-size=
:10.0pt">
</span>as a constrained Datatype, we can perceive it as a property that we =
can
enforce on the domain of a given type.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">But hey! This is nothin=
g but a
contract!<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><i>[Start note </i><i><=
span style=3D"font-family:"Times New Roman",serif">=E2=80=93</spa=
n><o:p></o:p></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">In Analogy to the above=
example:<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;
font-family:"Source Code Pro Medium";background:silver;mso-highli=
ght:silver">template<Regular
<span style=3D"color:red">typename </span>T> struct{};<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This now makes pretty c=
lear what<span style=3D"font-family:"Times New Roman",serif">=E2=
=80=99</span>s going on here.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><i>-- End note]<o:p></o=
:p></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">I think a great goal we=
should
discuss is merging contracts and concepts together since they portrait the =
same
idea.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">The only difference is =
that one
does it at compile time and the other one at runtime (a little bit
overgeneralized, but that<span style=3D"font-family:"Times New Roman&q=
uot;,serif">=E2=80=99</span>s
the basic idea, isn<span style=3D"font-family:"Times New Roman",s=
erif">=E2=80=99</span>t
it?).<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">If my argument is not c=
lear
already, consider the following combined Example:<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-fam=
ily:"Source Code Pro Medium";
background:silver;mso-highlight:silver">void f( Positive float m ){<o:p></o=
:p></span></p><p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span sty=
le=3D"font-family:"Source Code Pro Medium";
background:silver;mso-highlight:silver">}</span><span style=3D"font-family:=
"Source Code Pro Medium""><o:p></o:p></span></p><p class=3D"MsoNo=
rmal" style=3D"margin-left:18.0pt"><span style=3D"font-family:"Source =
Code Pro Medium";
background:silver;mso-highlight:silver">void f( NonNull char* dest ){<o:p><=
/o:p></span></p><p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span s=
tyle=3D"font-family:"Source Code Pro Medium";
background:silver;mso-highlight:silver">}</span></p><p class=3D"MsoNormal" =
style=3D"margin-left:18.0pt"><span style=3D"font-family:"Source Code P=
ro Medium";
background:silver;mso-highlight:silver">template<<o:p></o:p></span></p><=
p class=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><span=
style=3D"font-family:"Source Code Pro Medium";background:silver;=
mso-highlight:
silver">Arbitrary typename T,<o:p></o:p></span></p><p class=3D"MsoNormal" s=
tyle=3D"margin-left:18.0pt;text-indent:36.0pt"><span style=3D"font-family:&=
quot;Source Code Pro Medium";background:silver;mso-highlight:
silver">Positive int m,<o:p></o:p></span></p><p class=3D"MsoNormal" style=
=3D"margin-left:18.0pt;text-indent:36.0pt"><span style=3D"font-family:"=
;Source Code Pro Medium";background:silver;mso-highlight:
silver">Positive int n<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D=
"margin-left:18.0pt"><span style=3D"font-family:"Source Code Pro Mediu=
m";
background:silver;mso-highlight:silver">><o:p>=C2=A0</o:p></span></p><p =
class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-family=
:"Source Code Pro Medium";
background:silver;mso-highlight:silver">void f( Symmetric
std::matrix<T,m,n> m ){<o:p></o:p></span></p><p class=3D"MsoNormal" s=
tyle=3D"margin-left:18.0pt"><span style=3D"font-family:"Source Code Pr=
o Medium";
background:silver;mso-highlight:silver">
</span><span style=3D"font-family:"Source Code Pro Medium""><o:p>=
</o:p></span></p><p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span =
style=3D"font-family:"Source Code Pro Medium";
background:silver;mso-highlight:silver">}</span><span style=3D"font-family:=
"Source Code Pro Medium""><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-fam=
ily:"Source Code Pro Medium""><o:p>=C2=A0</o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=3D> We should try t=
o combine them somehow in a hybrid compiletime/runtime mechanism or else we=
have a great redundancy between contracts and concepts. (IMO)<o:p></o:p></=
p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">These are just a few Ideas that I have not seen anyo=
ne talk about. Therfore I'd like to do that now.</p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal"><br></p>
<p class=3D"MsoNormal">I<span style=3D"font-family:"Times New Roman&qu=
ot;,serif">=E2=80=99</span>d
be happy to hear from you!<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoNormal">Kind Regards,<o:p></o:p></p>
<p class=3D"MsoNormal">Jakob<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p></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/0656d3ef-2a9e-4026-b537-9cbe53c5452e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0656d3ef-2a9e-4026-b537-9cbe53c5452e=
%40isocpp.org</a>.<br />
------=_Part_3249_200018429.1497879723822--
------=_Part_3248_1748010695.1497879723821--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 19 Jun 2017 16:28:47 -0700 (PDT)
Raw View
------=_Part_3891_720488803.1497914927841
Content-Type: multipart/alternative;
boundary="----=_Part_3892_2097178822.1497914927841"
------=_Part_3892_2097178822.1497914927841
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Monday, June 19, 2017 at 6:42:03 AM UTC-7, Jakob Riedle wrote:
>
> Hello Folks,
>
> Reading P0587R0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0587r0.pdf> (th=
at=20
> talks about in what way Concepts might have to be refined),
> two questions came to my mind, that have not been adressed by any Papers =
I=20
> read about Concepts in C++:
>
>
> 1. *Allowing concepts to be passed as template parameters.*=20
>
> A potential syntax (as touched in P0587R0) has to take that into account=
=20
> that, If we want to allow *concepts to be passed as template parameters,*
>
> we don=E2=80=99t want to ambiguate this case with *constraining template=
=20
> parameters with concepts*.
>
> =20
>
> With Concepts Lite TS, I would intuitively write a template taking a=20
> concept as template parameter as:
>
> template<
>
> template<typename> concept MyConstraint
>
> > struct WhateverClass{
>
> template<MyConstraint T> // Use the passed concept here just as =E2=80=
=9Cnormal=E2=80=9D
>
> WhateverClass(T arg){ /* =E2=80=A6 */ }
>
> };
>
> This is not (yet) allowed but I did not find anyone that even considered=
=20
> it.
>
> Hopefully, I have not missed something.
>
I don't know anything authoritative about this, but my random uneducated=20
intuition is that either:
(A) given their extremely templatey syntax, concepts are just templates,=20
and so you can write
template<template<typename> bool MyConstraint>
struct WhateverClass {
template<MyConstraint T> WhateverClass(T arg) { ... }
}
or else (B) concepts operate at a higher level than templates, just as=20
types operate at a higher level than values, and so there are philosophical=
=20
problems with the entire idea of making a templated type based on a=20
concept. (But I don't *think* this is the case.)
=20
>
> 1. *How do we make clear if a concept is a value or type constraint?*=
=20
>
> Cited from the paper:
>
>
> *Conversely, given:*
>
> *template<int N> concept bool Even =3D N % 2 =3D=3D 0;*
>
> *This seems quite reasonable (if perhaps not all that useful):*
>
> *template<Even N> void f() {*
>
> *constexpr Even X =3D N;*
>
> *}*
>
> *Note that in this case, values of type Even are ontologically at the *
> *=E2=80=9Cvalue**=E2=80=9D level not at the **=E2=80=9Ctype**=E2=80=9D*
>
> *level because it is a concept constraining a value (non-type template=20
> parameter), not a concept*
>
> *constraining a type.*
>
> =20
>
> There is a problem with that: How do we know what type of template=20
> parameter f() actually takes?
>
> Does it refer to a type that is Even? Does it refer to a type =E2=80=98Ev=
en=E2=80=99,=20
> does it refer to an Even value (if yes, what type?) and how do we know,=
=20
> Even is a concept?
>
> We don=E2=80=99t.
>
> =20
>
> If we only can know e.g. the underlying data type (here int) of a=20
> concepts use (see *template<Even N> void f()*) by looking at its=20
> definition, this design is significantly flawed.
>
We have the same problem with type-concepts in general: given
template<Foo f> struct S { ... };
I have no way of knowing whether Foo is the name of a literal type (so I=20
should say S<Foo{x}>) or the name of a concept (so I should say S<Bar>).=20
And now you're saying it could even be a value constraint (so I should say=
=20
S<Bar{x}>)? Gross.
=20
> What my Idea here was is: what if we relax the value constraint with auto=
=20
> (this makes the value constraint reusable and overloadable), see
>
> template<auto N> concept bool Even =3D N % 2 =3D=3D 0;
>
> =20
>
> and mention an explicit type (or auto, depending on what we want) at the=
=20
> point of use?
>
> template<Even int N> void f() {
>
> constexpr Even int X =3D N;
>
> }
>
> This would turn out rather intuitive, doesn=E2=80=99t it?
>
> =20
>
> =3D> Outcome: Rather than perceiving Even as a constrained Datatype, we c=
an=20
> perceive it as a property that we can enforce on the domain of a given ty=
pe.
>
> But hey! This is nothing but a contract!
>
> =20
>
> *[Start note **=E2=80=93*
>
> In Analogy to the above example:
>
> template<Regular typename T> struct{};
>
> This now makes pretty clear what=E2=80=99s going on here.
>
> *-- End note]*
>
>
*This strikes me as a great idea.* I really hope people see this!
I'm skeptical of the perceived similarity between Concepts and Contracts=20
(and I'm skeptical of Contracts in general), but this syntactic idea of=20
putting "typename" or "int" or "auto" after the use of a concept's name=20
seems like a very nice way to keep the human reader "in the loop" about=20
what the code is actually trying to accomplish.
Some people (including my former self) would say that "typename" and "auto"=
=20
are themselves concepts in a sense: "auto" is the placeholder for "any=20
value whose type satisfies <the trivial/top concept>" and "typename" is the=
=20
placeholder for "any type satisfying <the trivial/top concept>". But with a=
=20
small syntactic suggestion, you've actually made it really hard for me to=
=20
see why I ever thought that was a compelling idea. The alternative =E2=80=
=94 that=20
"auto" is a word *meaning* "this thing here is (has) a value" and=20
"typename" is a word *meaning* "this thing here is a type" =E2=80=94 is not=
only=20
much easier to read, but strictly in keeping with the way C++11-and-later=
=20
has always used those words. It seems like a good idea.
=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/e76bbcf8-98f9-4f1e-813a-78fab188615c%40isocpp.or=
g.
------=_Part_3892_2097178822.1497914927841
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, June 19, 2017 at 6:42:03 AM UTC-7, Jakob Riedle=
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>H=
ello Folks,</div><div><br></div><div>Reading=C2=A0<a href=3D"http://www.ope=
n-std.org/jtc1/sc22/wg21/docs/papers/2017/p0587r0.pdf" target=3D"_blank" re=
l=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\=
x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F201=
7%2Fp0587r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFnWZpFDFfS_qJx90Neg=
obn0NhJtw';return true;" onclick=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpa=
pers%2F2017%2Fp0587r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFnWZpFDFf=
S_qJx90Negobn0NhJtw';return true;">P0587R0</a>=C2=A0(that talks about i=
n what way Concepts might have to be refined),</div><div>two questions came=
to my mind, that have not been adressed by any Papers I read about Concept=
s in C++:</div><div><b><br></b></div><ol start=3D"1" type=3D"1">
<li class=3D"MsoNormal"><b>Allowing concepts to be passed as template
parameters.</b></li>
</ol>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">A potential syntax (as =
touched in P0587R0) has to take
that into account that, If we want to allow <b>concepts to be passed as
template parameters,</b></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">we don<span style=3D"fo=
nt-family:"Times New Roman",serif">=E2=80=99</span>t want to ambi=
guate this case with <b>constraining
template parameters with concepts</b>.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">With Concepts Lite TS, =
I would
intuitively write a template taking a concept as template parameter as:</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><spa=
n style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium";=
background:silver">template<typename> concept MyConstraint</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
>
struct WhateverClass{</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
=C2=A0=C2=A0
template<MyConstraint T> // Use the passed concept here just as =E2=
=80=9Cnormal=E2=80=9D</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
=C2=A0=C2=A0
WhateverClass(T arg){ /* =E2=80=A6 */ }</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
};</span><span style=3D"font-size:10.0pt"></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This is not (yet) allow=
ed but I
did not find anyone that even considered it.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Hopefully, I have not m=
issed
something.</p></div></blockquote><div><br></div><div>I don't know anyth=
ing authoritative about this, but my random uneducated intuition is that ei=
ther:</div><div>(A) given their extremely templatey syntax, concepts are ju=
st templates, and so you can write</div><div><font face=3D"courier new, mon=
ospace">=C2=A0 =C2=A0 template<template<typename> bool MyConstrain=
t></font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
struct WhateverClass {</font></div><div><font face=3D"courier new, monospac=
e">=C2=A0 =C2=A0 =C2=A0 =C2=A0 template<MyConstraint T> WhateverClass=
(T arg) { ... }</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 }</font></div><div>or else (B) concepts operate at a higher leve=
l than templates, just as types operate at a higher level than values, and =
so there are philosophical problems with the entire idea of making a templa=
ted type based on a concept. =C2=A0(But I don't <i>think</i> this is th=
e case.)</div><div><br></div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">
<p class=3D"MsoNormal">=C2=A0=C2=A0</p>
<ol style=3D"margin-top:0cm" start=3D"2" type=3D"1">
<li class=3D"MsoNormal"><b>How
do we make clear if a concept is a value or type constraint?</b></li>
</ol>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Cited from the paper:</=
p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><br></i></p><p class=
=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>Conversely, given:</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;font-family:"Source Code Pro Medium";background:silve=
r">template<int
N> concept bool Even =3D N % 2 =3D=3D 0;</span></i><i><span style=3D"fon=
t-size:10.0pt;font-family:"Source Code Pro Medium""></span></i></=
p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>This seems quite rea=
sonable
(if perhaps not all that useful):</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;font-family:"Source Code Pro Medium";background:silve=
r">template<Even
N> void f() {</span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt;text-indent:36.0pt"><i><=
span style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium&quo=
t;;background:silver">constexpr Even X =3D N;</span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;font-family:"Source Code Pro Medium";background:silve=
r">}</span></i><i><span style=3D"font-size:10.0pt;font-family:"Source =
Code Pro Medium""></span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>Note that in this ca=
se, values
of type Even are ontologically at the </i><i><span style=3D"font-family:&qu=
ot;Times New Roman",serif">=E2=80=9C</span>value</i><i><span style=3D"=
font-family:"Times New Roman",serif">=E2=80=9D</span> level not a=
t the </i><i><span style=3D"font-family:"Times New Roman",serif">=
=E2=80=9C</span>type</i><i><span style=3D"font-family:"Times New Roman=
",serif">=E2=80=9D</span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>level because it is =
a concept
constraining a value (non-type template parameter), not a concept</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>constraining a type.=
</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">There is a problem with=
that: How
do we know what type of template parameter <span style=3D"font-family:"=
;Source Code Pro Medium";background:silver">f()</span> actually takes?=
</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Does it refer to a type=
that is
Even? Does it refer to a type <span style=3D"font-family:"Times New Ro=
man",serif">=E2=80=98</span>Even<span style=3D"font-family:"Times=
New Roman",serif">=E2=80=99</span>, does it refer to an Even
value (if yes, what type?) and how do we know, Even is a concept?</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">We don<span style=3D"fo=
nt-family:"Times New Roman",serif">=E2=80=99</span>t.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">If we only can know e.g=
.. the
underlying data type (here <span style=3D"font-size:10.0pt;font-family:&quo=
t;Source Code Pro Medium";background:silver">int</span>) of a concepts=
use (see <i><span style=3D"font-size:10.0pt;font-family:"Source Code =
Pro Medium";background:silver">template<<span style=3D"color:red">E=
ven N</span>> void
f()</span></i>) by looking at its definition, this design is significantly
flawed.</p></div></blockquote><div><br></div><div>We have the same problem =
with type-concepts in general: given</div><div><font face=3D"courier new, m=
onospace">template<Foo f> struct S { ... };</font></div><div>I have n=
o way of knowing whether Foo is the name of a literal type (so I should say=
<font face=3D"courier new, monospace">S<Foo{x}></font>) or the name =
of a concept (so I should say <font face=3D"courier new, monospace">S<Ba=
r></font>). And now you're saying it could even be a value constrain=
t (so I should say <font face=3D"courier new, monospace">S<Bar{x}></f=
ont>)? Gross.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr">
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">What my Idea here was i=
s: what if
we relax the value constraint with auto (this makes the value constraint
reusable and <span style=3D"color:red">overloadable</span>), see</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<auto
N> concept bool Even =3D N % 2 =3D=3D 0;</span><span style=3D"font-size:=
10.0pt;font-family:"Source Code Pro Medium""></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">and mention an explicit=
type (or
auto, depending on what we want) at the point of use?</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<Even
<span style=3D"color:red">int </span>N> void f() {</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><spa=
n style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium";=
background:silver">constexpr Even <span style=3D"color:red">int </span>X =
=3D N;</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
}</span><span style=3D"font-size:10.0pt;font-family:"Source Code Pro M=
edium""></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This would turn out rat=
her
intuitive, doesn<span style=3D"font-family:"Times New Roman",seri=
f">=E2=80=99</span>t it?</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=3D> Outcome: Rather=
than
perceiving <span style=3D"font-size:10.0pt;font-family:"Source Code Pr=
o Medium";background:silver">Even</span><span style=3D"font-size:10.0p=
t">
</span>as a constrained Datatype, we can perceive it as a property that we =
can
enforce on the domain of a given type.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">But hey! This is nothin=
g but a
contract!</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><i>[Start note </i><i><=
span style=3D"font-family:"Times New Roman",serif">=E2=80=93</spa=
n></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">In Analogy to the above=
example:</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<Regular
<span style=3D"color:red">typename </span>T> struct{};</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This now makes pretty c=
lear what<span style=3D"font-family:"Times New Roman",serif">=E2=
=80=99</span>s going on here.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><i>-- End note]</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"></p></div></blockquote>=
<div><br></div><div><b>This strikes me as a <i>great</i> idea.</b> I really=
hope people see this!</div><div><br></div><div>I'm skeptical of the pe=
rceived similarity between Concepts and Contracts (and I'm skeptical of=
Contracts in general), but this syntactic idea of putting "typename&q=
uot; or "int" or "auto" after the use of a concept'=
s name seems like a very nice way to keep the human reader "in the loo=
p" about what the code is actually trying to accomplish.</div><div><br=
></div><div>Some people (including my former self) would say that "typ=
ename" and "auto" are themselves concepts in a sense: "=
auto" is the placeholder for "any value whose type satisfies <=
the trivial/top concept>" and "typename" is the placehold=
er for "any type satisfying <the trivial/top concept>". But=
with a small syntactic suggestion, you've actually made it really hard=
for me to see why I ever thought that was a compelling idea. =C2=A0The alt=
ernative =E2=80=94 that "auto" is a word <i>meaning</i> "thi=
s thing here is (has) a value" and "typename" is a word <i>m=
eaning</i> "this thing here is a type" =E2=80=94 is not only much=
easier to read, but strictly in keeping with the way C++11-and-later has a=
lways used those words. =C2=A0It seems like a good idea.</div><div><br></di=
v><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/e76bbcf8-98f9-4f1e-813a-78fab188615c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e76bbcf8-98f9-4f1e-813a-78fab188615c=
%40isocpp.org</a>.<br />
------=_Part_3892_2097178822.1497914927841--
------=_Part_3891_720488803.1497914927841--
.
Author: inkwizytoryankes@gmail.com
Date: Tue, 20 Jun 2017 13:14:28 -0700 (PDT)
Raw View
------=_Part_4419_1000143616.1497989668512
Content-Type: multipart/alternative;
boundary="----=_Part_4420_1684869087.1497989668512"
------=_Part_4420_1684869087.1497989668512
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, June 20, 2017 at 1:28:47 AM UTC+2, Arthur O'Dwyer wrote:
>
> On Monday, June 19, 2017 at 6:42:03 AM UTC-7, Jakob Riedle wrote:
>>
>> Hello Folks,
>>
> =20
>
>> What my Idea here was is: what if we relax the value constraint with aut=
o=20
>> (this makes the value constraint reusable and overloadable), see
>>
>> template<auto N> concept bool Even =3D N % 2 =3D=3D 0;
>>
>> =20
>>
>> and mention an explicit type (or auto, depending on what we want) at the=
=20
>> point of use?
>>
>> template<Even int N> void f() {
>>
>> constexpr Even int X =3D N;
>>
>> }
>>
>> This would turn out rather intuitive, doesn=E2=80=99t it?
>>
>> =20
>>
>> =3D> Outcome: Rather than perceiving Even as a constrained Datatype, we=
=20
>> can perceive it as a property that we can enforce on the domain of a giv=
en=20
>> type.
>>
>> But hey! This is nothing but a contract!
>>
>> =20
>>
>> *[Start note **=E2=80=93*
>>
>> In Analogy to the above example:
>>
>> template<Regular typename T> struct{};
>>
>> This now makes pretty clear what=E2=80=99s going on here.
>>
>> *-- End note]*
>>
>>
> *This strikes me as a great idea.* I really hope people see this!
>
> I'm skeptical of the perceived similarity between Concepts and Contracts=
=20
> (and I'm skeptical of Contracts in general), but this syntactic idea of=
=20
> putting "typename" or "int" or "auto" after the use of a concept's name=
=20
> seems like a very nice way to keep the human reader "in the loop" about=
=20
> what the code is actually trying to accomplish.
>
> Some people (including my former self) would say that "typename" and=20
> "auto" are themselves concepts in a sense: "auto" is the placeholder for=
=20
> "any value whose type satisfies <the trivial/top concept>" and "typename"=
=20
> is the placeholder for "any type satisfying <the trivial/top concept>". B=
ut=20
> with a small syntactic suggestion, you've actually made it really hard fo=
r=20
> me to see why I ever thought that was a compelling idea. The alternative=
=E2=80=94=20
> that "auto" is a word *meaning* "this thing here is (has) a value" and=20
> "typename" is a word *meaning* "this thing here is a type" =E2=80=94 is n=
ot only=20
> much easier to read, but strictly in keeping with the way C++11-and-later=
=20
> has always used those words. It seems like a good idea.
>
> =E2=80=93Arthur
>
I agree with that, this fix too small insincerity with using terse syntax,=
=20
because `Concept A` mean different thing in context of template params and=
=20
function arguments.
With this it will always mean "define object/argument A that fulfills=20
concept" and in template we will use `Concept typename T` to define type.
This bring another thought, why do not allow use this new syntax in type=20
alias declaration or other similar contexts? something like that:
template<T>
using Z =3D ConceptA typename T::H<int>;
Now `Z` work only if `T::H<int>` fulfills `ConceptA`.
Overall concepts would become prefixes for `typename` keyword.
--=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/25f508be-8b71-4b2c-b9c7-3ef88573ba25%40isocpp.or=
g.
------=_Part_4420_1684869087.1497989668512
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, June 20, 2017 at 1:28:47 AM UTC+2, Art=
hur O'Dwyer 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 Monday, June 19, 2017 at 6:42:03 AM UTC-7, Jakob Riedle 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>Hello Folks,</=
div></div></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">What my Idea here was i=
s: what if
we relax the value constraint with auto (this makes the value constraint
reusable and <span style=3D"color:red">overloadable</span>), see</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<auto
N> concept bool Even =3D N % 2 =3D=3D 0;</span><span style=3D"font-size:=
10.0pt;font-family:"Source Code Pro Medium""></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">and mention an explicit=
type (or
auto, depending on what we want) at the point of use?</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<Even
<span style=3D"color:red">int </span>N> void f() {</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><spa=
n style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium";=
background:silver">constexpr Even <span style=3D"color:red">int </span>X =
=3D N;</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
}</span><span style=3D"font-size:10.0pt;font-family:"Source Code Pro M=
edium""></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This would turn out rat=
her
intuitive, doesn<span style=3D"font-family:"Times New Roman",seri=
f">=E2=80=99</span>t it?</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=3D> Outcome: Rather=
than
perceiving <span style=3D"font-size:10.0pt;font-family:"Source Code Pr=
o Medium";background:silver">Even</span><span style=3D"font-size:10.0p=
t">
</span>as a constrained Datatype, we can perceive it as a property that we =
can
enforce on the domain of a given type.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">But hey! This is nothin=
g but a
contract!</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><i>[Start note </i><i><=
span style=3D"font-family:"Times New Roman",serif">=E2=80=93</spa=
n></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">In Analogy to the above=
example:</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<Regular
<span style=3D"color:red">typename </span>T> struct{};</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This now makes pretty c=
lear what<span style=3D"font-family:"Times New Roman",serif">=E2=
=80=99</span>s going on here.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><i>-- End note]</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"></p></div></blockquote>=
<div><br></div><div><b>This strikes me as a <i>great</i> idea.</b> I really=
hope people see this!</div><div><br></div><div>I'm skeptical of the pe=
rceived similarity between Concepts and Contracts (and I'm skeptical of=
Contracts in general), but this syntactic idea of putting "typename&q=
uot; or "int" or "auto" after the use of a concept'=
s name seems like a very nice way to keep the human reader "in the loo=
p" about what the code is actually trying to accomplish.</div><div><br=
></div><div>Some people (including my former self) would say that "typ=
ename" and "auto" are themselves concepts in a sense: "=
auto" is the placeholder for "any value whose type satisfies <=
the trivial/top concept>" and "typename" is the placehold=
er for "any type satisfying <the trivial/top concept>". But=
with a small syntactic suggestion, you've actually made it really hard=
for me to see why I ever thought that was a compelling idea. =C2=A0The alt=
ernative =E2=80=94 that "auto" is a word <i>meaning</i> "thi=
s thing here is (has) a value" and "typename" is a word <i>m=
eaning</i> "this thing here is a type" =E2=80=94 is not only much=
easier to read, but strictly in keeping with the way C++11-and-later has a=
lways used those words. =C2=A0It seems like a good idea.</div><div><br></di=
v><div>=E2=80=93Arthur</div></div></blockquote><div><br>I agree with that, =
this fix too small insincerity with using terse syntax, because `Concept A`=
=C2=A0 mean different thing in context of template params and function argu=
ments.<br>With this it will always mean "define object/argument A that=
<span id=3D"result_box" class=3D"short_text" lang=3D"en"><span class=3D"">=
fulfills concept</span></span>" and in template we will use `Concept t=
ypename T` to define type.<br><br>This bring another thought, why do not al=
low use this new syntax in type alias declaration or other similar contexts=
? something like that:<br><br><div style=3D"background-color: rgb(250, 250,=
250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">></span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">usi=
ng</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> Z </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">ConceptA</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">H</span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify"><int></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span></div></code></div><br>Now `Z` work only if `T::H<int>` <sp=
an id=3D"result_box" class=3D"short_text" lang=3D"en"><span class=3D"">fulf=
ills `ConceptA`.<br><br>Overall concepts would become prefixes for `typenam=
e` keyword.<br></span></span><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/25f508be-8b71-4b2c-b9c7-3ef88573ba25%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/25f508be-8b71-4b2c-b9c7-3ef88573ba25=
%40isocpp.org</a>.<br />
------=_Part_4420_1684869087.1497989668512--
------=_Part_4419_1000143616.1497989668512--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 20 Jun 2017 14:45:30 -0700 (PDT)
Raw View
------=_Part_122_885684630.1497995130886
Content-Type: multipart/alternative;
boundary="----=_Part_123_1706804997.1497995130886"
------=_Part_123_1706804997.1497995130886
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
1. Using a concept as a template parameter the way you indicate needs a use=
=20
case to convince me. I think this will be hard to find as the idea of a=20
concept is to define what the actual type has to be capable of to be=20
possible to use. Being able to parameterize this would mean that the code=
=20
of the function would have to adapt to the _actual concept_ by basically=20
morphing the source code. Isn't this just the opposite of the idea of=20
overloading template functions based on which concepts the actual template=
=20
parameters fulfill. Thus the code of the two overloads is typically=20
different to handle the different abilities of the actual types of the=20
parameters.
When it comes to class templates this becomes more interesting as we=20
currently can't overload them. With concepts available it seems far more=20
reasonable to overload template classes (although there is already a bit=20
strange that you can't overload on the number of template parameters). I=20
guess the current reasoning is to build on the partial specialization=20
functionality and allow class templates to be specialized on the concept=20
level:
template<typename T> class my_template {
// base implementation
};
template<Sortable T> class my_template<T> {
// optimized implementation using the sortedness of T
};
I don't recall having seen such an example, but I assume this is how it is=
=20
supposed to work.
2. I didn't know that concepts for non-type template parameters were=20
included in concepts lite. If they are I can imagine that they have not=20
been widely explored... but maybe this is just something that P0355 authors=
=20
found plausible.
You write
Does it refer to a type that is Even? Does it refer to a type =E2=80=98Even=
=E2=80=99, does=20
it refer to an Even value (if yes, what type?) and how do we know, Even is=
=20
a concept? We don=E2=80=99t.
regarding this example:
*template<int N> concept bool Even =3D N % 2 =3D=3D 0;*
*This seems quite reasonable (if perhaps not all that useful):*
*template<Even N> void f() {*
*constexpr Even X =3D N;*
*}*
I think it is fairly clear that N is a int template parameter. The contents=
=20
of the {} seems malformed, as Even is not a type. Shouldn't it be=20
"constexpr int X =3D N;" ?
This said, your suggested syntax with the concept as a prefix of a type or=
=20
typename has something going for it as it clearly notifies the reader that=
=20
there is a concept involved without having to find the declaration. Before=
=20
going much further with this idea we must contemplate if this syntax would=
=20
work in all places where concepts can be mentioned, and whether it would=20
bloat the code too much to have to type typename in even more places than=
=20
we currently do.
I also find your analogy between concepts and contracts an interesting=20
thought. How about using the new requires keyword on the contract level=20
also?
template<typename T> T div_by_two(T x) requires Integral<T> // Compile=
=20
time requirement
{
requires x & 1 =3D=3D 0; // runtime requirement. May be checked by st=
atic=20
analyzers and/or compilers, probably depending on buid mode.
return x / 2;
}
Depending on the position and contents of the requires statement(?) it=20
would act as an invariant, precondition or postcondition. I guess you could=
=20
view this as conceptual requirements just being constexpr contracts=20
possible to evaluate at compile time, but this would make it hard to=20
explain why concept overloading is possible. Inverting that thought would=
=20
end up with more functional programming:
int fac(int x) requires x =3D=3D 0 // Runtime contract.
{=20
return 1;
}
int fac(int x)
{
return fac(x - 1) * x;
}
This does not seem that easy to implement, though. Probably a can of worms=
=20
not worth opening...
--=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/56bb80fc-cb3d-439e-9746-455df5ddb2d3%40isocpp.or=
g.
------=_Part_123_1706804997.1497995130886
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>1. Using a concept as a template parameter the way yo=
u indicate needs a use case to convince me. I think this will be hard to fi=
nd as the idea of a concept is to define what the actual type has to be cap=
able of to be possible to use. Being able to parameterize this would mean t=
hat the code of the function would have to adapt to the _actual concept_ by=
basically morphing the source code. Isn't this just the opposite of th=
e idea of overloading template functions based on which concepts the actual=
template parameters fulfill. Thus the code of the two overloads is typical=
ly different to handle the different abilities of the actual types of the p=
arameters.</div><div><br></div><div>When it comes to class templates this b=
ecomes more interesting as we currently can't overload them. With conce=
pts available it seems far more reasonable to overload template classes (al=
though there is already a bit strange that you can't overload on the nu=
mber of template parameters). I guess the current reasoning is to build on =
the partial specialization functionality and allow class templates to be sp=
ecialized on the concept level:</div><div><br></div><div>template<typena=
me T> class my_template {</div><div>=C2=A0 =C2=A0// base implementation<=
/div><div>};</div><div><br></div><div>template<Sortable T> class my_t=
emplate<T> {</div><div>=C2=A0 =C2=A0// optimized implementation using=
the sortedness of T</div><div>};</div><div><br></div><div>I don't reca=
ll having seen such an example, but I assume this is how it is supposed to =
work.</div><div><br></div>2. I didn't know that concepts for non-type t=
emplate parameters were included in concepts lite. If they are I can imagin=
e that they have not been widely explored... but maybe this is just somethi=
ng that P0355 authors found plausible.<div><br></div><div>You write<div><br=
></div><div><p class=3D"MsoNormal" style=3D"line-height: normal;">Does it r=
efer to a type that is Even? Does it refer to a type=C2=A0<span style=3D"fo=
nt-family: "Times New Roman", serif;">=E2=80=98</span>Even<span s=
tyle=3D"font-family: "Times New Roman", serif;">=E2=80=99</span>,=
does it refer to an Even value (if yes, what type?) and how do we know, Ev=
en is a concept? We don<span style=3D"font-family: "Times New Roman&qu=
ot;, serif;">=E2=80=99</span>t.</p></div><div><br></div><div>regarding this=
example:</div><div><br></div><div><div class=3D"prettyprint" style=3D"back=
ground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-=
style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><p class=3D"MsoNormal" style=3D"lin=
e-height: normal; font-family: Arial, Helvetica, sans-serif; background-col=
or: rgb(255, 255, 255);"><i><span style=3D"font-size: 10pt; font-family: &q=
uot;Source Code Pro Medium"; background: silver;"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> N</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>concept</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">Even</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> N </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">%</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">2</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span></span></i><i><span style=3D"=
font-size: 10pt; font-family: "Source Code Pro Medium";"></span><=
/i></p><p class=3D"MsoNormal" style=3D"line-height: normal; font-family: Ar=
ial, Helvetica, sans-serif; background-color: rgb(255, 255, 255);"><i><span=
style=3D"color: #606;" class=3D"styled-by-prettify">This</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> seems quite reasonable </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> perhaps </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">not</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> all that useful</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">):</span></i></p><p class=3D"MsoN=
ormal" style=3D"line-height: normal; font-family: Arial, Helvetica, sans-se=
rif; background-color: rgb(255, 255, 255);"><i><span style=3D"font-size: 10=
pt; font-family: "Source Code Pro Medium"; background: silver;"><=
span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">Even</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> N</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span></s=
pan></i></p><p class=3D"MsoNormal" style=3D"line-height: normal; font-famil=
y: Arial, Helvetica, sans-serif; background-color: rgb(255, 255, 255); text=
-indent: 36pt;"><i><span style=3D"font-size: 10pt; font-family: "Sourc=
e Code Pro Medium"; background: silver;"><span style=3D"color: #008;" =
class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Even</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> X </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
N</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
/span></i></p><p class=3D"MsoNormal" style=3D"line-height: normal; font-fam=
ily: Arial, Helvetica, sans-serif; background-color: rgb(255, 255, 255);"><=
i><span style=3D"font-size: 10pt; font-family: "Source Code Pro Medium=
"; background: silver;"><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">}</span></span></i><i><span style=3D"font-size: 10pt; font-fami=
ly: "Source Code Pro Medium";"></span></i></p><div><i><span style=
=3D"font-size: 10pt; font-family: "Source Code Pro Medium"; backg=
round: silver;"><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span></span></i></div></div></code></div><br>I think it is fairly clea=
r that N is a int template parameter. The contents of the {} seems malforme=
d, as Even is not a type. Shouldn't it be "constexpr int X =3D N;&=
quot; ?</div><div><br></div><div>This said, your suggested syntax with the =
concept as a prefix of a type or typename has something going for it as it =
clearly notifies the reader that there is a concept involved without having=
to find the declaration. Before going much further with this idea we must =
contemplate if this syntax would work in all places where concepts can be m=
entioned, and whether it would bloat the code too much to have to type=C2=
=A0<span style=3D"color: rgb(0, 0, 136); background-color: rgb(250, 250, 25=
0);">typename=C2=A0</span>in even more places than we currently do.</div></=
div><div><br></div><div>I also find your analogy between concepts and contr=
acts an interesting thought. How about using the new requires keyword on th=
e contract level also?</div><div><br></div><div>template<typename T> =
T div_by_two(T x) requires Integral<T> =C2=A0 =C2=A0// Compile time r=
equirement</div><div>{</div><div>=C2=A0 =C2=A0 requires x & 1 =3D=3D 0;=
=C2=A0 // runtime requirement. May be checked by static analyzers and/or c=
ompilers, probably depending on buid mode.</div><div>=C2=A0 =C2=A0 return x=
/ 2;</div><div>}</div><div><br></div><div>Depending on the position and co=
ntents of the requires statement(?) it would act as an invariant, precondit=
ion or postcondition. I guess you could view this as conceptual requirement=
s just being constexpr contracts possible to evaluate at compile time, but =
this would make it hard to explain why concept overloading is possible. Inv=
erting that thought would end up with more functional programming:</div><di=
v><br></div><div>int fac(int x) requires x =3D=3D 0 =C2=A0 =C2=A0// Runtime=
contract.</div><div>{=C2=A0</div><div>=C2=A0 =C2=A0return 1;</div><div>}</=
div><div><br></div><div>int fac(int x)</div><div>{</div><div>=C2=A0 =C2=A0r=
eturn fac(x - 1) * x;</div><div>}</div><div><br></div><div>This does not se=
em that easy to implement, though. Probably a can of worms not worth openin=
g...</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/56bb80fc-cb3d-439e-9746-455df5ddb2d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/56bb80fc-cb3d-439e-9746-455df5ddb2d3=
%40isocpp.org</a>.<br />
------=_Part_123_1706804997.1497995130886--
------=_Part_122_885684630.1497995130886--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 20 Jun 2017 15:10:40 -0700
Raw View
--94eb2c0b93e4db09cf05526b8613
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 20 June 2017 at 14:45, Bengt Gustafsson <bengt.gustafsson@beamways.com>
wrote:
> 1. Using a concept as a template parameter the way you indicate needs a
> use case to convince me. I think this will be hard to find as the idea of=
a
> concept is to define what the actual type has to be capable of to be
> possible to use. Being able to parameterize this would mean that the code
> of the function would have to adapt to the _actual concept_ by basically
> morphing the source code. Isn't this just the opposite of the idea of
> overloading template functions based on which concepts the actual templat=
e
> parameters fulfill. Thus the code of the two overloads is typically
> different to handle the different abilities of the actual types of the
> parameters.
>
> When it comes to class templates this becomes more interesting as we
> currently can't overload them. With concepts available it seems far more
> reasonable to overload template classes (although there is already a bit
> strange that you can't overload on the number of template parameters). I
> guess the current reasoning is to build on the partial specialization
> functionality and allow class templates to be specialized on the concept
> level:
>
> template<typename T> class my_template {
> // base implementation
> };
>
> template<Sortable T> class my_template<T> {
> // optimized implementation using the sortedness of T
> };
>
> I don't recall having seen such an example, but I assume this is how it i=
s
> supposed to work.
>
> 2. I didn't know that concepts for non-type template parameters were
> included in concepts lite. If they are I can imagine that they have not
> been widely explored... but maybe this is just something that P0355 autho=
rs
> found plausible.
>
> You write
>
> Does it refer to a type that is Even? Does it refer to a type =E2=80=98Ev=
en=E2=80=99,
> does it refer to an Even value (if yes, what type?) and how do we know,
> Even is a concept? We don=E2=80=99t.
>
> regarding this example:
>
> *template<int N> concept bool Even =3D N % 2 =3D=3D 0;*
>
> *This seems quite reasonable (if perhaps not all that useful):*
>
> *template<Even N> void f() {*
>
> *constexpr Even X =3D N;*
>
> *}*
>
>
> I think it is fairly clear that N is a int template parameter. The
> contents of the {} seems malformed, as Even is not a type. Shouldn't it b=
e
> "constexpr int X =3D N;" ?
>
No, that's exactly the point: in the template parameter list, Even *is*
acting as a type. It would be logical that you could use it in the same
semantic role elsewhere too.
I find the suggestion here very interesting, and it's made me realise
something that seems fundamental: concepts are adjectives, not nouns.
There's no such thing as a Regular, or an EqualityComparable, but there
clearly are Regular types and EqualityComparable types. Based on that, it
makes perfect sense to me that we should be able to write
void f(Regular auto x);
or even
void f(Regular EqualityComparable InputIterator auto x);
Likewise, it makes sense to be able to write
template<Regular EqualityComparable InputIterator typename T>
void f(T x);
and we can then easily distinguish between:
template<Integral typename T>
and
template<Integral auto T>
(where the former takes an Integral type and the latter takes a value of an
Integral type), and likewise we could write:
template<Even int N> void f() {
constexpr Even int X =3D 3 * N;
}
If desirable, the "natural notation" could then be obtained by omitting the
"auto" in a terse function template declaration:
void f(Regular x); // implicitly means "Regular auto x"
.... in much the same way that we can leave out the "int" in "unsigned long
x".
This said, your suggested syntax with the concept as a prefix of a type or
> typename has something going for it as it clearly notifies the reader tha=
t
> there is a concept involved without having to find the declaration. Befor=
e
> going much further with this idea we must contemplate if this syntax woul=
d
> work in all places where concepts can be mentioned, and whether it would
> bloat the code too much to have to type typename in even more places than
> we currently do.
>
> I also find your analogy between concepts and contracts an interesting
> thought. How about using the new requires keyword on the contract level
> also?
>
> template<typename T> T div_by_two(T x) requires Integral<T> // Compile
> time requirement
> {
> requires x & 1 =3D=3D 0; // runtime requirement. May be checked by
> static analyzers and/or compilers, probably depending on buid mode.
> return x / 2;
> }
>
> Depending on the position and contents of the requires statement(?) it
> would act as an invariant, precondition or postcondition. I guess you cou=
ld
> view this as conceptual requirements just being constexpr contracts
> possible to evaluate at compile time, but this would make it hard to
> explain why concept overloading is possible. Inverting that thought would
> end up with more functional programming:
>
> int fac(int x) requires x =3D=3D 0 // Runtime contract.
> {
> return 1;
> }
>
> int fac(int x)
> {
> return fac(x - 1) * x;
> }
>
> This does not seem that easy to implement, though. Probably a can of worm=
s
> not worth opening...
>
> --
> 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/56bb80fc-cb3d-439e-
> 9746-455df5ddb2d3%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56bb80fc-cb=
3d-439e-9746-455df5ddb2d3%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAOfiQqm%2B-S9zQNMUC2pyR_88T-Gzu7fi9Zq1zYwcF%3D3=
%2B0eAOmQ%40mail.gmail.com.
--94eb2c0b93e4db09cf05526b8613
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
0 June 2017 at 14:45, Bengt Gustafsson <span dir=3D"ltr"><<a href=3D"mai=
lto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafsson@beamw=
ays.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>1. Using a concept as a template parameter the way you indicate =
needs a use case to convince me. I think this will be hard to find as the i=
dea of a concept is to define what the actual type has to be capable of to =
be possible to use. Being able to parameterize this would mean that the cod=
e of the function would have to adapt to the _actual concept_ by basically =
morphing the source code. Isn't this just the opposite of the idea of o=
verloading template functions based on which concepts the actual template p=
arameters fulfill. Thus the code of the two overloads is typically differen=
t to handle the different abilities of the actual types of the parameters.<=
/div><div><br></div><div>When it comes to class templates this becomes more=
interesting as we currently can't overload them. With concepts availab=
le it seems far more reasonable to overload template classes (although ther=
e is already a bit strange that you can't overload on the number of tem=
plate parameters). I guess the current reasoning is to build on the partial=
specialization functionality and allow class templates to be specialized o=
n the concept level:</div><div><br></div><div>template<typename T> cl=
ass my_template {</div><div>=C2=A0 =C2=A0// base implementation</div><div>}=
;</div><div><br></div><div>template<Sortable T> class my_template<=
T> {</div><div>=C2=A0 =C2=A0// optimized implementation using the sorted=
ness of T</div><div>};</div><div><br></div><div>I don't recall having s=
een such an example, but I assume this is how it is supposed to work.</div>=
<div><br></div>2. I didn't know that concepts for non-type template par=
ameters were included in concepts lite. If they are I can imagine that they=
have not been widely explored... but maybe this is just something that P03=
55 authors found plausible.<div><br></div><div>You write<span class=3D""><d=
iv><br></div><div><p class=3D"MsoNormal" style=3D"line-height:normal">Does =
it refer to a type that is Even? Does it refer to a type=C2=A0<span style=
=3D"font-family:"Times New Roman",serif">=E2=80=98</span>Even<spa=
n style=3D"font-family:"Times New Roman",serif">=E2=80=99</span>,=
does it refer to an Even value (if yes, what type?) and how do we know, Ev=
en is a concept? We don<span style=3D"font-family:"Times New Roman&quo=
t;,serif">=E2=80=99</span>t.</p></div><div><br></div></span><div>regarding =
this example:</div><div><br></div><div><div class=3D"m_-416922115208636165p=
rettyprint" style=3D"background-color:rgb(250,250,250);border-color:rgb(187=
,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code c=
lass=3D"m_-416922115208636165prettyprint"><div class=3D"m_-4169221152086361=
65subprettyprint"><span class=3D""><p class=3D"MsoNormal" style=3D"line-hei=
ght:normal;font-family:Arial,Helvetica,sans-serif;background-color:rgb(255,=
255,255)"><i><span style=3D"font-size:10pt;font-family:"Source Code Pr=
o Medium";background:silver"><span style=3D"color:#008" class=3D"m_-41=
6922115208636165styled-by-prettify">template</span><span style=3D"color:#66=
0" class=3D"m_-416922115208636165styled-by-prettify"><</span><span style=
=3D"color:#008" class=3D"m_-416922115208636165styled-by-prettify">int</span=
><span style=3D"color:#000" class=3D"m_-416922115208636165styled-by-prettif=
y"> N</span><span style=3D"color:#660" class=3D"m_-416922115208636165styled=
-by-prettify">></span><span style=3D"color:#000" class=3D"m_-41692211520=
8636165styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_-4=
16922115208636165styled-by-prettify">concept</span><span style=3D"color:#00=
0" class=3D"m_-416922115208636165styled-by-prettify"> </span><span style=3D=
"color:#008" class=3D"m_-416922115208636165styled-by-prettify">bool</span><=
span style=3D"color:#000" class=3D"m_-416922115208636165styled-by-prettify"=
> </span><span style=3D"color:#606" class=3D"m_-416922115208636165styled-by=
-prettify">Even</span><span style=3D"color:#000" class=3D"m_-41692211520863=
6165styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_-4169=
22115208636165styled-by-prettify">=3D</span><span style=3D"color:#000" clas=
s=3D"m_-416922115208636165styled-by-prettify"> N </span><span style=3D"colo=
r:#660" class=3D"m_-416922115208636165styled-by-prettify">%</span><span sty=
le=3D"color:#000" class=3D"m_-416922115208636165styled-by-prettify"> </span=
><span style=3D"color:#066" class=3D"m_-416922115208636165styled-by-prettif=
y">2</span><span style=3D"color:#000" class=3D"m_-416922115208636165styled-=
by-prettify"> </span><span style=3D"color:#660" class=3D"m_-416922115208636=
165styled-by-prettify">=3D=3D</span><span style=3D"color:#000" class=3D"m_-=
416922115208636165styled-by-prettify"> </span><span style=3D"color:#066" cl=
ass=3D"m_-416922115208636165styled-by-prettify">0</span><span style=3D"colo=
r:#660" class=3D"m_-416922115208636165styled-by-prettify">;</span></span></=
i><i><span style=3D"font-size:10pt;font-family:"Source Code Pro Medium=
""></span></i></p><p class=3D"MsoNormal" style=3D"line-height:normal;f=
ont-family:Arial,Helvetica,sans-serif;background-color:rgb(255,255,255)"><i=
><span style=3D"color:#606" class=3D"m_-416922115208636165styled-by-prettif=
y">This</span><span style=3D"color:#000" class=3D"m_-416922115208636165styl=
ed-by-prettify"> seems quite reasonable </span><span style=3D"color:#660" c=
lass=3D"m_-416922115208636165styled-by-prettify">(</span><span style=3D"col=
or:#008" class=3D"m_-416922115208636165styled-by-prettify">if</span><span s=
tyle=3D"color:#000" class=3D"m_-416922115208636165styled-by-prettify"> perh=
aps </span><span style=3D"color:#008" class=3D"m_-416922115208636165styled-=
by-prettify">not</span><span style=3D"color:#000" class=3D"m_-4169221152086=
36165styled-by-prettify"> all that useful</span><span style=3D"color:#660" =
class=3D"m_-416922115208636165styled-by-prettify">):</span></i></p></span><=
p class=3D"MsoNormal" style=3D"line-height:normal;font-family:Arial,Helveti=
ca,sans-serif;background-color:rgb(255,255,255)"><i><span style=3D"font-siz=
e:10pt;font-family:"Source Code Pro Medium";background:silver"><s=
pan style=3D"color:#008" class=3D"m_-416922115208636165styled-by-prettify">=
template</span><span style=3D"color:#660" class=3D"m_-416922115208636165sty=
led-by-prettify"><</span><span style=3D"color:#606" class=3D"m_-41692211=
5208636165styled-by-prettify">Even</span><span style=3D"color:#000" class=
=3D"m_-416922115208636165styled-by-prettify"> N</span><span style=3D"color:=
#660" class=3D"m_-416922115208636165styled-by-prettify">></span><span st=
yle=3D"color:#000" class=3D"m_-416922115208636165styled-by-prettify"> </spa=
n><span style=3D"color:#008" class=3D"m_-416922115208636165styled-by-pretti=
fy">void</span><span style=3D"color:#000" class=3D"m_-416922115208636165sty=
led-by-prettify"> f</span><span style=3D"color:#660" class=3D"m_-4169221152=
08636165styled-by-prettify">()</span><span style=3D"color:#000" class=3D"m_=
-416922115208636165styled-by-prettify"> </span><span style=3D"color:#660" c=
lass=3D"m_-416922115208636165styled-by-prettify">{</span></span></i></p><p =
class=3D"MsoNormal" style=3D"line-height:normal;font-family:Arial,Helvetica=
,sans-serif;background-color:rgb(255,255,255);text-indent:36pt"><i><span st=
yle=3D"font-size:10pt;font-family:"Source Code Pro Medium";backgr=
ound:silver"><span style=3D"color:#008" class=3D"m_-416922115208636165style=
d-by-prettify">constexpr</span><span style=3D"color:#000" class=3D"m_-41692=
2115208636165styled-by-prettify"> </span><span style=3D"color:#606" class=
=3D"m_-416922115208636165styled-by-prettify">Even</span><span style=3D"colo=
r:#000" class=3D"m_-416922115208636165styled-by-prettify"> X </span><span s=
tyle=3D"color:#660" class=3D"m_-416922115208636165styled-by-prettify">=3D</=
span><span style=3D"color:#000" class=3D"m_-416922115208636165styled-by-pre=
ttify"> N</span><span style=3D"color:#660" class=3D"m_-416922115208636165st=
yled-by-prettify">;</span></span></i></p><p class=3D"MsoNormal" style=3D"li=
ne-height:normal;font-family:Arial,Helvetica,sans-serif;background-color:rg=
b(255,255,255)"><i><span style=3D"font-size:10pt;font-family:"Source C=
ode Pro Medium";background:silver"><span style=3D"color:#660" class=3D=
"m_-416922115208636165styled-by-prettify">}</span></span></i><i><span style=
=3D"font-size:10pt;font-family:"Source Code Pro Medium""></span><=
/i></p><div><i><span style=3D"font-size:10pt;font-family:"Source Code =
Pro Medium";background:silver"><span style=3D"color:#000" class=3D"m_-=
416922115208636165styled-by-prettify"><br></span></span></i></div></div></c=
ode></div><br>I think it is fairly clear that N is a int template parameter=
.. The contents of the {} seems malformed, as Even is not a type. Shouldn=
9;t it be "constexpr int X =3D N;" ?</div></div></div></blockquot=
e><div><br></div><div>No, that's exactly the point: in the template par=
ameter list, Even *is* acting as a type. It would be logical that you could=
use it in the same semantic role elsewhere too.</div><div><br></div><div><=
br></div><div>I find the suggestion here very interesting, and it's mad=
e me realise something that seems fundamental: concepts are adjectives, not=
nouns. There's no such thing as a Regular, or an EqualityComparable, b=
ut there clearly are Regular types and EqualityComparable types. Based on t=
hat, it makes perfect sense to me that we should be able to write</div><div=
><br></div><div>void f(Regular auto x);</div><div><br></div><div>or even</d=
iv><div><br></div><div>void f(Regular EqualityComparable InputIterator auto=
x);</div><div><br></div><div>Likewise, it makes sense to be able to write<=
/div><div><br></div><div>template<Regular EqualityComparable InputIterat=
or typename T></div><div>void f(T x);</div><div><br></div><div>and we ca=
n then easily distinguish between:</div><div><br></div><div>template<Int=
egral typename T></div><div><br></div><div>and</div><div><br></div><div>=
template<Integral auto T></div><div><br></div><div>(where the former =
takes an Integral type and the latter takes a value of an Integral type), a=
nd likewise we could write:</div><div><br></div><div>template<Even int N=
> void f() {</div><div>=C2=A0 constexpr Even int X =3D 3 * N;</div><div>=
}</div><div><br></div><div>If desirable, the "natural notation" c=
ould then be obtained by omitting the "auto" in a terse function =
template declaration:</div><div><br></div><div>void f(Regular x); // implic=
itly means "Regular auto x"</div><div><br></div><div>... in much =
the same way that we can leave out the "int" in "unsigned lo=
ng x".</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div><div>This said, your suggested syntax with the concept as a prefi=
x of a type or typename has something going for it as it clearly notifies t=
he reader that there is a concept involved without having to find the decla=
ration. Before going much further with this idea we must contemplate if thi=
s syntax would work in all places where concepts can be mentioned, and whet=
her it would bloat the code too much to have to type=C2=A0<span style=3D"co=
lor:rgb(0,0,136);background-color:rgb(250,250,250)">typename=C2=A0</span>in=
even more places than we currently do.</div></div><div><br></div><div>I al=
so find your analogy between concepts and contracts an interesting thought.=
How about using the new requires keyword on the contract level also?</div>=
<div><br></div><div>template<typename T> T div_by_two(T x) requires I=
ntegral<T> =C2=A0 =C2=A0// Compile time requirement</div><div>{</div>=
<div>=C2=A0 =C2=A0 requires x & 1 =3D=3D 0; =C2=A0 // runtime requireme=
nt. May be checked by static analyzers and/or compilers, probably depending=
on buid mode.</div><div>=C2=A0 =C2=A0 return x / 2;</div><div>}</div><div>=
<br></div><div>Depending on the position and contents of the requires state=
ment(?) it would act as an invariant, precondition or postcondition. I gues=
s you could view this as conceptual requirements just being constexpr contr=
acts possible to evaluate at compile time, but this would make it hard to e=
xplain why concept overloading is possible. Inverting that thought would en=
d up with more functional programming:</div><div><br></div><div>int fac(int=
x) requires x =3D=3D 0 =C2=A0 =C2=A0// Runtime contract.</div><div>{=C2=A0=
</div><div>=C2=A0 =C2=A0return 1;</div><div>}</div><div><br></div><div>int =
fac(int x)</div><div>{</div><div>=C2=A0 =C2=A0return fac(x - 1) * x;</div><=
div>}</div><div><br></div><div>This does not seem that easy to implement, t=
hough. Probably a can of worms not worth opening...</div></div><span class=
=3D"">
<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/56bb80fc-cb3d-439e-9746-455df5ddb2d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/56bb=
80fc-cb3d-439e-<wbr>9746-455df5ddb2d3%40isocpp.org</a><wbr>.<br>
</blockquote></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/CAOfiQqm%2B-S9zQNMUC2pyR_88T-Gzu7fi9Z=
q1zYwcF%3D3%2B0eAOmQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm%2B=
-S9zQNMUC2pyR_88T-Gzu7fi9Zq1zYwcF%3D3%2B0eAOmQ%40mail.gmail.com</a>.<br />
--94eb2c0b93e4db09cf05526b8613--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 20 Jun 2017 16:19:32 -0700 (PDT)
Raw View
------=_Part_4609_1770402451.1498000772822
Content-Type: multipart/alternative;
boundary="----=_Part_4610_1350722468.1498000772823"
------=_Part_4610_1350722468.1498000772823
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Compare these:
*template<int N> concept bool Even =3D N % 2 =3D=3D 0;*
*This seems quite reasonable (if perhaps not all that useful):*
*template<Even N> void f() {*
*constexpr Even X =3D N;*
*}*
*template<typename N> concept bool EqualComparable =3D ... ;*
*This seems quite reasonable (if perhaps not all that useful):*
*template<EqualComparable N> void f() {*
*constexpr N my_value;*
*}*
To me it is pretty clear that in the second case N is bound to a type=20
fulfilling EqualComparable concept, while the EqualComparable identifier=20
does not carry any new meaning inside the function compared to outside it.
Thus it seems very strange that the name of the int-valued concept Even=20
should carry special meaning (as an alias of int, maybe?) inside the=20
function. What if you wrote as below, this seems very strange to allow as=
=20
we immediately break the promise made by using Even as a type.
*emplate<int N> concept bool Even =3D N % 2 =3D=3D 0;*
*This seems quite reasonable (if perhaps not all that useful):*
*template<Even N> void f() {*
*Even x =3D N;*
*x++;*
*}*
*You posed this example which shows the same problem, where the 'Even'=20
value is actually odd, oddly enough:*
template<Even int N> void f() {
constexpr Even int X =3D 3 * N;
}
Unless this is of course a contrived way of stating that N must be 0...
I really like your idea about viewing concepts as adjectives though. It=20
seems very logical to be able to stack multiple adjectives on a type and=20
maybe on values too:
// A function taking an even constant value of some integral arithmetic=20
type, binding the value to the small even number N and the type to=20
decltype(N).
template<Arithmetic Integral auto Small Even N> f();
Well that could be taking it too far, maybe the type constraints should be=
=20
on the value constraint definition:
template<Arithmetic Integral auto N> concept Even =3D N % 2 =3D=3D 0;
No, also strange...
Lots of unfinished thoughs, but may be worth some more experimentation and=
=20
thinking about what the semantics really should be.
m=C3=A5ndag 19 juni 2017 kl. 15:42:03 UTC+2 skrev Jakob Riedle:
>
> Hello Folks,
>
> Reading P0587R0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0587r0.pdf> (th=
at=20
> talks about in what way Concepts might have to be refined),
> two questions came to my mind, that have not been adressed by any Papers =
I=20
> read about Concepts in C++:
>
>
> 1. *Allowing concepts to be passed as template parameters.*=20
>
> A potential syntax (as touched in P0587R0) has to take that into account=
=20
> that, If we want to allow *concepts to be passed as template parameters,*
>
> we don=E2=80=99t want to ambiguate this case with *constraining template=
=20
> parameters with concepts*.
>
> =20
>
> With Concepts Lite TS, I would intuitively write a template taking a=20
> concept as template parameter as:
>
> template<
>
> template<typename> concept MyConstraint
>
> > struct WhateverClass{
>
> template<MyConstraint T> // Use the passed concept here just as =E2=80=
=9Cnormal=E2=80=9D
>
> WhateverClass(T arg){ /* =E2=80=A6 */ }
>
> };
>
> This is not (yet) allowed but I did not find anyone that even considered=
=20
> it.
>
> Hopefully, I have not missed something.
>
> =20
>
> =20
>
> 1. *How do we make clear if a concept is a value or type constraint?*=
=20
>
> Cited from the paper:
>
>
> *Conversely, given:*
>
> *template<int N> concept bool Even =3D N % 2 =3D=3D 0;*
>
> *This seems quite reasonable (if perhaps not all that useful):*
>
> *template<Even N> void f() {*
>
> *constexpr Even X =3D N;*
>
> *}*
>
> *Note that in this case, values of type Even are ontologically at the *
> *=E2=80=9Cvalue**=E2=80=9D level not at the **=E2=80=9Ctype**=E2=80=9D*
>
> *level because it is a concept constraining a value (non-type template=20
> parameter), not a concept*
>
> *constraining a type.*
>
> =20
>
> There is a problem with that: How do we know what type of template=20
> parameter f() actually takes?
>
> Does it refer to a type that is Even? Does it refer to a type =E2=80=98Ev=
en=E2=80=99,=20
> does it refer to an Even value (if yes, what type?) and how do we know,=
=20
> Even is a concept?
>
> We don=E2=80=99t.
>
> =20
>
> If we only can know e.g. the underlying data type (here int) of a=20
> concepts use (see *template<Even N> void f()*) by looking at its=20
> definition, this design is significantly flawed.
>
> What my Idea here was is: what if we relax the value constraint with auto=
=20
> (this makes the value constraint reusable and overloadable), see
>
> template<auto N> concept bool Even =3D N % 2 =3D=3D 0;
>
> =20
>
> and mention an explicit type (or auto, depending on what we want) at the=
=20
> point of use?
>
> template<Even int N> void f() {
>
> constexpr Even int X =3D N;
>
> }
>
> This would turn out rather intuitive, doesn=E2=80=99t it?
>
> =20
>
> =3D> Outcome: Rather than perceiving Even as a constrained Datatype, we c=
an=20
> perceive it as a property that we can enforce on the domain of a given ty=
pe.
>
> But hey! This is nothing but a contract!
>
> =20
>
> *[Start note **=E2=80=93*
>
> In Analogy to the above example:
>
> template<Regular typename T> struct{};
>
> This now makes pretty clear what=E2=80=99s going on here.
>
> *-- End note]*
>
> =20
>
> I think a great goal we should discuss is merging contracts and concepts=
=20
> together since they portrait the same idea.
>
> The only difference is that one does it at compile time and the other one=
=20
> at runtime (a little bit overgeneralized, but that=E2=80=99s the basic id=
ea, isn=E2=80=99t=20
> it?).
>
> =20
>
> If my argument is not clear already, consider the following combined=20
> Example:
>
> void f( Positive float m ){
>
> }
>
> void f( NonNull char* dest ){
>
> }
>
> template<
>
> Arbitrary typename T,
>
> Positive int m,
>
> Positive int n
>
> >=20
>
> void f( Symmetric std::matrix<T,m,n> m ){
>
> }
>
> =20
>
> =3D> We should try to combine them somehow in a hybrid compiletime/runtim=
e=20
> mechanism or else we have a great redundancy between contracts and=20
> concepts. (IMO)
>
> =20
>
> =20
>
> These are just a few Ideas that I have not seen anyone talk about.=20
> Therfore I'd like to do that now.
>
> =20
>
>
> I=E2=80=99d be happy to hear from you!
>
> =20
>
> Kind Regards,
>
> Jakob
>
> =20
>
--=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/afa41fae-5040-440f-ad0a-5b0a4790980d%40isocpp.or=
g.
------=_Part_4610_1350722468.1498000772823
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Compare these:<div><br></div><div><p class=3D"MsoNormal" s=
tyle=3D""><i><span style=3D"font-size: 10pt; font-family: "Source Code=
Pro Medium"; background: silver;">template<int N> concept bool =
Even =3D N % 2 =3D=3D 0;</span></i><i><span style=3D"font-size: 10pt; font-=
family: "Source Code Pro Medium";"></span></i></p><p class=3D"Mso=
Normal" style=3D""><i>This seems quite reasonable (if perhaps not all that =
useful):</i></p><p class=3D"MsoNormal" style=3D""><i><span style=3D"font-si=
ze: 10pt; font-family: "Source Code Pro Medium"; background: silv=
er;">template<Even N> void f() {</span></i></p><p class=3D"MsoNormal"=
style=3D"text-indent: 36pt;"><i><span style=3D"font-size: 10pt; font-famil=
y: "Source Code Pro Medium"; background: silver;">constexpr Even =
X =3D N;</span></i></p><p class=3D"MsoNormal" style=3D""><i><span style=3D"=
font-size: 10pt; font-family: "Source Code Pro Medium"; backgroun=
d: silver;">}</span></i></p><div><br></div><p class=3D"MsoNormal" style=3D"=
"><i><span style=3D"font-size: 10pt; font-family: "Source Code Pro Med=
ium"; background: silver;">template<typename N> concept bool Equ=
alComparable =3D ... ;</span></i><i><span style=3D"font-size: 10pt; font-fa=
mily: "Source Code Pro Medium";"></span></i></p><p class=3D"MsoNo=
rmal" style=3D""><i>This seems quite reasonable (if perhaps not all that us=
eful):</i></p><p class=3D"MsoNormal" style=3D""><i><span style=3D"font-size=
: 10pt; font-family: "Source Code Pro Medium"; background: silver=
;">template<EqualComparable N> void f() {</span></i></p><p class=3D"M=
soNormal" style=3D"text-indent: 36pt;"><i><span style=3D"font-size: 10pt; f=
ont-family: "Source Code Pro Medium"; background: silver;">conste=
xpr N my_value;</span></i></p><p class=3D"MsoNormal" style=3D""><i><span st=
yle=3D"font-size: 10pt; font-family: "Source Code Pro Medium"; ba=
ckground: silver;">}</span></i></p><p class=3D"MsoNormal" style=3D""><i><sp=
an style=3D"font-size: 10pt; font-family: "Source Code Pro Medium"=
;; background: silver;"><br></span></i></p><p class=3D"MsoNormal" style=3D"=
">To me it is pretty clear that in the second case N is bound to a type ful=
filling EqualComparable concept, while the EqualComparable identifier does =
not carry any new meaning inside the function compared to outside it.<br></=
p><p class=3D"MsoNormal" style=3D""><br></p><p class=3D"MsoNormal" style=3D=
"">Thus it seems very strange that the name of the int-valued concept Even =
should carry special meaning (as an alias of int, maybe?) inside the functi=
on. What if you wrote as below, this seems very strange to allow as we imme=
diately break the promise made by using Even as a type.</p><p class=3D"MsoN=
ormal" style=3D""><br></p><p class=3D"MsoNormal"><i><span style=3D"font-siz=
e: 10pt; font-family: "Source Code Pro Medium"; background: silve=
r;">emplate<int N> concept bool Even =3D N % 2 =3D=3D 0;</span></i><i=
><span style=3D"font-size: 10pt; font-family: "Source Code Pro Medium&=
quot;;"></span></i></p><p class=3D"MsoNormal"><i>This seems quite reasonabl=
e (if perhaps not all that useful):</i></p><p class=3D"MsoNormal"><i><span =
style=3D"font-size: 10pt; font-family: "Source Code Pro Medium"; =
background: silver;">template<Even N> void f() {</span></i></p><p cla=
ss=3D"MsoNormal" style=3D"text-indent: 36pt;"><i><span style=3D"font-size: =
10pt; font-family: "Source Code Pro Medium"; background: silver;"=
>Even x =3D N;</span></i></p><p class=3D"MsoNormal" style=3D"text-indent: 3=
6pt;"><i><span style=3D"font-size: 10pt; font-family: "Source Code Pro=
Medium"; background: silver;">x++;</span></i></p><p class=3D"MsoNorma=
l"><i><span style=3D"font-size: 10pt; font-family: "Source Code Pro Me=
dium"; background: silver;">}</span></i></p><div><i><span style=3D"fon=
t-size: 10pt; font-family: "Source Code Pro Medium"; background: =
silver;"><br></span></i></div><div><i><span style=3D"font-size: 10pt; font-=
family: "Source Code Pro Medium"; background: silver;">You posed =
this example which shows the same problem, where the 'Even' value i=
s actually odd, oddly enough:</span></i></div><div><i><span style=3D"font-s=
ize: 10pt; font-family: "Source Code Pro Medium"; background: sil=
ver;"><br></span></i></div><div><div>template<Even int N> void f() {<=
/div><div>=C2=A0 constexpr Even int X =3D 3 * N;</div><div>}</div></div><di=
v><br></div><div>Unless this is of course a contrived way of stating that N=
must be 0...</div><div><i><span style=3D"font-size: 10pt; font-family: &qu=
ot;Source Code Pro Medium"; background: silver;"><br></span></i></div>=
<div>I really like your idea about viewing concepts as adjectives though. I=
t seems very logical to be able to stack multiple adjectives on a type and =
maybe on values too:</div><div><br></div><div>// A function taking an even =
constant value of some integral arithmetic type, binding the value to the s=
mall even number N and the type to decltype(N).</div><div>template<Arith=
metic Integral auto Small Even N> f();<br></div><div><br></div><div>Well=
that could be taking it too far, maybe the type constraints should be on t=
he value constraint definition:</div><div><br></div><div>template<Arithm=
etic Integral auto N> concept Even =3D N % 2 =3D=3D 0;</div><div><br></d=
iv><p class=3D"MsoNormal" style=3D"">No, also strange...</p><p class=3D"Mso=
Normal" style=3D""><br></p><p class=3D"MsoNormal" style=3D"">Lots of unfini=
shed thoughs, but may be worth some more experimentation and thinking about=
what the semantics really should be.</p></div><div><br></div><div>m=C3=A5n=
dag 19 juni 2017 kl. 15:42:03 UTC+2 skrev Jakob Riedle:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div>Hello Folks,</div><div><br><=
/div><div>Reading=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2017/p0587r0.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0587r0.pdf\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNFnWZpFDFfS_qJx90Negobn0NhJtw';return true=
;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2F=
www.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0587r0.pdf\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFnWZpFDFfS_qJx90Negobn0NhJtw';r=
eturn true;">P0587R0</a>=C2=A0(that talks about in what way Concepts might =
have to be refined),</div><div>two questions came to my mind, that have not=
been adressed by any Papers I read about Concepts in C++:</div><div><b><br=
></b></div><ol start=3D"1" type=3D"1">
<li class=3D"MsoNormal"><b>Allowing concepts to be passed as template
parameters.</b></li>
</ol>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">A potential syntax (as =
touched in P0587R0) has to take
that into account that, If we want to allow <b>concepts to be passed as
template parameters,</b></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">we don<span style=3D"fo=
nt-family:"Times New Roman",serif">=E2=80=99</span>t want to ambi=
guate this case with <b>constraining
template parameters with concepts</b>.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">With Concepts Lite TS, =
I would
intuitively write a template taking a concept as template parameter as:</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><spa=
n style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium";=
background:silver">template<typename> concept MyConstraint</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
>
struct WhateverClass{</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
=C2=A0=C2=A0
template<MyConstraint T> // Use the passed concept here just as =E2=
=80=9Cnormal=E2=80=9D</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
=C2=A0=C2=A0
WhateverClass(T arg){ /* =E2=80=A6 */ }</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
};</span><span style=3D"font-size:10.0pt"></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This is not (yet) allow=
ed but I
did not find anyone that even considered it.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Hopefully, I have not m=
issed
something.</p>
<p class=3D"MsoNormal">=C2=A0</p>
<p class=3D"MsoNormal">=C2=A0</p>
<ol style=3D"margin-top:0cm" start=3D"2" type=3D"1">
<li class=3D"MsoNormal"><b>How
do we make clear if a concept is a value or type constraint?</b></li>
</ol>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Cited from the paper:</=
p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><br></i></p><p class=
=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>Conversely, given:</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;font-family:"Source Code Pro Medium";background:silve=
r">template<int
N> concept bool Even =3D N % 2 =3D=3D 0;</span></i><i><span style=3D"fon=
t-size:10.0pt;font-family:"Source Code Pro Medium""></span></i></=
p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>This seems quite rea=
sonable
(if perhaps not all that useful):</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;font-family:"Source Code Pro Medium";background:silve=
r">template<Even
N> void f() {</span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt;text-indent:36.0pt"><i><=
span style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium&quo=
t;;background:silver">constexpr Even X =3D N;</span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;font-family:"Source Code Pro Medium";background:silve=
r">}</span></i><i><span style=3D"font-size:10.0pt;font-family:"Source =
Code Pro Medium""></span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>Note that in this ca=
se, values
of type Even are ontologically at the </i><i><span style=3D"font-family:&qu=
ot;Times New Roman",serif">=E2=80=9C</span>value</i><i><span style=3D"=
font-family:"Times New Roman",serif">=E2=80=9D</span> level not a=
t the </i><i><span style=3D"font-family:"Times New Roman",serif">=
=E2=80=9C</span>type</i><i><span style=3D"font-family:"Times New Roman=
",serif">=E2=80=9D</span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>level because it is =
a concept
constraining a value (non-type template parameter), not a concept</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>constraining a type.=
</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">There is a problem with=
that: How
do we know what type of template parameter <span style=3D"font-family:"=
;Source Code Pro Medium";background:silver">f()</span> actually takes?=
</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Does it refer to a type=
that is
Even? Does it refer to a type <span style=3D"font-family:"Times New Ro=
man",serif">=E2=80=98</span>Even<span style=3D"font-family:"Times=
New Roman",serif">=E2=80=99</span>, does it refer to an Even
value (if yes, what type?) and how do we know, Even is a concept?</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">We don<span style=3D"fo=
nt-family:"Times New Roman",serif">=E2=80=99</span>t.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">If we only can know e.g=
.. the
underlying data type (here <span style=3D"font-size:10.0pt;font-family:&quo=
t;Source Code Pro Medium";background:silver">int</span>) of a concepts=
use (see <i><span style=3D"font-size:10.0pt;font-family:"Source Code =
Pro Medium";background:silver">template<<span style=3D"color:red">E=
ven N</span>> void
f()</span></i>) by looking at its definition, this design is significantly
flawed.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">What my Idea here was i=
s: what if
we relax the value constraint with auto (this makes the value constraint
reusable and <span style=3D"color:red">overloadable</span>), see</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<auto
N> concept bool Even =3D N % 2 =3D=3D 0;</span><span style=3D"font-size:=
10.0pt;font-family:"Source Code Pro Medium""></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">and mention an explicit=
type (or
auto, depending on what we want) at the point of use?</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<Even
<span style=3D"color:red">int </span>N> void f() {</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><spa=
n style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium";=
background:silver">constexpr Even <span style=3D"color:red">int </span>X =
=3D N;</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
}</span><span style=3D"font-size:10.0pt;font-family:"Source Code Pro M=
edium""></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This would turn out rat=
her
intuitive, doesn<span style=3D"font-family:"Times New Roman",seri=
f">=E2=80=99</span>t it?</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=3D> Outcome: Rather=
than
perceiving <span style=3D"font-size:10.0pt;font-family:"Source Code Pr=
o Medium";background:silver">Even</span><span style=3D"font-size:10.0p=
t">
</span>as a constrained Datatype, we can perceive it as a property that we =
can
enforce on the domain of a given type.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">But hey! This is nothin=
g but a
contract!</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><i>[Start note </i><i><=
span style=3D"font-family:"Times New Roman",serif">=E2=80=93</spa=
n></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">In Analogy to the above=
example:</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<Regular
<span style=3D"color:red">typename </span>T> struct{};</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This now makes pretty c=
lear what<span style=3D"font-family:"Times New Roman",serif">=E2=
=80=99</span>s going on here.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><i>-- End note]</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">I think a great goal we=
should
discuss is merging contracts and concepts together since they portrait the =
same
idea.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">The only difference is =
that one
does it at compile time and the other one at runtime (a little bit
overgeneralized, but that<span style=3D"font-family:"Times New Roman&q=
uot;,serif">=E2=80=99</span>s
the basic idea, isn<span style=3D"font-family:"Times New Roman",s=
erif">=E2=80=99</span>t
it?).</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">If my argument is not c=
lear
already, consider the following combined Example:</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-fam=
ily:"Source Code Pro Medium";background:silver">void f( Positive =
float m ){</span></p><p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><s=
pan style=3D"font-family:"Source Code Pro Medium";background:silv=
er">}</span><span style=3D"font-family:"Source Code Pro Medium"">=
</span></p><p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=
=3D"font-family:"Source Code Pro Medium";background:silver">void =
f( NonNull char* dest ){</span></p><p class=3D"MsoNormal" style=3D"margin-l=
eft:18.0pt"><span style=3D"font-family:"Source Code Pro Medium";b=
ackground:silver">}</span></p><p class=3D"MsoNormal" style=3D"margin-left:1=
8.0pt"><span style=3D"font-family:"Source Code Pro Medium";backgr=
ound:silver">template<</span></p><p class=3D"MsoNormal" style=3D"margin-=
left:18.0pt;text-indent:36.0pt"><span style=3D"font-family:"Source Cod=
e Pro Medium";background:silver">Arbitrary typename T,</span></p><p cl=
ass=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><span sty=
le=3D"font-family:"Source Code Pro Medium";background:silver">Pos=
itive int m,</span></p><p class=3D"MsoNormal" style=3D"margin-left:18.0pt;t=
ext-indent:36.0pt"><span style=3D"font-family:"Source Code Pro Medium&=
quot;;background:silver">Positive int n</span></p><p class=3D"MsoNormal" st=
yle=3D"margin-left:18.0pt"><span style=3D"font-family:"Source Code Pro=
Medium";background:silver">>=C2=A0</span></p><p class=3D"MsoNormal=
" style=3D"margin-left:18.0pt"><span style=3D"font-family:"Source Code=
Pro Medium";background:silver">void f( Symmetric
std::matrix<T,m,n> m ){</span></p><p class=3D"MsoNormal" style=3D"mar=
gin-left:18.0pt"><span style=3D"font-family:"Source Code Pro Medium&qu=
ot;;background:silver">
</span><span style=3D"font-family:"Source Code Pro Medium""></spa=
n></p><p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"fo=
nt-family:"Source Code Pro Medium";background:silver">}</span><sp=
an style=3D"font-family:"Source Code Pro Medium""></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-fam=
ily:"Source Code Pro Medium"">=C2=A0</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=3D> We should try t=
o combine them somehow in a hybrid compiletime/runtime mechanism or else we=
have a great redundancy between contracts and concepts. (IMO)</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal">=C2=A0</p>
<p class=3D"MsoNormal">These are just a few Ideas that I have not seen anyo=
ne talk about. Therfore I'd like to do that now.</p>
<p class=3D"MsoNormal">=C2=A0</p>
<p class=3D"MsoNormal"><br></p>
<p class=3D"MsoNormal">I<span style=3D"font-family:"Times New Roman&qu=
ot;,serif">=E2=80=99</span>d
be happy to hear from you!</p>
<p class=3D"MsoNormal">=C2=A0</p>
<p class=3D"MsoNormal">Kind Regards,</p>
<p class=3D"MsoNormal">Jakob</p>
<p class=3D"MsoNormal">=C2=A0</p></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/afa41fae-5040-440f-ad0a-5b0a4790980d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/afa41fae-5040-440f-ad0a-5b0a4790980d=
%40isocpp.org</a>.<br />
------=_Part_4610_1350722468.1498000772823--
------=_Part_4609_1770402451.1498000772822--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 20 Jun 2017 18:35:22 -0700
Raw View
--001a113fe154e8abb405526e62c6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 20 June 2017 at 16:19, Bengt Gustafsson <bengt.gustafsson@beamways.com>
wrote:
> Compare these:
>
> *template<int N> concept bool Even =3D N % 2 =3D=3D 0;*
>
> *This seems quite reasonable (if perhaps not all that useful):*
>
> *template<Even N> void f() {*
>
> *constexpr Even X =3D N;*
>
> *}*
>
> *template<typename N> concept bool EqualComparable =3D ... ;*
>
> *This seems quite reasonable (if perhaps not all that useful):*
>
> *template<EqualComparable N> void f() {*
>
> *constexpr N my_value;*
>
> *}*
>
>
> To me it is pretty clear that in the second case N is bound to a type
> fulfilling EqualComparable concept, while the EqualComparable identifier
> does not carry any new meaning inside the function compared to outside it=
..
>
I don't follow what you're saying about new meaning inside / outside the
function. If we permitted the above, we would presumably also permit
constexpr Even x =3D 42;
.... at global scope. (And Even would have the same meaning in every
context: it introduces the name of an integer whose value is even.)
Thus it seems very strange that the name of the int-valued concept Even
> should carry special meaning (as an alias of int, maybe?) inside the
> function. What if you wrote as below, this seems very strange to allow as
> we immediately break the promise made by using Even as a type.
>
>
> *emplate<int N> concept bool Even =3D N % 2 =3D=3D 0;*
>
> *This seems quite reasonable (if perhaps not all that useful):*
>
> *template<Even N> void f() {*
>
> *Even x =3D N;*
>
This would be ill-formed, as the value of x cannot be statically checked to
satisfy the Even concept (Even<x> does not evaluate to true). You'd at
least need x to be const.
*x++;*
>
> *}*
>
> *You posed this example which shows the same problem, where the 'Even'
> value is actually odd, oddly enough:*
>
> template<Even int N> void f() {
> constexpr Even int X =3D 3 * N;
> }
>
> Unless this is of course a contrived way of stating that N must be 0...
>
I think you should think about this a bit more :-)
I really like your idea about viewing concepts as adjectives though. It
> seems very logical to be able to stack multiple adjectives on a type and
> maybe on values too:
>
> // A function taking an even constant value of some integral arithmetic
> type, binding the value to the small even number N and the type to
> decltype(N).
> template<Arithmetic Integral auto Small Even N> f();
>
> Well that could be taking it too far, maybe the type constraints should b=
e
> on the value constraint definition:
>
> template<Arithmetic Integral auto N> concept Even =3D N % 2 =3D=3D 0;
>
> No, also strange...
>
>
> Lots of unfinished thoughs, but may be worth some more experimentation an=
d
> thinking about what the semantics really should be.
>
It's interesting that even the "taking it too far" case still seems pretty
readable to me. This direction seems to have some very nice properties.
> m=C3=A5ndag 19 juni 2017 kl. 15:42:03 UTC+2 skrev Jakob Riedle:
>>
>> Hello Folks,
>>
>> Reading P0587R0
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0587r0.pdf> (t=
hat
>> talks about in what way Concepts might have to be refined),
>> two questions came to my mind, that have not been adressed by any Papers
>> I read about Concepts in C++:
>>
>>
>> 1. *Allowing concepts to be passed as template parameters.*
>>
>> A potential syntax (as touched in P0587R0) has to take that into account
>> that, If we want to allow *concepts to be passed as template parameters,=
*
>>
>> we don=E2=80=99t want to ambiguate this case with *constraining template
>> parameters with concepts*.
>>
>>
>>
>> With Concepts Lite TS, I would intuitively write a template taking a
>> concept as template parameter as:
>>
>> template<
>>
>> template<typename> concept MyConstraint
>>
>> > struct WhateverClass{
>>
>> template<MyConstraint T> // Use the passed concept here just as
>> =E2=80=9Cnormal=E2=80=9D
>>
>> WhateverClass(T arg){ /* =E2=80=A6 */ }
>>
>> };
>>
>> This is not (yet) allowed but I did not find anyone that even considered
>> it.
>>
>> Hopefully, I have not missed something.
>>
>>
>>
>>
>>
>> 1. *How do we make clear if a concept is a value or type constraint?*
>>
>> Cited from the paper:
>>
>>
>> *Conversely, given:*
>>
>> *template<int N> concept bool Even =3D N % 2 =3D=3D 0;*
>>
>> *This seems quite reasonable (if perhaps not all that useful):*
>>
>> *template<Even N> void f() {*
>>
>> *constexpr Even X =3D N;*
>>
>> *}*
>>
>> *Note that in this case, values of type Even are ontologically at the *
>> *=E2=80=9Cvalue**=E2=80=9D level not at the **=E2=80=9Ctype**=E2=80=9D*
>>
>> *level because it is a concept constraining a value (non-type template
>> parameter), not a concept*
>>
>> *constraining a type.*
>>
>>
>>
>> There is a problem with that: How do we know what type of template
>> parameter f() actually takes?
>>
>> Does it refer to a type that is Even? Does it refer to a type =E2=80=98E=
ven=E2=80=99,
>> does it refer to an Even value (if yes, what type?) and how do we know,
>> Even is a concept?
>>
>> We don=E2=80=99t.
>>
>>
>>
>> If we only can know e.g. the underlying data type (here int) of a
>> concepts use (see *template<Even N> void f()*) by looking at its
>> definition, this design is significantly flawed.
>>
>> What my Idea here was is: what if we relax the value constraint with aut=
o
>> (this makes the value constraint reusable and overloadable), see
>>
>> template<auto N> concept bool Even =3D N % 2 =3D=3D 0;
>>
>>
>>
>> and mention an explicit type (or auto, depending on what we want) at the
>> point of use?
>>
>> template<Even int N> void f() {
>>
>> constexpr Even int X =3D N;
>>
>> }
>>
>> This would turn out rather intuitive, doesn=E2=80=99t it?
>>
>>
>>
>> =3D> Outcome: Rather than perceiving Even as a constrained Datatype, we
>> can perceive it as a property that we can enforce on the domain of a giv=
en
>> type.
>>
>> But hey! This is nothing but a contract!
>>
>>
>>
>> *[Start note **=E2=80=93*
>>
>> In Analogy to the above example:
>>
>> template<Regular typename T> struct{};
>>
>> This now makes pretty clear what=E2=80=99s going on here.
>>
>> *-- End note]*
>>
>>
>>
>> I think a great goal we should discuss is merging contracts and concepts
>> together since they portrait the same idea.
>>
>> The only difference is that one does it at compile time and the other on=
e
>> at runtime (a little bit overgeneralized, but that=E2=80=99s the basic i=
dea, isn=E2=80=99t
>> it?).
>>
>>
>>
>> If my argument is not clear already, consider the following combined
>> Example:
>>
>> void f( Positive float m ){
>>
>> }
>>
>> void f( NonNull char* dest ){
>>
>> }
>>
>> template<
>>
>> Arbitrary typename T,
>>
>> Positive int m,
>>
>> Positive int n
>>
>> >
>>
>> void f( Symmetric std::matrix<T,m,n> m ){
>>
>> }
>>
>>
>>
>> =3D> We should try to combine them somehow in a hybrid compiletime/runti=
me
>> mechanism or else we have a great redundancy between contracts and
>> concepts. (IMO)
>>
>>
>>
>>
>>
>> These are just a few Ideas that I have not seen anyone talk about.
>> Therfore I'd like to do that now.
>>
>>
>>
>>
>> I=E2=80=99d be happy to hear from you!
>>
>>
>>
>> Kind Regards,
>>
>> Jakob
>>
>>
>>
> --
> 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/afa41fae-5040-440f-
> ad0a-5b0a4790980d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/afa41fae-50=
40-440f-ad0a-5b0a4790980d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAOfiQqnHf1wvGUqit6JRwknM-6gTOJ2E443Q6PTt7zjtYqy=
veQ%40mail.gmail.com.
--001a113fe154e8abb405526e62c6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
0 June 2017 at 16:19, Bengt Gustafsson <span dir=3D"ltr"><<a href=3D"mai=
lto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafsson@beamw=
ays.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr">Compare these:<div><br></div><div><span class=3D""><p class=3D"MsoNor=
mal"><i><span style=3D"font-size:10pt;font-family:"Source Code Pro Med=
ium";background:silver">template<int N> concept bool Even =3D N =
% 2 =3D=3D 0;</span></i><i><span style=3D"font-size:10pt;font-family:"=
Source Code Pro Medium""></span></i></p><p class=3D"MsoNormal"><i>This=
seems quite reasonable (if perhaps not all that useful):</i></p><p class=
=3D"MsoNormal"><i><span style=3D"font-size:10pt;font-family:"Source Co=
de Pro Medium";background:silver">template<Even N> void f() {</s=
pan></i></p><p class=3D"MsoNormal" style=3D"text-indent:36pt"><i><span styl=
e=3D"font-size:10pt;font-family:"Source Code Pro Medium";backgrou=
nd:silver">constexpr Even X =3D N;</span></i></p><p class=3D"MsoNormal"><i>=
<span style=3D"font-size:10pt;font-family:"Source Code Pro Medium"=
;;background:silver">}</span></i></p><div><br></div></span><p class=3D"MsoN=
ormal"><i><span style=3D"font-size:10pt;font-family:"Source Code Pro M=
edium";background:silver">template<typename N> concept bool Equa=
lComparable =3D ... ;</span></i><i><span style=3D"font-size:10pt;font-famil=
y:"Source Code Pro Medium""></span></i></p><span class=3D""><p cl=
ass=3D"MsoNormal"><i>This seems quite reasonable (if perhaps not all that u=
seful):</i></p></span><p class=3D"MsoNormal"><i><span style=3D"font-size:10=
pt;font-family:"Source Code Pro Medium";background:silver">templa=
te<EqualComparable N> void f() {</span></i></p><p class=3D"MsoNormal"=
style=3D"text-indent:36pt"><i><span style=3D"font-size:10pt;font-family:&q=
uot;Source Code Pro Medium";background:silver">constexpr N my_value;</=
span></i></p><p class=3D"MsoNormal"><i><span style=3D"font-size:10pt;font-f=
amily:"Source Code Pro Medium";background:silver">}</span></i></p=
><p class=3D"MsoNormal"><i><span style=3D"font-size:10pt;font-family:"=
Source Code Pro Medium";background:silver"><br></span></i></p><p class=
=3D"MsoNormal">To me it is pretty clear that in the second case N is bound =
to a type fulfilling EqualComparable concept, while the EqualComparable ide=
ntifier does not carry any new meaning inside the function compared to outs=
ide it.</p></div></div></blockquote><div><br></div><div>I don't follow =
what you're saying about new meaning inside / outside the function. If =
we permitted the above, we would presumably also permit</div><div><br></div=
><div>constexpr Even x =3D 42;</div><div><br></div><div>... at global scope=
.. (And Even would have the same meaning in every context: it introduces the=
name of an integer whose value is even.)</div><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><p class=3D"MsoNormal">Thus it seem=
s very strange that the name of the int-valued concept Even should carry sp=
ecial meaning (as an alias of int, maybe?) inside the function. What if you=
wrote as below, this seems very strange to allow as we immediately break t=
he promise made by using Even as a type.</p><span class=3D""><p class=3D"Ms=
oNormal"><br></p><p class=3D"MsoNormal"><i><span style=3D"font-size:10pt;fo=
nt-family:"Source Code Pro Medium";background:silver">emplate<=
int N> concept bool Even =3D N % 2 =3D=3D 0;</span></i><i><span style=3D=
"font-size:10pt;font-family:"Source Code Pro Medium""></span></i>=
</p><p class=3D"MsoNormal"><i>This seems quite reasonable (if perhaps not a=
ll that useful):</i></p><p class=3D"MsoNormal"><i><span style=3D"font-size:=
10pt;font-family:"Source Code Pro Medium";background:silver">temp=
late<Even N> void f() {</span></i></p></span><p class=3D"MsoNormal" s=
tyle=3D"text-indent:36pt"><i><span style=3D"font-size:10pt;font-family:&quo=
t;Source Code Pro Medium";background:silver">Even x =3D N;</span></i><=
/p></div></div></blockquote><div><br></div><div>This would be ill-formed, a=
s the value of x cannot be statically checked to satisfy the Even concept (=
Even<x> does not evaluate to true). You'd at least need x to be c=
onst.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div><p class=3D"MsoNormal" style=3D"text-indent:36pt"><i><span style=3D"fon=
t-size:10pt;font-family:"Source Code Pro Medium";background:silve=
r">x++;</span></i></p><p class=3D"MsoNormal"><i><span style=3D"font-size:10=
pt;font-family:"Source Code Pro Medium";background:silver">}</spa=
n></i></p><div><i><span style=3D"font-size:10pt;font-family:"Source Co=
de Pro Medium";background:silver"><br></span></i></div><div><i><span s=
tyle=3D"font-size:10pt;font-family:"Source Code Pro Medium";backg=
round:silver">You posed this example which shows the same problem, where th=
e 'Even' value is actually odd, oddly enough:</span></i></div><div>=
<i><span style=3D"font-size:10pt;font-family:"Source Code Pro Medium&q=
uot;;background:silver"><br></span></i></div><div><span class=3D""><div>tem=
plate<Even int N> void f() {</div></span><div>=C2=A0 constexpr Even i=
nt X =3D 3 * N;</div><div>}</div></div><div><br></div><div>Unless this is o=
f course a contrived way of stating that N must be 0...</div></div></div></=
blockquote><div><br></div><div>I think you should think about this a bit mo=
re :-)</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div>I really like your idea about viewing concepts as adjectives thou=
gh. It seems very logical to be able to stack multiple adjectives on a type=
and maybe on values too:</div><div><br></div><div>// A function taking an =
even constant value of some integral arithmetic type, binding the value to =
the small even number N and the type to decltype(N).</div><div>template<=
Arithmetic Integral auto Small Even N> f();<br></div><div><br></div><div=
>Well that could be taking it too far, maybe the type constraints should be=
on the value constraint definition:</div><div><br></div><div>template<A=
rithmetic Integral auto N> concept Even =3D N % 2 =3D=3D 0;</div><div><b=
r></div><p class=3D"MsoNormal">No, also strange...</p><p class=3D"MsoNormal=
"><br></p><p class=3D"MsoNormal">Lots of unfinished thoughs, but may be wor=
th some more experimentation and thinking about what the semantics really s=
hould be.</p></div></div></blockquote><div><br></div><div>It's interest=
ing that even the "taking it too far" case still seems pretty rea=
dable to me. This direction seems to have some very nice properties.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div c=
lass=3D"h5"><div>m=C3=A5ndag 19 juni 2017 kl. 15:42:03 UTC+2 skrev Jakob Ri=
edle:<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>Hello Fo=
lks,</div><div><br></div><div>Reading=C2=A0<a href=3D"http://www.open-std.o=
rg/jtc1/sc22/wg21/docs/papers/2017/p0587r0.pdf" rel=3D"nofollow" target=3D"=
_blank">P0587R0</a>=C2=A0(that talks about in what way Concepts might have =
to be refined),</div><div>two questions came to my mind, that have not been=
adressed by any Papers I read about Concepts in C++:</div><div><b><br></b>=
</div><ol start=3D"1" type=3D"1">
<li class=3D"MsoNormal"><b>Allowing concepts to be passed as template
parameters.</b></li>
</ol>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">A potential syntax (as =
touched in P0587R0) has to take
that into account that, If we want to allow <b>concepts to be passed as
template parameters,</b></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">we don<span style=3D"fo=
nt-family:"Times New Roman",serif">=E2=80=99</span>t want to ambi=
guate this case with <b>constraining
template parameters with concepts</b>.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">With Concepts Lite TS, =
I would
intuitively write a template taking a concept as template parameter as:</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><spa=
n style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium";=
background:silver">template<typename> concept MyConstraint</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
>
struct WhateverClass{</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
=C2=A0=C2=A0
template<MyConstraint T> // Use the passed concept here just as =E2=
=80=9Cnormal=E2=80=9D</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
=C2=A0=C2=A0
WhateverClass(T arg){ /* =E2=80=A6 */ }</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
};</span><span style=3D"font-size:10.0pt"></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This is not (yet) allow=
ed but I
did not find anyone that even considered it.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Hopefully, I have not m=
issed
something.</p>
<p class=3D"MsoNormal">=C2=A0</p>
<p class=3D"MsoNormal">=C2=A0</p>
<ol style=3D"margin-top:0cm" start=3D"2" type=3D"1">
<li class=3D"MsoNormal"><b>How
do we make clear if a concept is a value or type constraint?</b></li>
</ol>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Cited from the paper:</=
p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><br></i></p><p class=
=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>Conversely, given:</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;font-family:"Source Code Pro Medium";background:silve=
r">template<int
N> concept bool Even =3D N % 2 =3D=3D 0;</span></i><i><span style=3D"fon=
t-size:10.0pt;font-family:"Source Code Pro Medium""></span></i></=
p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>This seems quite rea=
sonable
(if perhaps not all that useful):</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;font-family:"Source Code Pro Medium";background:silve=
r">template<Even
N> void f() {</span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt;text-indent:36.0pt"><i><=
span style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium&quo=
t;;background:silver">constexpr Even X =3D N;</span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i><span style=3D"font-=
size:10.0pt;font-family:"Source Code Pro Medium";background:silve=
r">}</span></i><i><span style=3D"font-size:10.0pt;font-family:"Source =
Code Pro Medium""></span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>Note that in this ca=
se, values
of type Even are ontologically at the </i><i><span style=3D"font-family:&qu=
ot;Times New Roman",serif">=E2=80=9C</span>value</i><i><span style=3D"=
font-family:"Times New Roman",serif">=E2=80=9D</span> level not a=
t the </i><i><span style=3D"font-family:"Times New Roman",serif">=
=E2=80=9C</span>type</i><i><span style=3D"font-family:"Times New Roman=
",serif">=E2=80=9D</span></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>level because it is =
a concept
constraining a value (non-type template parameter), not a concept</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:54.0pt"><i>constraining a type.=
</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">There is a problem with=
that: How
do we know what type of template parameter <span style=3D"font-family:"=
;Source Code Pro Medium";background:silver">f()</span> actually takes?=
</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">Does it refer to a type=
that is
Even? Does it refer to a type <span style=3D"font-family:"Times New Ro=
man",serif">=E2=80=98</span>Even<span style=3D"font-family:"Times=
New Roman",serif">=E2=80=99</span>, does it refer to an Even
value (if yes, what type?) and how do we know, Even is a concept?</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">We don<span style=3D"fo=
nt-family:"Times New Roman",serif">=E2=80=99</span>t.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">If we only can know e.g=
.. the
underlying data type (here <span style=3D"font-size:10.0pt;font-family:&quo=
t;Source Code Pro Medium";background:silver">int</span>) of a concepts=
use (see <i><span style=3D"font-size:10.0pt;font-family:"Source Code =
Pro Medium";background:silver">template<<span style=3D"color:red">E=
ven N</span>> void
f()</span></i>) by looking at its definition, this design is significantly
flawed.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">What my Idea here was i=
s: what if
we relax the value constraint with auto (this makes the value constraint
reusable and <span style=3D"color:red">overloadable</span>), see</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<auto
N> concept bool Even =3D N % 2 =3D=3D 0;</span><span style=3D"font-size:=
10.0pt;font-family:"Source Code Pro Medium""></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">and mention an explicit=
type (or
auto, depending on what we want) at the point of use?</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<Even
<span style=3D"color:red">int </span>N> void f() {</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><spa=
n style=3D"font-size:10.0pt;font-family:"Source Code Pro Medium";=
background:silver">constexpr Even <span style=3D"color:red">int </span>X =
=3D N;</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
}</span><span style=3D"font-size:10.0pt;font-family:"Source Code Pro M=
edium""></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This would turn out rat=
her
intuitive, doesn<span style=3D"font-family:"Times New Roman",seri=
f">=E2=80=99</span>t it?</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=3D> Outcome: Rather=
than
perceiving <span style=3D"font-size:10.0pt;font-family:"Source Code Pr=
o Medium";background:silver">Even</span><span style=3D"font-size:10.0p=
t">
</span>as a constrained Datatype, we can perceive it as a property that we =
can
enforce on the domain of a given type.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">But hey! This is nothin=
g but a
contract!</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><i>[Start note </i><i><=
span style=3D"font-family:"Times New Roman",serif">=E2=80=93</spa=
n></i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">In Analogy to the above=
example:</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-siz=
e:10.0pt;font-family:"Source Code Pro Medium";background:silver">=
template<Regular
<span style=3D"color:red">typename </span>T> struct{};</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">This now makes pretty c=
lear what<span style=3D"font-family:"Times New Roman",serif">=E2=
=80=99</span>s going on here.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><i>-- End note]</i></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">I think a great goal we=
should
discuss is merging contracts and concepts together since they portrait the =
same
idea.</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">The only difference is =
that one
does it at compile time and the other one at runtime (a little bit
overgeneralized, but that<span style=3D"font-family:"Times New Roman&q=
uot;,serif">=E2=80=99</span>s
the basic idea, isn<span style=3D"font-family:"Times New Roman",s=
erif">=E2=80=99</span>t
it?).</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">If my argument is not c=
lear
already, consider the following combined Example:</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-fam=
ily:"Source Code Pro Medium";background:silver">void f( Positive =
float m ){</span></p><p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><s=
pan style=3D"font-family:"Source Code Pro Medium";background:silv=
er">}</span><span style=3D"font-family:"Source Code Pro Medium"">=
</span></p><p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=
=3D"font-family:"Source Code Pro Medium";background:silver">void =
f( NonNull char* dest ){</span></p><p class=3D"MsoNormal" style=3D"margin-l=
eft:18.0pt"><span style=3D"font-family:"Source Code Pro Medium";b=
ackground:silver">}</span></p><p class=3D"MsoNormal" style=3D"margin-left:1=
8.0pt"><span style=3D"font-family:"Source Code Pro Medium";backgr=
ound:silver">template<</span></p><p class=3D"MsoNormal" style=3D"margin-=
left:18.0pt;text-indent:36.0pt"><span style=3D"font-family:"Source Cod=
e Pro Medium";background:silver">Arbitrary typename T,</span></p><p cl=
ass=3D"MsoNormal" style=3D"margin-left:18.0pt;text-indent:36.0pt"><span sty=
le=3D"font-family:"Source Code Pro Medium";background:silver">Pos=
itive int m,</span></p><p class=3D"MsoNormal" style=3D"margin-left:18.0pt;t=
ext-indent:36.0pt"><span style=3D"font-family:"Source Code Pro Medium&=
quot;;background:silver">Positive int n</span></p><p class=3D"MsoNormal" st=
yle=3D"margin-left:18.0pt"><span style=3D"font-family:"Source Code Pro=
Medium";background:silver">>=C2=A0</span></p><p class=3D"MsoNormal=
" style=3D"margin-left:18.0pt"><span style=3D"font-family:"Source Code=
Pro Medium";background:silver">void f( Symmetric
std::matrix<T,m,n> m ){</span></p><p class=3D"MsoNormal" style=3D"mar=
gin-left:18.0pt"><span style=3D"font-family:"Source Code Pro Medium&qu=
ot;;background:silver">
</span><span style=3D"font-family:"Source Code Pro Medium""></spa=
n></p><p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"fo=
nt-family:"Source Code Pro Medium";background:silver">}</span><sp=
an style=3D"font-family:"Source Code Pro Medium""></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt"><span style=3D"font-fam=
ily:"Source Code Pro Medium"">=C2=A0</span></p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=3D> We should try t=
o combine them somehow in a hybrid compiletime/runtime mechanism or else we=
have a great redundancy between contracts and concepts. (IMO)</p>
<p class=3D"MsoNormal" style=3D"margin-left:18.0pt">=C2=A0</p>
<p class=3D"MsoNormal">=C2=A0</p>
<p class=3D"MsoNormal">These are just a few Ideas that I have not seen anyo=
ne talk about. Therfore I'd like to do that now.</p>
<p class=3D"MsoNormal">=C2=A0</p>
<p class=3D"MsoNormal"><br></p>
<p class=3D"MsoNormal">I<span style=3D"font-family:"Times New Roman&qu=
ot;,serif">=E2=80=99</span>d
be happy to hear from you!</p>
<p class=3D"MsoNormal">=C2=A0</p>
<p class=3D"MsoNormal">Kind Regards,</p>
<p class=3D"MsoNormal">Jakob</p>
<p class=3D"MsoNormal">=C2=A0</p></div></blockquote></div></div></div></div=
><div><div class=3D"h5">
<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/afa41fae-5040-440f-ad0a-5b0a4790980d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/afa4=
1fae-5040-440f-<wbr>ad0a-5b0a4790980d%40isocpp.org</a><wbr>.<br>
</blockquote></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/CAOfiQqnHf1wvGUqit6JRwknM-6gTOJ2E443Q=
6PTt7zjtYqyveQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnHf1wvGUqi=
t6JRwknM-6gTOJ2E443Q6PTt7zjtYqyveQ%40mail.gmail.com</a>.<br />
--001a113fe154e8abb405526e62c6--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Wed, 21 Jun 2017 02:18:25 -0700 (PDT)
Raw View
------=_Part_762_1022473645.1498036705842
Content-Type: multipart/alternative;
boundary="----=_Part_763_1109812437.1498036705843"
------=_Part_763_1109812437.1498036705843
Content-Type: text/plain; charset="UTF-8"
Hi Folks,
first of all thank you for your participation and all the constructive
replys!
Thank you Richard, you managed to express it even more clearly!: "concepts
are adjectives, not nouns."
As it seems that this Idea is favourited by many people, let's talk about
value concepts since I have the strong feeling we should approach all
concepts/contracts in the same fashion.
Namely I'd like to ask you, in what way contracts do the same thing as
concepts and where they do something different.
Concepts on types do participate in the type system and thus overload
resolution.
On the other hand, concepts on values might only be detectable at runtime.
Thus overload resolution has no clue about them. Is this desired, given
that we want to include mor functional programming into C++?
It might have great benefits to include them within the type system as the
following example allows to dream:
// Given:
void f( Even int );
int my_int = 4;
f( my_int ); // warning: implicit cast from 'int' to 'Even int'
f( claim<Even>( my_int ) ); // ok (e.g. Runtime Check with Debug Build, No
Check with Release build)
// some sugar if you will?
f( !Even! my_int );
Besides that, it feels very natural to me to include them into the type
system, although I cannot yet say what semantics it should have.
Am Dienstag, 20. Juni 2017 23:45:31 UTC+2 schrieb Bengt Gustafsson:
>
> 1. Using a concept as a template parameter the way you indicate needs a
> use case to convince me. I think this will be hard to find as the idea of a
> concept is to define what the actual type has to be capable of to be
> possible to use.
>
The reason I had the idea was an actual use case: Defining a Concept that
describes a Multidimensional Datastructure. Expressing this is done in
analogy to a range of ranges of ranges and so on... (to the depth you want
it)
Since we don't want to restrict ourself to a specific *class *of Ranges,
the 'MultidimensionalRange' Concept is itself templated with concepts.
With the Concepts of Ranges TS (and the Syntax of Concepts Lite, extended
with concepts as template parameters):
// Forward declaration
template<typename T, template<typename T> concept bool... RangeConcepts>
concept bool MultiDimRange;
// Recursive Case
template<
typename T ,
template<typename T> concept bool RangeConcept0 ,
template<typename T> concept bool RangeConcept1 ,
template<typename T> concept bool... RangeConcepts
>
concept bool MultiDimRange<T, RangeCocept0, RangeConcept1, RangeConcepts...>
=
Range<T> /* From Ranges TS */
&& RangeConcept0<T>
&& MultidimensionalRange<
ranges::value_type<T> ,
RangeConcept1 ,
RangeConcepts...
>
;
// Base Case
template<
typename T ,
template<typename T> concept bool RangeConcept
>
concept bool MultiDimRange<T, RangeConcept> = Range<T> /* <- From Ranges TS
*/ && RangeConcept<T>;
// Using the Declarations:
template<typename T>
concept bool MyMatrixType = MultiDimRange<T, RandomAccessRange,
RandomAccessRange>;
template<MyMatrixType T>
T matrixMultiply( T m1 , T m2 ){
// e.g.
int i, j;
m1[i][j] // This is defined!
}
I don't know if concepts will be passed as template parameter to
non-concepts, but they will definitely need to be passed as template
parameters to other concepts to refine them.
Cheers,
Jakob
--
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/75100291-2b85-4930-aa6a-930eaf2b8469%40isocpp.org.
------=_Part_763_1109812437.1498036705843
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Folks,</div><div><br></div><div>first of all thank=
you for your participation and all the constructive replys!</div><div><br>=
</div><div>Thank you Richard, you managed to express it even more clearly!:=
"concepts are adjectives, not nouns."</div><div><br></div><div>A=
s it seems that this Idea is favourited by many people, let's talk abou=
t value concepts since I have the strong feeling we should approach all con=
cepts/contracts in the same fashion.</div><div><br></div><div>Namely I'=
d like to ask you, in what way contracts do the same thing as concepts and =
where they do something different.</div><div>Concepts on types do participa=
te in the type system and thus overload resolution.</div><div>On the other =
hand, concepts on values might only be detectable at runtime. Thus overload=
resolution has no clue about them. Is this desired, given that we want to =
include mor functional programming into C++?</div><div>It might have great =
benefits to include them within the type system as the following example al=
lows to dream:</div><div><br></div><div><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;"=
class=3D"styled-by-prettify">// Given:</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Even</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br><br><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> my_int </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>f<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> my_int </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">// warning: implicit cast from 'i=
nt' to 'Even int'</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>f</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> claim</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
><</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Even<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">>(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> my_int </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// ok (e.g. Runtime Check with Debug Build, No Chec=
k with Release build)</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br></span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">// some sugar if you will?</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>f</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">!</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Even</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">!</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> my_int </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><d=
iv><br></div><div>Besides that, it feels very natural to me to include them=
into the type system, although I cannot yet say what semantics it should h=
ave.</div></div><div><br></div><div><br></div><div><br></div>Am Dienstag, 2=
0. Juni 2017 23:45:31 UTC+2 schrieb Bengt Gustafsson:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div>1. Using a concept as a templa=
te parameter the way you indicate needs a use case to convince me. I think =
this will be hard to find as the idea of a concept is to define what the ac=
tual type has to be capable of to be possible to use.</div></div></blockquo=
te><div><br></div><div>The reason I had the idea was an actual use case: De=
fining a Concept that describes a Multidimensional Datastructure. Expressin=
g this is done in analogy to a range of ranges of ranges and so on... (to t=
he depth you want it)</div><div>Since we don't want to restrict ourself=
to a specific <i>class </i>of Ranges, the 'MultidimensionalRange' =
Concept is itself templated with concepts.</div><div><br></div><div>With th=
e Concepts of Ranges TS (and the Syntax of Concepts Lite, extended with con=
cepts as template parameters):</div><div>=C2=A0<div class=3D"prettyprint" s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); border-style: solid; border-width: 1px; word-wrap: break-word;"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #=
800;" class=3D"styled-by-prettify">// Forward declaration</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">template</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">template</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ty=
pename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">concept</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">RangeConcepts</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">concept</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: rgb(102, 0, 102);"><span style=3D"color: #606;" class=3D=
"styled-by-prettify">MultiDimRange</span></span><font color=3D"#000000"><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// Recursive Case</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></font><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> T </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">concept</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">RangeConcep=
t0</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">concept</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ran=
geConcept1</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">template</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">concept</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">bool</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ra=
ngeConcepts</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">><=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">concept</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(=
102, 0, 102);"><span style=3D"color: #606;" class=3D"styled-by-prettify">Mu=
ltiDimRange</span></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">RangeCocept0</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">RangeConcept1</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">RangeConcepts</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">...></span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"styled-=
by-prettify">Range</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #800;" class=3D"styled-by-prettify">/* From Ranges TS */</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&am=
p;&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">RangeConcept=
0</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&&</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">MultidimensionalRange</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 ranges</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">v=
alue_type</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">RangeConcept1</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">RangeConcep=
ts</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">></=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
font color=3D"#000000"><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span></font><font color=3D"#660066"><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// Base Case</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">concept</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span></font><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">RangeConcept</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><font color=3D"#660066"=
><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">concept</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span></font><span style=3D"color: rgb(102, =
0, 102);"><span style=3D"color: #606;" class=3D"styled-by-prettify">MultiDi=
mRange</span></span><font color=3D"#660066"><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span></font><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>RangeConcept</span><font color=3D"#660066"><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span></font><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Range</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">/* <- From Ranges TS */</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&&</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">RangeConcept</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">>;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br><br></span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// Using the Declarations:</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">concept</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">My</span><font color=
=3D"#660066"><span style=3D"color: #606;" class=3D"styled-by-prettify">Matr=
ixType</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan></font><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #606;" class=3D"styled-by-prettify">MultiDimRange</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">RandomAccessRange</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: rgb(102, 0, 102);"><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">RandomAccessRange</=
span></span><span style=3D"color: #660;" class=3D"styled-by-prettify">>;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">template</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">My</span><font color=
=3D"#660066"><span style=3D"color: #606;" class=3D"styled-by-prettify">Matr=
ixType</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan></font><span style=3D"color: #000;" class=3D"styled-by-prettify">T</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>T matrixMultiply<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><font color=
=3D"#660066"><span style=3D"color: #000;" class=3D"styled-by-prettify">T </=
span></font><span style=3D"color: #000;" class=3D"styled-by-prettify">m1 </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><font color=
=3D"#660066"><span style=3D"color: #000;" class=3D"styled-by-prettify">T </=
span></font><span style=3D"color: #000;" class=3D"styled-by-prettify">m2 </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">){</span><fo=
nt color=3D"#880000"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// e.g.</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> j</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 m1</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">][</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">j</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// This is defined!</span></font><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><font color=3D"#666600"></font></div></code></div><br><=
/div><div><br></div><div>I don't know if concepts will be passed as tem=
plate parameter to non-concepts, but they will definitely need to be passed=
as template parameters to other concepts to refine them.</div><div><br></d=
iv><div>Cheers,</div><div>Jakob</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/75100291-2b85-4930-aa6a-930eaf2b8469%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/75100291-2b85-4930-aa6a-930eaf2b8469=
%40isocpp.org</a>.<br />
------=_Part_763_1109812437.1498036705843--
------=_Part_762_1022473645.1498036705842--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 21 Jun 2017 09:55:59 +0000
Raw View
--089e08236db8ae2d520552756056
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 20, 2017 at 11:45 PM Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:
> 1. Using a concept as a template parameter the way you indicate needs a
> use case to convince me. I think this will be hard to find as the idea of=
a
> concept is to
>
Here's my attempt:
I'm implementing a type erasure library, and I want to use concepts to
check whether types actually fit the archetype of the "typeclass" that I'm
erasing. To do that, I'd need to generate a concept per member function
name (obviously) to check whether that class has a member with a given name
and signature.
I can't do this easily, because I need to somehow decompose the function
types that my template machinery gives me (as a single type).
Now, I'd need either of three things:
1) Using concepts as template parameters. This way I could have a type that
kind of "explodes" the function type into its parameter. I have that
implemented for type templates, and it's extremely useful for this; I can't
do it for concepts, for exactly this reason.
2) A potentially simpler fix: allowing member concepts of types, because
then instead of exploding I could just have a member concept. This is of
course the less generic solution, since I'd need a wrapper for every "kind"
of a concept, but I could live with it.
3) A feature to allow me to specialize concepts - then I can just use the
decades old trick of pattern matching on the function type.
(Hopefully the usage is clear enough, but I can spend more time on
explaining it if it isn't.)
> define what the actual type has to be capable of to be possible to use.
> Being able to parameterize this would mean that the code of the function
> would have to adapt to the _actual concept_ by basically morphing the
> source code. Isn't this just the opposite of the idea of overloading
> template functions based on which concepts the actual template parameters
> fulfill. Thus the code of the two overloads is typically different to
> handle the different abilities of the actual types of the parameters.
>
> When it comes to class templates this becomes more interesting as we
> currently can't overload them. With concepts available it seems far more
> reasonable to overload template classes (although there is already a bit
> strange that you can't overload on the number of template parameters). I
> guess the current reasoning is to build on the partial specialization
> functionality and allow class templates to be specialized on the concept
> level:
>
> template<typename T> class my_template {
> // base implementation
> };
>
> template<Sortable T> class my_template<T> {
> // optimized implementation using the sortedness of T
> };
>
> I don't recall having seen such an example, but I assume this is how it i=
s
> supposed to work.
>
> 2. I didn't know that concepts for non-type template parameters were
> included in concepts lite. If they are I can imagine that they have not
> been widely explored... but maybe this is just something that P0355 autho=
rs
> found plausible.
>
> You write
>
> Does it refer to a type that is Even? Does it refer to a type =E2=80=98Ev=
en=E2=80=99,
> does it refer to an Even value (if yes, what type?) and how do we know,
> Even is a concept? We don=E2=80=99t.
>
> regarding this example:
>
> *template<int N> concept bool Even =3D N % 2 =3D=3D 0;*
>
> *This seems quite reasonable (if perhaps not all that useful):*
>
> *template<Even N> void f() {*
>
> *constexpr Even X =3D N;*
>
> *}*
>
>
> I think it is fairly clear that N is a int template parameter. The
> contents of the {} seems malformed, as Even is not a type. Shouldn't it b=
e
> "constexpr int X =3D N;" ?
>
> This said, your suggested syntax with the concept as a prefix of a type o=
r
> typename has something going for it as it clearly notifies the reader tha=
t
> there is a concept involved without having to find the declaration. Befor=
e
> going much further with this idea we must contemplate if this syntax woul=
d
> work in all places where concepts can be mentioned, and whether it would
> bloat the code too much to have to type typename in even more places than
> we currently do.
>
> I also find your analogy between concepts and contracts an interesting
> thought. How about using the new requires keyword on the contract level
> also?
>
> template<typename T> T div_by_two(T x) requires Integral<T> // Compile
> time requirement
> {
> requires x & 1 =3D=3D 0; // runtime requirement. May be checked by
> static analyzers and/or compilers, probably depending on buid mode.
> return x / 2;
> }
>
> Depending on the position and contents of the requires statement(?) it
> would act as an invariant, precondition or postcondition. I guess you cou=
ld
> view this as conceptual requirements just being constexpr contracts
> possible to evaluate at compile time, but this would make it hard to
> explain why concept overloading is possible. Inverting that thought would
> end up with more functional programming:
>
> int fac(int x) requires x =3D=3D 0 // Runtime contract.
> {
> return 1;
> }
>
> int fac(int x)
> {
> return fac(x - 1) * x;
> }
>
> This does not seem that easy to implement, though. Probably a can of worm=
s
> not worth opening...
>
> --
> 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/56bb80fc-cb3=
d-439e-9746-455df5ddb2d3%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56bb80fc-cb=
3d-439e-9746-455df5ddb2d3%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAPCFJdRgJOiX9x3eLBrKrgCQq8dfamia94AKSvKsyy2KScn=
yuQ%40mail.gmail.com.
--089e08236db8ae2d520552756056
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 20=
, 2017 at 11:45 PM Bengt Gustafsson <<a href=3D"mailto:bengt.gustafsson@=
beamways.com">bengt.gustafsson@beamways.com</a>> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>1. Using a concept as a templ=
ate parameter the way you indicate needs a use case to convince me. I think=
this will be hard to find as the idea of a concept is to </div></div></blo=
ckquote><div><br></div><div>Here's my attempt:</div><div><br></div><div=
>I'm implementing a type erasure library, and I want to use concepts to=
check whether types actually fit the archetype of the "typeclass"=
; that I'm erasing. To do that, I'd need to generate a concept per =
member function name (obviously) to check whether that class has a member w=
ith a given name and signature.</div><div><br></div><div>I can't do thi=
s easily, because I need to somehow decompose the function types that my te=
mplate machinery gives me (as a single type).</div><div><br></div><div>Now,=
I'd need either of three things:</div><div>1) Using concepts as templa=
te parameters. This way I could have a type that kind of "explodes&quo=
t; the function type into its parameter. I have that implemented for type t=
emplates, and it's extremely useful for this; I can't do it for con=
cepts, for exactly this reason.</div><div>2) A potentially simpler fix: all=
owing member concepts of types, because then instead of exploding I could j=
ust have a member concept. This is of course the less generic solution, sin=
ce I'd need a wrapper for every "kind" of a concept, but I co=
uld live with it.</div><div>3) A feature to allow me to specialize concepts=
- then I can just use the decades old trick of pattern matching on the fun=
ction type.</div><div><br></div><div>(Hopefully the usage is clear enough, =
but I can spend more time on explaining it if it isn't.)</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>define what t=
he actual type has to be capable of to be possible to use. Being able to pa=
rameterize this would mean that the code of the function would have to adap=
t to the _actual concept_ by basically morphing the source code. Isn't =
this just the opposite of the idea of overloading template functions based =
on which concepts the actual template parameters fulfill. Thus the code of =
the two overloads is typically different to handle the different abilities =
of the actual types of the parameters.</div><div><br></div><div>When it com=
es to class templates this becomes more interesting as we currently can'=
;t overload them. With concepts available it seems far more reasonable to o=
verload template classes (although there is already a bit strange that you =
can't overload on the number of template parameters). I guess the curre=
nt reasoning is to build on the partial specialization functionality and al=
low class templates to be specialized on the concept level:</div><div><br><=
/div><div>template<typename T> class my_template {</div><div>=C2=A0 =
=C2=A0// base implementation</div><div>};</div><div><br></div><div>template=
<Sortable T> class my_template<T> {</div><div>=C2=A0 =C2=A0// o=
ptimized implementation using the sortedness of T</div><div>};</div><div><b=
r></div><div>I don't recall having seen such an example, but I assume t=
his is how it is supposed to work.</div><div><br></div>2. I didn't know=
that concepts for non-type template parameters were included in concepts l=
ite. If they are I can imagine that they have not been widely explored... b=
ut maybe this is just something that P0355 authors found plausible.<div><br=
></div><div>You write</div></div><div dir=3D"ltr"><div><div><br></div><div>=
<p class=3D"MsoNormal" style=3D"line-height:normal">Does it refer to a type=
that is Even? Does it refer to a type=C2=A0<span style=3D"font-family:&quo=
t;Times New Roman",serif">=E2=80=98</span>Even<span style=3D"font-fami=
ly:"Times New Roman",serif">=E2=80=99</span>, does it refer to an=
Even value (if yes, what type?) and how do we know, Even is a concept? We =
don<span style=3D"font-family:"Times New Roman",serif">=E2=80=99<=
/span>t.</p></div><div><br></div></div></div><div dir=3D"ltr"><div><div>reg=
arding this example:</div><div><br></div><div><div class=3D"m_1784854522236=
596575prettyprint" style=3D"background-color:rgb(250,250,250);border-color:=
rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word">=
<code class=3D"m_1784854522236596575prettyprint"><div class=3D"m_1784854522=
236596575subprettyprint"></div></code></div></div></div></div><div dir=3D"l=
tr"><div><div><div class=3D"m_1784854522236596575prettyprint" style=3D"back=
ground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:so=
lid;border-width:1px;word-wrap:break-word"><code class=3D"m_178485452223659=
6575prettyprint"><div class=3D"m_1784854522236596575subprettyprint"><p clas=
s=3D"MsoNormal" style=3D"line-height:normal;font-family:Arial,Helvetica,san=
s-serif;background-color:rgb(255,255,255)"><i><span style=3D"font-size:10pt=
;font-family:"Source Code Pro Medium";background:silver"><span st=
yle=3D"color:#008" class=3D"m_1784854522236596575styled-by-prettify">templa=
te</span><span style=3D"color:#660" class=3D"m_1784854522236596575styled-by=
-prettify"><</span><span style=3D"color:#008" class=3D"m_178485452223659=
6575styled-by-prettify">int</span><span style=3D"color:#000" class=3D"m_178=
4854522236596575styled-by-prettify"> N</span><span style=3D"color:#660" cla=
ss=3D"m_1784854522236596575styled-by-prettify">></span><span style=3D"co=
lor:#000" class=3D"m_1784854522236596575styled-by-prettify"> </span><span s=
tyle=3D"color:#008" class=3D"m_1784854522236596575styled-by-prettify">conce=
pt</span><span style=3D"color:#000" class=3D"m_1784854522236596575styled-by=
-prettify"> </span><span style=3D"color:#008" class=3D"m_178485452223659657=
5styled-by-prettify">bool</span><span style=3D"color:#000" class=3D"m_17848=
54522236596575styled-by-prettify"> </span><span style=3D"color:#606" class=
=3D"m_1784854522236596575styled-by-prettify">Even</span><span style=3D"colo=
r:#000" class=3D"m_1784854522236596575styled-by-prettify"> </span><span sty=
le=3D"color:#660" class=3D"m_1784854522236596575styled-by-prettify">=3D</sp=
an><span style=3D"color:#000" class=3D"m_1784854522236596575styled-by-prett=
ify"> N </span><span style=3D"color:#660" class=3D"m_1784854522236596575sty=
led-by-prettify">%</span><span style=3D"color:#000" class=3D"m_178485452223=
6596575styled-by-prettify"> </span><span style=3D"color:#066" class=3D"m_17=
84854522236596575styled-by-prettify">2</span><span style=3D"color:#000" cla=
ss=3D"m_1784854522236596575styled-by-prettify"> </span><span style=3D"color=
:#660" class=3D"m_1784854522236596575styled-by-prettify">=3D=3D</span><span=
style=3D"color:#000" class=3D"m_1784854522236596575styled-by-prettify"> </=
span><span style=3D"color:#066" class=3D"m_1784854522236596575styled-by-pre=
ttify">0</span><span style=3D"color:#660" class=3D"m_1784854522236596575sty=
led-by-prettify">;</span></span></i><i><span style=3D"font-size:10pt;font-f=
amily:"Source Code Pro Medium""></span></i></p><p class=3D"MsoNor=
mal" style=3D"line-height:normal;font-family:Arial,Helvetica,sans-serif;bac=
kground-color:rgb(255,255,255)"><i><span style=3D"color:#606" class=3D"m_17=
84854522236596575styled-by-prettify">This</span><span style=3D"color:#000" =
class=3D"m_1784854522236596575styled-by-prettify"> seems quite reasonable <=
/span><span style=3D"color:#660" class=3D"m_1784854522236596575styled-by-pr=
ettify">(</span><span style=3D"color:#008" class=3D"m_1784854522236596575st=
yled-by-prettify">if</span><span style=3D"color:#000" class=3D"m_1784854522=
236596575styled-by-prettify"> perhaps </span><span style=3D"color:#008" cla=
ss=3D"m_1784854522236596575styled-by-prettify">not</span><span style=3D"col=
or:#000" class=3D"m_1784854522236596575styled-by-prettify"> all that useful=
</span><span style=3D"color:#660" class=3D"m_1784854522236596575styled-by-p=
rettify">):</span></i></p></div></code></div></div></div></div><div dir=3D"=
ltr"><div><div><div class=3D"m_1784854522236596575prettyprint" style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px;word-wrap:break-word"><code class=3D"m_17848545222365=
96575prettyprint"><div class=3D"m_1784854522236596575subprettyprint"><p cla=
ss=3D"MsoNormal" style=3D"line-height:normal;font-family:Arial,Helvetica,sa=
ns-serif;background-color:rgb(255,255,255)"><i><span style=3D"font-size:10p=
t;font-family:"Source Code Pro Medium";background:silver"><span s=
tyle=3D"color:#008" class=3D"m_1784854522236596575styled-by-prettify">templ=
ate</span><span style=3D"color:#660" class=3D"m_1784854522236596575styled-b=
y-prettify"><</span><span style=3D"color:#606" class=3D"m_17848545222365=
96575styled-by-prettify">Even</span><span style=3D"color:#000" class=3D"m_1=
784854522236596575styled-by-prettify"> N</span><span style=3D"color:#660" c=
lass=3D"m_1784854522236596575styled-by-prettify">></span><span style=3D"=
color:#000" class=3D"m_1784854522236596575styled-by-prettify"> </span><span=
style=3D"color:#008" class=3D"m_1784854522236596575styled-by-prettify">voi=
d</span><span style=3D"color:#000" class=3D"m_1784854522236596575styled-by-=
prettify"> f</span><span style=3D"color:#660" class=3D"m_178485452223659657=
5styled-by-prettify">()</span><span style=3D"color:#000" class=3D"m_1784854=
522236596575styled-by-prettify"> </span><span style=3D"color:#660" class=3D=
"m_1784854522236596575styled-by-prettify">{</span></span></i></p><p class=
=3D"MsoNormal" style=3D"line-height:normal;font-family:Arial,Helvetica,sans=
-serif;background-color:rgb(255,255,255);text-indent:36pt"><i><span style=
=3D"font-size:10pt;font-family:"Source Code Pro Medium";backgroun=
d:silver"><span style=3D"color:#008" class=3D"m_1784854522236596575styled-b=
y-prettify">constexpr</span><span style=3D"color:#000" class=3D"m_178485452=
2236596575styled-by-prettify"> </span><span style=3D"color:#606" class=3D"m=
_1784854522236596575styled-by-prettify">Even</span><span style=3D"color:#00=
0" class=3D"m_1784854522236596575styled-by-prettify"> X </span><span style=
=3D"color:#660" class=3D"m_1784854522236596575styled-by-prettify">=3D</span=
><span style=3D"color:#000" class=3D"m_1784854522236596575styled-by-prettif=
y"> N</span><span style=3D"color:#660" class=3D"m_1784854522236596575styled=
-by-prettify">;</span></span></i></p><p class=3D"MsoNormal" style=3D"line-h=
eight:normal;font-family:Arial,Helvetica,sans-serif;background-color:rgb(25=
5,255,255)"><i><span style=3D"font-size:10pt;font-family:"Source Code =
Pro Medium";background:silver"><span style=3D"color:#660" class=3D"m_1=
784854522236596575styled-by-prettify">}</span></span></i><i><span style=3D"=
font-size:10pt;font-family:"Source Code Pro Medium""></span></i><=
/p><div><i><span style=3D"font-size:10pt;font-family:"Source Code Pro =
Medium";background:silver"><span style=3D"color:#000" class=3D"m_17848=
54522236596575styled-by-prettify"><br></span></span></i></div></div></code>=
</div><br>I think it is fairly clear that N is a int template parameter. Th=
e contents of the {} seems malformed, as Even is not a type. Shouldn't =
it be "constexpr int X =3D N;" ?</div><div><br></div><div>This sa=
id, your suggested syntax with the concept as a prefix of a type or typenam=
e has something going for it as it clearly notifies the reader that there i=
s a concept involved without having to find the declaration. Before going m=
uch further with this idea we must contemplate if this syntax would work in=
all places where concepts can be mentioned, and whether it would bloat the=
code too much to have to type=C2=A0<span style=3D"color:rgb(0,0,136);backg=
round-color:rgb(250,250,250)">typename=C2=A0</span>in even more places than=
we currently do.</div></div><div><br></div><div>I also find your analogy b=
etween concepts and contracts an interesting thought. How about using the n=
ew requires keyword on the contract level also?</div><div><br></div><div>te=
mplate<typename T> T div_by_two(T x) requires Integral<T> =C2=
=A0 =C2=A0// Compile time requirement</div><div>{</div><div>=C2=A0 =C2=A0 r=
equires x & 1 =3D=3D 0; =C2=A0 // runtime requirement. May be checked b=
y static analyzers and/or compilers, probably depending on buid mode.</div>=
<div>=C2=A0 =C2=A0 return x / 2;</div><div>}</div><div><br></div><div>Depen=
ding on the position and contents of the requires statement(?) it would act=
as an invariant, precondition or postcondition. I guess you could view thi=
s as conceptual requirements just being constexpr contracts possible to eva=
luate at compile time, but this would make it hard to explain why concept o=
verloading is possible. Inverting that thought would end up with more funct=
ional programming:</div><div><br></div><div>int fac(int x) requires x =3D=
=3D 0 =C2=A0 =C2=A0// Runtime contract.</div><div>{=C2=A0</div><div>=C2=A0 =
=C2=A0return 1;</div><div>}</div><div><br></div><div>int fac(int x)</div><d=
iv>{</div><div>=C2=A0 =C2=A0return fac(x - 1) * x;</div><div>}</div><div><b=
r></div><div>This does not seem that easy to implement, though. Probably a =
can of worms not worth opening...</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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/56bb80fc-cb3d-439e-9746-455df5ddb2d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/56bb80fc-cb3d-=
439e-9746-455df5ddb2d3%40isocpp.org</a>.<br>
</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/CAPCFJdRgJOiX9x3eLBrKrgCQq8dfamia94AK=
SvKsyy2KScnyuQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRgJOiX9x3e=
LBrKrgCQq8dfamia94AKSvKsyy2KScnyuQ%40mail.gmail.com</a>.<br />
--089e08236db8ae2d520552756056--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 21 Jun 2017 15:28:38 -0700 (PDT)
Raw View
------=_Part_5369_1073268088.1498084118959
Content-Type: multipart/alternative;
boundary="----=_Part_5370_1557085466.1498084118961"
------=_Part_5370_1557085466.1498084118961
Content-Type: text/plain; charset="UTF-8"
Den onsdag 21 juni 2017 kl. 11:18:26 UTC+2 skrev Jakob Riedle:
>
> Hi Folks,
>
> first of all thank you for your participation and all the constructive
> replys!
>
> Thank you Richard, you managed to express it even more clearly!: "concepts
> are adjectives, not nouns."
>
> As it seems that this Idea is favourited by many people, let's talk about
> value concepts since I have the strong feeling we should approach all
> concepts/contracts in the same fashion.
>
> Namely I'd like to ask you, in what way contracts do the same thing as
> concepts and where they do something different.
> Concepts on types do participate in the type system and thus overload
> resolution.
> On the other hand, concepts on values might only be detectable at runtime.
> Thus overload resolution has no clue about them. Is this desired, given
> that we want to include mor functional programming into C++?
> It might have great benefits to include them within the type system as the
> following example allows to dream:
>
> // Given:
> void f( Even int );
>
>
> int my_int = 4;
>
> f( my_int ); // warning: implicit cast from 'int' to 'Even int'
> f( claim<Even>( my_int ) ); // ok (e.g. Runtime Check with Debug Build,
> No Check with Release build)
>
> // some sugar if you will?
> f( !Even! my_int );
>
> Besides that, it feels very natural to me to include them into the type
> system, although I cannot yet say what semantics it should have.
>
To me it is not totally obvious that "as concepts on values might only be
detectable at runtime overload resolution has no clue about them."
Many functional languages actually do implement runtime dispatching to
different implementation based on parameter values, and it is conceivable
that when using a concept like Even as the type of a normal function
parameter this could be a way to indicate that a runtime dispatch
subroutine has to be created:
f(Even x) { cout << "Even"; }
f(Odd x) { cout << "Odd"; }
for (int i = 0; i<2; i++)
f(i);
prints:
EvenOdd
The call site or a stub would have to be compiled to code containing an if
on i, but I don't see that as hard to do. The scary part is the variability
of the overload set, sometimes forcing creation of multiple stubs depending
on how many function overloads have been seen.
Also note that in the absence of the f(Odd x) declaration this could
degenerate to an assert that x is Even as there is no overload to call
otherwise.
While I'm not advocating for such an idea (at least not yet) I would say it
is premature to rule it out, given that this is how some other languages
deal with the situation...
>
>
> Am Dienstag, 20. Juni 2017 23:45:31 UTC+2 schrieb Bengt Gustafsson:
>>
>> 1. Using a concept as a template parameter the way you indicate needs a
>> use case to convince me. I think this will be hard to find as the idea of a
>> concept is to define what the actual type has to be capable of to be
>> possible to use.
>>
>
> The reason I had the idea was an actual use case: Defining a Concept that
> describes a Multidimensional Datastructure. Expressing this is done in
> analogy to a range of ranges of ranges and so on... (to the depth you want
> it)
> Since we don't want to restrict ourself to a specific *class *of Ranges,
> the 'MultidimensionalRange' Concept is itself templated with concepts.
>
> With the Concepts of Ranges TS (and the Syntax of Concepts Lite, extended
> with concepts as template parameters):
>
> // Forward declaration
> template<typename T, template<typename T> concept bool... RangeConcepts>
> concept bool MultiDimRange;
>
> // Recursive Case
> template<
> typename T ,
> template<typename T> concept bool RangeConcept0 ,
> template<typename T> concept bool RangeConcept1 ,
> template<typename T> concept bool... RangeConcepts
> >
> concept bool MultiDimRange<T, RangeCocept0, RangeConcept1, RangeConcepts
> ...> =
> Range<T> /* From Ranges TS */
> && RangeConcept0<T>
> && MultidimensionalRange<
> ranges::value_type<T> ,
> RangeConcept1 ,
> RangeConcepts...
> >
> ;
>
> // Base Case
> template<
> typename T ,
> template<typename T> concept bool RangeConcept
> >
> concept bool MultiDimRange<T, RangeConcept> = Range<T> /* <- From Ranges
> TS */ && RangeConcept<T>;
>
>
> // Using the Declarations:
> template<typename T>
> concept bool MyMatrixType = MultiDimRange<T, RandomAccessRange,
> RandomAccessRange>;
>
> template<MyMatrixType T>
> T matrixMultiply( T m1 , T m2 ){
> // e.g.
> int i, j;
> m1[i][j] // This is defined!
> }
>
>
> I don't know if concepts will be passed as template parameter to
> non-concepts, but they will definitely need to be passed as template
> parameters to other concepts to refine them.
>
> Wow. This gets compliacated. Does this code compile with the concept aware
GCC version?
I have a related issue I was aiming to bring up in a separate thread, but
as you started discussing multi-dimensional arrays I will out it here:
Is it possible to write a concept requiring that the multi-dimensional
matrix must have an overloaded operator() with as many indices as there are
dimensions? Is it even possible to write a concept that specifies that
there should be a method of a certain name that takes a unbounded number of
parameters?
I have not understood how as in concepts-lite you write "example code" to
express requirements, and there seems to be no way to exemplify that a
method must be callable with any number of parameters short of listing each
case... With the old concepts where requirements were formed as method
declarations this would have been natural, just write your
template<typename... Ts> my_fun(const Ts... ts) thingy.
A lesser version of this limitation also exists in the concrete
template<size_t RANK> class Matrix; case where you can't specify that an
operator() with RANK number of parameters exists, this will be revealed
only at the last recursive template instantiation step, just one of those
things that concepts should alleviate. I hope they do, but I for one can't
figure out how to specify it.
> Cheers,
> Jakob
>
--
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/d1905438-7265-46bb-85c2-91b4c95e9a20%40isocpp.org.
------=_Part_5370_1557085466.1498084118961
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Den onsdag 21 juni 2017 kl. 11:18:26 UTC+2 skrev J=
akob Riedle:<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>Hi Folks,</div><div><br></div><div>first of all thank you for your part=
icipation and all the constructive replys!</div><div><br></div><div>Thank y=
ou Richard, you managed to express it even more clearly!: "concepts ar=
e adjectives, not nouns."</div><div><br></div><div>As it seems that th=
is Idea is favourited by many people, let's talk about value concepts s=
ince I have the strong feeling we should approach all concepts/contracts in=
the same fashion.</div><div><br></div><div>Namely I'd like to ask you,=
in what way contracts do the same thing as concepts and where they do some=
thing different.</div><div>Concepts on types do participate in the type sys=
tem and thus overload resolution.</div><div>On the other hand, concepts on =
values might only be detectable at runtime. Thus overload resolution has no=
clue about them. Is this desired, given that we want to include mor functi=
onal programming into C++?</div><div>It might have great benefits to includ=
e them within the type system as the following example allows to dream:</di=
v><div><br></div><div><div style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:brea=
k-word"><code><div><span style=3D"color:#800">// Given:</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">void</span><span styl=
e=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span style=3D=
"color:#000"> </span><span style=3D"color:#606">Even</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">int</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">);</span><span style=3D"color:#0=
00"><br><br><br></span><span style=3D"color:#008">int</span><span style=3D"=
color:#000"> my_int </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#066">4</span><span style=3D"c=
olor:#660">;</span><span style=3D"color:#000"><br><br>f</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000"> my_int </span><span sty=
le=3D"color:#660">);</span><span style=3D"color:#000"> </span><span style=
=3D"color:#800">// warning: implicit cast from 'int' to 'Even i=
nt'</span><span style=3D"color:#000"><br>f</span><span style=3D"color:#=
660">(</span><span style=3D"color:#000"> claim</span><span style=3D"color:#=
660"><</span><span style=3D"color:#606">Even</span><span style=3D"color:=
#660">>(</span><span style=3D"color:#000"> my_int </span><span style=3D"=
color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">);</span><span style=3D"color:#000"> </span><span style=3D"color:#80=
0">// ok (e.g. Runtime Check with Debug Build, No Check with Release build)=
</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#800"=
>// some sugar if you will?</span><span style=3D"color:#000"><br>f</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">!</span><span style=3D"color:#606">Even</span><span sty=
le=3D"color:#660">!</span><span style=3D"color:#000"> my_int </span><span s=
tyle=3D"color:#660">);</span><span style=3D"color:#000"><br></span></div></=
code></div><div><br></div><div>Besides that, it feels very natural to me to=
include them into the type system, although I cannot yet say what semantic=
s it should have.</div></div></div></blockquote><div>To me it is not totall=
y obvious that "as concepts on values might only be detectable at runt=
ime overload resolution has no clue about them."</div><div>Many functi=
onal languages actually do implement runtime dispatching to different imple=
mentation based on parameter values, and it is conceivable that when using =
a concept like Even as the type of a normal function parameter this could b=
e a way to indicate that a runtime dispatch subroutine has to be created:</=
div><div><br></div><div>f(Even x) { cout << "Even"; }</div>=
<div>f(Odd x) { cout << "Odd"; }</div><div><br></div><div>f=
or (int i =3D 0; i<2; i++)</div><div>=C2=A0 =C2=A0 f(i);</div><div><br><=
/div><div>prints:</div><div>EvenOdd</div><div><br></div><div>The call site =
or a stub would have to be compiled to code containing an if on i, but I do=
n't see that as hard to do. The scary part is the variability of the ov=
erload set, sometimes forcing creation of multiple stubs depending on how m=
any function overloads have been seen.</div><div><br></div><div>Also note t=
hat in the absence of the f(Odd x) declaration this could degenerate to an =
assert that x is Even as there is no overload to call otherwise.</div><div>=
<br></div><div>While I'm not advocating for such an idea (at least not =
yet) I would say it is premature to rule it out, given that this is how som=
e other languages deal with the situation...</div><div><br></div><blockquot=
e 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><br></div><div><br=
></div><div><br></div>Am Dienstag, 20. Juni 2017 23:45:31 UTC+2 schrieb Ben=
gt Gustafsson:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>1. Using a concept as a template parameter the way you indicate needs a us=
e case to convince me. I think this will be hard to find as the idea of a c=
oncept is to define what the actual type has to be capable of to be possibl=
e to use.</div></div></blockquote><div><br></div><div>The reason I had the =
idea was an actual use case: Defining a Concept that describes a Multidimen=
sional Datastructure. Expressing this is done in analogy to a range of rang=
es of ranges and so on... (to the depth you want it)</div><div>Since we don=
't want to restrict ourself to a specific <i>class </i>of Ranges, the &=
#39;MultidimensionalRange' Concept is itself templated with concepts.</=
div><div><br></div><div>With the Concepts of Ranges TS (and the Syntax of C=
oncepts Lite, extended with concepts as template parameters):</div><div>=C2=
=A0<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187=
,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div>=
<span style=3D"color:#800">// Forward declaration</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#008">template</span><span style=3D=
"color:#660"><</span><span style=3D"color:#008">typename</span><span sty=
le=3D"color:#000"> T</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">template</span><span sty=
le=3D"color:#660"><</span><span style=3D"color:#008">typename</span><spa=
n style=3D"color:#000"> T</span><span style=3D"color:#660">></span><span=
style=3D"color:#000"> </span><span style=3D"color:#008">concept</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">bool</span><span =
style=3D"color:#660">...</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#606">RangeConcepts</span><span style=3D"color:#660">></span=
><span style=3D"color:#000"><br></span><span style=3D"color:#008">concept</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">bool</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:rgb(102,0,102)">=
<span style=3D"color:#606">MultiDimRange</span></span><font color=3D"#00000=
0"><span style=3D"color:#660">;</span><span style=3D"color:#000"><br><br></=
span><span style=3D"color:#800">// Recursive Case</span><span style=3D"colo=
r:#000"><br></span></font><span style=3D"color:#008">template</span><span s=
tyle=3D"color:#660"><</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0=
</span><span style=3D"color:#008">typename</span><span style=3D"color:#000=
"> T </span><span style=3D"color:#660">,</span><span style=3D"color:#000"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">template</span><span sty=
le=3D"color:#660"><</span><span style=3D"color:#008">typename</span><spa=
n style=3D"color:#000"> T</span><span style=3D"color:#660">></span><span=
style=3D"color:#000"> </span><span style=3D"color:#008">concept</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">bool</span><span =
style=3D"color:#000"> </span><span style=3D"color:#606">RangeConcept0</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">,</span><spa=
n style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">=
template</span><span style=3D"color:#660"><</span><span style=3D"color:#=
008">typename</span><span style=3D"color:#000"> T</span><span style=3D"colo=
r:#660">></span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">concept</span><span style=3D"color:#000"> </span><span style=3D"color=
:#008">bool</span><span style=3D"color:#000"> </span><span style=3D"color:#=
606">RangeConcept1</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">,</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color:#008">template</span><span style=3D"color:#660"><</spa=
n><span style=3D"color:#008">typename</span><span style=3D"color:#000"> T</=
span><span style=3D"color:#660">></span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">concept</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">bool</span><span style=3D"color:#660">...</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#606">RangeConc=
epts</span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>></span><span style=3D"color:#000"><br></span><span style=3D"color:#008=
">concept</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">bool</span><span style=3D"color:#000"> </span><span style=3D"color:rgb(1=
02,0,102)"><span style=3D"color:#606">MultiDimRange</span></span><span styl=
e=3D"color:#660"><</span><span style=3D"color:#000">T</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#606">RangeCocept0</span><span style=3D"color:#660">,</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#606">RangeConcept1</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#606">RangeConcepts</span><span style=3D"color:#660">...></=
span><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</spa=
n><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:=
#606">Range</span><span style=3D"color:#660"><</span><span style=3D"colo=
r:#000">T</span><span style=3D"color:#660">></span><span style=3D"color:=
#000"> </span><span style=3D"color:#800">/* From Ranges TS */</span><span s=
tyle=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">&am=
p;&</span><span style=3D"color:#000"> </span><span style=3D"color:#606"=
>RangeConcept0</span><span style=3D"color:#660"><</span><span style=3D"c=
olor:#000">T</span><span style=3D"color:#660">></span><span style=3D"col=
or:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">&&</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#606">Multidimen=
sionalRange</span><span style=3D"color:#660"><</span><span style=3D"colo=
r:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ranges</span><span style=3D"color:#=
660">::</span><span style=3D"color:#000">value_type</span><span style=3D"co=
lor:#660"><</span><span style=3D"color:#000">T</span><span style=3D"colo=
r:#660">></span><span style=3D"color:#000"> </span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </=
span><span style=3D"color:#606">RangeConcept1</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#660">,</span><span style=3D"color:#000"><=
br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#606">RangeConce=
pts</span><span style=3D"color:#660">...</span><span style=3D"color:#000"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">></span><span style=
=3D"color:#000"><br></span><font color=3D"#000000"><span style=3D"color:#66=
0">;</span></font><font color=3D"#660066"><span style=3D"color:#000"><br><b=
r></span><span style=3D"color:#800">// Base Case</span><span style=3D"color=
:#000"><br></span><span style=3D"color:#008">template</span><span style=3D"=
color:#660"><</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span>=
<span style=3D"color:#008">typename</span><span style=3D"color:#000"> T </s=
pan><span style=3D"color:#660">,</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color:#008">template</span><span style=3D"=
color:#660"><</span><span style=3D"color:#008">typename</span><span styl=
e=3D"color:#000"> T</span><span style=3D"color:#660">></span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">concept</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">bool</span><span style=
=3D"color:#000"> </span></font><span style=3D"color:#606">RangeConcept</spa=
n><span style=3D"color:#000"><br></span><font color=3D"#660066"><span style=
=3D"color:#660">></span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#008">concept</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">bool</span><span style=3D"color:#000"> </span></font><spa=
n style=3D"color:rgb(102,0,102)"><span style=3D"color:#606">MultiDimRange</=
span></span><font color=3D"#660066"><span style=3D"color:#660"><</span><=
span style=3D"color:#000">T</span><span style=3D"color:#660">,</span><span =
style=3D"color:#000"> </span></font><span style=3D"color:#606">RangeConcept=
</span><font color=3D"#660066"><span style=3D"color:#660">></span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> </span></font><span style=3D"color:#606">Range</span><sp=
an style=3D"color:#660"><</span><span style=3D"color:#000">T</span><span=
style=3D"color:#660">></span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#800">/* <- From Ranges TS */</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">&&</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#606">RangeConcept</span><span style=
=3D"color:#660"><</span><span style=3D"color:#000">T</span><span style=
=3D"color:#660">>;</span><span style=3D"color:#000"><br><br><br></span><=
span style=3D"color:#800">// Using the Declarations:</span><span style=3D"c=
olor:#000"><br></span><span style=3D"color:#008">template</span><span style=
=3D"color:#660"><</span><span style=3D"color:#008">typename</span><span =
style=3D"color:#000"> T</span><span style=3D"color:#660">></span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#008">concept</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#008">bool</span><span=
style=3D"color:#000"> </span><span style=3D"color:#606">My</span><font col=
or=3D"#660066"><span style=3D"color:#606">MatrixType</span><span style=3D"c=
olor:#000"> </span></font><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">MultiDimRange</span><spa=
n style=3D"color:#660"><</span><span style=3D"color:#000">T</span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">RandomAccessRange</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span style=3D"color:rgb(102,0,102)"><sp=
an style=3D"color:#606">RandomAccessRange</span></span><span style=3D"color=
:#660">>;</span><span style=3D"color:#000"><br><br></span><span style=3D=
"color:#008">template</span><span style=3D"color:#660"><</span><span sty=
le=3D"color:#606">My</span><font color=3D"#660066"><span style=3D"color:#60=
6">MatrixType</span><span style=3D"color:#000"> </span></font><span style=
=3D"color:#000">T</span><span style=3D"color:#660">></span><span style=
=3D"color:#000"><br>T matrixMultiply</span><span style=3D"color:#660">(</sp=
an><span style=3D"color:#000"> </span><font color=3D"#660066"><span style=
=3D"color:#000">T </span></font><span style=3D"color:#000">m1 </span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"> </span><font color=
=3D"#660066"><span style=3D"color:#000">T </span></font><span style=3D"colo=
r:#000">m2 </span><span style=3D"color:#660">){</span><font color=3D"#88000=
0"><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color=
:#800">// e.g.</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><s=
pan style=3D"color:#008">int</span><span style=3D"color:#000"> i</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> j</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 m1<=
/span><span style=3D"color:#660">[</span><span style=3D"color:#000">i</span=
><span style=3D"color:#660">][</span><span style=3D"color:#000">j</span><sp=
an style=3D"color:#660">]</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#800">// This is defined!</span></font><span style=3D"color:#0=
00"><br></span><span style=3D"color:#660">}</span><span style=3D"color:#000=
"><br></span><font color=3D"#666600"></font></div></code></div><br></div><d=
iv><br></div><div>I don't know if concepts will be passed as template p=
arameter to non-concepts, but they will definitely need to be passed as tem=
plate parameters to other concepts to refine them.</div><div><br></div></di=
v></blockquote><div>Wow. This gets compliacated. Does this code compile wit=
h the concept aware GCC version?</div><div><br></div><div>I have a related =
issue I was aiming to bring up in a separate thread, but as you started dis=
cussing multi-dimensional arrays I will out it here:</div><div><br></div><d=
iv>Is it possible to write a concept requiring that the multi-dimensional m=
atrix must have an overloaded operator() with as many indices as there are =
dimensions? Is it even possible to write a concept that specifies that ther=
e should be a method of a certain name that takes a unbounded number of par=
ameters?=C2=A0</div><div><br></div><div>I have not understood how as in con=
cepts-lite you write "example code" to express requirements, and =
there seems to be no way to exemplify that a method must be callable with a=
ny number of parameters short of listing each case... With the old concepts=
where requirements were formed as method declarations this would have been=
natural, just write your template<typename... Ts> my_fun(const Ts...=
ts) thingy.</div><div><br></div><div>A lesser version of this limitation a=
lso exists in the concrete template<size_t RANK> class Matrix; case w=
here you can't specify that an operator() with RANK number of parameter=
s exists, this will be revealed only at the last recursive template instant=
iation step, just one of those things that concepts should alleviate. I hop=
e they do, but I for one can't figure out how to specify it.</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"ltr"><div></div><div>Cheers,</div><div>Jakob</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/d1905438-7265-46bb-85c2-91b4c95e9a20%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d1905438-7265-46bb-85c2-91b4c95e9a20=
%40isocpp.org</a>.<br />
------=_Part_5370_1557085466.1498084118961--
------=_Part_5369_1073268088.1498084118959--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 21 Jun 2017 15:36:33 -0700 (PDT)
Raw View
------=_Part_5487_1713026765.1498084593189
Content-Type: multipart/alternative;
boundary="----=_Part_5488_759552061.1498084593189"
------=_Part_5488_759552061.1498084593189
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I think you may have to elaborate to make this more understandable. To me=
=20
it seems that your use case just calls for a regular concept for the type=
=20
to be erased, which describes each method that the type erasing wrapper has=
..
Den onsdag 21 juni 2017 kl. 11:56:13 UTC+2 skrev Micha=C5=82 Dominiak:
>
> On Tue, Jun 20, 2017 at 11:45 PM Bengt Gustafsson <
> bengt.gu...@beamways.com <javascript:>> wrote:
>
>> 1. Using a concept as a template parameter the way you indicate needs a=
=20
>> use case to convince me. I think this will be hard to find as the idea o=
f a=20
>> concept is to=20
>>
>
> Here's my attempt:
>
> I'm implementing a type erasure library, and I want to use concepts to=20
> check whether types actually fit the archetype of the "typeclass" that I'=
m=20
> erasing. To do that, I'd need to generate a concept per member function=
=20
> name (obviously) to check whether that class has a member with a given na=
me=20
> and signature.
>
> I can't do this easily, because I need to somehow decompose the function=
=20
> types that my template machinery gives me (as a single type).
>
> Now, I'd need either of three things:
> 1) Using concepts as template parameters. This way I could have a type=20
> that kind of "explodes" the function type into its parameter. I have that=
=20
> implemented for type templates, and it's extremely useful for this; I can=
't=20
> do it for concepts, for exactly this reason.
> 2) A potentially simpler fix: allowing member concepts of types, because=
=20
> then instead of exploding I could just have a member concept. This is of=
=20
> course the less generic solution, since I'd need a wrapper for every "kin=
d"=20
> of a concept, but I could live with it.
> 3) A feature to allow me to specialize concepts - then I can just use the=
=20
> decades old trick of pattern matching on the function type.
>
> (Hopefully the usage is clear enough, but I can spend more time on=20
> explaining it if it isn't.)
>
I think you may have to elaborate to make this more understandable. To me=
=20
it seems that your use case just calls for a regular concept for the type=
=20
to be erased, which describes each method that the type erasing wrapper=20
has. I could speculate that your trying to make a "general typ erasor"=20
where each method of the wrapped archetype is a member function template=20
parameter or something like that, if so it clearly needs more explanation.=
=20
Also maybe it could be taken as proof for the need for virtual concepts (or=
=20
proxies as they are called in another nearby thread).
=20
=20
--=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/18b35423-7a3f-4aff-8f12-eef1e5b87acb%40isocpp.or=
g.
------=_Part_5488_759552061.1498084593189
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think you may have to elaborate to make this more unders=
tandable. To me it seems that your use case just calls for a regular concep=
t for the type to be erased, which describes each method that the type eras=
ing wrapper has.<div><br></div><div><br><br>Den onsdag 21 juni 2017 kl. 11:=
56:13 UTC+2 skrev Micha=C5=82 Dominiak:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tu=
e, Jun 20, 2017 at 11:45 PM Bengt Gustafsson <<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"tKmKUqJMAAAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">bengt.gu...@beamways.com</a><wb=
r>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>1. Using a concept as a template parameter the way you indicate needs a us=
e case to convince me. I think this will be hard to find as the idea of a c=
oncept is to </div></div></blockquote><div><br></div><div>Here's my att=
empt:</div><div><br></div><div>I'm implementing a type erasure library,=
and I want to use concepts to check whether types actually fit the archety=
pe of the "typeclass" that I'm erasing. To do that, I'd n=
eed to generate a concept per member function name (obviously) to check whe=
ther that class has a member with a given name and signature.</div><div><br=
></div><div>I can't do this easily, because I need to somehow decompose=
the function types that my template machinery gives me (as a single type).=
</div><div><br></div><div>Now, I'd need either of three things:</div><d=
iv>1) Using concepts as template parameters. This way I could have a type t=
hat kind of "explodes" the function type into its parameter. I ha=
ve that implemented for type templates, and it's extremely useful for t=
his; I can't do it for concepts, for exactly this reason.</div><div>2) =
A potentially simpler fix: allowing member concepts of types, because then =
instead of exploding I could just have a member concept. This is of course =
the less generic solution, since I'd need a wrapper for every "kin=
d" of a concept, but I could live with it.</div><div>3) A feature to a=
llow me to specialize concepts - then I can just use the decades old trick =
of pattern matching on the function type.</div><div><br></div><div>(Hopeful=
ly the usage is clear enough, but I can spend more time on explaining it if=
it isn't.)</div></div></div></blockquote><div><br></div>I think you ma=
y have to elaborate to make this more understandable. To me it seems that y=
our use case just calls for a regular concept for the type to be erased, wh=
ich describes each method that the type erasing wrapper has. I could specul=
ate that your trying to make a "general typ erasor" where each me=
thod of the wrapped archetype is a member function template parameter or so=
mething like that, if so it clearly needs more explanation. Also maybe it c=
ould be taken as proof for the need for virtual concepts (or proxies as the=
y are called in another nearby thread).<div><br></div><div><br></div><div>=
=C2=A0</div><div>=C2=A0</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/18b35423-7a3f-4aff-8f12-eef1e5b87acb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/18b35423-7a3f-4aff-8f12-eef1e5b87acb=
%40isocpp.org</a>.<br />
------=_Part_5488_759552061.1498084593189--
------=_Part_5487_1713026765.1498084593189--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 21 Jun 2017 22:24:17 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">I can imagine this "runtime overloading" could be useful for th=
ings like optional. </div><div style=3D"width: 100%; font-size: initia=
l; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31=
, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">It =
is just pattern matching. </div> =
=
<div style=3D"width: 100%; font-size: initial; font-family: =
Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text=
-align: initial; background-color: rgb(255, 255, 255);"><br style=3D"displa=
y:initial"></div> =
=
<div style=3D=
"font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-se=
rif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(25=
5, 255, 255);">Sent from my BlackBerry portable Ba=
bbage Device</div> =
=
<table width=3D"100%" st=
yle=3D"background-color:white;border-spacing:0px;"> <tbody><tr><td colspan=
=3D"2" style=3D"font-size: initial; text-align: initial; background-color: =
rgb(255, 255, 255);"> <div style=3D"border-style:=
solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1=
pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'=
; font-size: 10pt;"> <div><b>From: </b>Bengt Gustafsson</div><div><b>Sent:=
</b>Wednesday, June 21, 2017 6:28 PM</div><div><b>To: </b>ISO C++ Standard=
- Future Proposals</div><div><b>Reply To: </b>std-proposals@isocpp.org</di=
v><div><b>Subject: </b>[std-proposals] Re: Clarification needed on Concepts=
(and Contracts?)</div></div></td></tr></tbody></table><div style=3D"border=
-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-w=
idth: 1pt; font-size: initial; text-align: initial; background-color: rgb(2=
55, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=
=3D"ltr"><br><br>Den onsdag 21 juni 2017 kl. 11:18:26 UTC+2 skrev Jakob Rie=
dle:<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>Hi F=
olks,</div><div><br></div><div>first of all thank you for your participatio=
n and all the constructive replys!</div><div><br></div><div>Thank you Richa=
rd, you managed to express it even more clearly!: "concepts are adjectives,=
not nouns."</div><div><br></div><div>As it seems that this Idea is favouri=
ted by many people, let's talk about value concepts since I have the strong=
feeling we should approach all concepts/contracts in the same fashion.</di=
v><div><br></div><div>Namely I'd like to ask you, in what way contracts do =
the same thing as concepts and where they do something different.</div><div=
>Concepts on types do participate in the type system and thus overload reso=
lution.</div><div>On the other hand, concepts on values might only be detec=
table at runtime. Thus overload resolution has no clue about them. Is this =
desired, given that we want to include mor functional programming into C++?=
</div><div>It might have great benefits to include them within the type sys=
tem as the following example allows to dream:</div><div><br></div><div><div=
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);b=
order-style:solid;border-width:1px;word-wrap:break-word"><code><div><span s=
tyle=3D"color:#800">// Given:</span><span style=3D"color:#000"><br></span><=
span style=3D"color:#008">void</span><span style=3D"color:#000"> f</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#606">Even</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">int</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">);</span><span style=3D"color:#000"><br><br><br></span><spa=
n style=3D"color:#008">int</span><span style=3D"color:#000"> my_int </span>=
<span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#066">4</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"><br><br>f</span><span style=3D"color:#660">(</span><span=
style=3D"color:#000"> my_int </span><span style=3D"color:#660">);</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#800">// warning: imp=
licit cast from 'int' to 'Even int'</span><span style=3D"color:#000"><br>f<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#000"> claim<=
/span><span style=3D"color:#660"><</span><span style=3D"color:#606">Even=
</span><span style=3D"color:#660">>(</span><span style=3D"color:#000"> m=
y_int </span><span style=3D"color:#660">)</span><span style=3D"color:#000">=
</span><span style=3D"color:#660">);</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#800">// ok (e.g. Runtime Check with Debug Build, =
No Check with Release build)</span><span style=3D"color:#000"><br><br></spa=
n><span style=3D"color:#800">// some sugar if you will?</span><span style=
=3D"color:#000"><br>f</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">!</span><span style=3D"c=
olor:#606">Even</span><span style=3D"color:#660">!</span><span style=3D"col=
or:#000"> my_int </span><span style=3D"color:#660">);</span><span style=3D"=
color:#000"><br></span></div></code></div><div><br></div><div>Besides that,=
it feels very natural to me to include them into the type system, although=
I cannot yet say what semantics it should have.</div></div></div></blockqu=
ote><div>To me it is not totally obvious that "as concepts on values might =
only be detectable at runtime overload resolution has no clue about them."<=
/div><div>Many functional languages actually do implement runtime dispatchi=
ng to different implementation based on parameter values, and it is conceiv=
able that when using a concept like Even as the type of a normal function p=
arameter this could be a way to indicate that a runtime dispatch subroutine=
has to be created:</div><div><br></div><div>f(Even x) { cout << "Eve=
n"; }</div><div>f(Odd x) { cout << "Odd"; }</div><div><br></div><div>=
for (int i =3D 0; i<2; i++)</div><div> f(i);</div><div><br>=
</div><div>prints:</div><div>EvenOdd</div><div><br></div><div>The call site=
or a stub would have to be compiled to code containing an if on i, but I d=
on't see that as hard to do. The scary part is the variability of the overl=
oad set, sometimes forcing creation of multiple stubs depending on how many=
function overloads have been seen.</div><div><br></div><div>Also note that=
in the absence of the f(Odd x) declaration this could degenerate to an ass=
ert that x is Even as there is no overload to call otherwise.</div><div><br=
></div><div>While I'm not advocating for such an idea (at least not yet) I =
would say it is premature to rule it out, given that this is how some other=
languages deal with the situation...</div><div><br></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><br></div>=
<div><br></div>Am Dienstag, 20. Juni 2017 23:45:31 UTC+2 schrieb Bengt Gust=
afsson:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>1. Usi=
ng a concept as a template parameter the way you indicate needs a use case =
to convince me. I think this will be hard to find as the idea of a concept =
is to define what the actual type has to be capable of to be possible to us=
e.</div></div></blockquote><div><br></div><div>The reason I had the idea wa=
s an actual use case: Defining a Concept that describes a Multidimensional =
Datastructure. Expressing this is done in analogy to a range of ranges of r=
anges and so on... (to the depth you want it)</div><div>Since we don't want=
to restrict ourself to a specific <i>class </i>of Ranges, the 'Multidimens=
ionalRange' Concept is itself templated with concepts.</div><div><br></div>=
<div>With the Concepts of Ranges TS (and the Syntax of Concepts Lite, exten=
ded with concepts as template parameters):</div><div> <div style=3D"ba=
ckground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:=
solid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"colo=
r:#800">// Forward declaration</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#008">template</span><span style=3D"color:#660"><</=
span><span style=3D"color:#008">typename</span><span style=3D"color:#000"> =
T</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">template</span><span style=3D"color:#660"><=
;</span><span style=3D"color:#008">typename</span><span style=3D"color:#000=
"> T</span><span style=3D"color:#660">></span><span style=3D"color:#000"=
> </span><span style=3D"color:#008">concept</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">bool</span><span style=3D"color:#660">=
....</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Ran=
geConcepts</span><span style=3D"color:#660">></span><span style=3D"color=
:#000"><br></span><span style=3D"color:#008">concept</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">bool</span><span style=3D"col=
or:#000"> </span><span style=3D"color:rgb(102,0,102)"><span style=3D"color:=
#606">MultiDimRange</span></span><font color=3D"#000000"><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"><br><br></span><span style=3D"c=
olor:#800">// Recursive Case</span><span style=3D"color:#000"><br></span></=
font><span style=3D"color:#008">template</span><span style=3D"color:#660">&=
lt;</span><span style=3D"color:#000"><br> </span><span style=
=3D"color:#008">typename</span><span style=3D"color:#000"> T </span><span s=
tyle=3D"color:#660">,</span><span style=3D"color:#000"><br> </=
span><span style=3D"color:#008">template</span><span style=3D"color:#660">&=
lt;</span><span style=3D"color:#008">typename</span><span style=3D"color:#0=
00"> T</span><span style=3D"color:#660">></span><span style=3D"color:#00=
0"> </span><span style=3D"color:#008">concept</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">bool</span><span style=3D"color:#000=
"> </span><span style=3D"color:#606">RangeConcept0</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">,</span><span style=3D"color:#0=
00"><br> </span><span style=3D"color:#008">template</span><spa=
n style=3D"color:#660"><</span><span style=3D"color:#008">typename</span=
><span style=3D"color:#000"> T</span><span style=3D"color:#660">></span>=
<span style=3D"color:#000"> </span><span style=3D"color:#008">concept</span=
><span style=3D"color:#000"> </span><span style=3D"color:#008">bool</span><=
span style=3D"color:#000"> </span><span style=3D"color:#606">RangeConcept1<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">,</span=
><span style=3D"color:#000"><br> </span><span style=3D"color:#=
008">template</span><span style=3D"color:#660"><</span><span style=3D"co=
lor:#008">typename</span><span style=3D"color:#000"> T</span><span style=3D=
"color:#660">></span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">concept</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">bool</span><span style=3D"color:#660">...</span><span style=3D"=
color:#000"> </span><span style=3D"color:#606">RangeConcepts</span><span st=
yle=3D"color:#000"><br></span><span style=3D"color:#660">></span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#008">concept</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#008">bool</span><span=
style=3D"color:#000"> </span><span style=3D"color:rgb(102,0,102)"><span st=
yle=3D"color:#606">MultiDimRange</span></span><span style=3D"color:#660">&l=
t;</span><span style=3D"color:#000">T</span><span style=3D"color:#660">,</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#606">RangeCoce=
pt0</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </=
span><span style=3D"color:#606">RangeConcept1</span><span style=3D"color:#6=
60">,</span><span style=3D"color:#000"> </span><span style=3D"color:#606">R=
angeConcepts</span><span style=3D"color:#660">...></span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">=3D</span><span style=3D"col=
or:#000"><br> </span><span style=3D"color:#606">Range</span><s=
pan style=3D"color:#660"><</span><span style=3D"color:#000">T</span><spa=
n style=3D"color:#660">></span><span style=3D"color:#000"> </span><span =
style=3D"color:#800">/* From Ranges TS */</span><span style=3D"color:#000">=
<br> </span><span style=3D"color:#660">&&</span><span =
style=3D"color:#000"> </span><span style=3D"color:#606">RangeConcept0</span=
><span style=3D"color:#660"><</span><span style=3D"color:#000">T</span><=
span style=3D"color:#660">></span><span style=3D"color:#000"><br> =
</span><span style=3D"color:#660">&&</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#606">MultidimensionalRange</span><s=
pan style=3D"color:#660"><</span><span style=3D"color:#000"><br> &=
nbsp; ranges</span><span style=3D"color:#660">::</span><span =
style=3D"color:#000">value_type</span><span style=3D"color:#660"><</span=
><span style=3D"color:#000">T</span><span style=3D"color:#660">></span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">,</span><span =
style=3D"color:#000"><br> </span><span style=3D"=
color:#606">RangeConcept1</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">,</span><span style=3D"color:#000"><br> &nb=
sp; </span><span style=3D"color:#606">RangeConcepts</span><span styl=
e=3D"color:#660">...</span><span style=3D"color:#000"><br> </s=
pan><span style=3D"color:#660">></span><span style=3D"color:#000"><br></=
span><font color=3D"#000000"><span style=3D"color:#660">;</span></font><fon=
t color=3D"#660066"><span style=3D"color:#000"><br><br></span><span style=
=3D"color:#800">// Base Case</span><span style=3D"color:#000"><br></span><s=
pan style=3D"color:#008">template</span><span style=3D"color:#660"><</sp=
an><span style=3D"color:#000"><br> </span><span style=3D"color=
:#008">typename</span><span style=3D"color:#000"> T </span><span style=3D"c=
olor:#660">,</span><span style=3D"color:#000"><br> </span><spa=
n style=3D"color:#008">template</span><span style=3D"color:#660"><</span=
><span style=3D"color:#008">typename</span><span style=3D"color:#000"> T</s=
pan><span style=3D"color:#660">></span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#008">concept</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">bool</span><span style=3D"color:#000"> </span=
></font><span style=3D"color:#606">RangeConcept</span><span style=3D"color:=
#000"><br></span><font color=3D"#660066"><span style=3D"color:#660">></s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#008">concep=
t</span><span style=3D"color:#000"> </span><span style=3D"color:#008">bool<=
/span><span style=3D"color:#000"> </span></font><span style=3D"color:rgb(10=
2,0,102)"><span style=3D"color:#606">MultiDimRange</span></span><font color=
=3D"#660066"><span style=3D"color:#660"><</span><span style=3D"color:#00=
0">T</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> <=
/span></font><span style=3D"color:#606">RangeConcept</span><font color=3D"#=
660066"><span style=3D"color:#660">></span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </sp=
an></font><span style=3D"color:#606">Range</span><span style=3D"color:#660"=
><</span><span style=3D"color:#000">T</span><span style=3D"color:#660">&=
gt;</span><span style=3D"color:#000"> </span><span style=3D"color:#800">/* =
<- From Ranges TS */</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">&&</span><span style=3D"color:#000"> </span><span =
style=3D"color:#606">RangeConcept</span><span style=3D"color:#660"><</sp=
an><span style=3D"color:#000">T</span><span style=3D"color:#660">>;</spa=
n><span style=3D"color:#000"><br><br><br></span><span style=3D"color:#800">=
// Using the Declarations:</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#008">template</span><span style=3D"color:#660"><</span=
><span style=3D"color:#008">typename</span><span style=3D"color:#000"> T</s=
pan><span style=3D"color:#660">></span><span style=3D"color:#000"><br></=
span><span style=3D"color:#008">concept</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">bool</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#606">My</span><font color=3D"#660066"><span style=
=3D"color:#606">MatrixType</span><span style=3D"color:#000"> </span></font>=
<span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#606">MultiDimRange</span><span style=3D"color:#660"><=
</span><span style=3D"color:#000">T</span><span style=3D"color:#660">,</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#606">RandomAcces=
sRange</span><span style=3D"color:#660">,</span><span style=3D"color:#000">=
</span><span style=3D"color:rgb(102,0,102)"><span style=3D"color:#606">Ran=
domAccessRange</span></span><span style=3D"color:#660">>;</span><span st=
yle=3D"color:#000"><br><br></span><span style=3D"color:#008">template</span=
><span style=3D"color:#660"><</span><span style=3D"color:#606">My</span>=
<font color=3D"#660066"><span style=3D"color:#606">MatrixType</span><span s=
tyle=3D"color:#000"> </span></font><span style=3D"color:#000">T</span><span=
style=3D"color:#660">></span><span style=3D"color:#000"><br>T matrixMul=
tiply</span><span style=3D"color:#660">(</span><span style=3D"color:#000"> =
</span><font color=3D"#660066"><span style=3D"color:#000">T </span></font><=
span style=3D"color:#000">m1 </span><span style=3D"color:#660">,</span><spa=
n style=3D"color:#000"> </span><font color=3D"#660066"><span style=3D"color=
:#000">T </span></font><span style=3D"color:#000">m2 </span><span style=3D"=
color:#660">){</span><font color=3D"#880000"><span style=3D"color:#000"><br=
> </span><span style=3D"color:#800">// e.g.</span><span style=
=3D"color:#000"><br> </span><span style=3D"color:#008">int</sp=
an><span style=3D"color:#000"> i</span><span style=3D"color:#660">,</span><=
span style=3D"color:#000"> j</span><span style=3D"color:#660">;</span><span=
style=3D"color:#000"><br> m1</span><span style=3D"color:#660"=
>[</span><span style=3D"color:#000">i</span><span style=3D"color:#660">][</=
span><span style=3D"color:#000">j</span><span style=3D"color:#660">]</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#800">// This is de=
fined!</span></font><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#660">}</span><span style=3D"color:#000"><br></span><font color=3D"#666=
600"></font></div></code></div><br></div><div><br></div><div>I don't know i=
f concepts will be passed as template parameter to non-concepts, but they w=
ill definitely need to be passed as template parameters to other concepts t=
o refine them.</div><div><br></div></div></blockquote><div>Wow. This gets c=
ompliacated. Does this code compile with the concept aware GCC version?</di=
v><div><br></div><div>I have a related issue I was aiming to bring up in a =
separate thread, but as you started discussing multi-dimensional arrays I w=
ill out it here:</div><div><br></div><div>Is it possible to write a concept=
requiring that the multi-dimensional matrix must have an overloaded operat=
or() with as many indices as there are dimensions? Is it even possible to w=
rite a concept that specifies that there should be a method of a certain na=
me that takes a unbounded number of parameters? </div><div><br></div><=
div>I have not understood how as in concepts-lite you write "example code" =
to express requirements, and there seems to be no way to exemplify that a m=
ethod must be callable with any number of parameters short of listing each =
case... With the old concepts where requirements were formed as method decl=
arations this would have been natural, just write your template<typename=
.... Ts> my_fun(const Ts... ts) thingy.</div><div><br></div><div>A lesser=
version of this limitation also exists in the concrete template<size_t =
RANK> class Matrix; case where you can't specify that an operator() with=
RANK number of parameters exists, this will be revealed only at the last r=
ecursive template instantiation step, just one of those things that concept=
s should alleviate. I hope they do, but I for one can't figure out how to s=
pecify it.</div><div><br></div><div><br></div><div> </div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Cheers,</=
div><div>Jakob</div></div></blockquote></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
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/d1905438-7265-46bb-85c2-91b4c95e9a20%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/d1905438-7265-46bb-85c2-91b4c95e=
9a20%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<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/20170622022417.5115986.56900.31497%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20170622022417.5115986.56900.31497%40gm=
ail.com</a>.<br />
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Thu, 22 Jun 2017 04:38:01 -0700 (PDT)
Raw View
------=_Part_1104_1649587515.1498131481318
Content-Type: multipart/alternative;
boundary="----=_Part_1105_414448447.1498131481319"
------=_Part_1105_414448447.1498131481319
Content-Type: text/plain; charset="UTF-8"
Am Donnerstag, 22. Juni 2017 04:24:47 UTC+2 schrieb Tony V E:
>
> I can imagine this "runtime overloading" could be useful for things like
> optional.
> It is just pattern matching.
>
I have thought about this for a little now and I found an argument, why we
probably don't want pattern matching in the form of runtime overloading:
At Overloading Resolution, all Functions are equally considered in the
sence that there is *no ordering of preference* other than *declaration
scope* and *castability of function parameters*.
This however restricts us to function overloads whose concepts are disjunct
sets of values (e.g. Even and Odd) in order to prevent ambiguity.
In Ordinary Pattern Matching however we have an ordering mechanism: The
first one that matches gets taken, regardless of whether a following
pattern matches as well.
In C++ the only place where you can see a glimps of this mechanism in
switch-case, where the first matching branch gets taken:
int a = 0;
switch(a){
case 0: // Matches -> gets taken
break;
default: // matches as well but not taken
break;
}
switch(a){
default: // Matches -> gets taken
break;
case 0: // matches as well but not taken
break;
}
Since you can only resolve this ambiguity by an implicit set of ordering
rules (that is, there is no exlicit ordering specified in your code), this
can become after all a big source of errors.
Therefore I'm agains runtime overloading using concepts as patterns.
Instead, I think allowing something like pattern matching in the form of:
/* Don't think about this syntax, I don't like it yet*/
template<typename T>
concept Valid( std::optional<T>& opt ){
return opt.is_valid();
}
std::optional<int> opt = 5;
switch(opt){
case Valid:
//do something with the valid value
break;
case Empty:
//Whatever
break;
}
Since pattern matching in this form is a different proposal and since
Concepts/Contracts don't depend upon it, I'd rather not waste time now
talking about it. I feel we need to make progress with the meat of the
topic first.
That is for me, how can we merge contracts and concepts?. If you need
reasons, why this is desirable:
1. Contracts (as introduced by P0380R1
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf>)
are not meant to be reusable that the *meaning *behind them cannot be
expressed as a NAME: [Cited from the Paper]
int f(int x) noexcept [[expects:x>0]];
Rather it would be way more intuitive to write
int f(Positive int x) noexcept;
No only is this shorter but it also transports the meaning of what x>0
means.
Another example:
float algo(float lambda) [[expects:lambda>=0 && lambda<=1]];
float algo(Normalized float lambda);
The former is not only more descriptive, it is more readable and
furthermore reusable.
2. The Redundancy comes into play, when we mix value concepts and
contracts
template<int I>
concept bool PowerOfTwo = /* Is I a power of two? */;
template<PowerOfTwo N>
struct Foo{};
void bar(int N) [[expects: /* Is I a power of two? */]] ;
Instead we can write e.g.
concept PowerOfTwo(Numerical I){ /* Is I a power of two? */ }
template<PowerOfTwo int N>
struct Foo{};
void bar(PowerOfTwo int N);
Summary:
- *Contracts *restrict the domain of a datatype to a set of values at
runtime.
- *Concepts Lite *restrict the set of types (or the domain of a datatype
in case of value concepts as touch previously in P0587R1) at compile time.
Contracts target use cases where you don't want to give a name to a
property that you enforce on your types.
This is equivalent to the *requires *keyword from Concepts that you can use
above function declarations (take this as indication that they are indeed
portraiting the same idea):
template<typename T>
requires is_convertible<T,int>() && is_constructible<T,int>
void func();
// Or even more redundancy to contracts
template<int N>
requires (N % 2 == 0)
void func2();
--
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/cdceffb6-976b-4f54-b6ea-fa4ee1527275%40isocpp.org.
------=_Part_1105_414448447.1498131481319
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Am Donnerstag, 22. Juni 2017 04:24:47 UTC+2 schrie=
b Tony V E:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div lang=3D"en-US"=
style=3D"background-color:rgb(255,255,255);line-height:initial"> =
=
<div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate =
Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;back=
ground-color:rgb(255,255,255)">I can imagine this "runtime overloading=
" could be useful for things like optional.=C2=A0</div><div style=3D"w=
idth:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-se=
rif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb=
(255,255,255)">It is just pattern matching.</div></div></blockquote><div><b=
r></div><div>I have thought about this for a little now and I found an argu=
ment, why we probably don't want pattern matching in the form of runtim=
e overloading:</div><div><br></div><blockquote style=3D"margin: 0 0 0 40px;=
border: none; padding: 0px;"><div>At Overloading Resolution, all Functions=
are equally considered in the sence that there is <b>no ordering of prefer=
ence</b> other than <i>declaration scope</i> and <i>castability of function=
parameters</i>.</div></blockquote><blockquote style=3D"margin: 0 0 0 40px;=
border: none; padding: 0px;"><div>This however restricts us to function ov=
erloads whose concepts are disjunct sets of values (e.g. Even and Odd) in o=
rder to prevent ambiguity.</div><div>In Ordinary Pattern Matching however w=
e have an ordering mechanism: The first one that matches gets taken, regard=
less of whether a following pattern matches as well.</div><div>In C++ the o=
nly place where you can see a glimps of this mechanism in switch-case, wher=
e the first matching branch gets taken:</div><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">switch</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">a</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">){</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">case</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Matches =
-> gets taken</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">break</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">default</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// matc=
hes as well but not taken</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">break</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">switc=
h</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">a</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">){</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">default</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// Matches -> gets taken</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">break</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">// matches as well but not taken</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">break</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span></div></code></div><div><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></d=
iv></div><div>Since you can only resolve this ambiguity by an implicit set =
of ordering rules (that is, there is no exlicit ordering specified in your =
code), this can become after all a big source of errors.</div><div>Therefor=
e I'm agains runtime overloading using concepts as patterns.</div></blo=
ckquote><div><br></div><div>Instead, I think allowing something like patter=
n matching in the form of:</div><div><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">/* Don't think about this syntax, I don't =
like it yet*/</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">tem=
plate</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">></span><font colo=
r=3D"#660066"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">concept</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">Valid</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">optional</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">>&</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> opt </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">){</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
opt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">is_valid</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br><br>std</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">optional</span><span style=3D"color: #080;" =
class=3D"styled-by-prettify"><int></span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> opt </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">switch</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">opt</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">){</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">case</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Valid</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">//do something with the valid value</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">break</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">case</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Empty</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">//Whatever</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">break</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span></font></div></code></div>=
<div><br></div>Since pattern matching in this form is a different proposal =
and since Concepts/Contracts don't depend upon it, I'd rather not w=
aste time now talking about it. I feel we need to make progress with the me=
at of the topic first.</div><div>That is for me, how can we merge contracts=
and concepts?. If you need reasons, why this is desirable:</div><div><ol><=
li>Contracts (as introduced by <a href=3D"http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2016/p0380r1.pdf">P0380R1</a>) are not meant to be reusab=
le that the <b>meaning </b>behind them cannot be expressed as a NAME: [Cite=
d from the Paper]<br><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; =
border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div=
class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> noexcept </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">[[</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">expects</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">></span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]];</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></=
div></code></div><font style=3D"background-color: rgb(250, 250, 250);"><spa=
n class=3D"styled-by-prettify"><font><span class=3D"styled-by-prettify"><fo=
nt face=3D"arial, sans-serif"><font color=3D"#000000">Rather it would be wa=
y more intuitive to write</font><br><div class=3D"prettyprint" style=3D"col=
or: rgb(0, 0, 0); background-color: rgb(250, 250, 250); border-color: rgb(1=
87, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wor=
d;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Positive</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> noexcept=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span></=
div></code></div><font color=3D"#000000">No only is this shorter but it als=
o transports the meaning of what x>0 means.<br>Another example:</font><b=
r><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250);=
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpretty=
print"><span style=3D"color: #008;" class=3D"styled-by-prettify">float</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> algo</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">float</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">lambda</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">[[</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">expects</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
:</span><span style=3D"color: #008;" class=3D"styled-by-prettify">lambda</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">>=3D</span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&&</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">lambda</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><=3D</span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">]];</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">float</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> algo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Normalized</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">lambda</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span></div></code></div>The former =
is not only more descriptive, it is more readable and furthermore reusable.=
<br><br></font></span></font></span></font></li><li>The Redundancy comes in=
to play, when we mix value concepts and contracts<br><div class=3D"prettypr=
int" style=3D"border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><font color=3D"#000000"><span style=3D"background-color=
: rgb(250, 250, 250);"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">template</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">in=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> I</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">concept</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span></span></font><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">PowerOfTwo</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">/* Is I a power of two? */</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify"><</span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">PowerOfTwo</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> N</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{};</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: rgb(0, 0, 0); backg=
round-color: rgb(250, 250, 250);"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">bar</span></span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> N</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">expects</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">/* Is I a power of two? */</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">]]</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span></div></code></div><span class=3D"styled-by-pre=
ttify"><font style=3D"background-color: rgb(255, 255, 255);"><font color=3D=
"#000000">Instead we can write e.g.</font><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">concept</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">PowerOfTwo</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Numerical</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> I</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>){</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">/* Is I a power =
of two? */</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">PowerOfTwo</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> N</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">F=
oo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> bar</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">PowerOfTwo</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> N</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span></div></code></div></font></span></li></ol>Summary=
:<br><ul><li><b>Contracts </b>restrict the domain of a datatype to a set of=
values at runtime.</li><li><b>Concepts Lite </b>restrict the set of types =
(or the domain of a datatype in case of value concepts as touch previously =
in P0587R1) at compile time.</li></ul>Contracts target use cases where you =
don't want to give a name to a property that you enforce on your types.=
</div><div>This is equivalent to the <b><i>requires </i></b>keyword from Co=
ncepts that you can use above function declarations (take this as indicatio=
n that they are indeed portraiting the same idea):</div><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #008;" class=3D"styled-by-prettify">template</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>requires is_convertible</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">>()</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> is_c=
onstructible</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> func</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br></span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// Or even more redundancy to contracts</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify"><</span><font color=3D"#000000"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> N</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>requires </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">N </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">%</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>2</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> func2</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">();</span></font></div></code></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/cdceffb6-976b-4f54-b6ea-fa4ee1527275%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cdceffb6-976b-4f54-b6ea-fa4ee1527275=
%40isocpp.org</a>.<br />
------=_Part_1105_414448447.1498131481319--
------=_Part_1104_1649587515.1498131481318--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 22 Jun 2017 08:11:50 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Good point about ordering. </div><div style=3D"width: 100%=
; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-s=
erif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(2=
55, 255, 255);">P.S. There is another place that does ordered pattern match=
ing - catching exceptions. </div> =
=
<div style=3D"width: 100%; font-size: initial; font-family:=
Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); tex=
t-align: initial; background-color: rgb(255, 255, 255);"><br style=3D"displ=
ay:initial"></div> =
=
<div style=
=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb=
(255, 255, 255);">Sent from my BlackBerry portable =
;Babbage Device</div> =
=
<table width=3D"100%"=
style=3D"background-color:white;border-spacing:0px;"> <tbody><tr><td colsp=
an=3D"2" style=3D"font-size: initial; text-align: initial; background-color=
: rgb(255, 255, 255);"> <div style=3D"border-styl=
e: solid none none; border-top-color: rgb(181, 196, 223); border-top-width:=
1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pr=
o'; font-size: 10pt;"> <div><b>From: </b>Jakob Riedle</div><div><b>Sent: <=
/b>Thursday, June 22, 2017 7:38 AM</div><div><b>To: </b>ISO C++ Standard - =
Future Proposals</div><div><b>Reply To: </b>std-proposals@isocpp.org</div><=
div><b>Subject: </b>Re: [std-proposals] Re: Clarification needed on Concept=
s (and Contracts?)</div></div></td></tr></tbody></table><div style=3D"borde=
r-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-=
width: 1pt; font-size: initial; text-align: initial; background-color: rgb(=
255, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=
=3D"ltr"><br><br>Am Donnerstag, 22. Juni 2017 04:24:47 UTC+2 schrieb Tony V=
E:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div lang=3D"en-US" style=
=3D"background-color:rgb(255,255,255);line-height:initial"> =
<div =
style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-=
serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:r=
gb(255,255,255)">I can imagine this "runtime overloading" could be useful f=
or things like optional. </div><div style=3D"width:100%;font-size:init=
ial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,1=
25);text-align:initial;background-color:rgb(255,255,255)">It is just patter=
n matching.</div></div></blockquote><div><br></div><div>I have thought abou=
t this for a little now and I found an argument, why we probably don't want=
pattern matching in the form of runtime overloading:</div><div><br></div><=
blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>A=
t Overloading Resolution, all Functions are equally considered in the sence=
that there is <b>no ordering of preference</b> other than <i>declaration s=
cope</i> and <i>castability of function parameters</i>.</div></blockquote><=
blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>T=
his however restricts us to function overloads whose concepts are disjunct =
sets of values (e.g. Even and Odd) in order to prevent ambiguity.</div><div=
>In Ordinary Pattern Matching however we have an ordering mechanism: The fi=
rst one that matches gets taken, regardless of whether a following pattern =
matches as well.</div><div>In C++ the only place where you can see a glimps=
of this mechanism in switch-case, where the first matching branch gets tak=
en:</div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">int=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">switch</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">){</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &=
nbsp;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">case<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">// Matches -> gets taken</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">break</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">default</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">// matches as well but not taken</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br> &=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">brea=
k</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">switch</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">){</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br> </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">default</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Matc=
hes -> gets taken</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">break</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">case</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// matches as well but n=
ot taken</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r> </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">break</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span=
></div></code></div><div><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span></div></code></div></div><div>Since you can only re=
solve this ambiguity by an implicit set of ordering rules (that is, there i=
s no exlicit ordering specified in your code), this can become after all a =
big source of errors.</div><div>Therefore I'm agains runtime overloading us=
ing concepts as patterns.</div></blockquote><div><br></div><div>Instead, I =
think allowing something like pattern matching in the form of:</div><div><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #800;" class=3D"styled-by-prettify">/* Don't think=
about this syntax, I don't like it yet*/</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">></span><font color=3D"#660066"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">concept</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">Valid</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">optional</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">>&</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> opt </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">){</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> opt</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">is_valid</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">optional</span><=
span style=3D"color: #080;" class=3D"styled-by-prettify"><int></span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> opt </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">switch</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>opt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">){</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">case</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #606;" class=3D"styled-by-prettify">Valid</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">//do something with t=
he valid value</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">break</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">case</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Emp=
ty</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
Whatever</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r> </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">break</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span=
></font></div></code></div><div><br></div>Since pattern matching in this fo=
rm is a different proposal and since Concepts/Contracts don't depend upon i=
t, I'd rather not waste time now talking about it. I feel we need to make p=
rogress with the meat of the topic first.</div><div>That is for me, how can=
we merge contracts and concepts?. If you need reasons, why this is desirab=
le:</div><div><ol><li>Contracts (as introduced by <a href=3D"http://www.ope=
n-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf">P0380R1</a>) are not=
meant to be reusable that the <b>meaning </b>behind them cannot be express=
ed as a NAME: [Cited from the Paper]<br><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> noexcept </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">expects</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">></span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">]];</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span></div></code></div><font style=3D"background-color: rgb(=
250, 250, 250);"><span class=3D"styled-by-prettify"><font><span class=3D"st=
yled-by-prettify"><font face=3D"arial, sans-serif"><font color=3D"#000000">=
Rather it would be way more intuitive to write</font><br><div class=3D"pret=
typrint" style=3D"color: rgb(0, 0, 0); background-color: rgb(250, 250, 250)=
; border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px;=
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Positive</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> noexcept</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span></div></code></div><font color=3D"#000000">No only is this sh=
orter but it also transports the meaning of what x>0 means.<br>Another e=
xample:</font><br><div class=3D"prettyprint" style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">float</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> algo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">lambda</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">expects</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">:</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">lambda</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">>=3D</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&&</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">lambda</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify"><=3D</span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">]];</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> algo</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Normalized</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">floa=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">lambda</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code>=
</div>The former is not only more descriptive, it is more readable and furt=
hermore reusable.<br><br></font></span></font></span></font></li><li>The Re=
dundancy comes into play, when we mix value concepts and contracts<br><div =
class=3D"prettyprint" style=3D"border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><font color=3D"#000000"><span style=3D=
"background-color: rgb(250, 250, 250);"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> I</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">concept</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span></sp=
an></font><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #606;" class=3D"styled-by-prettify">PowerOfTwo</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" c=
lass=3D"styled-by-prettify">/* Is I a power of two? */</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify"><</span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">PowerOfTwo</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> N</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: rgb(0, 0, 0); background-color: rgb(250, 250, 250);"><span style=3D"color=
: #000;" class=3D"styled-by-prettify">bar</span></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> N</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[[=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">expects</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">/* Is I a power of two? */</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">]]</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span></div></code></div><span=
class=3D"styled-by-prettify"><font style=3D"background-color: rgb(255, 255=
, 255);"><font color=3D"#000000">Instead we can write e.g.</font><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">concept</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">PowerOfTwo</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">Numerical</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> I</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">){</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">/* Is I a power of two? */</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Powe=
rOfTwo</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> N</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Foo</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{};</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">PowerOfTwo</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> N</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span></div></code></div></font><=
/span></li></ol>Summary:<br><ul><li><b>Contracts </b>restrict the domain of=
a datatype to a set of values at runtime.</li><li><b>Concepts Lite </b>res=
trict the set of types (or the domain of a datatype in case of value concep=
ts as touch previously in P0587R1) at compile time.</li></ul>Contracts targ=
et use cases where you don't want to give a name to a property that you enf=
orce on your types.</div><div>This is equivalent to the <b><i>requires </i>=
</b>keyword from Concepts that you can use above function declarations (tak=
e this as indication that they are indeed portraiting the same idea):</div>=
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); b=
order-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wo=
rd-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>requires is_convertible</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">>()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&&</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> is_constructible</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> func</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">// Or even more redundancy to contrac=
ts</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><font=
color=3D"#000000"><span style=3D"color: #008;" class=3D"styled-by-prettify=
">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> N</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>requires </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">N </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">%</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">2</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> func2</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">();</span></font></div></code></div></div=
>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
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/cdceffb6-976b-4f54-b6ea-fa4ee1527275%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/cdceffb6-976b-4f54-b6ea-fa4ee152=
7275%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<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/20170622121150.5115986.1538.31509%40g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/20170622121150.5115986.1538.31509%40gmai=
l.com</a>.<br />
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Thu, 22 Jun 2017 11:04:24 -0700
Raw View
--94eb2c1a074aa48e4b05529050b7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 22, 2017 at 4:38 AM, Jakob Riedle <jakob.riedle@gmail.com>
wrote:
> Am Donnerstag, 22. Juni 2017 04:24:47 UTC+2 schrieb Tony V E:
>>
>> I can imagine this "runtime overloading" could be useful for things like
>> optional.
>> It is just pattern matching.
>>
>
> I have thought about this for a little now and I found an argument, why w=
e
> probably don't want pattern matching in the form of runtime overloading:
>
> At Overloading Resolution, all Functions are equally considered in the
> sence that there is *no ordering of preference* other than *declaration
> scope* and *castability of function parameters*.
>
> This however restricts us to function overloads whose concepts are
> disjunct sets of values (e.g. Even and Odd) in order to prevent ambiguity=
..
>
>
Well, that's not true. Overload resolution has a whole bunch of priority
rules about what constitutes a "better match".
template<class T> void f(T t) { puts("worst match"); }
template<class T> void f(T *t) { puts("better match"); }
template<class T> void f(T **t) { puts("best match"); }
int main() { void ****p; f(p); }
(These are three different overloaded function templates, not a base
template and two partial specializations.)
My impression is that Concepts Lite proposes a similar hierarchy of
concepts, since that's kind of the purpose of having Concepts in the
language at all. It may not always be implemented properly
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D67018>, but I believe it's
supposed to work.
template<InputIterator T> void f(T t) { puts("worst match"); }
template<ForwardIterator T> void f(T t) { puts("better match"); }
template<RandomAccessIterator T> void f(T t) { puts("best match"); }
int main() { int *p; f(p); }
> In Ordinary Pattern Matching however we have an ordering mechanism: The
> first one that matches gets taken, regardless of whether a following
> pattern matches as well.
> In C++ the only place where you can see a glimps of this mechanism in
> switch-case, where the first matching branch gets taken:
> int a =3D 0;
> switch(a){
> case 0: // Matches -> gets taken
> break;
> default: // matches as well but not taken
> break;
> }
> switch(a){
> default: // Matches -> gets taken
> break;
> case 0: // matches as well but not taken
> break;
> }
>
>
Well, that's blatantly false. The "default" switch case matches
if-and-only-if none of the others matches; that's why it's called
"default". Also, all of the cases in a switch must be disjoint; otherwise
it's a compile-time error.
int main() {
switch (42) {
default: puts("not taken"); break;
case 42: puts("taken"); break;
}
}
Tony identified a case that does kinda-sorta work this way, though:
catch-handler chains. They're always implicitly nested, just like if-else
chains.
if (x) {
} else if (true) {
} else if (z) {
}
really means
if (x) {
} else {
if (true) {
} else if (z) {
}
}
and similarly
try {
} catch (x) {
} catch (...) {
} catch (z) {
}
really *almost* means
try {
try {
try {
} catch (x) {
}
} catch (...) {
}
} catch (z) {
}
except that if you re-throw from one of those inner catch handlers, it will
*not* be caught by the outer handlers.
Instead, I think allowing something like pattern matching in the form of:
> /* Don't think about this syntax, I don't like it yet*/
> template<typename T>
> concept Valid( std::optional<T>& opt ){
> return opt.is_valid();
> }
>
> std::optional<int> opt =3D 5;
> switch(opt){
> case Valid:
> //do something with the valid value
> break;
> case Empty:
> //Whatever
> break;
> }
>
> Since pattern matching in this form is a different proposal and since
> Concepts/Contracts don't depend upon it, I'd rather not waste time now
> talking about it. I feel we need to make progress with the meat of the
> topic first.
> That is for me, how can we merge contracts and concepts?. If you need
> reasons, why this is desirable:
>
> 1. Contracts (as introduced by P0380R1
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf>)
> are not meant to be reusable that the *meaning *behind them cannot be
> expressed as a NAME: [Cited from the Paper]
> int f(int x) noexcept [[expects:x>0]];
> Rather it would be way more intuitive to write
> int f(Positive int x) noexcept;
> No only is this shorter but it also transports the meaning of what x>0
> means.
> Another example:
> float algo(float lambda) [[expects:lambda>=3D0 && lambda<=3D1]];
>
> float algo(Normalized float lambda);
> The former is not only more descriptive, it is more readable and
> furthermore reusable.
>
> 2. The Redundancy comes into play, when we mix value concepts and
> contracts
> template<int I>
> concept bool PowerOfTwo =3D /* Is I a power of two? */;
>
> template<PowerOfTwo N>
> struct Foo{};
>
> void bar(int N) [[expects: /* Is I a power of two? */]] ;
> Instead we can write e.g.
> concept PowerOfTwo(Numerical I){ /* Is I a power of two? */ }
>
> template<PowerOfTwo int N>
> struct Foo{};
>
> void bar(PowerOfTwo int N);
>
> Summary:
>
> - *Contracts *restrict the domain of a datatype to a set of values at
> runtime.
> - *Concepts Lite *restrict the set of types (or the domain of a
> datatype in case of value concepts as touch previously in P0587R1) at
> compile time.
>
> FWIW, the problem I always have whenever anyone tries to explain Contract=
s
to me this way is: there's no such thing as "restricting" behavior at
runtime! What you really mean is, "At runtime, *if* this situation arises,
*then* <do something>." And C++ already has tons of ways to express that.
In other words, Concepts Lite provides a way to say, "If this condition
isn't satisfied, then SFINAE away: do the next-best thing if there is one."
But with Contracts, all we can say is, "If this condition isn't satisfied,
then the code has a bug and we need to hard-fail." So these Contracts are
not the runtime equivalent of SFINAE/Concepts; these Contracts are the
runtime equivalent of static_assert(). But C++ has had the runtime
equivalent of static_assert() for longer than we've had static_assert()! :=
)
However, at C++Now I had a long talk with Lisa Lippincott and she had a way
of looking at Contracts that at least was self-consistent (although I
cannot judge how much it is in step with the mainstream at the current
moment). Forget runtime. Contracts are about annotating code with
annotations ("contracts") that can be *statically checked at compile-time*.
That is, they're the equivalent of the semi-common practice
#define REQUIRES(x) assert(x)
#define ENSURES(x) assert(x)
int log2(int x)
{
REQUIRES((x & (x-1)) =3D=3D 0);
int r =3D 0;
while (x !=3D 1) x >>=3D 1, ++r;
ENSURES(0 <=3D r && r <=3D 31);
return r;
}
(logic bugs in the above code are somewhat intentional).
The hope is that by religiously annotating every speck of code with these
preconditions and postconditions, the compiler will actually be able to
check your "correctness proof" and verify that each ENSURES clause follows
logically from its corresponding REQUIRES clauses and the code in between.
This has nothing to do with *changing behavior based on pattern matching*;
this has to do with *machine verification of formal proofs of program
correctness*.
The big concern I have with this approach to Contracts is that most people
hate writing formal proofs, and in fact with the current state of the art,
I claim that most people simply won't be able to do it. So it has to remain
optional, closeted off in the [[attributes]] ghetto so that it's not part
of the "real" syntax, and maybe so that you can quickly turn it off =E2=80=
=94 for
build time, or for prototyping, or just to make the dang thing compile. We
can't build static-ENSURES()-checking into the language until we can show
that it would actually work and not just get in everyone's way.
my $.02,
Arthur
--=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/CADvuK0L%3DhP_J%2BOe8AT_-TAFG-SA3yCrxBY-uGS0xKNh=
qTJ8sgw%40mail.gmail.com.
--94eb2c1a074aa48e4b05529050b7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jun 22, 2017 at 4:38 AM, Jakob Riedle <span dir=3D=
"ltr"><<a href=3D"mailto:jakob.riedle@gmail.com" target=3D"_blank">jakob=
..riedle@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmai=
l-">Am Donnerstag, 22. Juni 2017 04:24:47 UTC+2 schrieb Tony V E:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"><div lang=3D"en-US" style=3D"background-color:rgb(255,255,255);line-=
height:initial"> =
<div style=3D"width:100%;font-size:initial;font-=
family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,12=
5);text-align:initial;background-color:rgb(255,255,255)">I can imagine this=
"runtime overloading" could be useful for things like optional.=
=C2=A0</div><div style=3D"width:100%;font-size:initial;font-family:Calibri,=
'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:i=
nitial;background-color:rgb(255,255,255)">It is just pattern matching.</div=
></div></blockquote><div><br></div></span><div>I have thought about this fo=
r a little now and I found an argument, why we probably don't want patt=
ern matching in the form of runtime overloading:</div><div><br></div><block=
quote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px"><div>At Ove=
rloading Resolution, all Functions are equally considered in the sence that=
there is <b>no ordering of preference</b> other than <i>declaration scope<=
/i> and <i>castability of function parameters</i>.</div></blockquote><block=
quote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px"><div>This h=
owever restricts us to function overloads whose concepts are disjunct sets =
of values (e.g. Even and Odd) in order to prevent ambiguity.</div></blockqu=
ote></div></blockquote><div><br></div><div>Well, that's not true. Overl=
oad resolution has a whole bunch of priority rules about what constitutes a=
"better match".</div><div><br></div><div><font face=3D"monospace=
, monospace">template<class T> void f(T t) { puts("worst match&q=
uot;); }</font></div><div><div><font face=3D"monospace, monospace">template=
<class T> void f(T *t) { puts("better match"); }</font></di=
v></div><div><div><font face=3D"monospace, monospace">template<class T&g=
t; void f(T **t) { puts("best match"); }</font></div></div><div><=
font face=3D"monospace, monospace">int main() { void ****p; f(p); }</font><=
/div><div><br></div><div>(These are three different overloaded function tem=
plates, not a base template and two partial specializations.)</div><div>My =
impression is that Concepts Lite proposes a similar hierarchy of concepts, =
since that's kind of the purpose of having Concepts in the language at =
all. <a href=3D"https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D67018">It ma=
y not always be implemented properly</a>, but I believe it's supposed t=
o work.</div><div><br></div><div><font face=3D"monospace, monospace">templa=
te<InputIterator T> void f(T t) { puts("worst match"); }</f=
ont></div><div><div><font face=3D"monospace, monospace">template<Forward=
Iterator T> void f(T t) { puts("better match"); }</font></div>=
</div><div><div><font face=3D"monospace, monospace">template<RandomAcces=
sIterator T> void f(T t) { puts("best match"); }</font></div><=
/div><div><font face=3D"monospace, monospace">int main() { int *p; f(p); }<=
/font></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"lt=
r"><blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px"><d=
iv>In Ordinary Pattern Matching however we have an ordering mechanism: The =
first one that matches gets taken, regardless of whether a following patter=
n matches as well.</div><div>In C++ the only place where you can see a glim=
ps of this mechanism in switch-case, where the first matching branch gets t=
aken:</div><div class=3D"gmail-m_-2950525757914535371prettyprint" style=3D"=
background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wr=
ap:break-word"><code class=3D"gmail-m_-2950525757914535371prettyprint"><div=
class=3D"gmail-m_-2950525757914535371subprettyprint"><span style=3D"color:=
rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">int<=
/span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-295052575791453537=
1styled-by-prettify"> a </span><span style=3D"color:rgb(102,102,0)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify">=3D</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-pretti=
fy"> </span><span style=3D"color:rgb(0,102,102)" class=3D"gmail-m_-29505257=
57914535371styled-by-prettify">0</span><span style=3D"color:rgb(102,102,0)"=
class=3D"gmail-m_-2950525757914535371styled-by-prettify">;</span><span sty=
le=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-pret=
tify"><br></span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-29505=
25757914535371styled-by-prettify">switch</span><span style=3D"color:rgb(102=
,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">(</span><=
span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled=
-by-prettify">a</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m=
_-2950525757914535371styled-by-prettify">){</span><span style=3D"color:rgb(=
0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><br>=C2=A0=
=C2=A0</span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-29505257=
57914535371styled-by-prettify">case</span><span style=3D"color:rgb(0,0,0)" =
class=3D"gmail-m_-2950525757914535371styled-by-prettify"> </span><span styl=
e=3D"color:rgb(0,102,102)" class=3D"gmail-m_-2950525757914535371styled-by-p=
rettify">0</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-295=
0525757914535371styled-by-prettify">:</span><span style=3D"color:rgb(0,0,0)=
" class=3D"gmail-m_-2950525757914535371styled-by-prettify"> </span><span st=
yle=3D"color:rgb(136,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-p=
rettify">// Matches -> gets taken</span><span style=3D"color:rgb(0,0,0)"=
class=3D"gmail-m_-2950525757914535371styled-by-prettify"><br>=C2=A0 =C2=A0=
=C2=A0 </span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525=
757914535371styled-by-prettify">break</span><span style=3D"color:rgb(102,10=
2,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">;</span><spa=
n style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by=
-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color:rgb(0,0,136)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify">default</span><span sty=
le=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-=
prettify">:</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-295052=
5757914535371styled-by-prettify"> </span><span style=3D"color:rgb(136,0,0)"=
class=3D"gmail-m_-2950525757914535371styled-by-prettify">// matches as wel=
l but not taken</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-29=
50525757914535371styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span =
style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by=
-prettify">break</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-=
m_-2950525757914535371styled-by-prettify">;</span><span style=3D"color:rgb(=
0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><br></span=
><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371=
styled-by-prettify">}</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail=
-m_-2950525757914535371styled-by-prettify"><br></span><span style=3D"color:=
rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">swit=
ch</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-29505257579=
14535371styled-by-prettify">(</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify">a</span><span style=3D"=
color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-pretti=
fy">){</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-29505257579=
14535371styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color:rg=
b(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">defaul=
t</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-295052575791=
4535371styled-by-prettify">:</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify"> </span><span style=3D"=
color:rgb(136,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify=
">// Matches -> gets taken</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-29505257579=
14535371styled-by-prettify">break</span><span style=3D"color:rgb(102,102,0)=
" class=3D"gmail-m_-2950525757914535371styled-by-prettify">;</span><span st=
yle=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-pre=
ttify"><br>=C2=A0 =C2=A0</span><span style=3D"color:rgb(0,0,136)" class=3D"=
gmail-m_-2950525757914535371styled-by-prettify">case</span><span style=3D"c=
olor:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"> =
</span><span style=3D"color:rgb(0,102,102)" class=3D"gmail-m_-2950525757914=
535371styled-by-prettify">0</span><span style=3D"color:rgb(102,102,0)" clas=
s=3D"gmail-m_-2950525757914535371styled-by-prettify">:</span><span style=3D=
"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"=
> </span><span style=3D"color:rgb(136,0,0)" class=3D"gmail-m_-2950525757914=
535371styled-by-prettify">// matches as well but not taken</span><span styl=
e=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prett=
ify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)" cla=
ss=3D"gmail-m_-2950525757914535371styled-by-prettify">break</span><span sty=
le=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-=
prettify">;</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-295052=
5757914535371styled-by-prettify"><br></span><span style=3D"color:rgb(102,10=
2,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">}</span></di=
v></code></div></blockquote></div></blockquote><div><br></div><div>Well, th=
at's blatantly false.=C2=A0 The "default" switch case matches=
if-and-only-if none of the others matches; that's why it's called =
"default". Also, all of the cases in a switch must be disjoint; o=
therwise it's a compile-time error.</div><div><br></div><div><font face=
=3D"monospace, monospace">int main() {</font></div><div><font face=3D"monos=
pace, monospace">=C2=A0 =C2=A0 switch (42) {</font></div><div><font face=3D=
"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 default: puts("not =
taken"); break;</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case 42: puts("taken"); break;</font>=
</div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 }</font></div>=
<div><font face=3D"monospace, monospace">}</font></div><div><br></div><div>=
Tony identified a case that does kinda-sorta work this way, though: catch-h=
andler chains. They're always implicitly nested, just like if-else chai=
ns.</div><div><br></div><div><font face=3D"monospace, monospace">if (x) {</=
font></div><div><font face=3D"monospace, monospace">} else if (true) {</fon=
t></div><div><font face=3D"monospace, monospace">} else if (z) {<br></font>=
</div><div><font face=3D"monospace, monospace">}</font></div><div><br></div=
><div>really means</div><div><br></div><div><font face=3D"monospace, monosp=
ace">if (x) {</font></div><div><font face=3D"monospace, monospace">} else {=
</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 if (tru=
e) {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 } e=
lse if (z) {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 }</font></div><div><font face=3D"monospace, monospace">}</font></div=
><div><br></div><div>and similarly</div><div><br></div><div><font face=3D"m=
onospace, monospace">try {</font></div><div><font face=3D"monospace, monosp=
ace">} catch (x) {</font></div><div><font face=3D"monospace, monospace">} c=
atch (...) {</font></div><div><font face=3D"monospace, monospace">} catch (=
z) {</font></div><div><font face=3D"monospace, monospace">}</font></div><di=
v><br></div><div>really <b><i>almost</i></b> means</div><div><br></div><div=
><font face=3D"monospace, monospace">try {</font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 =C2=A0 try {</font></div><div><font face=3D"mon=
ospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 try {</font></div><div><font=
face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 } catch (x) {</f=
ont></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 }</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 } =
catch (...) {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 }</font></div><div><font face=3D"monospace, monospace">} catch (z) {=
</font></div><div><font face=3D"monospace, monospace">}</font></div><div><b=
r></div><div>except that if you re-throw from one of those inner catch hand=
lers, it will <i><b>not</b></i> be caught by the outer handlers.</div><div>=
<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>Instead, I =
think allowing something like pattern matching in the form of:<br></div><di=
v><div class=3D"gmail-m_-2950525757914535371prettyprint" style=3D"backgroun=
d-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-=
word"><code class=3D"gmail-m_-2950525757914535371prettyprint"><div class=3D=
"gmail-m_-2950525757914535371subprettyprint"><span style=3D"color:rgb(136,0=
,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">/* Don't =
think about this syntax, I don't like it yet*/</span><span style=3D"col=
or:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><br=
></span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-29505257579145=
35371styled-by-prettify">template</span><span style=3D"color:rgb(102,102,0)=
" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><</span><span=
style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-b=
y-prettify">typename</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-=
m_-2950525757914535371styled-by-prettify"> T</span><span style=3D"color:rgb=
(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">><=
/span><font color=3D"#660066"><span style=3D"color:rgb(0,0,0)" class=3D"gma=
il-m_-2950525757914535371styled-by-prettify"><br></span><span style=3D"colo=
r:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">co=
ncept</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-295052575791=
4535371styled-by-prettify"> </span><span style=3D"color:rgb(102,0,102)" cla=
ss=3D"gmail-m_-2950525757914535371styled-by-prettify">Valid</span><span sty=
le=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-=
prettify">(</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-295052=
5757914535371styled-by-prettify"> std</span><span style=3D"color:rgb(102,10=
2,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">::</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-b=
y-prettify">optional</span><span style=3D"color:rgb(102,102,0)" class=3D"gm=
ail-m_-2950525757914535371styled-by-prettify"><</span><span style=3D"col=
or:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">T</=
span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-295052575791453=
5371styled-by-prettify">>&</span><span style=3D"color:rgb(0,0,0)" cl=
ass=3D"gmail-m_-2950525757914535371styled-by-prettify"> opt </span><span st=
yle=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by=
-prettify">){</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950=
525757914535371styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"=
color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-prettify=
">return</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-295052575=
7914535371styled-by-prettify"> opt</span><span style=3D"color:rgb(102,102,0=
)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">.</span><span s=
tyle=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-pr=
ettify">is_valid</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-=
m_-2950525757914535371styled-by-prettify">();</span><span style=3D"color:rg=
b(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><br></sp=
an><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-29505257579145353=
71styled-by-prettify">}</span><span style=3D"color:rgb(0,0,0)" class=3D"gma=
il-m_-2950525757914535371styled-by-prettify"><br><br>std</span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-pr=
ettify">::</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525=
757914535371styled-by-prettify">optional</span><span style=3D"color:rgb(0,1=
36,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><int>=
</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-29505257579145353=
71styled-by-prettify"> opt </span><span style=3D"color:rgb(102,102,0)" clas=
s=3D"gmail-m_-2950525757914535371styled-by-prettify">=3D</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-pretti=
fy"> </span><span style=3D"color:rgb(0,102,102)" class=3D"gmail-m_-29505257=
57914535371styled-by-prettify">5</span><span style=3D"color:rgb(102,102,0)"=
class=3D"gmail-m_-2950525757914535371styled-by-prettify">;</span><span sty=
le=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-pret=
tify"><br></span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-29505=
25757914535371styled-by-prettify">switch</span><span style=3D"color:rgb(102=
,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">(</span><=
span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled=
-by-prettify">opt</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail=
-m_-2950525757914535371styled-by-prettify">){</span><span style=3D"color:rg=
b(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><br>=C2=
=A0 =C2=A0</span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-29505=
25757914535371styled-by-prettify">case</span><span style=3D"color:rgb(0,0,0=
)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"> </span><span s=
tyle=3D"color:rgb(102,0,102)" class=3D"gmail-m_-2950525757914535371styled-b=
y-prettify">Valid</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail=
-m_-2950525757914535371styled-by-prettify">:</span><span style=3D"color:rgb=
(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><br>=C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)" class=3D"gmail-=
m_-2950525757914535371styled-by-prettify">//do something with the valid val=
ue</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-295052575791453=
5371styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"colo=
r:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">br=
eak</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757=
914535371styled-by-prettify">;</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify"><br>=C2=A0 =C2=A0</span=
><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371st=
yled-by-prettify">case</span><span style=3D"color:rgb(0,0,0)" class=3D"gmai=
l-m_-2950525757914535371styled-by-prettify"> </span><span style=3D"color:rg=
b(102,0,102)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">Empt=
y</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-295052575791=
4535371styled-by-prettify">:</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(136,0,0)" class=3D"gmail-m_-29505257579=
14535371styled-by-prettify">//Whatever</span><span style=3D"color:rgb(0,0,0=
)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><br>=C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950=
525757914535371styled-by-prettify">break</span><span style=3D"color:rgb(102=
,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">;</span><=
span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled=
-by-prettify"><br></span><span style=3D"color:rgb(102,102,0)" class=3D"gmai=
l-m_-2950525757914535371styled-by-prettify">}</span></font></div></code></d=
iv><div><br></div>Since pattern matching in this form is a different propos=
al and since Concepts/Contracts don't depend upon it, I'd rather no=
t waste time now talking about it. I feel we need to make progress with the=
meat of the topic first.</div><div>That is for me, how can we merge contra=
cts and concepts?. If you need reasons, why this is desirable:</div><div><o=
l><li>Contracts (as introduced by <a href=3D"http://www.open-std.org/jtc1/s=
c22/wg21/docs/papers/2016/p0380r1.pdf" target=3D"_blank">P0380R1</a>) are n=
ot meant to be reusable that the <b>meaning </b>behind them cannot be expre=
ssed as a NAME: [Cited from the Paper]<br><div class=3D"gmail-m_-2950525757=
914535371prettyprint" style=3D"background-color:rgb(250,250,250);border:1px=
solid rgb(187,187,187);word-wrap:break-word"><code class=3D"gmail-m_-29505=
25757914535371prettyprint"><div class=3D"gmail-m_-2950525757914535371subpre=
ttyprint"><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-295052575791=
4535371styled-by-prettify">int</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify"> f</span><span style=3D=
"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prett=
ify">(</span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-295052575=
7914535371styled-by-prettify">int</span><span style=3D"color:rgb(0,0,0)" cl=
ass=3D"gmail-m_-2950525757914535371styled-by-prettify"> x</span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-pr=
ettify">)</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-29505257=
57914535371styled-by-prettify"> noexcept </span><span style=3D"color:rgb(10=
2,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">[[</span=
><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styl=
ed-by-prettify">expects</span><span style=3D"color:rgb(102,102,0)" class=3D=
"gmail-m_-2950525757914535371styled-by-prettify">:</span><span style=3D"col=
or:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">x</=
span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-295052575791453=
5371styled-by-prettify">></span><span style=3D"color:rgb(0,102,102)" cla=
ss=3D"gmail-m_-2950525757914535371styled-by-prettify">0</span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-pr=
ettify">]];</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-295052=
5757914535371styled-by-prettify"><br></span></div></code></div><font style=
=3D"background-color:rgb(250,250,250)"><span class=3D"gmail-m_-295052575791=
4535371styled-by-prettify"><font><span class=3D"gmail-m_-295052575791453537=
1styled-by-prettify"><font face=3D"arial, sans-serif"><font color=3D"#00000=
0">Rather it would be way more intuitive to write</font><br><div class=3D"g=
mail-m_-2950525757914535371prettyprint" style=3D"color:rgb(0,0,0);backgroun=
d-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-=
word"><code class=3D"gmail-m_-2950525757914535371prettyprint"><div class=3D=
"gmail-m_-2950525757914535371subprettyprint"><span style=3D"color:rgb(0,0,1=
36)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">int</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-b=
y-prettify"> f</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_=
-2950525757914535371styled-by-prettify">(</span><span style=3D"color:rgb(10=
2,0,102)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">Positive=
</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-29505257579145353=
71styled-by-prettify"> </span><span style=3D"color:rgb(0,0,136)" class=3D"g=
mail-m_-2950525757914535371styled-by-prettify">int</span><span style=3D"col=
or:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"> x<=
/span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-29505257579145=
35371styled-by-prettify">)</span><span style=3D"color:rgb(0,0,0)" class=3D"=
gmail-m_-2950525757914535371styled-by-prettify"> noexcept</span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-pr=
ettify">;</span></div></code></div><font color=3D"#000000">No only is this =
shorter but it also transports the meaning of what x>0 means.<br>Another=
example:</font><br><div class=3D"gmail-m_-2950525757914535371prettyprint" =
style=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187=
);word-wrap:break-word"><code class=3D"gmail-m_-2950525757914535371prettypr=
int"><div class=3D"gmail-m_-2950525757914535371subprettyprint"><span style=
=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-pret=
tify">float</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-295052=
5757914535371styled-by-prettify"> algo</span><span style=3D"color:rgb(102,1=
02,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">(</span><sp=
an style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled=
-by-prettify">float</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m=
_-2950525757914535371styled-by-prettify"> </span><span style=3D"color:rgb(0=
,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">lambda</s=
pan><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535=
371styled-by-prettify">)</span><span style=3D"color:rgb(0,0,0)" class=3D"gm=
ail-m_-2950525757914535371styled-by-prettify"> </span><span style=3D"color:=
rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">[[=
</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-29505257579145353=
71styled-by-prettify">expects</span><span style=3D"color:rgb(102,102,0)" cl=
ass=3D"gmail-m_-2950525757914535371styled-by-prettify">:</span><span style=
=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-pret=
tify">lambda</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2=
950525757914535371styled-by-prettify">>=3D</span><span style=3D"color:rg=
b(0,102,102)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">0</s=
pan><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371s=
tyled-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gm=
ail-m_-2950525757914535371styled-by-prettify">&&</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-pretti=
fy"> </span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757=
914535371styled-by-prettify">lambda</span><span style=3D"color:rgb(102,102,=
0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><=3D</span>=
<span style=3D"color:rgb(0,102,102)" class=3D"gmail-m_-2950525757914535371s=
tyled-by-prettify">1</span><span style=3D"color:rgb(102,102,0)" class=3D"gm=
ail-m_-2950525757914535371styled-by-prettify">]];</span><span style=3D"colo=
r:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><br>=
<br></span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-29505257579=
14535371styled-by-prettify">float</span><span style=3D"color:rgb(0,0,0)" cl=
ass=3D"gmail-m_-2950525757914535371styled-by-prettify"> algo</span><span st=
yle=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by=
-prettify">(</span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-2=
950525757914535371styled-by-prettify">Normalized</span><span style=3D"color=
:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"> </sp=
an><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371=
styled-by-prettify">float</span><span style=3D"color:rgb(0,0,0)" class=3D"g=
mail-m_-2950525757914535371styled-by-prettify"> </span><span style=3D"color=
:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">lam=
bda</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757=
914535371styled-by-prettify">);</span></div></code></div>The former is not =
only more descriptive, it is more readable and furthermore reusable.<br><br=
></font></span></font></span></font></li><li>The Redundancy comes into play=
, when we mix value concepts and contracts<br><div class=3D"gmail-m_-295052=
5757914535371prettyprint" style=3D"border:1px solid rgb(187,187,187);word-w=
rap:break-word"><code class=3D"gmail-m_-2950525757914535371prettyprint"><di=
v class=3D"gmail-m_-2950525757914535371subprettyprint"><font color=3D"#0000=
00"><span style=3D"background-color:rgb(250,250,250)"><span style=3D"color:=
rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">temp=
late</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-295052575=
7914535371styled-by-prettify"><</span><span style=3D"color:rgb(0,0,136)"=
class=3D"gmail-m_-2950525757914535371styled-by-prettify">int</span><span s=
tyle=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-pr=
ettify"> I</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-295=
0525757914535371styled-by-prettify">></span><span style=3D"color:rgb(0,0=
,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"><br></span><s=
pan style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371style=
d-by-prettify">concept</span><span style=3D"color:rgb(0,0,0)" class=3D"gmai=
l-m_-2950525757914535371styled-by-prettify"> </span></span></font><span sty=
le=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-pr=
ettify">bool</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-29505=
25757914535371styled-by-prettify"> </span><span style=3D"color:rgb(102,0,10=
2)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">PowerOfTwo</sp=
an><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371st=
yled-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gma=
il-m_-2950525757914535371styled-by-prettify">=3D</span><span style=3D"color=
:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"> </sp=
an><span style=3D"color:rgb(136,0,0)" class=3D"gmail-m_-2950525757914535371=
styled-by-prettify">/* Is I a power of two? */</span><span style=3D"color:r=
gb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">;</=
span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371=
styled-by-prettify"><br><br></span><span style=3D"color:rgb(0,0,136)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify">template</span><span st=
yle=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by=
-prettify"><</span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m=
_-2950525757914535371styled-by-prettify">PowerOfTwo</span><span style=3D"co=
lor:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"> N=
</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914=
535371styled-by-prettify">></span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify"><br></span><span style=
=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-pret=
tify">struct</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-29505=
25757914535371styled-by-prettify"> </span><span style=3D"color:rgb(102,0,10=
2)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">Foo</span><spa=
n style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371style=
d-by-prettify">{};</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_=
-2950525757914535371styled-by-prettify"><br><br></span><span style=3D"color=
:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">voi=
d</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535=
371styled-by-prettify"> </span><span style=3D"color:rgb(0,0,0);background-c=
olor:rgb(250,250,250)"><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2=
950525757914535371styled-by-prettify">bar</span></span><span style=3D"color=
:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">(=
</span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-295052575791453=
5371styled-by-prettify">int</span><span style=3D"color:rgb(0,0,0)" class=3D=
"gmail-m_-2950525757914535371styled-by-prettify"> N</span><span style=3D"co=
lor:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify=
">)</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-29505257579145=
35371styled-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify">[[</span><span style=3D=
"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"=
>expects</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-29505=
25757914535371styled-by-prettify">:</span><span style=3D"color:rgb(0,0,0)" =
class=3D"gmail-m_-2950525757914535371styled-by-prettify"> </span><span styl=
e=3D"color:rgb(136,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-pre=
ttify">/* Is I a power of two? */</span><span style=3D"color:rgb(102,102,0)=
" class=3D"gmail-m_-2950525757914535371styled-by-prettify">]]</span><span s=
tyle=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-pr=
ettify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950=
525757914535371styled-by-prettify">;</span></div></code></div><span class=
=3D"gmail-m_-2950525757914535371styled-by-prettify"><font style=3D"backgrou=
nd-color:rgb(255,255,255)"><font color=3D"#000000">Instead we can write e.g=
..</font><div class=3D"gmail-m_-2950525757914535371prettyprint" style=3D"bac=
kground-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:=
break-word"><code class=3D"gmail-m_-2950525757914535371prettyprint"><div cl=
ass=3D"gmail-m_-2950525757914535371subprettyprint"><span style=3D"color:rgb=
(0,0,136)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">concept=
</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-29505257579145353=
71styled-by-prettify"> </span><span style=3D"color:rgb(102,0,102)" class=3D=
"gmail-m_-2950525757914535371styled-by-prettify">PowerOfTwo</span><span sty=
le=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-=
prettify">(</span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-29=
50525757914535371styled-by-prettify">Numerical</span><span style=3D"color:r=
gb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"> I</spa=
n><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-295052575791453537=
1styled-by-prettify">){</span><span style=3D"color:rgb(0,0,0)" class=3D"gma=
il-m_-2950525757914535371styled-by-prettify"> </span><span style=3D"color:r=
gb(136,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">/* Is=
I a power of two? */</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail=
-m_-2950525757914535371styled-by-prettify"> </span><span style=3D"color:rgb=
(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">}</sp=
an><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371st=
yled-by-prettify"><br><br></span><span style=3D"color:rgb(0,0,136)" class=
=3D"gmail-m_-2950525757914535371styled-by-prettify">template</span><span st=
yle=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by=
-prettify"><</span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m=
_-2950525757914535371styled-by-prettify">PowerOfTwo</span><span style=3D"co=
lor:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"> <=
/span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-2950525757914535=
371styled-by-prettify">int</span><span style=3D"color:rgb(0,0,0)" class=3D"=
gmail-m_-2950525757914535371styled-by-prettify"> N</span><span style=3D"col=
or:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"=
>></span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-295052575791=
4535371styled-by-prettify"><br></span><span style=3D"color:rgb(0,0,136)" cl=
ass=3D"gmail-m_-2950525757914535371styled-by-prettify">struct</span><span s=
tyle=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-pr=
ettify"> </span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-2950=
525757914535371styled-by-prettify">Foo</span><span style=3D"color:rgb(102,1=
02,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify">{};</span><=
span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled=
-by-prettify"><br><br></span><span style=3D"color:rgb(0,0,136)" class=3D"gm=
ail-m_-2950525757914535371styled-by-prettify">void</span><span style=3D"col=
or:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"> ba=
r</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-295052575791=
4535371styled-by-prettify">(</span><span style=3D"color:rgb(102,0,102)" cla=
ss=3D"gmail-m_-2950525757914535371styled-by-prettify">PowerOfTwo</span><spa=
n style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-2950525757914535371styled-by=
-prettify"> </span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-295=
0525757914535371styled-by-prettify">int</span><span style=3D"color:rgb(0,0,=
0)" class=3D"gmail-m_-2950525757914535371styled-by-prettify"> N</span><span=
style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-2950525757914535371styled=
-by-prettify">);</span></div></code></div></font></span></li></ol>Summary:<=
br><ul><li><b>Contracts </b>restrict the domain of a datatype to a set of v=
alues at runtime.</li><li><b>Concepts Lite </b>restrict the set of types (o=
r the domain of a datatype in case of value concepts as touch previously in=
P0587R1) at compile time.</li></ul></div></div></blockquote><div>FWIW, the=
problem I always have whenever anyone tries to explain Contracts to me thi=
s way is: there's no such thing as "restricting" behavior at =
runtime! What you really mean is, "At runtime, <b><i>if</i></b>=C2=A0t=
his situation arises, <i><b>then</b></i> <do something>." =C2=A0=
And C++ already has tons of ways to express that.</div><div>In other words,=
Concepts Lite provides a way to say, "If this condition isn't sat=
isfied, then SFINAE away: do the next-best thing if there is one." =C2=
=A0But with Contracts, all we can say is, "If this condition isn't=
satisfied, then the code has a bug and we need to hard-fail." So thes=
e Contracts are not the runtime equivalent of SFINAE/Concepts; these Contra=
cts are the runtime equivalent of static_assert().=C2=A0 But C++ has had th=
e runtime equivalent of static_assert() for longer than we've had stati=
c_assert()! =C2=A0:)</div><div><br></div><div><br></div><div>However, at C+=
+Now I had a long talk with Lisa Lippincott and she had a way of looking at=
Contracts that at least was self-consistent (although I cannot judge how m=
uch it is in step with the mainstream at the current moment).=C2=A0 Forget =
runtime. Contracts are about annotating code with annotations ("contra=
cts") that can be <b>statically checked at compile-time</b>. That is, =
they're the equivalent of the semi-common practice</div><div><br></div>=
<div><font face=3D"monospace, monospace">#define REQUIRES(x) assert(x)</fon=
t></div><div><font face=3D"monospace, monospace">#define ENSURES(x) assert(=
x)</font></div><div><font face=3D"monospace, monospace"><br></font></div><d=
iv><font face=3D"monospace, monospace">int log2(int x)</font></div><div><fo=
nt face=3D"monospace, monospace">{</font></div><div><font face=3D"monospace=
, monospace">=C2=A0 =C2=A0 REQUIRES((x & (x-1)) =3D=3D 0);<br></font></=
div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 int r =3D 0;<br>=
</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 while (=
x !=3D 1) x >>=3D 1, ++r;</font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 =C2=A0 ENSURES(0 <=3D r && r <=3D 31);</font=
></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 return r;</fo=
nt></div><div><font face=3D"monospace, monospace">}</font></div><div><br></=
div><div>(logic bugs in the above code are somewhat intentional).</div><div=
>The hope is that by religiously annotating every speck of code with these =
preconditions and postconditions, the compiler will actually be able to che=
ck your "correctness proof" and verify that each ENSURES clause f=
ollows logically from its corresponding REQUIRES clauses and the code in be=
tween.</div><div><br></div><div>This has nothing to do with <i>changing beh=
avior based on pattern matching</i>; this has to do with <i>machine verific=
ation of formal proofs of program correctness</i>.</div><div><br></div><div=
>The big concern I have with this approach to Contracts is that most people=
hate writing formal proofs, and in fact with the current state of the art,=
I claim that most people simply won't be able to do it. So it has to r=
emain optional, closeted off in the =C2=A0[[attributes]] ghetto so that it&=
#39;s not part of the "real" syntax, and maybe so that you can qu=
ickly turn it off =E2=80=94 for build time, or for prototyping, or just to =
make the dang thing compile. We can't build static-ENSURES()-checking i=
nto the language until we can show that it would actually work and not just=
get in everyone's way.</div><div><br></div><div>my $.02,</div><div>Art=
hur</div><div><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0L%3DhP_J%2BOe8AT_-TAFG-SA3yCrx=
BY-uGS0xKNhqTJ8sgw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0L%3DhP=
_J%2BOe8AT_-TAFG-SA3yCrxBY-uGS0xKNhqTJ8sgw%40mail.gmail.com</a>.<br />
--94eb2c1a074aa48e4b05529050b7--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Thu, 22 Jun 2017 19:57:54 +0000
Raw View
--089e08236db82838b9055291e774
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 22, 2017 at 12:36 AM Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:
> I think you may have to elaborate to make this more understandable. To me
> it seems that your use case just calls for a regular concept for the type
> to be erased, which describes each method that the type erasing wrapper h=
as.
>
> Den onsdag 21 juni 2017 kl. 11:56:13 UTC+2 skrev Micha=C5=82 Dominiak:
>
>> On Tue, Jun 20, 2017 at 11:45 PM Bengt Gustafsson <
>> bengt.gu...@beamways.com> wrote:
>>
>>> 1. Using a concept as a template parameter the way you indicate needs a
>>> use case to convince me. I think this will be hard to find as the idea =
of a
>>> concept is to
>>>
>>
>> Here's my attempt:
>>
>> I'm implementing a type erasure library, and I want to use concepts to
>> check whether types actually fit the archetype of the "typeclass" that I=
'm
>> erasing. To do that, I'd need to generate a concept per member function
>> name (obviously) to check whether that class has a member with a given n=
ame
>> and signature.
>>
>> I can't do this easily, because I need to somehow decompose the function
>> types that my template machinery gives me (as a single type).
>>
>> Now, I'd need either of three things:
>> 1) Using concepts as template parameters. This way I could have a type
>> that kind of "explodes" the function type into its parameter. I have tha=
t
>> implemented for type templates, and it's extremely useful for this; I ca=
n't
>> do it for concepts, for exactly this reason.
>> 2) A potentially simpler fix: allowing member concepts of types, because
>> then instead of exploding I could just have a member concept. This is of
>> course the less generic solution, since I'd need a wrapper for every "ki=
nd"
>> of a concept, but I could live with it.
>> 3) A feature to allow me to specialize concepts - then I can just use th=
e
>> decades old trick of pattern matching on the function type.
>>
>> (Hopefully the usage is clear enough, but I can spend more time on
>> explaining it if it isn't.)
>>
>
> I think you may have to elaborate to make this more understandable. To me
> it seems that your use case just calls for a regular concept for the type
> to be erased, which describes each method that the type erasing wrapper
> has. I could speculate that your trying to make a "general typ erasor"
> where each method of the wrapped archetype is a member function template
> parameter or something like that, if so it clearly needs more explanation=
..
> Also maybe it could be taken as proof for the need for virtual concepts (=
or
> proxies as they are called in another nearby thread).
>
It'll probably be easiest if I point to slides from my C++Now talk, you can
go watch it if you wish so:
https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-201=
7_friday/customization_points_that_such_less__michal_dominiak__cppnow_05-19=
-2017.pdf.
The interesting slides are 55 onwards.
I create a structure defining the interface for the type erased "concept",
and then I create mixins that provide those members for various elements of
the machinery. Now, slides 63 onwards show what I'd like to do with
concepts *somehow*. I can only operate on function types, and while I can
pass the function types into concepts, I can't decompose them in any way.
Bottom line is: I need to be able to define a concept's body in a place
where I have access to the decomposed elements of the function type.
Currently it's literally impossible.
As for virtual concepts -- yeah, and I do also mention them in the slides.
But I can't use concepts to define the interface for my library -- there's
no way to iterate over all the subexpressions that need to compile for the
concept to be true, to generate a mechanism for invoking them through the
type erasure wrapper. I *have* to do it through an actual interface --
which, coincidentally, looks exactly like Haskell typeclasses, Rust traits,
...., ...
I believe that if we do go down the current path, and then the path of
virtual concepts, actual implementations of the feature will have a lot of
work generating these wrappers from the subexpressions. *IMO basing the
feature on them is a mistake*; we should be defining the interface *by
defining the interface*, not by defining its usage. I believe there's no
prior art on this in the field, which makes the C++ approach a research
project, which is not a great fit in a mainstream programming language's
core. (I wish we iterated a few more times on this in form of TS revisions.=
)
> --
> 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/18b35423-7a3=
f-4aff-8f12-eef1e5b87acb%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/18b35423-7a=
3f-4aff-8f12-eef1e5b87acb%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAPCFJdQ2_9WuiKaQ3i-MMxmeKQqjpoG5rXHaZmpQnQcdD8W=
Wdg%40mail.gmail.com.
--089e08236db82838b9055291e774
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Jun 22=
, 2017 at 12:36 AM Bengt Gustafsson <<a href=3D"mailto:bengt.gustafsson@=
beamways.com">bengt.gustafsson@beamways.com</a>> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">I think you may have to elaborate =
to make this more understandable. To me it seems that your use case just ca=
lls for a regular concept for the type to be erased, which describes each m=
ethod that the type erasing wrapper has.<div><br></div><div>Den onsdag 21 j=
uni 2017 kl. 11:56:13 UTC+2 skrev Micha=C5=82 Dominiak:</div></div><div dir=
=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 20, 2017 at 11:45 PM Be=
ngt Gustafsson <<a rel=3D"nofollow">bengt.gu...@beamways.com</a>> wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>1. Using =
a concept as a template parameter the way you indicate needs a use case to =
convince me. I think this will be hard to find as the idea of a concept is =
to </div></div></blockquote><div><br></div><div>Here's my attempt:</div=
><div><br></div><div>I'm implementing a type erasure library, and I wan=
t to use concepts to check whether types actually fit the archetype of the =
"typeclass" that I'm erasing. To do that, I'd need to gen=
erate a concept per member function name (obviously) to check whether that =
class has a member with a given name and signature.</div><div><br></div><di=
v>I can't do this easily, because I need to somehow decompose the funct=
ion types that my template machinery gives me (as a single type).</div><div=
><br></div><div>Now, I'd need either of three things:</div><div>1) Usin=
g concepts as template parameters. This way I could have a type that kind o=
f "explodes" the function type into its parameter. I have that im=
plemented for type templates, and it's extremely useful for this; I can=
't do it for concepts, for exactly this reason.</div><div>2) A potentia=
lly simpler fix: allowing member concepts of types, because then instead of=
exploding I could just have a member concept. This is of course the less g=
eneric solution, since I'd need a wrapper for every "kind" of=
a concept, but I could live with it.</div><div>3) A feature to allow me to=
specialize concepts - then I can just use the decades old trick of pattern=
matching on the function type.</div><div><br></div><div>(Hopefully the usa=
ge is clear enough, but I can spend more time on explaining it if it isn=
9;t.)</div></div></div></blockquote><div><br></div></div></div><div dir=3D"=
ltr">I think you may have to elaborate to make this more understandable. To=
me it seems that your use case just calls for a regular concept for the ty=
pe to be erased, which describes each method that the type erasing wrapper =
has. I could speculate that your trying to make a "general typ erasor&=
quot; where each method of the wrapped archetype is a member function templ=
ate parameter or something like that, if so it clearly needs more explanati=
on. Also maybe it could be taken as proof for the need for virtual concepts=
(or proxies as they are called in another nearby thread).<div></div></div>=
</blockquote><div><br></div><div>It'll probably be easiest if I point t=
o slides from my C++Now talk, you can go watch it if you wish so:=C2=A0<a h=
ref=3D"https://github.com/boostcon/cppnow_presentations_2017/blob/master/05=
-19-2017_friday/customization_points_that_such_less__michal_dominiak__cppno=
w_05-19-2017.pdf">https://github.com/boostcon/cppnow_presentations_2017/blo=
b/master/05-19-2017_friday/customization_points_that_such_less__michal_domi=
niak__cppnow_05-19-2017.pdf</a>. The interesting slides are 55 onwards.</di=
v><div><br></div><div>I create a structure defining the interface for the t=
ype erased "concept", and then I create mixins that provide those=
members for various elements of the machinery. Now, slides 63 onwards show=
what I'd like to do with concepts <i>somehow</i>. I can only operate o=
n function types, and while I can pass the function types into concepts, I =
can't decompose them in any way.</div><div><br></div><div>Bottom line i=
s: I need to be able to define a concept's body in a place where I have=
access to the decomposed elements of the function type. Currently it's=
literally impossible.</div><div><br></div><div><br></div><div>As for virtu=
al concepts -- yeah, and I do also mention them in the slides. But I can=
9;t use concepts to define the interface for my library -- there's no w=
ay to iterate over all the subexpressions that need to compile for the conc=
ept to be true, to generate a mechanism for invoking them through the type =
erasure wrapper. I <i>have</i>=C2=A0to do it through an actual interface --=
which, coincidentally, looks exactly like Haskell typeclasses, Rust traits=
, ..., ...</div><div><br></div><div>I believe that if we do go down the cur=
rent path, and then the path of virtual concepts, actual implementations of=
the feature will have a lot of work generating these wrappers from the sub=
expressions. <b>IMO basing the feature on them is a mistake</b>; we should =
be defining the interface <i>by defining the interface</i>, not by defining=
its usage. I believe there's no prior art on this in the field, which =
makes the C++ approach a research project, which is not a great fit in a ma=
instream programming language's core. (I wish we iterated a few more ti=
mes on this in form of TS revisions.)</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/18b35423-7a3f-4aff-8f12-eef1e5b87acb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/18b35423-7a3f-=
4aff-8f12-eef1e5b87acb%40isocpp.org</a>.<br>
</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/CAPCFJdQ2_9WuiKaQ3i-MMxmeKQqjpoG5rXHa=
ZmpQnQcdD8WWdg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQ2_9WuiKaQ=
3i-MMxmeKQqjpoG5rXHaZmpQnQcdD8WWdg%40mail.gmail.com</a>.<br />
--089e08236db82838b9055291e774--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Thu, 22 Jun 2017 15:40:18 -0700 (PDT)
Raw View
------=_Part_117_1443622732.1498171218810
Content-Type: multipart/alternative;
boundary="----=_Part_118_701545855.1498171218811"
------=_Part_118_701545855.1498171218811
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hey Guys,
Am Donnerstag, 22. Juni 2017 20:04:28 UTC+2 schrieb Arthur O'Dwyer:
>
> On Thu, Jun 22, 2017 at 4:38 AM, Jakob Riedle <jakob....@gmail.com=20
> <javascript:>> wrote:
>
>> I have thought about this for a little now and I found an argument, why=
=20
>> we probably don't want pattern matching in the form of runtime overloadi=
ng:
>>
>> At Overloading Resolution, all Functions are equally considered in the=
=20
>> sence that there is *no ordering of preference* other than *declaration=
=20
>> scope* and *castability of function parameters*.
>>
>> This however restricts us to function overloads whose concepts are=20
>> disjunct sets of values (e.g. Even and Odd) in order to prevent ambiguit=
y.
>>
>>
> Well, that's not true. Overload resolution has a whole bunch of priority=
=20
> rules about what constitutes a "better match".
>
As I said, "no ordering of preference *other than declaration scope and=20
castability of parameters*". I mean exactly what you said :D
Am Donnerstag, 22. Juni 2017 20:04:28 UTC+2 schrieb Arthur O'Dwyer:
> Well, that's blatantly false. The "default" switch case matches=20
> if-and-only-if none of the others matches; that's why it's called=20
> "default". Also, all of the cases in a switch must be disjoint; otherwise=
=20
> it's a compile-time error.
>
I think you got me down the wrong pipe. I know what pattern matching is and=
=20
how it works and I know that it is not, what switch-case does.
I am sorry for posting this example about switch-case, it apparently does=
=20
nothing to clarify any of the meat discussed in this thread.
Am Donnerstag, 22. Juni 2017 20:04:28 UTC+2 schrieb Arthur O'Dwyer:
> This has nothing to do with *changing behavior based on pattern matching*=
;=20
> this has to do with *machine verification of formal proofs of program=20
> correctness*.
>
> The big concern I have with this approach to Contracts is that most peopl=
e=20
> hate writing formal proofs, and in fact with the current state of the art=
,=20
> I claim that most people simply won't be able to do it. So it has to rema=
in=20
> optional, closeted off in the [[attributes]] ghetto so that it's not par=
t=20
> of the "real" syntax, and maybe so that you can quickly turn it off =E2=
=80=94 for=20
> build time, or for prototyping, or just to make the dang thing compile. W=
e=20
> can't build static-ENSURES()-checking into the language until we can show=
=20
> that it would actually work and not just get in everyone's way.
>
Yeah, I understand the problem a little bit more now. I had a new Idea=20
concerning this while writing this answer, I'll append it to the end.
Am Donnerstag, 22. Juni 2017 21:58:08 UTC+2 schrieb Micha=C5=82 Dominiak:
> I believe that if we do go down the current path, and then the path of=20
> virtual concepts, actual implementations of the feature will have a lot o=
f=20
> work generating these wrappers from the subexpressions. *IMO basing the=
=20
> feature on them is a mistake*; we should be defining the interface *by=20
> defining the interface*, not by defining its usage.
Yes this hits the nail right on top I think. Isn't the problem 'just', that=
=20
we want to use a specific operation of/on a type and want it to be defined=
=20
but don't want to care about how, where and as what it is implemented?
The problem here is IMO that operations can be defined in many ways (member=
=20
function, static function, object with operator() overloaded ...), still=20
they can share the same invocation syntax.
Actually, I would not call an interface what you call interface.
In the context of concept definitions, IMO defining the usage of a feature =
*is=20
defining an abstract interface (even more abtract than in form of a=20
function signature). [An interface of an interface, if you will.]*
This way, many implementations of that feature (as freestanding function,=
=20
member function, constructor) can fulfill it.
After all I think this Proposal=20
<https://github.com/andyprowl/virtual-concepts/blob/master/draft/Dynamic%20=
Generic%20Programming%20with%20Virtual%20Concepts.pdf> is=20
quite doable, but you probably are referring to this as well.
*Appendix:*
Contracts are part of the type system but are not statically checked.=20
However in Debug Builds, whenever there is an implicit cast from an=20
unconstrained value to a constrained one, a warning and an implicit runtime=
=20
check is generated.
Whenever we want to ellide this warning (not the runtime check, for this=20
you have to switch to release build mode), you write something with the=20
semantics of 'claim ... is ...'.
This can be within a function call, Assignment Operation or outside of it=
=20
(as are Ensures and Expects). Result of this claim operation is always the=
=20
value itself.
However after the claim, the definition of the variable being claimed to=20
fulfill a given concept is changed to include this claim. This happens to=
=20
the point, where the variable is changed again.
Example:
void foo( Even int );
int i =3D 5;
foo( i ); // warning: implicit cast from 'int' to 'Even int'.
// This would remind the programmer at the place of the function invokation=
=20
to check the contracts of the called function.
foo( claim Even(i) ); // implicit runtime check on debug builds, no warning=
..
// For now, let's ignore the discussion about what happens if the check=20
fails
foo( !Even! i ); // Possible Syntactic Sugar for unary Constraints with=20
same semantic as above
foo( i ); // No warning anymore, since we already claimed i to be Even,=20
that is decltype(i) is 'Even int'
i =3D 5;
foo( i ); // Again a warning, since we changed i
Iterator iter1 =3D /*...*/;
Iterator iter2 =3D /*...*/;
claim Reachable(iter1,iter2); // Turns out to be Synonym to 'REQUIRES( )'=
=20
resp. '[[expect: ...]]' except that it 'saves' the claimed constraint=20
Reachable(iter1,iter2) for both variables.
// decltype(iter1) is now something like 'Reachable(X,iter2) Iterator' //=
=20
finding a good textual representation for this type name is irrelevant for=
=20
now
// decltype(iter2) is now something like 'Reachable(iter1,X) Iterator'
bool is_reachable =3D Reachable(iter1,iter2); // Only evaluates the constra=
int
To claim an unnamed constraint, you would write for example
claim i%2=3D=3D0;
In contrast to *assert, REQUIRES and [[expects: ]]*, claim (or whatever=20
name we may choose) would probably be an operator and it changes the=20
declared type of the involved variable for all future uses of it (below the=
=20
call to claim).
Allowing the constraints to be part of the type system and thus allowing=20
them to be part of a function declaration resembles the idea that the=20
caller is responsible for passing in the right values (a contract), instead=
=20
of the idea of values being checked within the function.
Sure, many aspects of this approach are not determined yet and may even be=
=20
a rather big discussion point... BUT:
By using this approach,
1. you provide the tools for formal verification/static analysis (to the=
=20
extent that programmers annotate their code), you
2. have everything compile as usually (no errors, just warnings), you
3. conditionally support runtime-checks as described in P0380R1=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf>,=
=20
you
4. can reuse the defined constraints for future pattern matching=20
proposals and you
5. bridge the gap between value concepts and contracts (as 'constexpr'=
=20
constraints are usable for template parameters as well).
I hope I have not forgotten something essential, please have mercy with me=
=20
in this case :D
Cheers and have a nice Evening,
Jakob
--=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/b87e09a1-fd8f-48f2-b075-25acc68b1e86%40isocpp.or=
g.
------=_Part_118_701545855.1498171218811
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hey Guys,<div><br></div><div>Am Donnerstag, 22. Juni 2017 =
20:04:28 UTC+2 schrieb Arthur O'Dwyer:<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 Thu, Jun 22, 2017 at 4:38 AM, Jakob Riedle =
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"tMHQxtu1AAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;javascript:';return true;" onclick=3D"this.href=3D'javascript:=
9;;return true;">jakob....@gmail.com</a>></span> wrote:<br><div><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span><div>I have thou=
ght about this for a little now and I found an argument, why we probably do=
n't want pattern matching in the form of runtime overloading:<br></div>=
</span><div><br></div><blockquote style=3D"margin:0px 0px 0px 40px;border:n=
one;padding:0px"><div>At Overloading Resolution, all Functions are equally =
considered in the sence that there is <b>no ordering of preference</b> othe=
r than <i>declaration scope</i> and <i>castability of function parameters</=
i>.</div></blockquote><blockquote style=3D"margin:0px 0px 0px 40px;border:n=
one;padding:0px"><div>This however restricts us to function overloads whose=
concepts are disjunct sets of values (e.g. Even and Odd) in order to preve=
nt ambiguity.</div></blockquote></div></blockquote><div><br></div><div>Well=
, that's not true. Overload resolution has a whole bunch of priority ru=
les about what constitutes a "better match".</div></div></div></d=
iv></blockquote><div><br></div><div>As I said, "no ordering of prefere=
nce <i>other than declaration scope and castability of parameters</i>"=
.. I mean exactly what you said :D</div><div><br></div><div><br></div><div>A=
m Donnerstag, 22. Juni 2017 20:04:28 UTC+2 schrieb Arthur O'Dwyer:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Well, that&#=
39;s blatantly false.=C2=A0 The "default" switch case matches if-=
and-only-if none of the others matches; that's why it's called &quo=
t;default". Also, all of the cases in a switch must be disjoint; other=
wise it's a compile-time error.<br></blockquote><div><br></div><div>I t=
hink you got me down the wrong pipe. I know what pattern matching is and ho=
w it works and I know that it is not, what switch-case does.</div><div>I am=
sorry for posting this example about switch-case, it apparently does nothi=
ng to clarify any of the meat discussed in this thread.</div><div><br></div=
><div><br></div><div>Am Donnerstag, 22. Juni 2017 20:04:28 UTC+2 schrieb Ar=
thur O'Dwyer:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le=
ft: 1ex;"><div>This has nothing to do with=C2=A0<i>changing behavior based =
on pattern matching</i>; this has to do with=C2=A0<i>machine verification o=
f formal proofs of program correctness</i>.</div><div><br></div><div>The bi=
g concern I have with this approach to Contracts is that most people hate w=
riting formal proofs, and in fact with the current state of the art, I clai=
m that most people simply won't be able to do it. So it has to remain o=
ptional, closeted off in the =C2=A0[[attributes]] ghetto so that it's n=
ot part of the "real" syntax, and maybe so that you can quickly t=
urn it off =E2=80=94 for build time, or for prototyping, or just to make th=
e dang thing compile. We can't build static-ENSURES()-checking into the=
language until we can show that it would actually work and not just get in=
everyone's way.</div></blockquote><div><br></div><div>Yeah, I understa=
nd the problem a little bit more now. I had a new Idea concerning this whil=
e writing this answer, I'll append it to the end.</div><div><br><br>Am =
Donnerstag, 22. Juni 2017 21:58:08 UTC+2 schrieb Micha=C5=82 Dominiak:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I believe th=
at if we do go down the current path, and then the path of virtual concepts=
, actual implementations of the feature will have a lot of work generating =
these wrappers from the subexpressions.=C2=A0<b>IMO basing the feature on t=
hem is a mistake</b>; we should be defining the interface=C2=A0<i>by defini=
ng the interface</i>, not by defining its usage.</blockquote><div><br></div=
><div>Yes this hits the nail right on top I think. Isn't the problem &#=
39;just', that we want to use a specific operation of/on a type and wan=
t it to be defined but don't want to care about how, where and as what =
it is implemented?</div><div>The problem here is IMO that operations can be=
defined in many ways (member function, static function, object with operat=
or() overloaded ...), still they can share the same invocation syntax.</div=
><div><br></div><div>Actually, I would not call an interface what you call =
interface.</div><div>In the context of concept definitions, IMO defining th=
e usage of a feature <i>is defining an abstract interface (even more abtrac=
t than in form of a function signature). [An interface of an interface, if =
you will.]</i></div><div>This way, many implementations of that feature (as=
freestanding function, member function, constructor) can fulfill it.</div>=
<div><br></div><div>After all I think=C2=A0<a href=3D"https://github.com/an=
dyprowl/virtual-concepts/blob/master/draft/Dynamic%20Generic%20Programming%=
20with%20Virtual%20Concepts.pdf">this Proposal</a>=C2=A0is quite doable, bu=
t you probably are referring to this as well.<br></div><div><br></div><div>=
<br></div><div><br></div><div><b>Appendix:</b></div><div><b><br></b></div><=
div>Contracts are part of the type system but are not statically checked. H=
owever in Debug Builds, whenever there is an implicit cast from an unconstr=
ained value to a constrained one, a warning and an implicit runtime check i=
s generated.</div><div>Whenever we want to ellide this warning (not the run=
time check, for this you have to switch to release build mode), you write s=
omething with the semantics of 'claim ... is ...'.</div><div>This c=
an be within a function call, Assignment Operation or outside of it (as are=
Ensures and Expects). Result of this claim operation is always the value i=
tself.</div><div>However after the claim, the definition of the variable be=
ing claimed to fulfill a given concept is changed to include this claim. Th=
is happens to the point, where the variable is changed again.</div><div>Exa=
mple:</div><div><div class=3D"prettyprint" style=3D"background-color: rgb(2=
50, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; borde=
r-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Even</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" c=
lass=3D"styled-by-prettify">5</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br><br>foo</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #800;" class=3D"styled-by-prettify">// warning: implicit c=
ast from 'int' to 'Even int'.</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><span style=3D"color: rgb(34, 34, 34); f=
ont-family: Arial, Helvetica, sans-serif; background-color: rgb(255, 255, 2=
55);"><br></span><span style=3D"color: rgb(34, 34, 34); font-family: Arial,=
Helvetica, sans-serif; background-color: rgb(255, 255, 255);">// This woul=
d remind the programmer at the place of the function invokation to check th=
e contracts of the called function.<br></span><br>foo</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> claim </span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">Even</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">i</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// implicit runtime check on=
debug builds, no warning.<br></span>// For now, let's ignore the discu=
ssion about what happens if the check fails<br><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br>foo</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">!</span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Even</span><span style=3D"color: #660;" class=3D"styled-by-prettify">!</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">// Possible Syntactic Sugar for unary=
Constraints with same semantic as above<br></span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>foo</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">=
// No warning anymore, since we already claimed i to be Even, that is declt=
ype(i) is 'Even int'</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br><br>i </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>foo</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// Again a warning, since we changed i</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><span style=3D"color: rgb=
(136, 0, 0);">Iterator=C2=A0</span>iter1 </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">/*...*/</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><sp=
an style=3D"color: rgb(136, 0, 0);">Iterator=C2=A0</span>iter2 </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">/*...*/</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br>claim </span><span style=3D"color: #606;"=
class=3D"styled-by-prettify">Reachable</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">iter1</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">iter2</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">// Turns out to =
be Synonym to 'REQUIRES( )' resp. '[[expect: ...]]' except =
that it 'saves' the claimed constraint Reachable(iter1,iter2) for b=
oth variables.<br><br>// decltype(iter1) is now something like 'Reachab=
le(X,iter2) Iterator' // finding a good textual representation for this=
type name is irrelevant for now<br>// decltype(iter2) is now something lik=
e 'Reachable(iter1,X) Iterator'<br></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> is_reachable </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">Reachable</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i=
ter1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">iter2</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">// Only evaluates the constraint</spa=
n><br></div></code></div></code></div><div><br></div>To claim an unnamed co=
nstraint, you would write for example</div><div><div class=3D"prettyprint" =
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, =
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><code=
class=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#660066=
">claim i%2=3D=3D0;</font></div></code></div><br>In contrast to <i>assert, =
REQUIRES and [[expects: ]]</i>, claim (or whatever name we may choose) woul=
d probably be an operator and it changes the declared type of the involved=
=C2=A0variable for all future uses of it (below the call to claim).</div><d=
iv><div>Allowing the constraints to be part of the type system and thus all=
owing them to be part of a function declaration resembles the idea that the=
caller is responsible for passing in the right values (a contract), instea=
d of the idea of values being checked within the function.</div></div><div>=
<br></div><div>Sure, many aspects of this approach are not determined yet a=
nd may even be a rather big discussion point... BUT:<br></div><div>By using=
this approach,</div><div><ol><li>you provide the tools for formal verifica=
tion/static analysis (to the extent that programmers annotate their code), =
you</li><li>have everything compile as usually (no errors, just warnings), =
you</li><li>conditionally support runtime-checks as described in <a href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf">P0380=
R1</a>, you</li><li>can reuse the defined constraints for future pattern ma=
tching proposals and you</li><li>bridge the gap between value concepts and =
contracts (as 'constexpr' constraints are usable for template param=
eters as well).</li></ol>I hope I have not forgotten something essential, p=
lease have mercy with me in this case :D<br></div><div><br></div><div>Cheer=
s and have a nice Evening,</div><div>Jakob</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/b87e09a1-fd8f-48f2-b075-25acc68b1e86%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b87e09a1-fd8f-48f2-b075-25acc68b1e86=
%40isocpp.org</a>.<br />
------=_Part_118_701545855.1498171218811--
------=_Part_117_1443622732.1498171218810--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Tue, 27 Jun 2017 02:31:25 -0700 (PDT)
Raw View
------=_Part_578_1708529506.1498555885776
Content-Type: multipart/alternative;
boundary="----=_Part_579_55152619.1498555885776"
------=_Part_579_55152619.1498555885776
Content-Type: text/plain; charset="UTF-8"
Michael? Arthur? Are you there?
--
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/88a228f4-eb3a-49ec-b29d-ffafe320fb96%40isocpp.org.
------=_Part_579_55152619.1498555885776
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Michael? Arthur? Are you there?<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/88a228f4-eb3a-49ec-b29d-ffafe320fb96%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/88a228f4-eb3a-49ec-b29d-ffafe320fb96=
%40isocpp.org</a>.<br />
------=_Part_579_55152619.1498555885776--
------=_Part_578_1708529506.1498555885776--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Tue, 27 Jun 2017 10:43:14 +0000
Raw View
--94eb2c145bd6bc2ca60552eebc02
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 23, 2017 at 12:40 AM Jakob Riedle <jakob.riedle@gmail.com>
wrote:
> Hey Guys,
>
> Am Donnerstag, 22. Juni 2017 20:04:28 UTC+2 schrieb Arthur O'Dwyer:
>
>> On Thu, Jun 22, 2017 at 4:38 AM, Jakob Riedle <jakob....@gmail.com>
>> wrote:
>>
>>> I have thought about this for a little now and I found an argument, why
>>> we probably don't want pattern matching in the form of runtime overload=
ing:
>>>
>>> At Overloading Resolution, all Functions are equally considered in the
>>> sence that there is *no ordering of preference* other than *declaration
>>> scope* and *castability of function parameters*.
>>>
>>> This however restricts us to function overloads whose concepts are
>>> disjunct sets of values (e.g. Even and Odd) in order to prevent ambigui=
ty.
>>>
>>>
>> Well, that's not true. Overload resolution has a whole bunch of priority
>> rules about what constitutes a "better match".
>>
>
> As I said, "no ordering of preference *other than declaration scope and
> castability of parameters*". I mean exactly what you said :D
>
>
> Am Donnerstag, 22. Juni 2017 20:04:28 UTC+2 schrieb Arthur O'Dwyer:
>
>> Well, that's blatantly false. The "default" switch case matches
>> if-and-only-if none of the others matches; that's why it's called
>> "default". Also, all of the cases in a switch must be disjoint; otherwis=
e
>> it's a compile-time error.
>>
>
> I think you got me down the wrong pipe. I know what pattern matching is
> and how it works and I know that it is not, what switch-case does.
> I am sorry for posting this example about switch-case, it apparently does
> nothing to clarify any of the meat discussed in this thread.
>
>
> Am Donnerstag, 22. Juni 2017 20:04:28 UTC+2 schrieb Arthur O'Dwyer:
>
>> This has nothing to do with *changing behavior based on pattern matching=
*;
>> this has to do with *machine verification of formal proofs of program
>> correctness*.
>>
>> The big concern I have with this approach to Contracts is that most
>> people hate writing formal proofs, and in fact with the current state of
>> the art, I claim that most people simply won't be able to do it. So it h=
as
>> to remain optional, closeted off in the [[attributes]] ghetto so that i=
t's
>> not part of the "real" syntax, and maybe so that you can quickly turn it
>> off =E2=80=94 for build time, or for prototyping, or just to make the da=
ng thing
>> compile. We can't build static-ENSURES()-checking into the language unti=
l
>> we can show that it would actually work and not just get in everyone's w=
ay.
>>
>
> Yeah, I understand the problem a little bit more now. I had a new Idea
> concerning this while writing this answer, I'll append it to the end.
>
>
> Am Donnerstag, 22. Juni 2017 21:58:08 UTC+2 schrieb Micha=C5=82 Dominiak:
>
>> I believe that if we do go down the current path, and then the path of
>> virtual concepts, actual implementations of the feature will have a lot =
of
>> work generating these wrappers from the subexpressions. *IMO basing the
>> feature on them is a mistake*; we should be defining the interface *by
>> defining the interface*, not by defining its usage.
>
>
> Yes this hits the nail right on top I think. Isn't the problem 'just',
> that we want to use a specific operation of/on a type and want it to be
> defined but don't want to care about how, where and as what it is
> implemented?
> The problem here is IMO that operations can be defined in many ways
> (member function, static function, object with operator() overloaded ...)=
,
> still they can share the same invocation syntax.
>
> Actually, I would not call an interface what you call interface.
> In the context of concept definitions, IMO defining the usage of a featur=
e *is
> defining an abstract interface (even more abtract than in form of a
> function signature). [An interface of an interface, if you will.]*
> This way, many implementations of that feature (as freestanding function,
> member function, constructor) can fulfill it.
>
> After all I think this Proposal
> <https://github.com/andyprowl/virtual-concepts/blob/master/draft/Dynamic%=
20Generic%20Programming%20with%20Virtual%20Concepts.pdf> is
> quite doable, but you probably are referring to this as well.
>
>
This might be a good way to call them. But I also don't think you
necessarily need an "interface interface", in presence of concept maps.
Especially since, with if constexpr and proper requires that's usable
wherever, you could create default implementations that dispatch to various
different kinds of function calls. (In the simplest case, it could just
dispatch to the `foo.bar()` call, and that'll work.)
Now, this has the advantage of providing customization points, and all this
very naturally leads to type erasure (which is extremely powerful, because
you can adapt types that don't fit!).
Virtual concepts is a thing I often refer to, and while I believe that'd be
a necessary thing to have if we end up with the TS concepts, I'd much
prefer not to end up with TS concepts and have a way to specify an (
*adaptable* - this is a truly crucial point, because it allows me to do
semantic specializations, not just a syntactic one, by providing an
"explicit" concept thing, which stops types *accidentally* matching an
interface) interface instead of specifying an interface interface.
*And now the crazy part: *I think we can implement all that with
metaclasses. *I still want a language feature*, because that'd make it
easier to avoid mixing a concept kind with a type kind, but it *could* be
done. If someone gave me a way to create a new *kind* of an entity in the
language, I could have an implementation I'd be happy with with
metaclasses. (I don't know whether having a generic facility to introduce
new entity kinds would be a popular idea for C++. Up until this very moment
I haven't even considered it for a research language that I'm working on,
which usually ends up being the bag to put features I eventually want to
implement in.)
>
>
> *Appendix:*
>
> Contracts are part of the type system but are not statically checked.
> However in Debug Builds, whenever there is an implicit cast from an
> unconstrained value to a constrained one, a warning and an implicit runti=
me
> check is generated.
> Whenever we want to ellide this warning (not the runtime check, for this
> you have to switch to release build mode), you write something with the
> semantics of 'claim ... is ...'.
> This can be within a function call, Assignment Operation or outside of it
> (as are Ensures and Expects). Result of this claim operation is always th=
e
> value itself.
> However after the claim, the definition of the variable being claimed to
> fulfill a given concept is changed to include this claim. This happens to
> the point, where the variable is changed again.
> Example:
> void foo( Even int );
>
> int i =3D 5;
>
> foo( i ); // warning: implicit cast from 'int' to 'Even int'.
> // This would remind the programmer at the place of the function
> invokation to check the contracts of the called function.
>
> foo( claim Even(i) ); // implicit runtime check on debug builds, no
> warning.
> // For now, let's ignore the discussion about what happens if the check
> fails
>
> foo( !Even! i ); // Possible Syntactic Sugar for unary Constraints with
> same semantic as above
>
> foo( i ); // No warning anymore, since we already claimed i to be Even,
> that is decltype(i) is 'Even int'
>
> i =3D 5;
> foo( i ); // Again a warning, since we changed i
>
> Iterator iter1 =3D /*...*/;
> Iterator iter2 =3D /*...*/;
>
> claim Reachable(iter1,iter2); // Turns out to be Synonym to 'REQUIRES( )'
> resp. '[[expect: ...]]' except that it 'saves' the claimed constraint
> Reachable(iter1,iter2) for both variables.
>
> // decltype(iter1) is now something like 'Reachable(X,iter2) Iterator' //
> finding a good textual representation for this type name is irrelevant fo=
r
> now
> // decltype(iter2) is now something like 'Reachable(iter1,X) Iterator'
>
> bool is_reachable =3D Reachable(iter1,iter2); // Only evaluates the
> constraint
>
> To claim an unnamed constraint, you would write for example
> claim i%2=3D=3D0;
>
> In contrast to *assert, REQUIRES and [[expects: ]]*, claim (or whatever
> name we may choose) would probably be an operator and it changes the
> declared type of the involved variable for all future uses of it (below t=
he
> call to claim).
> Allowing the constraints to be part of the type system and thus allowing
> them to be part of a function declaration resembles the idea that the
> caller is responsible for passing in the right values (a contract), inste=
ad
> of the idea of values being checked within the function.
>
> Sure, many aspects of this approach are not determined yet and may even b=
e
> a rather big discussion point... BUT:
> By using this approach,
>
> 1. you provide the tools for formal verification/static analysis (to
> the extent that programmers annotate their code), you
> 2. have everything compile as usually (no errors, just warnings), you
> 3. conditionally support runtime-checks as described in P0380R1
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf>,
> you
> 4. can reuse the defined constraints for future pattern matching
> proposals and you
> 5. bridge the gap between value concepts and contracts (as 'constexpr'
> constraints are usable for template parameters as well).
>
> I hope I have not forgotten something essential, please have mercy with m=
e
> in this case :D
>
> Cheers and have a nice Evening,
> Jakob
>
> --
> 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/b87e09a1-fd8=
f-48f2-b075-25acc68b1e86%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b87e09a1-fd=
8f-48f2-b075-25acc68b1e86%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAPCFJdTiRg0f%3DGLiQAOPkZXf9dtTKNNVABRTKAy8p4tyv=
-Tx%2BA%40mail.gmail.com.
--94eb2c145bd6bc2ca60552eebc02
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Jun 23=
, 2017 at 12:40 AM Jakob Riedle <<a href=3D"mailto:jakob.riedle@gmail.co=
m">jakob.riedle@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">Hey Guys,<div><br></div><div>Am Donnerstag, 22. Juni=
2017 20:04:28 UTC+2 schrieb Arthur O'Dwyer:</div></div><div dir=3D"ltr=
"><div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thu, Jun=
22, 2017 at 4:38 AM, Jakob Riedle <span dir=3D"ltr"><<a rel=3D"nofollow=
">jakob....@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><div dir=3D"ltr"><span><div>I have thought about this =
for a little now and I found an argument, why we probably don't want pa=
ttern matching in the form of runtime overloading:<br></div></span><div><br=
></div><blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px=
"><div>At Overloading Resolution, all Functions are equally considered in t=
he sence that there is <b>no ordering of preference</b> other than <i>decla=
ration scope</i> and <i>castability of function parameters</i>.</div></bloc=
kquote><blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px=
"><div>This however restricts us to function overloads whose concepts are d=
isjunct sets of values (e.g. Even and Odd) in order to prevent ambiguity.</=
div></blockquote></div></blockquote><div><br></div><div>Well, that's no=
t true. Overload resolution has a whole bunch of priority rules about what =
constitutes a "better match".</div></div></div></div></blockquote=
><div><br></div></div></div><div dir=3D"ltr"><div><div>As I said, "no =
ordering of preference <i>other than declaration scope and castability of p=
arameters</i>". I mean exactly what you said :D</div></div></div><div =
dir=3D"ltr"><div><div><br></div><div><br></div><div>Am Donnerstag, 22. Juni=
2017 20:04:28 UTC+2 schrieb Arthur O'Dwyer:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Well, that's blatantly false.=C2=A0 Th=
e "default" switch case matches if-and-only-if none of the others=
matches; that's why it's called "default". Also, all of =
the cases in a switch must be disjoint; otherwise it's a compile-time e=
rror.<br></blockquote><div><br></div></div></div><div dir=3D"ltr"><div><div=
>I think you got me down the wrong pipe. I know what pattern matching is an=
d how it works and I know that it is not, what switch-case does.</div><div>=
I am sorry for posting this example about switch-case, it apparently does n=
othing to clarify any of the meat discussed in this thread.</div></div></di=
v><div dir=3D"ltr"><div><div><br></div><div><br></div><div>Am Donnerstag, 2=
2. Juni 2017 20:04:28 UTC+2 schrieb Arthur O'Dwyer:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div>This has nothing to do with=C2=
=A0<i>changing behavior based on pattern matching</i>; this has to do with=
=C2=A0<i>machine verification of formal proofs of program correctness</i>.<=
/div><div><br></div><div>The big concern I have with this approach to Contr=
acts is that most people hate writing formal proofs, and in fact with the c=
urrent state of the art, I claim that most people simply won't be able =
to do it. So it has to remain optional, closeted off in the =C2=A0[[attribu=
tes]] ghetto so that it's not part of the "real" syntax, and =
maybe so that you can quickly turn it off =E2=80=94 for build time, or for =
prototyping, or just to make the dang thing compile. We can't build sta=
tic-ENSURES()-checking into the language until we can show that it would ac=
tually work and not just get in everyone's way.</div></blockquote><div>=
<br></div></div></div><div dir=3D"ltr"><div><div>Yeah, I understand the pro=
blem a little bit more now. I had a new Idea concerning this while writing =
this answer, I'll append it to the end.</div></div></div><div dir=3D"lt=
r"><div><div><br><br>Am Donnerstag, 22. Juni 2017 21:58:08 UTC+2 schrieb Mi=
cha=C5=82 Dominiak:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">I believe that if we do go down the current path, and then the path of =
virtual concepts, actual implementations of the feature will have a lot of =
work generating these wrappers from the subexpressions.=C2=A0<b>IMO basing =
the feature on them is a mistake</b>; we should be defining the interface=
=C2=A0<i>by defining the interface</i>, not by defining its usage.</blockqu=
ote><div><br></div></div></div><div dir=3D"ltr"><div><div>Yes this hits the=
nail right on top I think. Isn't the problem 'just', that we w=
ant to use a specific operation of/on a type and want it to be defined but =
don't want to care about how, where and as what it is implemented?</div=
><div>The problem here is IMO that operations can be defined in many ways (=
member function, static function, object with operator() overloaded ...), s=
till they can share the same invocation syntax.</div><div><br></div><div>Ac=
tually, I would not call an interface what you call interface.</div><div>In=
the context of concept definitions, IMO defining the usage of a feature <i=
>is defining an abstract interface (even more abtract than in form of a fun=
ction signature). [An interface of an interface, if you will.]</i></div><di=
v>This way, many implementations of that feature (as freestanding function,=
member function, constructor) can fulfill it.</div><div><br></div><div>Aft=
er all I think=C2=A0<a href=3D"https://github.com/andyprowl/virtual-concept=
s/blob/master/draft/Dynamic%20Generic%20Programming%20with%20Virtual%20Conc=
epts.pdf" target=3D"_blank">this Proposal</a>=C2=A0is quite doable, but you=
probably are referring to this as well.<br></div><div><br></div></div></di=
v></blockquote><div><br></div><div>This might be a good way to call them. B=
ut I also don't think you necessarily need an "interface interface=
", in presence of concept maps. Especially since, with if constexpr an=
d proper requires that's usable wherever, you could create default impl=
ementations that dispatch to various different kinds of function calls. (In=
the simplest case, it could just dispatch to the `foo.bar()` call, and tha=
t'll work.)</div><div><br></div><div>Now, this has the advantage of pro=
viding customization points, and all this very naturally leads to type eras=
ure (which is extremely powerful, because you can adapt types that don'=
t fit!).</div><div><br></div><div>Virtual concepts is a thing I often refer=
to, and while I believe that'd be a necessary thing to have if we end =
up with the TS concepts, I'd much prefer not to end up with TS concepts=
and have a way to specify an (<b>adaptable</b>=C2=A0- this is a truly cruc=
ial point, because it allows me to do semantic specializations, not just a =
syntactic one, by providing an "explicit" concept thing, which st=
ops types <i>accidentally</i>=C2=A0matching an interface) interface instead=
of specifying an interface interface.</div><div><br></div><div><b>And now =
the crazy part: </b>I think we can implement all that with metaclasses. <i>=
I still want a language feature</i>, because that'd make it easier to a=
void mixing a concept kind with a type kind, but it <i>could</i>=C2=A0be do=
ne. If someone gave me a way to create a new <i>kind</i>=C2=A0of an entity =
in the language, I could have an implementation I'd be happy with with =
metaclasses. (I don't know whether having a generic facility to introdu=
ce new entity kinds would be a popular idea for C++. Up until this very mom=
ent I haven't even considered it for a research language that I'm w=
orking on, which usually ends up being the bag to put features I eventually=
want to implement in.)</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div><div></div><div><br></div><div><br></div><div><b>Ap=
pendix:</b></div><div><b><br></b></div><div>Contracts are part of the type =
system but are not statically checked. However in Debug Builds, whenever th=
ere is an implicit cast from an unconstrained value to a constrained one, a=
warning and an implicit runtime check is generated.</div><div>Whenever we =
want to ellide this warning (not the runtime check, for this you have to sw=
itch to release build mode), you write something with the semantics of '=
;claim ... is ...'.</div><div>This can be within a function call, Assig=
nment Operation or outside of it (as are Ensures and Expects). Result of th=
is claim operation is always the value itself.</div><div>However after the =
claim, the definition of the variable being claimed to fulfill a given conc=
ept is changed to include this claim. This happens to the point, where the =
variable is changed again.</div><div>Example:</div><div><div class=3D"m_-65=
95837517255212237prettyprint" style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:b=
reak-word"><code class=3D"m_-6595837517255212237prettyprint"><div class=3D"=
m_-6595837517255212237prettyprint" style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-w=
rap:break-word"><code class=3D"m_-6595837517255212237prettyprint"><div clas=
s=3D"m_-6595837517255212237subprettyprint"><span style=3D"color:#008" class=
=3D"m_-6595837517255212237styled-by-prettify">void</span><span style=3D"col=
or:#000" class=3D"m_-6595837517255212237styled-by-prettify"> foo</span><spa=
n style=3D"color:#660" class=3D"m_-6595837517255212237styled-by-prettify">(=
</span><span style=3D"color:#000" class=3D"m_-6595837517255212237styled-by-=
prettify"> </span><span style=3D"color:#606" class=3D"m_-659583751725521223=
7styled-by-prettify">Even</span><span style=3D"color:#000" class=3D"m_-6595=
837517255212237styled-by-prettify"> </span><span style=3D"color:#008" class=
=3D"m_-6595837517255212237styled-by-prettify">int</span><span style=3D"colo=
r:#000" class=3D"m_-6595837517255212237styled-by-prettify"> </span><span st=
yle=3D"color:#660" class=3D"m_-6595837517255212237styled-by-prettify">);</s=
pan><span style=3D"color:#000" class=3D"m_-6595837517255212237styled-by-pre=
ttify"><br><br></span><span style=3D"color:#008" class=3D"m_-65958375172552=
12237styled-by-prettify">int</span><span style=3D"color:#000" class=3D"m_-6=
595837517255212237styled-by-prettify"> i </span><span style=3D"color:#660" =
class=3D"m_-6595837517255212237styled-by-prettify">=3D</span><span style=3D=
"color:#000" class=3D"m_-6595837517255212237styled-by-prettify"> </span><sp=
an style=3D"color:#066" class=3D"m_-6595837517255212237styled-by-prettify">=
5</span><span style=3D"color:#660" class=3D"m_-6595837517255212237styled-by=
-prettify">;</span><span style=3D"color:#000" class=3D"m_-65958375172552122=
37styled-by-prettify"><br><br>foo</span><span style=3D"color:#660" class=3D=
"m_-6595837517255212237styled-by-prettify">(</span><span style=3D"color:#00=
0" class=3D"m_-6595837517255212237styled-by-prettify"> i </span><span style=
=3D"color:#660" class=3D"m_-6595837517255212237styled-by-prettify">);</span=
><span style=3D"color:#000" class=3D"m_-6595837517255212237styled-by-pretti=
fy"> </span><span style=3D"color:#800" class=3D"m_-6595837517255212237style=
d-by-prettify">// warning: implicit cast from 'int' to 'Even in=
t'.</span><span style=3D"color:#000" class=3D"m_-6595837517255212237sty=
led-by-prettify"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helve=
tica,sans-serif;background-color:rgb(255,255,255)"><br></span><span style=
=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;background-c=
olor:rgb(255,255,255)">// This would remind the programmer at the place of =
the function invokation to check the contracts of the called function.<br><=
/span><br>foo</span><span style=3D"color:#660" class=3D"m_-6595837517255212=
237styled-by-prettify">(</span><span style=3D"color:#000" class=3D"m_-65958=
37517255212237styled-by-prettify"> claim </span><span style=3D"color:#606" =
class=3D"m_-6595837517255212237styled-by-prettify">Even</span><span style=
=3D"color:#660" class=3D"m_-6595837517255212237styled-by-prettify">(</span>=
<span style=3D"color:#000" class=3D"m_-6595837517255212237styled-by-prettif=
y">i</span><span style=3D"color:#660" class=3D"m_-6595837517255212237styled=
-by-prettify">)</span><span style=3D"color:#000" class=3D"m_-65958375172552=
12237styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_-659=
5837517255212237styled-by-prettify">);</span><span style=3D"color:#000" cla=
ss=3D"m_-6595837517255212237styled-by-prettify"> </span><span style=3D"colo=
r:#800" class=3D"m_-6595837517255212237styled-by-prettify">// implicit runt=
ime check on debug builds, no warning.<br></span>// For now, let's igno=
re the discussion about what happens if the check fails<br><span style=3D"c=
olor:#000" class=3D"m_-6595837517255212237styled-by-prettify"><br>foo</span=
><span style=3D"color:#660" class=3D"m_-6595837517255212237styled-by-pretti=
fy">(</span><span style=3D"color:#000" class=3D"m_-6595837517255212237style=
d-by-prettify"> </span><span style=3D"color:#660" class=3D"m_-6595837517255=
212237styled-by-prettify">!</span><span style=3D"color:#606" class=3D"m_-65=
95837517255212237styled-by-prettify">Even</span><span style=3D"color:#660" =
class=3D"m_-6595837517255212237styled-by-prettify">!</span><span style=3D"c=
olor:#000" class=3D"m_-6595837517255212237styled-by-prettify"> i </span><sp=
an style=3D"color:#660" class=3D"m_-6595837517255212237styled-by-prettify">=
);</span><span style=3D"color:#000" class=3D"m_-6595837517255212237styled-b=
y-prettify"> </span><span style=3D"color:#800" class=3D"m_-6595837517255212=
237styled-by-prettify">// Possible Syntactic Sugar for unary Constraints wi=
th same semantic as above<br></span><span style=3D"color:#000" class=3D"m_-=
6595837517255212237styled-by-prettify"><br>foo</span><span style=3D"color:#=
660" class=3D"m_-6595837517255212237styled-by-prettify">(</span><span style=
=3D"color:#000" class=3D"m_-6595837517255212237styled-by-prettify"> i </spa=
n><span style=3D"color:#660" class=3D"m_-6595837517255212237styled-by-prett=
ify">);</span><span style=3D"color:#000" class=3D"m_-6595837517255212237sty=
led-by-prettify"> </span><span style=3D"color:#800" class=3D"m_-65958375172=
55212237styled-by-prettify">// No warning anymore, since we already claimed=
i to be Even, that is decltype(i) is 'Even int'</span><span style=
=3D"color:#000" class=3D"m_-6595837517255212237styled-by-prettify"><br><br>=
i </span><span style=3D"color:#660" class=3D"m_-6595837517255212237styled-b=
y-prettify">=3D</span><span style=3D"color:#000" class=3D"m_-65958375172552=
12237styled-by-prettify"> </span><span style=3D"color:#066" class=3D"m_-659=
5837517255212237styled-by-prettify">5</span><span style=3D"color:#660" clas=
s=3D"m_-6595837517255212237styled-by-prettify">;</span><span style=3D"color=
:#000" class=3D"m_-6595837517255212237styled-by-prettify"><br>foo</span><sp=
an style=3D"color:#660" class=3D"m_-6595837517255212237styled-by-prettify">=
(</span><span style=3D"color:#000" class=3D"m_-6595837517255212237styled-by=
-prettify"> i </span><span style=3D"color:#660" class=3D"m_-659583751725521=
2237styled-by-prettify">);</span><span style=3D"color:#000" class=3D"m_-659=
5837517255212237styled-by-prettify"> </span><span style=3D"color:#800" clas=
s=3D"m_-6595837517255212237styled-by-prettify">// Again a warning, since we=
changed i</span><span style=3D"color:#000" class=3D"m_-6595837517255212237=
styled-by-prettify"><br><br></span><span style=3D"color:#000" class=3D"m_-6=
595837517255212237styled-by-prettify"><span style=3D"color:rgb(136,0,0)">It=
erator=C2=A0</span>iter1 </span><span style=3D"color:#660" class=3D"m_-6595=
837517255212237styled-by-prettify">=3D</span><span style=3D"color:#000" cla=
ss=3D"m_-6595837517255212237styled-by-prettify"> </span><span style=3D"colo=
r:#800" class=3D"m_-6595837517255212237styled-by-prettify">/*...*/</span><s=
pan style=3D"color:#660" class=3D"m_-6595837517255212237styled-by-prettify"=
>;</span><span style=3D"color:#000" class=3D"m_-6595837517255212237styled-b=
y-prettify"><br></span><span style=3D"color:#000" class=3D"m_-6595837517255=
212237styled-by-prettify"><span style=3D"color:rgb(136,0,0)">Iterator=C2=A0=
</span>iter2 </span><span style=3D"color:#660" class=3D"m_-6595837517255212=
237styled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_-659=
5837517255212237styled-by-prettify"> </span><span style=3D"color:#800" clas=
s=3D"m_-6595837517255212237styled-by-prettify">/*...*/</span><span style=3D=
"color:#660" class=3D"m_-6595837517255212237styled-by-prettify">;</span><sp=
an style=3D"color:#000" class=3D"m_-6595837517255212237styled-by-prettify">=
<br><br>claim </span><span style=3D"color:#606" class=3D"m_-659583751725521=
2237styled-by-prettify">Reachable</span><span style=3D"color:#660" class=3D=
"m_-6595837517255212237styled-by-prettify">(</span><span style=3D"color:#00=
0" class=3D"m_-6595837517255212237styled-by-prettify">iter1</span><span sty=
le=3D"color:#660" class=3D"m_-6595837517255212237styled-by-prettify">,</spa=
n><span style=3D"color:#000" class=3D"m_-6595837517255212237styled-by-prett=
ify">iter2</span><span style=3D"color:#660" class=3D"m_-6595837517255212237=
styled-by-prettify">);</span><span style=3D"color:#000" class=3D"m_-6595837=
517255212237styled-by-prettify"> </span><span style=3D"color:#800" class=3D=
"m_-6595837517255212237styled-by-prettify">// Turns out to be Synonym to &#=
39;REQUIRES( )' resp. '[[expect: ...]]' except that it 'sav=
es' the claimed constraint Reachable(iter1,iter2) for both variables.<b=
r><br>// decltype(iter1) is now something like 'Reachable(X,iter2) Iter=
ator' // finding a good textual representation for this type name is ir=
relevant for now<br>// decltype(iter2) is now something like 'Reachable=
(iter1,X) Iterator'<br></span><span style=3D"color:#000" class=3D"m_-65=
95837517255212237styled-by-prettify"><br></span><span style=3D"color:#008" =
class=3D"m_-6595837517255212237styled-by-prettify">bool</span><span style=
=3D"color:#000" class=3D"m_-6595837517255212237styled-by-prettify"> is_reac=
hable </span><span style=3D"color:#660" class=3D"m_-6595837517255212237styl=
ed-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_-6595837517=
255212237styled-by-prettify"> </span><span style=3D"color:#606" class=3D"m_=
-6595837517255212237styled-by-prettify">Reachable</span><span style=3D"colo=
r:#660" class=3D"m_-6595837517255212237styled-by-prettify">(</span><span st=
yle=3D"color:#000" class=3D"m_-6595837517255212237styled-by-prettify">iter1=
</span><span style=3D"color:#660" class=3D"m_-6595837517255212237styled-by-=
prettify">,</span><span style=3D"color:#000" class=3D"m_-659583751725521223=
7styled-by-prettify">iter2</span><span style=3D"color:#660" class=3D"m_-659=
5837517255212237styled-by-prettify">);</span><span style=3D"color:#000" cla=
ss=3D"m_-6595837517255212237styled-by-prettify"> </span><span style=3D"colo=
r:#800" class=3D"m_-6595837517255212237styled-by-prettify">// Only evaluate=
s the constraint</span><br></div></code></div></code></div><div><br></div>T=
o claim an unnamed constraint, you would write for example</div><div><div c=
lass=3D"m_-6595837517255212237prettyprint" style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x;word-wrap:break-word"><code class=3D"m_-6595837517255212237prettyprint"><=
div class=3D"m_-6595837517255212237subprettyprint"><font color=3D"#660066">=
claim i%2=3D=3D0;</font></div></code></div><br>In contrast to <i>assert, RE=
QUIRES and [[expects: ]]</i>, claim (or whatever name we may choose) would =
probably be an operator and it changes the declared type of the involved=C2=
=A0variable for all future uses of it (below the call to claim).</div><div>=
<div>Allowing the constraints to be part of the type system and thus allowi=
ng them to be part of a function declaration resembles the idea that the ca=
ller is responsible for passing in the right values (a contract), instead o=
f the idea of values being checked within the function.</div></div><div><br=
></div><div>Sure, many aspects of this approach are not determined yet and =
may even be a rather big discussion point... BUT:<br></div><div>By using th=
is approach,</div><div><ol><li>you provide the tools for formal verificatio=
n/static analysis (to the extent that programmers annotate their code), you=
</li><li>have everything compile as usually (no errors, just warnings), you=
</li><li>conditionally support runtime-checks as described in <a href=3D"ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf" target=
=3D"_blank">P0380R1</a>, you</li><li>can reuse the defined constraints for =
future pattern matching proposals and you</li><li>bridge the gap between va=
lue concepts and contracts (as 'constexpr' constraints are usable f=
or template parameters as well).</li></ol>I hope I have not forgotten somet=
hing essential, please have mercy with me in this case :D<br></div><div><br=
></div><div>Cheers and have a nice Evening,</div><div>Jakob</div></div></di=
v>
<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/b87e09a1-fd8f-48f2-b075-25acc68b1e86%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b87e09a1-fd8f-=
48f2-b075-25acc68b1e86%40isocpp.org</a>.<br>
</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/CAPCFJdTiRg0f%3DGLiQAOPkZXf9dtTKNNVAB=
RTKAy8p4tyv-Tx%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTiRg0f=
%3DGLiQAOPkZXf9dtTKNNVABRTKAy8p4tyv-Tx%2BA%40mail.gmail.com</a>.<br />
--94eb2c145bd6bc2ca60552eebc02--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Tue, 27 Jun 2017 06:49:26 -0700 (PDT)
Raw View
------=_Part_2232_783904893.1498571366129
Content-Type: multipart/alternative;
boundary="----=_Part_2233_2072182485.1498571366129"
------=_Part_2233_2072182485.1498571366129
Content-Type: text/plain; charset="UTF-8"
>
> This might be a good way to call them. But I also don't think you
> necessarily need an "interface interface", in presence of concept maps.
> Especially since, with if constexpr and proper requires that's usable
> wherever, you could create default implementations that dispatch to various
> different kinds of function calls. (In the simplest case, it could just
> dispatch to the `foo.bar()` call, and that'll work.)
>
The redundancy of concepts to contracts, that I'm talking about, is only
present with Concepts Lite (constraining the set of types to those that
behave/can be used in a certain desired way). They are redundant in that
way, that contracts (if contracts want to represent something more than
just asserts, which they currently do) provide the same mechanism for
constraining *values *to those that fulfill the given contract.
Only this redundancy can lead to a unified approach of contracts and
concepts.
Your approach does something very differnt and has a very different
purpose, that is providing a uniform interface for different types, that
don't have a uniform interface but only a uniform *usage *(e.g. operator+
defined as member function or static function). In the same way, enforcing
operator+ to be defined as a member function within a concept is analogue
to stating that an even number must have an integer datatype (contract).
This problem would be completely solved, if we had uniform call syntax for
all functions. Then every pointer to member function would be implicitely
convertible to a pointer to a freestanding function taking the object as
first parameter.
In this case we could completely adapt your solution, yes, since it is
equivalent to stating the usage of a type, since
*the usage would be homogeneous across all declaration types* (memberfn,
freestanding fn, etc.)* and the declaration type would be indifferent
across different usages *(invokation through member operator or without)*.*
However: I disagree on your point, that if constexpr circumvents this
problem. Double type erasure is worse than single type erasure. That means,
why do you only erase the implementation, when you can erase the signature
as well? Your simplest case is probably the most common but to the extent I
understand your comment, this represents double type erasure:
adapting a given type (1st erasure) to be passed to a concept map (2nd
erasure).
This basically comes down to the point, that we need uniform call syntax in
order to come up with a solution that provides for both applications
(Concepts as "contracts based on types") and automatic type erasure
(virtual concepts).
I really have a bad feeling now with standardizing both contracts and
concepts as they are now. They are neither the prettiest nor most elegant
solution but instead introduce a rather big redundancy. Given that they
represent huge changes to the standard, I am against standardizing them at
this point.
What do you think?
--
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/1cdeeb4c-fcce-4295-9dc0-48b7023a7391%40isocpp.org.
------=_Part_2233_2072182485.1498571366129
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
This might be a good way to call them. But I also don't think you neces=
sarily need an "interface interface", in presence of concept maps=
.. Especially since, with if constexpr and proper requires that's usable=
wherever, you could create default implementations that dispatch to variou=
s different kinds of function calls. (In the simplest case, it could just d=
ispatch to the `foo.bar()` call, and that'll work.)<br></blockquote><di=
v><br></div><div>The redundancy of concepts to contracts, that I'm talk=
ing about, is only present with Concepts Lite (constraining the set of type=
s to those that behave/can be used in a certain desired way). They are redu=
ndant in that way, that contracts (if contracts want to represent something=
more than just asserts, which they currently do) provide the same mechanis=
m for constraining <b>values </b>to those that fulfill the given contract.<=
br>Only this redundancy can lead to a unified approach of contracts and con=
cepts.</div><div><br></div><div>Your approach does something very differnt =
and has a very different purpose, that is providing a uniform interface for=
different types, that don't have a uniform interface but only a unifor=
m <b>usage </b>(e.g. operator+ defined as member function or static functio=
n). In the same way, enforcing operator+ to be defined as a member function=
within a concept is analogue to stating that an even number must have an i=
nteger datatype (contract).</div><div>This problem would be completely solv=
ed, if we had uniform call syntax for all functions. Then every pointer to =
member function would be implicitely convertible to a pointer to a freestan=
ding function taking the object as first parameter.</div><div>In this case =
we could completely adapt your solution, yes, since it is equivalent to sta=
ting the usage of a type, since</div><div><i><b>the usage would be homogene=
ous across all declaration types</b></i> (memberfn, freestanding fn, etc.)<=
i style=3D"font-weight: bold;"> and the declaration type would be indiffere=
nt across different usages </i>(invokation through member operator or witho=
ut)<i style=3D"font-weight: bold;">.</i></div><div><br></div><div><br></div=
><div>However: I disagree on your point, that if constexpr circumvents this=
problem. Double type erasure is worse than single type erasure. That means=
, why do you only erase the implementation, when you can erase the signatur=
e as well? Your simplest case is probably the most common but to the extent=
I understand your comment, this represents double type erasure:<br>adaptin=
g a given type (1st erasure) to be passed to a concept map (2nd erasure).</=
div><div><br></div><div><br></div><div>This basically comes down to the poi=
nt, that we need uniform call syntax in order to come up with a solution th=
at provides for both applications (Concepts as "contracts based on typ=
es") and automatic type erasure (virtual concepts).</div><div>I really=
have a bad feeling now with standardizing both contracts and concepts as t=
hey are now. They are neither the prettiest nor most elegant solution but i=
nstead introduce a rather big redundancy. Given that they represent huge ch=
anges to the standard, I am against standardizing them at this point.</div>=
<div><br></div><div>What do you think?</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/1cdeeb4c-fcce-4295-9dc0-48b7023a7391%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1cdeeb4c-fcce-4295-9dc0-48b7023a7391=
%40isocpp.org</a>.<br />
------=_Part_2233_2072182485.1498571366129--
------=_Part_2232_783904893.1498571366129--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Tue, 27 Jun 2017 14:01:31 +0000
Raw View
--94eb2c09340ecd7a780552f18180
Content-Type: text/plain; charset="UTF-8"
On Tue, Jun 27, 2017 at 3:49 PM Jakob Riedle <jakob.riedle@gmail.com> wrote:
> This might be a good way to call them. But I also don't think you
>> necessarily need an "interface interface", in presence of concept maps.
>> Especially since, with if constexpr and proper requires that's usable
>> wherever, you could create default implementations that dispatch to various
>> different kinds of function calls. (In the simplest case, it could just
>> dispatch to the `foo.bar()` call, and that'll work.)
>>
>
> The redundancy of concepts to contracts, that I'm talking about, is only
> present with Concepts Lite (constraining the set of types to those that
> behave/can be used in a certain desired way). They are redundant in that
> way, that contracts (if contracts want to represent something more than
> just asserts, which they currently do) provide the same mechanism for
> constraining *values *to those that fulfill the given contract.
> Only this redundancy can lead to a unified approach of contracts and
> concepts.
>
> Your approach does something very differnt and has a very different
> purpose, that is providing a uniform interface for different types, that
> don't have a uniform interface but only a uniform *usage *(e.g. operator+
> defined as member function or static function). In the same way, enforcing
> operator+ to be defined as a member function within a concept is analogue
> to stating that an even number must have an integer datatype (contract).
> This problem would be completely solved, if we had uniform call syntax for
> all functions. Then every pointer to member function would be implicitely
> convertible to a pointer to a freestanding function taking the object as
> first parameter.
> In this case we could completely adapt your solution, yes, since it is
> equivalent to stating the usage of a type, since
> *the usage would be homogeneous across all declaration types* (memberfn,
> freestanding fn, etc.)* and the declaration type would be indifferent
> across different usages *(invokation through member operator or without)
> *.*
>
>
> However: I disagree on your point, that if constexpr circumvents this
> problem. Double type erasure is worse than single type erasure. That means,
> why do you only erase the implementation, when you can erase the signature
> as well? Your simplest case is probably the most common but to the extent I
> understand your comment, this represents double type erasure:
> adapting a given type (1st erasure) to be passed to a concept map (2nd
> erasure).
>
>
A concept map is what is doing the adaptation.
It is a completely compile time thing; a different way to resolve a call
(to a thing that could be customized, hence also fixing all our problems
that we have with customization points currently). Type erasure is the
runtime component, and it just uses the potentially customized calls inside
the interface.
I'll once again refer to my talk
<https://www.youtube.com/watch?v=LC7BuYeDezQ>, especially the part after
the interludes, that describes those ideas somewhat better than I can in a
concise manner in an email.
Maybe I should write a paper on this, though it'd probably heavily look
like C++0x concepts, and would probably scare half the committee away by
being heavy on the use of the phrase "concept maps".
>
> This basically comes down to the point, that we need uniform call syntax
> in order to come up with a solution that provides for both applications
> (Concepts as "contracts based on types") and automatic type erasure
> (virtual concepts).
> I really have a bad feeling now with standardizing both contracts and
> concepts as they are now. They are neither the prettiest nor most elegant
> solution but instead introduce a rather big redundancy. Given that they
> represent huge changes to the standard, I am against standardizing them at
> this point.
>
>
No, we don't need UFCS. We need concepts as interfaces, not as contracts on
types, for all the reasons I stated above.
> What do you think?
>
I think that UFCS would *hide* the actual problem from us, making it seem *as
if* we solved the adaptation problem, while we would not have actually
looked at the problem of customization points that we have all over the
place. (std::swap is an ADL mess, operator overloading as free functions is
a total mess - see all the issues where `stream << foo` picks up the wrong
type by accident, or see how many of those overloads need to be considered
before the call is resolved; and a recent shiny one, customization points
of structured bindings, which I do mention in the talk linked above, are a
terrible, terrible thing.)
We *could *be solving three problems - template constraints, type erasure
*and* customization points - by just looking at how other languages
implemented typeclasses / traits / whatever, but instead we're spending
waaay too much time on a feature that's just SFINAE on steroids (there's a
conceptless implementation of the Ranges TS, for crying out loud, and that
library *supposedly* needs concepts...).
> --
> 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/1cdeeb4c-fcce-4295-9dc0-48b7023a7391%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1cdeeb4c-fcce-4295-9dc0-48b7023a7391%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPCFJdQqYHYXdzshGmTy4eGBGNnkeeEn9ueMBFXQ-%2BNh-E%2BfeQ%40mail.gmail.com.
--94eb2c09340ecd7a780552f18180
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 27=
, 2017 at 3:49 PM Jakob Riedle <<a href=3D"mailto:jakob.riedle@gmail.com=
">jakob.riedle@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thi=
s might be a good way to call them. But I also don't think you necessar=
ily need an "interface interface", in presence of concept maps. E=
specially since, with if constexpr and proper requires that's usable wh=
erever, you could create default implementations that dispatch to various d=
ifferent kinds of function calls. (In the simplest case, it could just disp=
atch to the `foo.bar()` call, and that'll work.)<br></blockquote><div><=
br></div></div><div dir=3D"ltr"><div>The redundancy of concepts to contract=
s, that I'm talking about, is only present with Concepts Lite (constrai=
ning the set of types to those that behave/can be used in a certain desired=
way). They are redundant in that way, that contracts (if contracts want to=
represent something more than just asserts, which they currently do) provi=
de the same mechanism for constraining <b>values </b>to those that fulfill =
the given contract.<br>Only this redundancy can lead to a unified approach =
of contracts and concepts.</div><div><br></div><div>Your approach does some=
thing very differnt and has a very different purpose, that is providing a u=
niform interface for different types, that don't have a uniform interfa=
ce but only a uniform <b>usage </b>(e.g. operator+ defined as member functi=
on or static function). In the same way, enforcing operator+ to be defined =
as a member function within a concept is analogue to stating that an even n=
umber must have an integer datatype (contract).</div><div>This problem woul=
d be completely solved, if we had uniform call syntax for all functions. Th=
en every pointer to member function would be implicitely convertible to a p=
ointer to a freestanding function taking the object as first parameter.</di=
v><div>In this case we could completely adapt your solution, yes, since it =
is equivalent to stating the usage of a type, since</div><div><i><b>the usa=
ge would be homogeneous across all declaration types</b></i> (memberfn, fre=
estanding fn, etc.)<i style=3D"font-weight:bold"> and the declaration type =
would be indifferent across different usages </i>(invokation through member=
operator or without)<i style=3D"font-weight:bold">.</i></div><div><br></di=
v><div><br></div><div>However: I disagree on your point, that if constexpr =
circumvents this problem. Double type erasure is worse than single type era=
sure. That means, why do you only erase the implementation, when you can er=
ase the signature as well? Your simplest case is probably the most common b=
ut to the extent I understand your comment, this represents double type era=
sure:<br>adapting a given type (1st erasure) to be passed to a concept map =
(2nd erasure).</div><div><br></div></div></blockquote><div><br></div><div>A=
concept map is what is doing the adaptation.</div><div><br></div><div>It i=
s a completely compile time thing; a different way to resolve a call (to a =
thing that could be customized, hence also fixing all our problems that we =
have with customization points currently). Type erasure is the runtime comp=
onent, and it just uses the potentially customized calls inside the interfa=
ce.</div><div><br></div><div>I'll once again refer to=C2=A0<a href=3D"h=
ttps://www.youtube.com/watch?v=3DLC7BuYeDezQ">my talk</a>, especially the p=
art after the interludes, that describes those ideas somewhat better than I=
can in a concise manner in an email.</div><div><br></div><div>Maybe I shou=
ld write a paper on this, though it'd probably heavily look like C++0x =
concepts, and would probably scare half the committee away by being heavy o=
n the use of the phrase "concept maps".</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div><br></div><div=
>This basically comes down to the point, that we need uniform call syntax i=
n order to come up with a solution that provides for both applications (Con=
cepts as "contracts based on types") and automatic type erasure (=
virtual concepts).</div><div>I really have a bad feeling now with standardi=
zing both contracts and concepts as they are now. They are neither the pret=
tiest nor most elegant solution but instead introduce a rather big redundan=
cy. Given that they represent huge changes to the standard, I am against st=
andardizing them at this point.</div><div><br></div></div></blockquote><div=
><br></div><div>No, we don't need UFCS. We need concepts as interfaces,=
not as contracts on types, for all the reasons I stated above.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div=
>What do you think?</div></div></blockquote><div><br></div><div>I think tha=
t UFCS would <i>hide</i>=C2=A0the actual problem from us, making it seem <i=
>as if</i>=C2=A0we solved the adaptation problem, while we would not have a=
ctually looked at the problem of customization points that we have all over=
the place. (std::swap is an ADL mess, operator overloading as free functio=
ns is a total mess - see all the issues where `stream << foo` picks u=
p the wrong type by accident, or see how many of those overloads need to be=
considered before the call is resolved; and a recent shiny one, customizat=
ion points of structured bindings, which I do mention in the talk linked ab=
ove, are a terrible, terrible thing.)</div><div><br></div><div>We <i>could =
</i>be=C2=A0solving three problems - template constraints, type erasure <i>=
and</i>=C2=A0customization points - by just looking at how other languages =
implemented typeclasses / traits / whatever, but instead we're spending=
waaay too much time on a feature that's just SFINAE on steroids (there=
's a conceptless implementation of the Ranges TS, for crying out loud, =
and that library <i>supposedly</i>=C2=A0needs concepts...).</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/1cdeeb4c-fcce-4295-9dc0-48b7023a7391%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1cdeeb4c-fcce-=
4295-9dc0-48b7023a7391%40isocpp.org</a>.<br>
</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/CAPCFJdQqYHYXdzshGmTy4eGBGNnkeeEn9ueM=
BFXQ-%2BNh-E%2BfeQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQqYHYX=
dzshGmTy4eGBGNnkeeEn9ueMBFXQ-%2BNh-E%2BfeQ%40mail.gmail.com</a>.<br />
--94eb2c09340ecd7a780552f18180--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 27 Jun 2017 09:55:55 -0700 (PDT)
Raw View
------=_Part_2397_134708060.1498582555602
Content-Type: multipart/alternative;
boundary="----=_Part_2398_1399531523.1498582555602"
------=_Part_2398_1399531523.1498582555602
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, June 27, 2017 at 10:01:45 AM UTC-4, Micha=C5=82 Dominiak wrote:
>
> We *could *be solving three problems - template constraints, type erasure=
=20
> *and* customization points - by just looking at how other languages=20
> implemented typeclasses / traits / whatever, but instead we're spending=
=20
> waaay too much time on a feature that's just SFINAE on steroids (there's =
a=20
> conceptless implementation of the Ranges TS, for crying out loud, and tha=
t=20
> library *supposedly* needs concepts...).
>
And in so doing, take another 5 years to get it done while simultaneously=
=20
doing nothing about having a usable form of compile-time checking for=20
static polymorphism in the language. How many C++ programmers can actually=
=20
write that concept-less version of Ranges TS? And how many could write it=
=20
with Concepts TS? I'd bet that the number in the latter is several orders=
=20
of magnitude greater than the former.
At some point, you've got to get *something* done. Concepts TS isn't the=20
best it could be, and I really want to see some changes to the proposal=20
(and I really hope the committee rejects Stroustrup's "everything is=20
awesome" approach to integrating the TS with the standard). But saying that=
=20
we ought to ditch it and start from scratch, just because you think you=20
could do better is not productive.
If you had a better idea, you could have been working on it in parallel=20
with Concepts TS. You could have gotten together with people and wrote a=20
proposal with standards wording, forked Clang and implemented it, and=20
proven your point. After all, Concepts Lite was able to do those things.=20
Right now, you are nothing but words, while Concepts TS is a real, live,=20
and *useful* feature of C++.
--=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/a92a08bf-d210-4b6d-b728-3d6d8c5fac26%40isocpp.or=
g.
------=_Part_2398_1399531523.1498582555602
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, June 27, 2017 at 10:01:45 AM UTC-4, Micha=C5=
=82 Dominiak wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div class=3D"gmail_quote"><div></div><div>We <i>could </i>be=C2=A0so=
lving three problems - template constraints, type erasure <i>and</i>=C2=A0c=
ustomization points - by just looking at how other languages implemented ty=
peclasses / traits / whatever, but instead we're spending waaay too muc=
h time on a feature that's just SFINAE on steroids (there's a conce=
ptless implementation of the Ranges TS, for crying out loud, and that libra=
ry <i>supposedly</i>=C2=A0needs concepts...).</div></div></div></blockquote=
><div><br>And in so doing, take another 5 years to get it done while simult=
aneously doing nothing about having a usable form of compile-time checking =
for static polymorphism in the language. How many C++ programmers can actua=
lly write that concept-less version of Ranges TS? And how many could write =
it with Concepts TS? I'd bet that the number in the latter is several o=
rders of magnitude greater than the former.<br><br>At some point, you'v=
e got to get <i>something</i> done. Concepts TS isn't the best it could=
be, and I really want to see some changes to the proposal (and I really ho=
pe the committee rejects Stroustrup's "everything is awesome"=
approach to integrating the TS with the standard). But saying that we ough=
t to ditch it and start from scratch, just because you think you could do b=
etter is not productive.<br><br>If you had a better idea, you could have be=
en working on it in parallel with Concepts TS. You could have gotten togeth=
er with people and wrote a proposal with standards wording, forked Clang an=
d implemented it, and proven your point. After all, Concepts Lite was able =
to do those things. Right now, you are nothing but words, while Concepts TS=
is a real, live, and <i>useful</i> feature of C++.<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/a92a08bf-d210-4b6d-b728-3d6d8c5fac26%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a92a08bf-d210-4b6d-b728-3d6d8c5fac26=
%40isocpp.org</a>.<br />
------=_Part_2398_1399531523.1498582555602--
------=_Part_2397_134708060.1498582555602--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Tue, 27 Jun 2017 18:53:04 +0000
Raw View
--089e08233e14853af50552f594df
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 27, 2017, 6:55 PM Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, June 27, 2017 at 10:01:45 AM UTC-4, Micha=C5=82 Dominiak wrot=
e:
>>
>> We *could *be solving three problems - template constraints, type
>> erasure *and* customization points - by just looking at how other
>> languages implemented typeclasses / traits / whatever, but instead we're
>> spending waaay too much time on a feature that's just SFINAE on steroids
>> (there's a conceptless implementation of the Ranges TS, for crying out
>> loud, and that library *supposedly* needs concepts...).
>>
>
> And in so doing, take another 5 years to get it done while simultaneously
> doing nothing about having a usable form of compile-time checking for
> static polymorphism in the language. How many C++ programmers can actuall=
y
> write that concept-less version of Ranges TS? And how many could write it
> with Concepts TS? I'd bet that the number in the latter is several orders
> of magnitude greater than the former.
>
> At some point, you've got to get *something* done. Concepts TS isn't the
> best it could be, and I really want to see some changes to the proposal
> (and I really hope the committee rejects Stroustrup's "everything is
> awesome" approach to integrating the TS with the standard). But saying th=
at
> we ought to ditch it and start from scratch, just because you think you
> could do better is not productive.
>
> If you had a better idea, you could have been working on it in parallel
> with Concepts TS. You could have gotten together with people and wrote a
> proposal with standards wording, forked Clang and implemented it, and
> proven your point. After all, Concepts Lite was able to do those things.
> Right now, you are nothing but words, while Concepts TS is a real, live,
> and *useful* feature of C++.
>
Yes, splendid. Let's get a terrible feature in because we prefer that over
nothing. This has never caused any problems for anyone, right?
About the only thing I like from the TS is the requires expressions in any
context and the requires clauses on declarations. Pulling more stops us
from ever having a truly good feature dealing with this.
We need to either iterate on the TS concepts, or iterate on the C++0x
concepts. But I, for one, prefer no feature over bad feature, and I much
prefer writing sfinae over doing TS concepts (and my first non trivial
attempt at them has shown me that I'd still need crazy code to express the
constraints that I have). If you want your users to suffer less - use a
macro like Range v3's REQUIRES.
> --
> 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/a92a08bf-d21=
0-4b6d-b728-3d6d8c5fac26%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a92a08bf-d2=
10-4b6d-b728-3d6d8c5fac26%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAPCFJdTpZXe4tvHHi_cgP6-Bj1n3Goe%2B%2BACyraK_%3D=
gBEkE_TPA%40mail.gmail.com.
--089e08233e14853af50552f594df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 27, 2017, 6:55 PM N=
icol Bolas <<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</=
a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On T=
uesday, June 27, 2017 at 10:01:45 AM UTC-4, Micha=C5=82 Dominiak wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_qu=
ote"><div></div><div>We <i>could </i>be=C2=A0solving three problems - templ=
ate constraints, type erasure <i>and</i>=C2=A0customization points - by jus=
t looking at how other languages implemented typeclasses / traits / whateve=
r, but instead we're spending waaay too much time on a feature that'=
;s just SFINAE on steroids (there's a conceptless implementation of the=
Ranges TS, for crying out loud, and that library <i>supposedly</i>=C2=A0ne=
eds concepts...).</div></div></div></blockquote></div><div dir=3D"ltr"><div=
><br>And in so doing, take another 5 years to get it done while simultaneou=
sly doing nothing about having a usable form of compile-time checking for s=
tatic polymorphism in the language. How many C++ programmers can actually w=
rite that concept-less version of Ranges TS? And how many could write it wi=
th Concepts TS? I'd bet that the number in the latter is several orders=
of magnitude greater than the former.<br><br>At some point, you've got=
to get <i>something</i> done. Concepts TS isn't the best it could be, =
and I really want to see some changes to the proposal (and I really hope th=
e committee rejects Stroustrup's "everything is awesome" appr=
oach to integrating the TS with the standard). But saying that we ought to =
ditch it and start from scratch, just because you think you could do better=
is not productive.<br><br>If you had a better idea, you could have been wo=
rking on it in parallel with Concepts TS. You could have gotten together wi=
th people and wrote a proposal with standards wording, forked Clang and imp=
lemented it, and proven your point. After all, Concepts Lite was able to do=
those things. Right now, you are nothing but words, while Concepts TS is a=
real, live, and <i>useful</i> feature of C++.<br></div></div></blockquote>=
</div><div><br></div><div>Yes, splendid. Let's get a terrible feature i=
n because we prefer that over nothing. This has never caused any problems f=
or anyone, right?</div><div><br></div><div>About the only thing I like from=
the TS is the requires expressions in any context and the requires clauses=
on declarations. Pulling more stops us from ever having a truly good featu=
re dealing with this.</div><div><br></div><div>We need to either iterate on=
the TS concepts, or iterate on the C++0x concepts. But I, for one, prefer =
no feature over bad feature, and I much prefer writing sfinae over doing TS=
concepts (and my first non trivial attempt at them has shown me that I'=
;d still need crazy code to express the constraints that I have). If you wa=
nt your users to suffer less - use a macro like Range v3's REQUIRES.</d=
iv><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/a92a08bf-d210-4b6d-b728-3d6d8c5fac26%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a92a08bf-d210-=
4b6d-b728-3d6d8c5fac26%40isocpp.org</a>.<br>
</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/CAPCFJdTpZXe4tvHHi_cgP6-Bj1n3Goe%2B%2=
BACyraK_%3DgBEkE_TPA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTpZX=
e4tvHHi_cgP6-Bj1n3Goe%2B%2BACyraK_%3DgBEkE_TPA%40mail.gmail.com</a>.<br />
--089e08233e14853af50552f594df--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Wed, 28 Jun 2017 03:41:00 -0700 (PDT)
Raw View
------=_Part_2722_1108976089.1498646461001
Content-Type: multipart/alternative;
boundary="----=_Part_2723_1625080976.1498646461003"
------=_Part_2723_1625080976.1498646461003
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Am Dienstag, 27. Juni 2017 16:01:45 UTC+2 schrieb Micha=C5=82 Dominiak:
>
> A concept map is what is doing the adaptation.
>
> It is a completely compile time thing; a different way to resolve a call=
=20
> (to a thing that could be customized, hence also fixing all our problems=
=20
> that we have with customization points currently). Type erasure is the=20
> runtime component, and it just uses the potentially customized calls insi=
de=20
> the interface.
>
> I'll once again refer to my talk=20
> <https://www.youtube.com/watch?v=3DLC7BuYeDezQ>, especially the part afte=
r=20
> the interludes, that describes those ideas somewhat better than I can in =
a=20
> concise manner in an email.
>
> Maybe I should write a paper on this, though it'd probably heavily look=
=20
> like C++0x concepts, and would probably scare half the committee away by=
=20
> being heavy on the use of the phrase "concept maps".
>
Oh sure, gotcha! I understand now, what a concept map is, which I=20
apparently did not previously.
=20
>
>> This basically comes down to the point, that we need uniform call syntax=
=20
>> in order to come up with a solution that provides for both applications=
=20
>> (Concepts as "contracts based on types") and automatic type erasure=20
>> (virtual concepts).
>> I really have a bad feeling now with standardizing both contracts and=20
>> concepts as they are now. They are neither the prettiest nor most elegan=
t=20
>> solution but instead introduce a rather big redundancy. Given that they=
=20
>> represent huge changes to the standard, I am against standardizing them =
at=20
>> this point.
>>
>>
> No, we don't need UFCS. We need concepts as interfaces, not as contracts=
=20
> on types, for all the reasons I stated above.
>
But in this case, you exclude everyone from using Concepts, who wants to=20
use concepts as contracts on types!?
The following example shall elaborate on that, If you should see not, why=
=20
this is the case:
template<typename T>
concept bool LessThanComparable =3D requires(T a, T b){
bool operator<( T a , T b );
};
template<typename T>
T min1( T a , T b ){
return a < b ? a : b;
}
template<typename T>
requires LessThanComparable <T>()
T min2( T a , T b ){
return a < b ? a : b; // We actually only care about whether the=20
expression 'a < b' is well formed
}
struct Foo{ int bar; };
bool operator<(Foo a, Foo b){ return a.bar < b.bar; }
min1( Foo{4} , Foo{5} ); // This works
min2( Foo{4} , Foo{5} ); // Error: No Foo::operator< defined to fulfill=20
concept LessThanComparable
// Unless you do this (I use the syntax that you used in your talk)
concept_map LessThanComparable<Foo>{
bool operator<(const Foo& lhs, const Foo& rhs) {
return lhs < rhs;
}
};
Either you
1. presume UFCS and the definition of LessThanComparable finds the=20
freestanding operator< (BTW as well as built-in operators for let's say=
=20
'int') or
2. you leave UFCS out, in which case you have to write=20
concept_maps/adaptors for every class/primitive type that implements=20
operators not as member functions (e.g. like Foo).
=20
So either you consider UFCS in some form or you end up with concepts not=20
being able to be used as constracts on types.
From your talk I understand your point on why it is neat to specify=20
Interfaces instead of usage :D, but if you do not presume some sort of UFCS=
=20
then concepts are once more only a partial solution.
Was that explained properly? I hope, you see my point.
I think that UFCS would *hide* the actual problem from us, making it seem *=
as=20
> if* we solved the adaptation problem, while we would not have actually=20
> looked at the problem of customization points that we have all over the=
=20
> place. (std::swap is an ADL mess, operator overloading as free functions =
is=20
> a total mess - see all the issues where `stream << foo` picks up the wron=
g=20
> type by accident, or see how many of those overloads need to be considere=
d=20
> before the call is resolved; and a recent shiny one, customization points=
=20
> of structured bindings, which I do mention in the talk linked above, are =
a=20
> terrible, terrible thing.)
>
To me, UFCS really does represent the *only solution* that allows us to=20
support both worlds with a uniform mechanism (concepts as contracts on=20
types as well as concepts as interface specifications).
=20
> We *could *be solving three problems - template constraints, type erasure=
=20
> *and* customization points - by just looking at how other languages=20
> implemented typeclasses / traits / whatever, but instead we're spending=
=20
> waaay too much time on a feature that's just SFINAE on steroids (there's =
a=20
> conceptless implementation of the Ranges TS, for crying out loud, and tha=
t=20
> library *supposedly* needs concepts...).
>
C++ has its own ways of doing things already, so in the majority of cases=
=20
we cannot just incorporate certain approaches of another language to C++.
How would *you *solve template constraints, type erasure and customizations=
=20
points at once? You need to elaborate a bit more here please.
Especially considering: A specification of a type class in Haskell=20
specifies its interface, which is identical to specifying its usage. This=
=20
is however not the case for C++ as discussed already. So that can't be a=20
solution for C++, unless you presume some sort of UFCS, as discussed above.
*Furthermore:*
What do you think of my approach to contracts in my third last post? Nobody=
=20
replied anything to it?!
Is that because you don't see the similarity of contracts and concepts and=
=20
the need for approaching them in a uniform fashion?
Cheers,
Jakob
--=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/673b6386-cc71-40b9-9237-925049821c8b%40isocpp.or=
g.
------=_Part_2723_1625080976.1498646461003
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Am Dienstag, 27. Juni 2017 16:01:45 UTC+2 schrieb =
Micha=C5=82 Dominiak:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">A concept map is what =
is doing the adaptation.<br></div><div><br></div><div>It is a completely co=
mpile time thing; a different way to resolve a call (to a thing that could =
be customized, hence also fixing all our problems that we have with customi=
zation points currently). Type erasure is the runtime component, and it jus=
t uses the potentially customized calls inside the interface.</div><div><br=
></div><div>I'll once again refer to=C2=A0<a href=3D"https://www.youtub=
e.com/watch?v=3DLC7BuYeDezQ" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'https://www.youtube.com/watch?v\x3dLC7BuYeDezQ';re=
turn true;" onclick=3D"this.href=3D'https://www.youtube.com/watch?v\x3d=
LC7BuYeDezQ';return true;">my talk</a>, especially the part after the i=
nterludes, that describes those ideas somewhat better than I can in a conci=
se manner in an email.</div><div><br></div><div>Maybe I should write a pape=
r on this, though it'd probably heavily look like C++0x concepts, and w=
ould probably scare half the committee away by being heavy on the use of th=
e phrase "concept maps".</div></div></div></blockquote><div><br><=
/div><div>Oh sure, gotcha! I understand now, what a concept map is, which I=
apparently did not previously.</div><div><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail=
_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></d=
iv><div><br></div><div>This basically comes down to the point, that we need=
uniform call syntax in order to come up with a solution that provides for =
both applications (Concepts as "contracts based on types") and au=
tomatic type erasure (virtual concepts).</div><div>I really have a bad feel=
ing now with standardizing both contracts and concepts as they are now. The=
y are neither the prettiest nor most elegant solution but instead introduce=
a rather big redundancy. Given that they represent huge changes to the sta=
ndard, I am against standardizing them at this point.</div><div><br></div><=
/div></blockquote><div><br></div><div>No, we don't need UFCS. We need c=
oncepts as interfaces, not as contracts on types, for all the reasons I sta=
ted above.</div></div></div></blockquote><div><br></div><div>But in this ca=
se, you exclude everyone from using Concepts, who wants to use concepts as =
contracts on types!?<br>The following example shall elaborate on that, If y=
ou should see not, why this is the case:</div><div><br></div><div><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">concept</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
LessThanComparable</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> requir=
es</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">T a</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> T b</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">){</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">operator</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify"><(</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> T a </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
T b </span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>T min1</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T a </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> T b </span><span style=3D"color: #660;" class=3D"styled-by-prettify">){<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
a </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> b </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">?</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> a </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">te=
mplate</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">></span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 requires=
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">LessThanC=
omparable</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">>()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>T min2</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> T a </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T b </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">){</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> b </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>?</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">// We actually only care about whether the express=
ion 'a < b' is well formed</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> bar</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify"><(</span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Foo</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">){</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">bar </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">bar</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br>min1=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">4</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">5</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">// This works</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>min2</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">Foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">5</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// Error: No Foo::operator< defined to fulfill concept =
LessThanComparable</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br><br><br></span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// Unless you do this (I use the syntax that you used in your tal=
k)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">concept_map</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #606;" class=3D"styled-by-prettify">LessThanComparable</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">>{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify"><(</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: rgb(102, 0, 102);">=
<span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> lhs</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: rgb(102, 0, 102);"><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> rhs</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> lhs</span><font color=3D"#666600"><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span></font><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">rhs</span><font color=3D"#666600"><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span></font><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></div>=
<br>Either you</div><div><ol><li>presume UFCS and the definition of LessTha=
nComparable finds the freestanding operator< (BTW as well as built-in op=
erators for let's say 'int') or</li><li>you leave UFCS out, in =
which case you have to write concept_maps/adaptors for every class/primitiv=
e type that implements operators not as member functions (e.g. like Foo).<b=
r></li></ol></div><div>So either you consider UFCS in some form or you end =
up with concepts not being able to be used as constracts on types.</div><di=
v>From your talk I understand your point on why it is neat to specify Inter=
faces instead of usage :D, but if you do not presume some sort of UFCS then=
concepts are once more only a partial solution.</div><div>Was that explain=
ed properly? I hope, you see my point.</div><div><br></div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"=
gmail_quote"><div>I think that UFCS would <i>hide</i>=C2=A0the actual probl=
em from us, making it seem <i>as if</i>=C2=A0we solved the adaptation probl=
em, while we would not have actually looked at the problem of customization=
points that we have all over the place. (std::swap is an ADL mess, operato=
r overloading as free functions is a total mess - see all the issues where =
`stream << foo` picks up the wrong type by accident, or see how many =
of those overloads need to be considered before the call is resolved; and a=
recent shiny one, customization points of structured bindings, which I do =
mention in the talk linked above, are a terrible, terrible thing.)</div></d=
iv></div></blockquote><div><br></div><div>To me, UFCS really does represent=
the <i>only solution</i> that allows us to support both worlds with a unif=
orm mechanism (concepts as contracts on types as well as concepts as interf=
ace specifications).<br></div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>We <i>cou=
ld </i>be=C2=A0solving three problems - template constraints, type erasure =
<i>and</i>=C2=A0customization points - by just looking at how other languag=
es implemented typeclasses / traits / whatever, but instead we're spend=
ing waaay too much time on a feature that's just SFINAE on steroids (th=
ere's a conceptless implementation of the Ranges TS, for crying out lou=
d, and that library <i>supposedly</i>=C2=A0needs concepts...).</div></div><=
/div></blockquote><div><br></div><div>C++ has its own ways of doing things =
already, so in the majority of cases we cannot just incorporate certain app=
roaches of another language to C++.</div><div>How would <i>you </i>solve te=
mplate constraints, type erasure and customizations points at once? You nee=
d to elaborate a bit more here please.</div><div>Especially considering: A =
specification of a type class in Haskell specifies its interface, which is =
identical to specifying its usage. This is however not the case for C++ as =
discussed already. So that can't be a solution for C++, unless you pres=
ume some sort of UFCS, as discussed above.</div><div><br></div><div><br></d=
iv><div><b>Furthermore:</b></div><div>What do you think of my approach to c=
ontracts in my third last post? Nobody replied anything to it?!</div><div>I=
s that because you don't see the similarity of contracts and concepts a=
nd the need for approaching them in a uniform fashion?</div><div><br></div>=
<div>Cheers,</div><div>Jakob</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/673b6386-cc71-40b9-9237-925049821c8b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/673b6386-cc71-40b9-9237-925049821c8b=
%40isocpp.org</a>.<br />
------=_Part_2723_1625080976.1498646461003--
------=_Part_2722_1108976089.1498646461001--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 28 Jun 2017 11:14:42 +0000
Raw View
--f403045c390e11d81d0553034b46
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 28, 2017 at 12:41 PM Jakob Riedle <jakob.riedle@gmail.com>
wrote:
>
>
> Am Dienstag, 27. Juni 2017 16:01:45 UTC+2 schrieb Micha=C5=82 Dominiak:
>>
>> A concept map is what is doing the adaptation.
>>
>> It is a completely compile time thing; a different way to resolve a call
>> (to a thing that could be customized, hence also fixing all our problems
>> that we have with customization points currently). Type erasure is the
>> runtime component, and it just uses the potentially customized calls ins=
ide
>> the interface.
>>
>> I'll once again refer to my talk
>> <https://www.youtube.com/watch?v=3DLC7BuYeDezQ>, especially the part aft=
er
>> the interludes, that describes those ideas somewhat better than I can in=
a
>> concise manner in an email.
>>
>> Maybe I should write a paper on this, though it'd probably heavily look
>> like C++0x concepts, and would probably scare half the committee away by
>> being heavy on the use of the phrase "concept maps".
>>
>
> Oh sure, gotcha! I understand now, what a concept map is, which I
> apparently did not previously.
>
>
>
>>
>>> This basically comes down to the point, that we need uniform call synta=
x
>>> in order to come up with a solution that provides for both applications
>>> (Concepts as "contracts based on types") and automatic type erasure
>>> (virtual concepts).
>>> I really have a bad feeling now with standardizing both contracts and
>>> concepts as they are now. They are neither the prettiest nor most elega=
nt
>>> solution but instead introduce a rather big redundancy. Given that they
>>> represent huge changes to the standard, I am against standardizing them=
at
>>> this point.
>>>
>>>
>> No, we don't need UFCS. We need concepts as interfaces, not as contracts
>> on types, for all the reasons I stated above.
>>
>
> But in this case, you exclude everyone from using Concepts, who wants to
> use concepts as contracts on types!?
> The following example shall elaborate on that, If you should see not, why
> this is the case:
>
> template<typename T>
> concept bool LessThanComparable =3D requires(T a, T b){
> bool operator<( T a , T b );
> };
>
> template<typename T>
> T min1( T a , T b ){
> return a < b ? a : b;
> }
>
> template<typename T>
> requires LessThanComparable <T>()
> T min2( T a , T b ){
> return a < b ? a : b; // We actually only care about whether the
> expression 'a < b' is well formed
> }
>
> struct Foo{ int bar; };
> bool operator<(Foo a, Foo b){ return a.bar < b.bar; }
>
>
> min1( Foo{4} , Foo{5} ); // This works
> min2( Foo{4} , Foo{5} ); // Error: No Foo::operator< defined to fulfill
> concept LessThanComparable
>
>
> // Unless you do this (I use the syntax that you used in your talk)
> concept_map LessThanComparable<Foo>{
> bool operator<(const Foo& lhs, const Foo& rhs) {
> return lhs < rhs;
> }
> };
>
> Either you
>
> 1. presume UFCS and the definition of LessThanComparable finds the
> freestanding operator< (BTW as well as built-in operators for let's sa=
y
> 'int') or
> 2. you leave UFCS out, in which case you have to write
> concept_maps/adaptors for every class/primitive type that implements
> operators not as member functions (e.g. like Foo).
>
> So either you consider UFCS in some form or you end up with concepts not
> being able to be used as constracts on types.
> From your talk I understand your point on why it is neat to specify
> Interfaces instead of usage :D, but if you do not presume some sort of UF=
CS
> then concepts are once more only a partial solution.
> Was that explained properly? I hope, you see my point.
>
>
My ultimate idealistic goal would be to have predefined concepts for
operators (that'd be used for lookup when an operator is invoked) and then
make people migrate to those (to use proper customization points for
customization, and to eventually completely stop using ADL for
customization points).
>
>
I think that UFCS would *hide* the actual problem from us, making it seem *=
as
>> if* we solved the adaptation problem, while we would not have actually
>> looked at the problem of customization points that we have all over the
>> place. (std::swap is an ADL mess, operator overloading as free functions=
is
>> a total mess - see all the issues where `stream << foo` picks up the wro=
ng
>> type by accident, or see how many of those overloads need to be consider=
ed
>> before the call is resolved; and a recent shiny one, customization point=
s
>> of structured bindings, which I do mention in the talk linked above, are=
a
>> terrible, terrible thing.)
>>
>
> To me, UFCS really does represent the *only solution* that allows us to
> support both worlds with a uniform mechanism (concepts as contracts on
> types as well as concepts as interface specifications).
>
>
>> We *could *be solving three problems - template constraints, type
>> erasure *and* customization points - by just looking at how other
>> languages implemented typeclasses / traits / whatever, but instead we're
>> spending waaay too much time on a feature that's just SFINAE on steroids
>> (there's a conceptless implementation of the Ranges TS, for crying out
>> loud, and that library *supposedly* needs concepts...).
>>
>
> C++ has its own ways of doing things already, so in the majority of cases
> we cannot just incorporate certain approaches of another language to C++.
> How would *you *solve template constraints, type erasure and
> customizations points at once? You need to elaborate a bit more here plea=
se.
> Especially considering: A specification of a type class in Haskell
> specifies its interface, which is identical to specifying its usage. This
> is however not the case for C++ as discussed already. So that can't be a
> solution for C++, unless you presume some sort of UFCS, as discussed abov=
e.
>
I see ADL as the biggest enemy here; see above.
>
>
> *Furthermore:*
> What do you think of my approach to contracts in my third last post?
> Nobody replied anything to it?!
> Is that because you don't see the similarity of contracts and concepts an=
d
> the need for approaching them in a uniform fashion?
>
Dunno - I don't see the similarity really, concepts define a static set of
requirements, while contracts specify invariants dynamically, in a way
that's related directly to a position in code. You can see some syntactic
parallels between the two (especially when you can do your claim
everywhere, and requires everywhere), but they serve purposes that are
different enough that I can't see too much of a semantic parallel.
>
>
Cheers,
> Jakob
>
> --
> 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/673b6386-cc7=
1-40b9-9237-925049821c8b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/673b6386-cc=
71-40b9-9237-925049821c8b%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAPCFJdRPAZqPqvxA7TeYBWmKog39v_NQD12tNWYmv31g9AB=
D%3DA%40mail.gmail.com.
--f403045c390e11d81d0553034b46
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, Jun 28, 2017 at 12:41 PM Jakob Riedle <<a href=3D"mailto:jakob.riedle@=
gmail.com">jakob.riedle@gmail.com</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br><br>Am Dienstag, 27. Juni 2017 16:01:45 =
UTC+2 schrieb Micha=C5=82 Dominiak:<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 class=3D"gmail_quote"><div dir=3D"ltr">A concept map=
is what is doing the adaptation.<br></div><div><br></div><div>It is a comp=
letely compile time thing; a different way to resolve a call (to a thing th=
at could be customized, hence also fixing all our problems that we have wit=
h customization points currently). Type erasure is the runtime component, a=
nd it just uses the potentially customized calls inside the interface.</div=
><div><br></div><div>I'll once again refer to=C2=A0<a href=3D"https://w=
ww.youtube.com/watch?v=3DLC7BuYeDezQ" rel=3D"nofollow" target=3D"_blank">my=
talk</a>, especially the part after the interludes, that describes those i=
deas somewhat better than I can in a concise manner in an email.</div><div>=
<br></div><div>Maybe I should write a paper on this, though it'd probab=
ly heavily look like C++0x concepts, and would probably scare half the comm=
ittee away by being heavy on the use of the phrase "concept maps"=
..</div></div></div></blockquote><div><br></div></div><div dir=3D"ltr"><div>=
Oh sure, gotcha! I understand now, what a concept map is, which I apparentl=
y did not previously.</div></div><div dir=3D"ltr"><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 clas=
s=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div></div><div><br></div><div>This basically comes down to the point, th=
at we need uniform call syntax in order to come up with a solution that pro=
vides for both applications (Concepts as "contracts based on types&quo=
t;) and automatic type erasure (virtual concepts).</div><div>I really have =
a bad feeling now with standardizing both contracts and concepts as they ar=
e now. They are neither the prettiest nor most elegant solution but instead=
introduce a rather big redundancy. Given that they represent huge changes =
to the standard, I am against standardizing them at this point.</div><div><=
br></div></div></blockquote><div><br></div><div>No, we don't need UFCS.=
We need concepts as interfaces, not as contracts on types, for all the rea=
sons I stated above.</div></div></div></blockquote><div><br></div></div><di=
v dir=3D"ltr"><div>But in this case, you exclude everyone from using Concep=
ts, who wants to use concepts as contracts on types!?<br>The following exam=
ple shall elaborate on that, If you should see not, why this is the case:</=
div><div><br></div><div><div class=3D"m_6246567533183861977prettyprint" sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px;word-wrap:break-word"><code class=3D"m_62465=
67533183861977prettyprint"><div class=3D"m_6246567533183861977subprettyprin=
t"><span style=3D"color:#008" class=3D"m_6246567533183861977styled-by-prett=
ify">template</span><span style=3D"color:#660" class=3D"m_62465675331838619=
77styled-by-prettify"><</span><span style=3D"color:#008" class=3D"m_6246=
567533183861977styled-by-prettify">typename</span><span style=3D"color:#000=
" class=3D"m_6246567533183861977styled-by-prettify"> T</span><span style=3D=
"color:#660" class=3D"m_6246567533183861977styled-by-prettify">></span><=
span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"=
><br></span><span style=3D"color:#008" class=3D"m_6246567533183861977styled=
-by-prettify">concept</span><span style=3D"color:#000" class=3D"m_624656753=
3183861977styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m=
_6246567533183861977styled-by-prettify">bool</span><span style=3D"color:#00=
0" class=3D"m_6246567533183861977styled-by-prettify"> </span><span style=3D=
"color:#606" class=3D"m_6246567533183861977styled-by-prettify">LessThanComp=
arable</span><span style=3D"color:#000" class=3D"m_6246567533183861977style=
d-by-prettify"> </span><span style=3D"color:#660" class=3D"m_62465675331838=
61977styled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_62=
46567533183861977styled-by-prettify"> requires</span><span style=3D"color:#=
660" class=3D"m_6246567533183861977styled-by-prettify">(</span><span style=
=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify">T a</span=
><span style=3D"color:#660" class=3D"m_6246567533183861977styled-by-prettif=
y">,</span><span style=3D"color:#000" class=3D"m_6246567533183861977styled-=
by-prettify"> T b</span><span style=3D"color:#660" class=3D"m_6246567533183=
861977styled-by-prettify">){</span><span style=3D"color:#000" class=3D"m_62=
46567533183861977styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D=
"color:#008" class=3D"m_6246567533183861977styled-by-prettify">bool</span><=
span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"=
> </span><span style=3D"color:#008" class=3D"m_6246567533183861977styled-by=
-prettify">operator</span><span style=3D"color:#660" class=3D"m_62465675331=
83861977styled-by-prettify"><(</span><span style=3D"color:#000" class=3D=
"m_6246567533183861977styled-by-prettify"> T a </span><span style=3D"color:=
#660" class=3D"m_6246567533183861977styled-by-prettify">,</span><span style=
=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"> T b </sp=
an><span style=3D"color:#660" class=3D"m_6246567533183861977styled-by-prett=
ify">);</span><span style=3D"color:#000" class=3D"m_6246567533183861977styl=
ed-by-prettify"><br></span><span style=3D"color:#660" class=3D"m_6246567533=
183861977styled-by-prettify">};</span><span style=3D"color:#000" class=3D"m=
_6246567533183861977styled-by-prettify"><br><br></span><span style=3D"color=
:#008" class=3D"m_6246567533183861977styled-by-prettify">template</span><sp=
an style=3D"color:#660" class=3D"m_6246567533183861977styled-by-prettify">&=
lt;</span><span style=3D"color:#008" class=3D"m_6246567533183861977styled-b=
y-prettify">typename</span><span style=3D"color:#000" class=3D"m_6246567533=
183861977styled-by-prettify"> T</span><span style=3D"color:#660" class=3D"m=
_6246567533183861977styled-by-prettify">></span><span style=3D"color:#00=
0" class=3D"m_6246567533183861977styled-by-prettify"><br>T min1</span><span=
style=3D"color:#660" class=3D"m_6246567533183861977styled-by-prettify">(</=
span><span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-pre=
ttify"> T a </span><span style=3D"color:#660" class=3D"m_624656753318386197=
7styled-by-prettify">,</span><span style=3D"color:#000" class=3D"m_62465675=
33183861977styled-by-prettify"> T b </span><span style=3D"color:#660" class=
=3D"m_6246567533183861977styled-by-prettify">){</span><span style=3D"color:=
#000" class=3D"m_6246567533183861977styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0</span><span style=3D"color:#008" class=3D"m_6246567533183861977style=
d-by-prettify">return</span><span style=3D"color:#000" class=3D"m_624656753=
3183861977styled-by-prettify"> a </span><span style=3D"color:#660" class=3D=
"m_6246567533183861977styled-by-prettify"><</span><span style=3D"color:#=
000" class=3D"m_6246567533183861977styled-by-prettify"> b </span><span styl=
e=3D"color:#660" class=3D"m_6246567533183861977styled-by-prettify">?</span>=
<span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify=
"> a </span><span style=3D"color:#660" class=3D"m_6246567533183861977styled=
-by-prettify">:</span><span style=3D"color:#000" class=3D"m_624656753318386=
1977styled-by-prettify"> b</span><span style=3D"color:#660" class=3D"m_6246=
567533183861977styled-by-prettify">;</span><span style=3D"color:#000" class=
=3D"m_6246567533183861977styled-by-prettify"><br></span><span style=3D"colo=
r:#660" class=3D"m_6246567533183861977styled-by-prettify">}</span><span sty=
le=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"><br><br=
></span><span style=3D"color:#008" class=3D"m_6246567533183861977styled-by-=
prettify">template</span><span style=3D"color:#660" class=3D"m_624656753318=
3861977styled-by-prettify"><</span><span style=3D"color:#008" class=3D"m=
_6246567533183861977styled-by-prettify">typename</span><span style=3D"color=
:#000" class=3D"m_6246567533183861977styled-by-prettify"> T</span><span sty=
le=3D"color:#660" class=3D"m_6246567533183861977styled-by-prettify">></s=
pan><span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-pret=
tify"><br>=C2=A0 =C2=A0 requires </span><span style=3D"color:#606" class=3D=
"m_6246567533183861977styled-by-prettify">LessThanComparable</span><span st=
yle=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"> </spa=
n><span style=3D"color:#660" class=3D"m_6246567533183861977styled-by-pretti=
fy"><</span><span style=3D"color:#000" class=3D"m_6246567533183861977sty=
led-by-prettify">T</span><span style=3D"color:#660" class=3D"m_624656753318=
3861977styled-by-prettify">>()</span><span style=3D"color:#000" class=3D=
"m_6246567533183861977styled-by-prettify"><br>T min2</span><span style=3D"c=
olor:#660" class=3D"m_6246567533183861977styled-by-prettify">(</span><span =
style=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"> T a=
</span><span style=3D"color:#660" class=3D"m_6246567533183861977styled-by-=
prettify">,</span><span style=3D"color:#000" class=3D"m_6246567533183861977=
styled-by-prettify"> T b </span><span style=3D"color:#660" class=3D"m_62465=
67533183861977styled-by-prettify">){</span><span style=3D"color:#000" class=
=3D"m_6246567533183861977styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0</span=
><span style=3D"color:#008" class=3D"m_6246567533183861977styled-by-prettif=
y">return</span><span style=3D"color:#000" class=3D"m_6246567533183861977st=
yled-by-prettify"> a </span><span style=3D"color:#660" class=3D"m_624656753=
3183861977styled-by-prettify"><</span><span style=3D"color:#000" class=
=3D"m_6246567533183861977styled-by-prettify"> b </span><span style=3D"color=
:#660" class=3D"m_6246567533183861977styled-by-prettify">?</span><span styl=
e=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"> a </spa=
n><span style=3D"color:#660" class=3D"m_6246567533183861977styled-by-pretti=
fy">:</span><span style=3D"color:#000" class=3D"m_6246567533183861977styled=
-by-prettify"> b</span><span style=3D"color:#660" class=3D"m_62465675331838=
61977styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_6246=
567533183861977styled-by-prettify"> </span><span style=3D"color:#800" class=
=3D"m_6246567533183861977styled-by-prettify">// We actually only care about=
whether the expression 'a < b' is well formed</span><span style=
=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"><br></spa=
n><span style=3D"color:#660" class=3D"m_6246567533183861977styled-by-pretti=
fy">}</span><span style=3D"color:#000" class=3D"m_6246567533183861977styled=
-by-prettify"><br><br></span><span style=3D"color:#008" class=3D"m_62465675=
33183861977styled-by-prettify">struct</span><span style=3D"color:#000" clas=
s=3D"m_6246567533183861977styled-by-prettify"> </span><span style=3D"color:=
#606" class=3D"m_6246567533183861977styled-by-prettify">Foo</span><span sty=
le=3D"color:#660" class=3D"m_6246567533183861977styled-by-prettify">{</span=
><span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettif=
y"> </span><span style=3D"color:#008" class=3D"m_6246567533183861977styled-=
by-prettify">int</span><span style=3D"color:#000" class=3D"m_62465675331838=
61977styled-by-prettify"> bar</span><span style=3D"color:#660" class=3D"m_6=
246567533183861977styled-by-prettify">;</span><span style=3D"color:#000" cl=
ass=3D"m_6246567533183861977styled-by-prettify"> </span><span style=3D"colo=
r:#660" class=3D"m_6246567533183861977styled-by-prettify">};</span><span st=
yle=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"><br></=
span><span style=3D"color:#008" class=3D"m_6246567533183861977styled-by-pre=
ttify">bool</span><span style=3D"color:#000" class=3D"m_6246567533183861977=
styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_624656753=
3183861977styled-by-prettify">operator</span><span style=3D"color:#660" cla=
ss=3D"m_6246567533183861977styled-by-prettify"><(</span><span style=3D"c=
olor:#606" class=3D"m_6246567533183861977styled-by-prettify">Foo</span><spa=
n style=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"> a=
</span><span style=3D"color:#660" class=3D"m_6246567533183861977styled-by-p=
rettify">,</span><span style=3D"color:#000" class=3D"m_6246567533183861977s=
tyled-by-prettify"> </span><span style=3D"color:#606" class=3D"m_6246567533=
183861977styled-by-prettify">Foo</span><span style=3D"color:#000" class=3D"=
m_6246567533183861977styled-by-prettify"> b</span><span style=3D"color:#660=
" class=3D"m_6246567533183861977styled-by-prettify">){</span><span style=3D=
"color:#000" class=3D"m_6246567533183861977styled-by-prettify"> </span><spa=
n style=3D"color:#008" class=3D"m_6246567533183861977styled-by-prettify">re=
turn</span><span style=3D"color:#000" class=3D"m_6246567533183861977styled-=
by-prettify"> a</span><span style=3D"color:#660" class=3D"m_624656753318386=
1977styled-by-prettify">.</span><span style=3D"color:#000" class=3D"m_62465=
67533183861977styled-by-prettify">bar </span><span style=3D"color:#660" cla=
ss=3D"m_6246567533183861977styled-by-prettify"><</span><span style=3D"co=
lor:#000" class=3D"m_6246567533183861977styled-by-prettify"> b</span><span =
style=3D"color:#660" class=3D"m_6246567533183861977styled-by-prettify">.</s=
pan><span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-pret=
tify">bar</span><span style=3D"color:#660" class=3D"m_6246567533183861977st=
yled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_62465675331=
83861977styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_6=
246567533183861977styled-by-prettify">}</span><span style=3D"color:#000" cl=
ass=3D"m_6246567533183861977styled-by-prettify"><br><br><br>min1</span><spa=
n style=3D"color:#660" class=3D"m_6246567533183861977styled-by-prettify">(<=
/span><span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-pr=
ettify"> </span><span style=3D"color:#606" class=3D"m_6246567533183861977st=
yled-by-prettify">Foo</span><span style=3D"color:#660" class=3D"m_624656753=
3183861977styled-by-prettify">{</span><span style=3D"color:#066" class=3D"m=
_6246567533183861977styled-by-prettify">4</span><span style=3D"color:#660" =
class=3D"m_6246567533183861977styled-by-prettify">}</span><span style=3D"co=
lor:#000" class=3D"m_6246567533183861977styled-by-prettify"> </span><span s=
tyle=3D"color:#660" class=3D"m_6246567533183861977styled-by-prettify">,</sp=
an><span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-prett=
ify"> </span><span style=3D"color:#606" class=3D"m_6246567533183861977style=
d-by-prettify">Foo</span><span style=3D"color:#660" class=3D"m_624656753318=
3861977styled-by-prettify">{</span><span style=3D"color:#066" class=3D"m_62=
46567533183861977styled-by-prettify">5</span><span style=3D"color:#660" cla=
ss=3D"m_6246567533183861977styled-by-prettify">}</span><span style=3D"color=
:#000" class=3D"m_6246567533183861977styled-by-prettify"> </span><span styl=
e=3D"color:#660" class=3D"m_6246567533183861977styled-by-prettify">);</span=
><span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettif=
y"> </span><span style=3D"color:#800" class=3D"m_6246567533183861977styled-=
by-prettify">// This works</span><span style=3D"color:#000" class=3D"m_6246=
567533183861977styled-by-prettify"><br>min2</span><span style=3D"color:#660=
" class=3D"m_6246567533183861977styled-by-prettify">(</span><span style=3D"=
color:#000" class=3D"m_6246567533183861977styled-by-prettify"> </span><span=
style=3D"color:#606" class=3D"m_6246567533183861977styled-by-prettify">Foo=
</span><span style=3D"color:#660" class=3D"m_6246567533183861977styled-by-p=
rettify">{</span><span style=3D"color:#066" class=3D"m_6246567533183861977s=
tyled-by-prettify">4</span><span style=3D"color:#660" class=3D"m_6246567533=
183861977styled-by-prettify">}</span><span style=3D"color:#000" class=3D"m_=
6246567533183861977styled-by-prettify"> </span><span style=3D"color:#660" c=
lass=3D"m_6246567533183861977styled-by-prettify">,</span><span style=3D"col=
or:#000" class=3D"m_6246567533183861977styled-by-prettify"> </span><span st=
yle=3D"color:#606" class=3D"m_6246567533183861977styled-by-prettify">Foo</s=
pan><span style=3D"color:#660" class=3D"m_6246567533183861977styled-by-pret=
tify">{</span><span style=3D"color:#066" class=3D"m_6246567533183861977styl=
ed-by-prettify">5</span><span style=3D"color:#660" class=3D"m_6246567533183=
861977styled-by-prettify">}</span><span style=3D"color:#000" class=3D"m_624=
6567533183861977styled-by-prettify"> </span><span style=3D"color:#660" clas=
s=3D"m_6246567533183861977styled-by-prettify">);</span><span style=3D"color=
:#000" class=3D"m_6246567533183861977styled-by-prettify"> </span><span styl=
e=3D"color:#800" class=3D"m_6246567533183861977styled-by-prettify">// Error=
: No Foo::operator< defined to fulfill concept LessThanComparable</span>=
<span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify=
"><br><br><br></span><span style=3D"color:#800" class=3D"m_6246567533183861=
977styled-by-prettify">// Unless you do this (I use the syntax that you use=
d in your talk)</span><span style=3D"color:#000" class=3D"m_624656753318386=
1977styled-by-prettify"><br></span><span style=3D"color:#008" class=3D"m_62=
46567533183861977styled-by-prettify">concept_map</span><span style=3D"color=
:#000" class=3D"m_6246567533183861977styled-by-prettify"> </span><span styl=
e=3D"color:#606" class=3D"m_6246567533183861977styled-by-prettify">LessThan=
Comparable</span><span style=3D"color:#660" class=3D"m_6246567533183861977s=
tyled-by-prettify"><</span><span style=3D"color:#606" class=3D"m_6246567=
533183861977styled-by-prettify">Foo</span><span style=3D"color:#660" class=
=3D"m_6246567533183861977styled-by-prettify">>{</span><span style=3D"col=
or:#000" class=3D"m_6246567533183861977styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:#008" class=3D"m_6246567533183861977styled-=
by-prettify">bool</span><span style=3D"color:#000" class=3D"m_6246567533183=
861977styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_624=
6567533183861977styled-by-prettify">operator</span><span style=3D"color:#66=
0" class=3D"m_6246567533183861977styled-by-prettify"><(</span><span styl=
e=3D"color:#008" class=3D"m_6246567533183861977styled-by-prettify">const</s=
pan><span style=3D"color:#000" class=3D"m_6246567533183861977styled-by-pret=
tify"> </span><span style=3D"color:rgb(102,0,102)"><span style=3D"color:#60=
6" class=3D"m_6246567533183861977styled-by-prettify">Foo</span></span><span=
style=3D"color:#660" class=3D"m_6246567533183861977styled-by-prettify">&am=
p;</span><span style=3D"color:#000" class=3D"m_6246567533183861977styled-by=
-prettify"> lhs</span><span style=3D"color:#660" class=3D"m_624656753318386=
1977styled-by-prettify">,</span><span style=3D"color:#000" class=3D"m_62465=
67533183861977styled-by-prettify"> </span><span style=3D"color:#008" class=
=3D"m_6246567533183861977styled-by-prettify">const</span><span style=3D"col=
or:#000" class=3D"m_6246567533183861977styled-by-prettify"> </span><span st=
yle=3D"color:rgb(102,0,102)"><span style=3D"color:#606" class=3D"m_62465675=
33183861977styled-by-prettify">Foo</span></span><span style=3D"color:#660" =
class=3D"m_6246567533183861977styled-by-prettify">&</span><span style=
=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"> rhs</spa=
n><span style=3D"color:#660" class=3D"m_6246567533183861977styled-by-pretti=
fy">)</span><span style=3D"color:#000" class=3D"m_6246567533183861977styled=
-by-prettify"> </span><span style=3D"color:#660" class=3D"m_624656753318386=
1977styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_62465=
67533183861977styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><s=
pan style=3D"color:#008" class=3D"m_6246567533183861977styled-by-prettify">=
return</span><span style=3D"color:#000" class=3D"m_6246567533183861977style=
d-by-prettify"> lhs</span><font color=3D"#666600"><span style=3D"color:#000=
" class=3D"m_6246567533183861977styled-by-prettify"> </span><span style=3D"=
color:#660" class=3D"m_6246567533183861977styled-by-prettify"><</span><s=
pan style=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify">=
</span></font><span style=3D"color:#000" class=3D"m_6246567533183861977sty=
led-by-prettify">rhs</span><font color=3D"#666600"><span style=3D"color:#66=
0" class=3D"m_6246567533183861977styled-by-prettify">;</span></font><span s=
tyle=3D"color:#000" class=3D"m_6246567533183861977styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:#660" class=3D"m_6246567533183861=
977styled-by-prettify">}</span><span style=3D"color:#000" class=3D"m_624656=
7533183861977styled-by-prettify"><br></span><span style=3D"color:#660" clas=
s=3D"m_6246567533183861977styled-by-prettify">};</span></div></code></div><=
br>Either you</div><div><ol><li>presume UFCS and the definition of LessThan=
Comparable finds the freestanding operator< (BTW as well as built-in ope=
rators for let's say 'int') or</li><li>you leave UFCS out, in w=
hich case you have to write concept_maps/adaptors for every class/primitive=
type that implements operators not as member functions (e.g. like Foo).<br=
></li></ol></div><div>So either you consider UFCS in some form or you end u=
p with concepts not being able to be used as constracts on types.</div><div=
>From your talk I understand your point on why it is neat to specify Interf=
aces instead of usage :D, but if you do not presume some sort of UFCS then =
concepts are once more only a partial solution.</div><div>Was that explaine=
d properly? I hope, you see my point.</div></div><div dir=3D"ltr"><div><br>=
</div></div></blockquote><div><br></div><div>My ultimate idealistic goal wo=
uld be to have predefined concepts for operators (that'd be used for lo=
okup when an operator is invoked) and then make people migrate to those (to=
use proper customization points for customization, and to eventually compl=
etely stop using ADL for customization points).</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>=C2=A0<br></div>=
</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_quote"><div>I think that UFCS would <i>hide</i>=C2=A0the actual proble=
m from us, making it seem <i>as if</i>=C2=A0we solved the adaptation proble=
m, while we would not have actually looked at the problem of customization =
points that we have all over the place. (std::swap is an ADL mess, operator=
overloading as free functions is a total mess - see all the issues where `=
stream << foo` picks up the wrong type by accident, or see how many o=
f those overloads need to be considered before the call is resolved; and a =
recent shiny one, customization points of structured bindings, which I do m=
ention in the talk linked above, are a terrible, terrible thing.)</div></di=
v></div></blockquote><div><br></div></div><div dir=3D"ltr"><div>To me, UFCS=
really does represent the <i>only solution</i> that allows us to support b=
oth worlds with a uniform mechanism (concepts as contracts on types as well=
as concepts as interface specifications).<br></div></div><div dir=3D"ltr">=
<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 class=3D"gmail_quote"><div>We <i>could </i>be=C2=A0solving three proble=
ms - template constraints, type erasure <i>and</i>=C2=A0customization point=
s - by just looking at how other languages implemented typeclasses / traits=
/ whatever, but instead we're spending waaay too much time on a featur=
e that's just SFINAE on steroids (there's a conceptless implementat=
ion of the Ranges TS, for crying out loud, and that library <i>supposedly</=
i>=C2=A0needs concepts...).</div></div></div></blockquote><div><br></div></=
div><div dir=3D"ltr"><div>C++ has its own ways of doing things already, so =
in the majority of cases we cannot just incorporate certain approaches of a=
nother language to C++.</div><div>How would <i>you </i>solve template const=
raints, type erasure and customizations points at once? You need to elabora=
te a bit more here please.</div><div>Especially considering: A specificatio=
n of a type class in Haskell specifies its interface, which is identical to=
specifying its usage. This is however not the case for C++ as discussed al=
ready. So that can't be a solution for C++, unless you presume some sor=
t of UFCS, as discussed above.</div></div></blockquote><div><br></div><div>=
I see ADL as the biggest enemy here; see above.</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0<br></div></div></blo=
ckquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div><br=
></div><div><b>Furthermore:</b></div><div>What do you think of my approach =
to contracts in my third last post? Nobody replied anything to it?!</div><d=
iv>Is that because you don't see the similarity of contracts and concep=
ts and the need for approaching them in a uniform fashion?</div></div></blo=
ckquote><div><br></div><div>Dunno - I don't see the similarity really, =
concepts define a static set of requirements, while contracts specify invar=
iants dynamically, in a way that's related directly to a position in co=
de. You can see some syntactic parallels between the two (especially when y=
ou can do your claim everywhere, and requires everywhere), but they serve p=
urposes that are different enough that I can't see too much of a semant=
ic parallel.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>=C2=A0<br></div></div></blockquote><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div></div><div>Cheers,</div><div>Jakob</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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/673b6386-cc71-40b9-9237-925049821c8b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/673b6386-cc71-=
40b9-9237-925049821c8b%40isocpp.org</a>.<br>
</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/CAPCFJdRPAZqPqvxA7TeYBWmKog39v_NQD12t=
NWYmv31g9ABD%3DA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRPAZqPqv=
xA7TeYBWmKog39v_NQD12tNWYmv31g9ABD%3DA%40mail.gmail.com</a>.<br />
--f403045c390e11d81d0553034b46--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Jun 2017 14:22:25 +0300
Raw View
On 27 June 2017 at 21:53, Micha=C5=82 Dominiak <griwes@griwes.info> wrote:
>> If you had a better idea, you could have been working on it in parallel
>> with Concepts TS. You could have gotten together with people and wrote a
>> proposal with standards wording, forked Clang and implemented it, and pr=
oven
>> your point. After all, Concepts Lite was able to do those things. Right =
now,
>> you are nothing but words, while Concepts TS is a real, live, and useful
>> feature of C++.
>
>
> Yes, splendid. Let's get a terrible feature in because we prefer that ove=
r
> nothing. This has never caused any problems for anyone, right?
Where are the papers describing how Concepts are terrible? You've had 6 yea=
rs
to write them.
> About the only thing I like from the TS is the requires expressions in an=
y
> context and the requires clauses on declarations. Pulling more stops us f=
rom
> ever having a truly good feature dealing with this.
I fail to see how what you like or not is something we should take seriousl=
y.
> We need to either iterate on the TS concepts, or iterate on the C++0x
> concepts. But I, for one, prefer no feature over bad feature, and I much
Iterating on the C++0x concepts is certainly a great way to waste
everybody's time.
> prefer writing sfinae over doing TS concepts (and my first non trivial
> attempt at them has shown me that I'd still need crazy code to express th=
e
> constraints that I have). If you want your users to suffer less - use a
> macro like Range v3's REQUIRES.
Wow. My attempts have shown me that the code is *MUCH* less crazy than
it is with
SFINAE. I have no illusion of your reading this paper, but perhaps it
will show to
some others why SFINAE is laughably inferior:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0225r0.html
--=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/CAFk2RUZjnnqHZOt0rQx-d%2BdxzdmVVNBjM-ANB5iB1PPt5=
r5tEw%40mail.gmail.com.
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 28 Jun 2017 11:41:02 +0000
Raw View
--94eb2c145bd6707981055303a9c9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
This is a very emotional mail you've written, which is why I'll only answer
two parts of it - one of them despite it being not very professional.
There are no papers that I've written, mostly because it's only now that
I'm really starting to be involved in the process; but as far as I'm
concerned, there's been numerous papers describing how they are terrible
(and no, I'm not going to enumerate them here, because I find it to be a
great waste of time to point the EWG chair to EWG papers).
And what I like or not is something you should at least acknowledge,
because there's a non-zero chance of a new National Body popping into
existence in WG21 due to my involvement within a timeframe of several
months.
On Wed, Jun 28, 2017, 1:22 PM Ville Voutilainen <ville.voutilainen@gmail.co=
m>
wrote:
> On 27 June 2017 at 21:53, Micha=C5=82 Dominiak <griwes@griwes.info> wrote=
:
> >> If you had a better idea, you could have been working on it in paralle=
l
> >> with Concepts TS. You could have gotten together with people and wrote=
a
> >> proposal with standards wording, forked Clang and implemented it, and
> proven
> >> your point. After all, Concepts Lite was able to do those things. Righ=
t
> now,
> >> you are nothing but words, while Concepts TS is a real, live, and usef=
ul
> >> feature of C++.
> >
> >
> > Yes, splendid. Let's get a terrible feature in because we prefer that
> over
> > nothing. This has never caused any problems for anyone, right?
>
> Where are the papers describing how Concepts are terrible? You've had 6
> years
> to write them.
>
> > About the only thing I like from the TS is the requires expressions in
> any
> > context and the requires clauses on declarations. Pulling more stops us
> from
> > ever having a truly good feature dealing with this.
>
> I fail to see how what you like or not is something we should take
> seriously.
>
> > We need to either iterate on the TS concepts, or iterate on the C++0x
> > concepts. But I, for one, prefer no feature over bad feature, and I muc=
h
>
> Iterating on the C++0x concepts is certainly a great way to waste
> everybody's time.
>
> > prefer writing sfinae over doing TS concepts (and my first non trivial
> > attempt at them has shown me that I'd still need crazy code to express
> the
> > constraints that I have). If you want your users to suffer less - use a
> > macro like Range v3's REQUIRES.
>
> Wow. My attempts have shown me that the code is *MUCH* less crazy than
> it is with
> SFINAE. I have no illusion of your reading this paper, but perhaps it
> will show to
> some others why SFINAE is laughably inferior:
>
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0225r0.html
>
> --
> 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/CAFk2RUZjnnq=
HZOt0rQx-d%2BdxzdmVVNBjM-ANB5iB1PPt5r5tEw%40mail.gmail.com
> .
>
--=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/CAPCFJdRTZ7rV%3Dz0eiQ7D_djS4gJ2jSRoVh3-vH61%2BfZ=
-sfCkwQ%40mail.gmail.com.
--94eb2c145bd6707981055303a9c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
This is a very emotional mail you've written, which is why I'll onl=
y answer two parts of it - one of them despite it being not very profession=
al.<br><br>There are no papers that I've written, mostly because it'=
;s only now that I'm really starting to be involved in the process; but=
as far as I'm concerned, there's been numerous papers describing h=
ow they are terrible (and no, I'm not going to enumerate them here, bec=
ause I find it to be a great waste of time to point the EWG chair to EWG pa=
pers).<div><br></div><div>And what I like or not is something you should at=
least acknowledge, because there's a non-zero chance of a new National=
Body popping into existence in WG21 due to my involvement within a timefra=
me of several months.<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On=
Wed, Jun 28, 2017, 1:22 PM Ville Voutilainen <<a href=3D"mailto:ville.v=
outilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex">On 27 June 2017 at 21:53, Micha=C5=82 Dominia=
k <<a href=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes=
..info</a>> wrote:<br>
>> If you had a better idea, you could have been working on it in par=
allel<br>
>> with Concepts TS. You could have gotten together with people and w=
rote a<br>
>> proposal with standards wording, forked Clang and implemented it, =
and proven<br>
>> your point. After all, Concepts Lite was able to do those things. =
Right now,<br>
>> you are nothing but words, while Concepts TS is a real, live, and =
useful<br>
>> feature of C++.<br>
><br>
><br>
> Yes, splendid. Let's get a terrible feature in because we prefer t=
hat over<br>
> nothing. This has never caused any problems for anyone, right?<br>
<br>
Where are the papers describing how Concepts are terrible? You've had 6=
years<br>
to write them.<br><br>
> About the only thing I like from the TS is the requires expressions in=
any<br>
> context and the requires clauses on declarations. Pulling more stops u=
s from<br>
> ever having a truly good feature dealing with this.<br>
<br>
I fail to see how what you like or not is something we should take seriousl=
y.<br>
<br>
> We need to either iterate on the TS concepts, or iterate on the C++0x<=
br>
> concepts. But I, for one, prefer no feature over bad feature, and I mu=
ch<br>
<br>
Iterating on the C++0x concepts is certainly a great way to waste<br>
everybody's time.<br>
<br>
> prefer writing sfinae over doing TS concepts (and my first non trivial=
<br>
> attempt at them has shown me that I'd still need crazy code to exp=
ress the<br>
> constraints that I have). If you want your users to suffer less - use =
a<br>
> macro like Range v3's REQUIRES.<br>
<br>
Wow. My attempts have shown me that the code is *MUCH* less crazy than<br>
it is with<br>
SFINAE. I have no illusion of your reading this paper, but perhaps it<br>
will show to<br>
some others why SFINAE is laughably inferior:<br>
<br>
<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0225r0.html=
" rel=3D"noreferrer" target=3D"_blank">http://open-std.org/JTC1/SC22/WG21/d=
ocs/papers/2016/p0225r0.html</a><br>
<br>
--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/CAFk2RUZjnnqHZOt0rQx-d%2BdxzdmVVNBjM-=
ANB5iB1PPt5r5tEw%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZjnnqHZOt0=
rQx-d%2BdxzdmVVNBjM-ANB5iB1PPt5r5tEw%40mail.gmail.com</a>.<br>
</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/CAPCFJdRTZ7rV%3Dz0eiQ7D_djS4gJ2jSRoVh=
3-vH61%2BfZ-sfCkwQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRTZ7rV=
%3Dz0eiQ7D_djS4gJ2jSRoVh3-vH61%2BfZ-sfCkwQ%40mail.gmail.com</a>.<br />
--94eb2c145bd6707981055303a9c9--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Jun 2017 15:18:48 +0300
Raw View
On 28 June 2017 at 14:41, Micha=C5=82 Dominiak <griwes@griwes.info> wrote:
> This is a very emotional mail you've written, which is why I'll only answ=
er
> two parts of it - one of them despite it being not very professional.
Gee, we must disagree on what is or is not emotional. It sure seems to
me that your describing Concepts
as terrible, and deeming SFINAE a better choice, is nothing short of emotio=
nal.
> There are no papers that I've written, mostly because it's only now that =
I'm
> really starting to be involved in the process; but as far as I'm concerne=
d,
> there's been numerous papers describing how they are terrible (and no, I'=
m
> not going to enumerate them here, because I find it to be a great waste o=
f
> time to point the EWG chair to EWG papers).
I am aware of current papers that propose changes to Concepts, but none of =
those
papers describe Concepts as terrible in the sense that you seem to do.
> And what I like or not is something you should at least acknowledge, beca=
use
> there's a non-zero chance of a new National Body popping into existence i=
n
> WG21 due to my involvement within a timeframe of several months.
That's interesting, hopefully that NB has the ability to send experts
who can actually
explain their views and can think and participate rationally.
--=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/CAFk2RUbucuTZnpfrLLQQDAAwfB5%3DJQnagr8OQhPEtMd-f=
x-czA%40mail.gmail.com.
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 28 Jun 2017 12:35:51 +0000
Raw View
--94eb2c1482224816d70553046daa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 28, 2017 at 2:18 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 28 June 2017 at 14:41, Micha=C5=82 Dominiak <griwes@griwes.info> wrote=
:
> > This is a very emotional mail you've written, which is why I'll only
> answer
> > two parts of it - one of them despite it being not very professional.
>
> Gee, we must disagree on what is or is not emotional. It sure seems to
> me that your describing Concepts
> as terrible, and deeming SFINAE a better choice, is nothing short of
> emotional.
>
I described what I think we need in detail in this thread. I also described
in detail how TS concepts relate to what I think we need, and what are
their shortcomings, IMHO. If you had read this thread, you'd've noticed.
There's not a single place where I said SFINAE is a better; there's only a
place where I say that SFINAE works and can be made not as terrible for a
general population of C++ programmers with macros; and a *separate* opinion
that I gave is that releasing a standard with TS concepts would hurt the
language. For reasons that I and others have described. What else do you
want me to do, short of writing a paper? How is actually explaining my
technical problems with a feature in any way emotional?
>
> > There are no papers that I've written, mostly because it's only now tha=
t
> I'm
> > really starting to be involved in the process; but as far as I'm
> concerned,
> > there's been numerous papers describing how they are terrible (and no,
> I'm
> > not going to enumerate them here, because I find it to be a great waste
> of
> > time to point the EWG chair to EWG papers).
>
> I am aware of current papers that propose changes to Concepts, but none o=
f
> those
> papers describe Concepts as terrible in the sense that you seem to do.
>
Sure. Maybe not in the same sense, but there's a clear consensus about a
lack of consensus, and I personally know quite a few committee members who
mostly share my opinion on this.
>
> > And what I like or not is something you should at least acknowledge,
> because
> > there's a non-zero chance of a new National Body popping into existence
> in
> > WG21 due to my involvement within a timeframe of several months.
>
> That's interesting, hopefully that NB has the ability to send experts
> who can actually
> explain their views and can think and participate rationally.
>
This is bordering on being inappropriate due to its intent, but I agree
with the letter (and not the spirit) - I'm more than capable to explain my
views, and I have done that earlier in this thread (and to an extend in the
talk that's been linked earlier in this thread). If you want me to explain
my views verbally (since that'll be easier than throwing emails at each
other), *and* you're willing to listen and discuss arguments, then I'll be
more than happy to discuss this with you in Toronto, should you find some
time for it.
>
> --
> 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/CAFk2RUbucuT=
ZnpfrLLQQDAAwfB5%3DJQnagr8OQhPEtMd-fx-czA%40mail.gmail.com
> .
>
--=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/CAPCFJdS_rFRgQzs1UBekadxjoVRXj8WrPye4oU_OsnVn7vw=
8GQ%40mail.gmail.com.
--94eb2c1482224816d70553046daa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jun 28=
, 2017 at 2:18 PM Ville Voutilainen <<a href=3D"mailto:ville.voutilainen=
@gmail.com">ville.voutilainen@gmail.com</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On 28 June 2017 at 14:41, Micha=C5=82 Dominiak <<a h=
ref=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>&=
gt; wrote:<br>
> This is a very emotional mail you've written, which is why I'l=
l only answer<br>
> two parts of it - one of them despite it being not very professional.<=
br>
<br>
Gee, we must disagree on what is or is not emotional. It sure seems to<br>
me that your describing Concepts<br>
as terrible, and deeming SFINAE a better choice, is nothing short of emotio=
nal.<br></blockquote><div><br></div><div>I described what I think we need i=
n detail in this thread. I also described in detail how TS concepts relate =
to what I think we need, and what are their shortcomings, IMHO. If you had =
read this thread, you'd've noticed.</div><div><br></div><div>There&=
#39;s not a single place where I said SFINAE is a better; there's only =
a place where I say that SFINAE works and can be made not as terrible for a=
general population of C++ programmers with macros; and a <i>separate</i>=
=C2=A0opinion that I gave is that releasing a standard with TS concepts wou=
ld hurt the language. For reasons that I and others have described. What el=
se do you want me to do, short of writing a paper? How is actually explaini=
ng my technical problems with a feature in any way emotional?</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<br>
> There are no papers that I've written, mostly because it's onl=
y now that I'm<br>
> really starting to be involved in the process; but as far as I'm c=
oncerned,<br>
> there's been numerous papers describing how they are terrible (and=
no, I'm<br>
> not going to enumerate them here, because I find it to be a great wast=
e of<br>
> time to point the EWG chair to EWG papers).<br>
<br>
I am aware of current papers that propose changes to Concepts, but none of =
those<br>
papers describe Concepts as terrible in the sense that you seem to do.<br><=
/blockquote><div><br></div><div>Sure. Maybe not in the same sense, but ther=
e's a clear consensus about a lack of consensus, and I personally know =
quite a few committee members who mostly share my opinion on this.</div><di=
v>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> And what I like or not is something you should at least acknowledge, b=
ecause<br>
> there's a non-zero chance of a new National Body popping into exis=
tence in<br>
> WG21 due to my involvement within a timeframe of several months.<br>
<br>
That's interesting, hopefully that NB has the ability to send experts<b=
r>
who can actually<br>
explain their views and can think and participate rationally.<br></blockquo=
te><div><br></div><div>This is bordering on being inappropriate due to its =
intent, but I agree with the letter (and not the spirit) - I'm more tha=
n capable to explain my views, and I have done that earlier in this thread =
(and to an extend in the talk that's been linked earlier in this thread=
). If you want me to explain my views verbally (since that'll be easier=
than throwing emails at each other), <i>and</i>=C2=A0you're willing to=
listen and discuss arguments, then I'll be more than happy to discuss =
this with you in Toronto, should you find some time for it.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<br>
--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/CAFk2RUbucuTZnpfrLLQQDAAwfB5%3DJQnagr=
8OQhPEtMd-fx-czA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbucuTZnpfr=
LLQQDAAwfB5%3DJQnagr8OQhPEtMd-fx-czA%40mail.gmail.com</a>.<br>
</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/CAPCFJdS_rFRgQzs1UBekadxjoVRXj8WrPye4=
oU_OsnVn7vw8GQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdS_rFRgQzs1=
UBekadxjoVRXj8WrPye4oU_OsnVn7vw8GQ%40mail.gmail.com</a>.<br />
--94eb2c1482224816d70553046daa--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Jun 2017 15:51:12 +0300
Raw View
On 28 June 2017 at 15:35, Micha=C5=82 Dominiak <griwes@griwes.info> wrote:
>> Gee, we must disagree on what is or is not emotional. It sure seems to
>> me that your describing Concepts
>> as terrible, and deeming SFINAE a better choice, is nothing short of
>> emotional.
> I described what I think we need in detail in this thread. I also describ=
ed
> in detail how TS concepts relate to what I think we need, and what are th=
eir
> shortcomings, IMHO. If you had read this thread, you'd've noticed.
If you want to change how Concepts work, describing it on this thread
does precisely
nothing to achieve that goal.
> There's not a single place where I said SFINAE is a better; there's only =
a
> place where I say that SFINAE works and can be made not as terrible for a
> general population of C++ programmers with macros; and a separate opinion
> that I gave is that releasing a standard with TS concepts would hurt the
> language. For reasons that I and others have described. What else do you
> want me to do, short of writing a paper? How is actually explaining my
> technical problems with a feature in any way emotional?
Pardon me for misunderstanding "But I, for one, prefer no feature over
bad feature, and I
much prefer writing sfinae over doing TS concepts". And yes, if you
have something
to say about concepts, you should say it in a paper.
>> > There are no papers that I've written, mostly because it's only now th=
at
>> > I'm
>> > really starting to be involved in the process; but as far as I'm
>> > concerned,
>> > there's been numerous papers describing how they are terrible (and no,
>> > I'm
>> > not going to enumerate them here, because I find it to be a great wast=
e
>> > of
>> > time to point the EWG chair to EWG papers).
>> I am aware of current papers that propose changes to Concepts, but none =
of
>> those
>> papers describe Concepts as terrible in the sense that you seem to do.
> Sure. Maybe not in the same sense, but there's a clear consensus about a
> lack of consensus, and I personally know quite a few committee members wh=
o
> mostly share my opinion on this.
So what are the papers describing how Concepts are terrible, since you said
there are numerous such papers, and I should know what they are?
>> > And what I like or not is something you should at least acknowledge,
>> > because
>> > there's a non-zero chance of a new National Body popping into existenc=
e
>> > in
>> > WG21 due to my involvement within a timeframe of several months.
>> That's interesting, hopefully that NB has the ability to send experts
>> who can actually
>> explain their views and can think and participate rationally.
> This is bordering on being inappropriate due to its intent, but I agree w=
ith
Sounds like a very liberal interpretation to me.
> the letter (and not the spirit) - I'm more than capable to explain my vie=
ws,
> and I have done that earlier in this thread (and to an extend in the talk
> that's been linked earlier in this thread). If you want me to explain my
> views verbally (since that'll be easier than throwing emails at each othe=
r),
> and you're willing to listen and discuss arguments, then I'll be more tha=
n
> happy to discuss this with you in Toronto, should you find some time for =
it.
I have no use for verbal explanations, std-proposals threads, or
talks. What I have
use for is papers directed at WG21. There can barely be sane
discussion on anything
if the responses to proposals are only ever provided in non-paper form.
--=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/CAFk2RUZZritz2SV3jQTJDJrREKVxEbKAKiQVjpth1RYBO2c=
_Ow%40mail.gmail.com.
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 28 Jun 2017 13:08:50 +0000
Raw View
--94eb2c08aebc43cd63055304e331
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 28, 2017 at 2:51 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 28 June 2017 at 15:35, Micha=C5=82 Dominiak <griwes@griwes.info> wrote=
:
> >> Gee, we must disagree on what is or is not emotional. It sure seems to
> >> me that your describing Concepts
> >> as terrible, and deeming SFINAE a better choice, is nothing short of
> >> emotional.
> > I described what I think we need in detail in this thread. I also
> described
> > in detail how TS concepts relate to what I think we need, and what are
> their
> > shortcomings, IMHO. If you had read this thread, you'd've noticed.
>
> If you want to change how Concepts work, describing it on this thread
> does precisely
> nothing to achieve that goal.
>
> > There's not a single place where I said SFINAE is a better; there's onl=
y
> a
> > place where I say that SFINAE works and can be made not as terrible for=
a
> > general population of C++ programmers with macros; and a separate opini=
on
> > that I gave is that releasing a standard with TS concepts would hurt th=
e
> > language. For reasons that I and others have described. What else do yo=
u
> > want me to do, short of writing a paper? How is actually explaining my
> > technical problems with a feature in any way emotional?
>
> Pardon me for misunderstanding "But I, for one, prefer no feature over
> bad feature, and I
> much prefer writing sfinae over doing TS concepts".
"I prefer doing X over Y" states preference, not whether I claim X is
better than Y. TS concepts are indeed a better way to express the same
intent as SFINAE than SFINAE, but I prefer having to do SFINAE over having
TS concepts because of how TS concepts being merged into the standard
impact future development of related features.
> And yes, if you
> have something
> to say about concepts, you should say it in a paper.
>
Yes, probably.
>
> >> > There are no papers that I've written, mostly because it's only now
> that
> >> > I'm
> >> > really starting to be involved in the process; but as far as I'm
> >> > concerned,
> >> > there's been numerous papers describing how they are terrible (and n=
o,
> >> > I'm
> >> > not going to enumerate them here, because I find it to be a great
> waste
> >> > of
> >> > time to point the EWG chair to EWG papers).
> >> I am aware of current papers that propose changes to Concepts, but non=
e
> of
> >> those
> >> papers describe Concepts as terrible in the sense that you seem to do.
> > Sure. Maybe not in the same sense, but there's a clear consensus about =
a
> > lack of consensus, and I personally know quite a few committee members
> who
> > mostly share my opinion on this.
>
> So what are the papers describing how Concepts are terrible, since you sa=
id
> there are numerous such papers, and I should know what they are?
>
I've overstated this; I'm sorry. For some reason I was under an impression
there's been more papers in the previous years. *My bad.*
>
> >> > And what I like or not is something you should at least acknowledge,
> >> > because
> >> > there's a non-zero chance of a new National Body popping into
> existence
> >> > in
> >> > WG21 due to my involvement within a timeframe of several months.
> >> That's interesting, hopefully that NB has the ability to send experts
> >> who can actually
> >> explain their views and can think and participate rationally.
> > This is bordering on being inappropriate due to its intent, but I agree
> with
>
> Sounds like a very liberal interpretation to me.
>
> > the letter (and not the spirit) - I'm more than capable to explain my
> views,
> > and I have done that earlier in this thread (and to an extend in the ta=
lk
> > that's been linked earlier in this thread). If you want me to explain m=
y
> > views verbally (since that'll be easier than throwing emails at each
> other),
> > and you're willing to listen and discuss arguments, then I'll be more
> than
> > happy to discuss this with you in Toronto, should you find some time fo=
r
> it.
>
> I have no use for verbal explanations, std-proposals threads, or
> talks. What I have
> use for is papers directed at WG21. There can barely be sane
> discussion on anything
> if the responses to proposals are only ever provided in non-paper form.
>
I'm not making a proposal here, I was discussing some ideas and opinions
about features with other people on this list (and not *you* in
particular). Then you came in and demanded that I explain what I've
explained earlier. If I wanted to have a discussion specifically with you
and EWG, I would've written a paper. As it is, I was merely having a
discussion.
Does the EWG chair think that discussions of proposed features that are to
be discussed at the next meeting on std-proposals should be banned? (Yes,
this is an intentional strawman.)
*Bottom line is*, you're right - I don't have a paper for this meeting.
Depending on how the meeting goes and what WG21 decides to do w.r.t. your
paper-to-be-a-core-motion of putting the TS into the working paper, I might
or might not produce a paper on this topic. Whether I do or do not produce
a paper is not, however, going to stop me from discussing this in
discussions that touch this topic.
>
> --
> 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/CAFk2RUZZrit=
z2SV3jQTJDJrREKVxEbKAKiQVjpth1RYBO2c_Ow%40mail.gmail.com
> .
>
--=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/CAPCFJdSTCQx3%3DyGAJTVaeB1pgrW3v4nLTVxDqVjdM%3Du=
pZWaUgw%40mail.gmail.com.
--94eb2c08aebc43cd63055304e331
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jun 28=
, 2017 at 2:51 PM Ville Voutilainen <<a href=3D"mailto:ville.voutilainen=
@gmail.com">ville.voutilainen@gmail.com</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On 28 June 2017 at 15:35, Micha=C5=82 Dominiak <<a h=
ref=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>&=
gt; wrote:<br>
>> Gee, we must disagree on what is or is not emotional. It sure seem=
s to<br>
>> me that your describing Concepts<br>
>> as terrible, and deeming SFINAE a better choice, is nothing short =
of<br>
>> emotional.<br>
> I described what I think we need in detail in this thread. I also desc=
ribed<br>
> in detail how TS concepts relate to what I think we need, and what are=
their<br>
> shortcomings, IMHO. If you had read this thread, you'd've noti=
ced.<br>
<br>
If you want to change how Concepts work, describing it on this thread<br>
does precisely<br>
nothing to achieve that goal.<br>
<br>
> There's not a single place where I said SFINAE is a better; there&=
#39;s only a<br>
> place where I say that SFINAE works and can be made not as terrible fo=
r a<br>
> general population of C++ programmers with macros; and a separate opin=
ion<br>
> that I gave is that releasing a standard with TS concepts would hurt t=
he<br>
> language. For reasons that I and others have described. What else do y=
ou<br>
> want me to do, short of writing a paper? How is actually explaining my=
<br>
> technical problems with a feature in any way emotional?<br>
<br>
Pardon me for misunderstanding "But I, for one, prefer no feature over=
<br>
bad feature, and I<br>
much prefer writing sfinae over doing TS concepts". </blockquote><div>=
<br></div><div>"I prefer doing X over Y" states preference, not w=
hether I claim X is better than Y. TS concepts are indeed a better way to e=
xpress the same intent as SFINAE than SFINAE, but I prefer having to do SFI=
NAE over having TS concepts because of how TS concepts being merged into th=
e standard impact future development of related features.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">And yes, if you<br>
have something<br>
to say about concepts, you should say it in a paper.<br></blockquote><div><=
br></div><div>Yes, probably.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<br>
>> > There are no papers that I've written, mostly because it&=
#39;s only now that<br>
>> > I'm<br>
>> > really starting to be involved in the process; but as far as =
I'm<br>
>> > concerned,<br>
>> > there's been numerous papers describing how they are terr=
ible (and no,<br>
>> > I'm<br>
>> > not going to enumerate them here, because I find it to be a g=
reat waste<br>
>> > of<br>
>> > time to point the EWG chair to EWG papers).<br>
>> I am aware of current papers that propose changes to Concepts, but=
none of<br>
>> those<br>
>> papers describe Concepts as terrible in the sense that you seem to=
do.<br>
> Sure. Maybe not in the same sense, but there's a clear consensus a=
bout a<br>
> lack of consensus, and I personally know quite a few committee members=
who<br>
> mostly share my opinion on this.<br>
<br>
So what are the papers describing how Concepts are terrible, since you said=
<br>
there are numerous such papers, and I should know what they are?<br></block=
quote><div><br></div><div>I've overstated this; I'm sorry. For some=
reason I was under an impression there's been more papers in the previ=
ous years. <b>My bad.</b></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<br>
>> > And what I like or not is something you should at least ackno=
wledge,<br>
>> > because<br>
>> > there's a non-zero chance of a new National Body popping =
into existence<br>
>> > in<br>
>> > WG21 due to my involvement within a timeframe of several mont=
hs.<br>
>> That's interesting, hopefully that NB has the ability to send =
experts<br>
>> who can actually<br>
>> explain their views and can think and participate rationally.<br>
> This is bordering on being inappropriate due to its intent, but I agre=
e with<br>
<br>
Sounds like a very liberal interpretation to me.<br>
<br>
> the letter (and not the spirit) - I'm more than capable to explain=
my views,<br>
> and I have done that earlier in this thread (and to an extend in the t=
alk<br>
> that's been linked earlier in this thread). If you want me to expl=
ain my<br>
> views verbally (since that'll be easier than throwing emails at ea=
ch other),<br>
> and you're willing to listen and discuss arguments, then I'll =
be more than<br>
> happy to discuss this with you in Toronto, should you find some time f=
or it.<br>
<br>
I have no use for verbal explanations, std-proposals threads, or<br>
talks. What I have<br>
use for is papers directed at WG21. There can barely be sane<br>
discussion on anything<br>
if the responses to proposals are only ever provided in non-paper form.<br>=
</blockquote><div><br></div><div>I'm not making a proposal here, I was =
discussing some ideas and opinions about features with other people on this=
list (and not <i>you</i>=C2=A0in particular). Then you came in and demande=
d that I explain what I've explained earlier. If I wanted to have a dis=
cussion specifically with you and EWG, I would've written a paper. As i=
t is, I was merely having a discussion.</div><div><br></div><div>Does the E=
WG chair think that discussions of proposed features that are to be discuss=
ed at the next meeting on std-proposals should be banned? (Yes, this is an =
intentional strawman.)</div><div><br></div><div><b>Bottom line is</b>, you&=
#39;re right - I don't have a paper for this meeting. Depending on how =
the meeting goes and what WG21 decides to do w.r.t. your paper-to-be-a-core=
-motion of putting the TS into the working paper, I might or might not prod=
uce a paper on this topic. Whether I do or do not produce a paper is not, h=
owever, going to stop me from discussing this in discussions that touch thi=
s topic.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/CAFk2RUZZritz2SV3jQTJDJrREKVxEbKAKiQV=
jpth1RYBO2c_Ow%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZZritz2SV3jQ=
TJDJrREKVxEbKAKiQVjpth1RYBO2c_Ow%40mail.gmail.com</a>.<br>
</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/CAPCFJdSTCQx3%3DyGAJTVaeB1pgrW3v4nLTV=
xDqVjdM%3DupZWaUgw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdSTCQx3=
%3DyGAJTVaeB1pgrW3v4nLTVxDqVjdM%3DupZWaUgw%40mail.gmail.com</a>.<br />
--94eb2c08aebc43cd63055304e331--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Jun 2017 16:20:27 +0300
Raw View
On 28 June 2017 at 16:08, Micha=C5=82 Dominiak <griwes@griwes.info> wrote:
>> I have no use for verbal explanations, std-proposals threads, or
>> talks. What I have
>> use for is papers directed at WG21. There can barely be sane
>> discussion on anything
>> if the responses to proposals are only ever provided in non-paper form.
> I'm not making a proposal here, I was discussing some ideas and opinions
> about features with other people on this list (and not you in particular)=
..
> Then you came in and demanded that I explain what I've explained earlier.=
If
> I wanted to have a discussion specifically with you and EWG, I would've
> written a paper. As it is, I was merely having a discussion.
I didn't suggest you're making a proposal, but you seem to have strong opin=
ions
about Concepts as proposed, and apparently a strong preference that somethi=
ng
significantly different should be standardized instead. If you think
that should be
known by the committee and/or the authors of the Concepts proposal, I doubt
you'll reach either of those parties here.
> Does the EWG chair think that discussions of proposed features that are t=
o
> be discussed at the next meeting on std-proposals should be banned? (Yes,
> this is an intentional strawman.)
The EWG chair doesn't care. He also signs his emails when he wants to
emphasize that he's speaking as the EWG chair. See below.
> Bottom line is, you're right - I don't have a paper for this meeting.
> Depending on how the meeting goes and what WG21 decides to do w.r.t. your
> paper-to-be-a-core-motion of putting the TS into the working paper, I mig=
ht
> or might not produce a paper on this topic. Whether I do or do not produc=
e a
> paper is not, however, going to stop me from discussing this in discussio=
ns
> that touch this topic.
That's fine, but I recommend avoiding being disappointed if you have
very strong views
and concerns on Concepts or any proposal going on in the committee,
and the committee fails to address
your concerns because it has never heard of them.
--=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/CAFk2RUYJwir2uPkxcOAVKPgbW5ey5apMCRfSk98hWD7%2BC=
jctSQ%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 28 Jun 2017 06:21:12 -0700 (PDT)
Raw View
------=_Part_2873_1319688343.1498656073001
Content-Type: multipart/alternative;
boundary="----=_Part_2874_1088804928.1498656073001"
------=_Part_2874_1088804928.1498656073001
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, June 28, 2017 at 9:09:04 AM UTC-4, Micha=C5=82 Dominiak wrote=
:
>
> Depending on how the meeting goes and what WG21 decides to do w.r.t. your=
=20
> paper-to-be-a-core-motion of putting the TS into the working paper, I mig=
ht=20
> or might not produce a paper on this topic.
>
FYI: you may want to look at the date on the paper he linked to. It was=20
from early 2016, and its purpose was to get the committee to adopt Concepts=
=20
TS into C++17. It's right there in the abstract.
Since Concepts TS did not go into C++17, you can assume that the paper's=20
goal did not achieve consensus.
Similarly, Gabriel Dos Reis's paper P0606 from early 2017 to blanket adopt=
=20
Concepts TS as is didn't seem to fly either, since the committee is still=
=20
debating and considering changes to Concepts.
Now, you should not take that to mean that the committee is going to be=20
willing to consider a page-1 rewrite of concepts the way you want.
--=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/b0b34c4f-cc6a-4680-a957-51cf01308d0f%40isocpp.or=
g.
------=_Part_2874_1088804928.1498656073001
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, June 28, 2017 at 9:09:04 AM UTC-4, Micha=C5=
=82 Dominiak wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div class=3D"gmail_quote"></div></div></blockquote><div></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail=
_quote"><div>Depending on how the meeting goes and what WG21 decides to do =
w.r.t. your paper-to-be-a-core-motion of putting the TS into the working pa=
per, I might or might not produce a paper on this topic.</div></div></div><=
/blockquote><div><br>FYI: you may want to look at the date on the paper he =
linked to. It was from early 2016, and its purpose was to get the committee=
to adopt Concepts TS into C++17. It's right there in the abstract.<br>=
<br>Since Concepts TS did not go into C++17, you can assume that the paper&=
#39;s goal did not achieve consensus.<br><br>Similarly, Gabriel Dos Reis=
9;s paper P0606 from early 2017 to blanket adopt Concepts TS as is didn'=
;t seem to fly either, since the committee is still debating and considerin=
g changes to Concepts.</div><br>Now, you should not take that to mean that =
the committee is going to be willing to consider a page-1 rewrite of concep=
ts the way you want.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b0b34c4f-cc6a-4680-a957-51cf01308d0f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b0b34c4f-cc6a-4680-a957-51cf01308d0f=
%40isocpp.org</a>.<br />
------=_Part_2874_1088804928.1498656073001--
------=_Part_2873_1319688343.1498656073001--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 28 Jun 2017 13:26:32 +0000
Raw View
--001a114f8eca909fbd055305228b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 28, 2017 at 3:21 PM Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, June 28, 2017 at 9:09:04 AM UTC-4, Micha=C5=82 Dominiak wro=
te:
>>
>> Depending on how the meeting goes and what WG21 decides to do w.r.t. you=
r
>> paper-to-be-a-core-motion of putting the TS into the working paper, I mi=
ght
>> or might not produce a paper on this topic.
>>
>
> FYI: you may want to look at the date on the paper he linked to. It was
> from early 2016, and its purpose was to get the committee to adopt Concep=
ts
> TS into C++17. It's right there in the abstract.
>
The paper I referred to is a late paper for Toronto, that I assume will
become public in the post-meeting mailing.
>
> Since Concepts TS did not go into C++17, you can assume that the paper's
> goal did not achieve consensus.
>
> Similarly, Gabriel Dos Reis's paper P0606 from early 2017 to blanket adop=
t
> Concepts TS as is didn't seem to fly either, since the committee is still
> debating and considering changes to Concepts.
>
> Now, you should not take that to mean that the committee is going to be
> willing to consider a page-1 rewrite of concepts the way you want.
>
> --
> 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/b0b34c4f-cc6=
a-4680-a957-51cf01308d0f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b0b34c4f-cc=
6a-4680-a957-51cf01308d0f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAPCFJdQ7666cg5OvhYnFA0-PsjF_jX%3DuyTRZnoEiSoH64=
oi2%3DA%40mail.gmail.com.
--001a114f8eca909fbd055305228b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jun 28=
, 2017 at 3:21 PM Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com">jm=
ckesson@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">On Wednesday, June 28, 2017 at 9:09:04 AM UTC-4, Micha=C5=82=
Dominiak 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"><d=
iv class=3D"gmail_quote"></div></div></blockquote><div></div><blockquote cl=
ass=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 class=3D"gmail_quote"><div>=
Depending on how the meeting goes and what WG21 decides to do w.r.t. your p=
aper-to-be-a-core-motion of putting the TS into the working paper, I might =
or might not produce a paper on this topic.</div></div></div></blockquote><=
/div><div dir=3D"ltr"><div><br>FYI: you may want to look at the date on the=
paper he linked to. It was from early 2016, and its purpose was to get the=
committee to adopt Concepts TS into C++17. It's right there in the abs=
tract.<br></div></div></blockquote><div><br></div><div>The paper I referred=
to is a late paper for Toronto, that I assume will become public in the po=
st-meeting mailing.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><br>Since Concepts TS did not go into C++17, you can as=
sume that the paper's goal did not achieve consensus.<br><br>Similarly,=
Gabriel Dos Reis's paper P0606 from early 2017 to blanket adopt Concep=
ts TS as is didn't seem to fly either, since the committee is still deb=
ating and considering changes to Concepts.</div><br>Now, you should not tak=
e that to mean that the committee is going to be willing to consider a page=
-1 rewrite of concepts the way you want.<br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/b0b34c4f-cc6a-4680-a957-51cf01308d0f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b0b34c4f-cc6a-=
4680-a957-51cf01308d0f%40isocpp.org</a>.<br>
</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/CAPCFJdQ7666cg5OvhYnFA0-PsjF_jX%3DuyT=
RZnoEiSoH64oi2%3DA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQ7666c=
g5OvhYnFA0-PsjF_jX%3DuyTRZnoEiSoH64oi2%3DA%40mail.gmail.com</a>.<br />
--001a114f8eca909fbd055305228b--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 28 Jun 2017 13:31:31 +0000
Raw View
--001a114ad32a62197c0553053438
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 28, 2017 at 3:20 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 28 June 2017 at 16:08, Micha=C5=82 Dominiak <griwes@griwes.info> wrote=
:
> >> I have no use for verbal explanations, std-proposals threads, or
> >> talks. What I have
> >> use for is papers directed at WG21. There can barely be sane
> >> discussion on anything
> >> if the responses to proposals are only ever provided in non-paper form=
..
> > I'm not making a proposal here, I was discussing some ideas and opinion=
s
> > about features with other people on this list (and not you in
> particular).
> > Then you came in and demanded that I explain what I've explained
> earlier. If
> > I wanted to have a discussion specifically with you and EWG, I would've
> > written a paper. As it is, I was merely having a discussion.
>
> I didn't suggest you're making a proposal, but you seem to have strong
> opinions
> about Concepts as proposed, and apparently a strong preference that
> something
> significantly different should be standardized instead. If you think
> that should be
> known by the committee and/or the authors of the Concepts proposal, I dou=
bt
> you'll reach either of those parties here.
>
I doubt I'll really reach the authors of the proposal even when I do write
a paper, but that's a different issue... :P As I said, right now I'm
primarily interested in what the voting part of the committee does in
Toronto; I'll treat that as a direction of whether anyone might actually
listen. If it appears that there's a sufficient consensus to put the TS
into the WP, I'll probably write a different paper that I would've written
if no such sufficient consensus is reached.
>
> > Does the EWG chair think that discussions of proposed features that are
> to
> > be discussed at the next meeting on std-proposals should be banned? (Ye=
s,
> > this is an intentional strawman.)
>
> The EWG chair doesn't care. He also signs his emails when he wants to
> emphasize that he's speaking as the EWG chair. See below.
>
> > Bottom line is, you're right - I don't have a paper for this meeting.
> > Depending on how the meeting goes and what WG21 decides to do w.r.t. yo=
ur
> > paper-to-be-a-core-motion of putting the TS into the working paper, I
> might
> > or might not produce a paper on this topic. Whether I do or do not
> produce a
> > paper is not, however, going to stop me from discussing this in
> discussions
> > that touch this topic.
>
> That's fine, but I recommend avoiding being disappointed if you have
> very strong views
> and concerns on Concepts or any proposal going on in the committee,
> and the committee fails to address
> your concerns because it has never heard of them.
>
Those concerns are probably going to be raised at the meeting in one form
or another. I have strong views on this, but I recognize that the process
is a democratic one and I won't fall into black despair if the committee
decides to follow p0724r0.
>
> --
> 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/CAFk2RUYJwir=
2uPkxcOAVKPgbW5ey5apMCRfSk98hWD7%2BCjctSQ%40mail.gmail.com
> .
>
--=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/CAPCFJdTcLemkZc0oyqBM%3DnFXK73KM_g58a%3DMQUd8rwx=
snybKyA%40mail.gmail.com.
--001a114ad32a62197c0553053438
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jun 28=
, 2017 at 3:20 PM Ville Voutilainen <<a href=3D"mailto:ville.voutilainen=
@gmail.com">ville.voutilainen@gmail.com</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On 28 June 2017 at 16:08, Micha=C5=82 Dominiak <<a h=
ref=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>&=
gt; wrote:<br>
>> I have no use for verbal explanations, std-proposals threads, or<b=
r>
>> talks. What I have<br>
>> use for is papers directed at WG21. There can barely be sane<br>
>> discussion on anything<br>
>> if the responses to proposals are only ever provided in non-paper =
form.<br>
> I'm not making a proposal here, I was discussing some ideas and op=
inions<br>
> about features with other people on this list (and not you in particul=
ar).<br>
> Then you came in and demanded that I explain what I've explained e=
arlier. If<br>
> I wanted to have a discussion specifically with you and EWG, I would&#=
39;ve<br>
> written a paper. As it is, I was merely having a discussion.<br>
<br>
I didn't suggest you're making a proposal, but you seem to have str=
ong opinions<br>
about Concepts as proposed, and apparently a strong preference that somethi=
ng<br>
significantly different should be standardized instead. If you think<br>
that should be<br>
known by the committee and/or the authors of the Concepts proposal, I doubt=
<br>
you'll reach either of those parties here.<br></blockquote><div><br></d=
iv><div>I doubt I'll really reach the authors of the proposal even when=
I do write a paper, but that's a different issue... :P As I said, righ=
t now I'm primarily interested in what the voting part of the committee=
does in Toronto; I'll treat that as a direction of whether anyone migh=
t actually listen. If it appears that there's a sufficient consensus to=
put the TS into the WP, I'll probably write a different paper that I w=
ould've written if no such sufficient consensus is reached.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<br>
> Does the EWG chair think that discussions of proposed features that ar=
e to<br>
> be discussed at the next meeting on std-proposals should be banned? (Y=
es,<br>
> this is an intentional strawman.)<br>
<br>
The EWG chair doesn't care. He also signs his emails when he wants to<b=
r>
emphasize that he's speaking as the EWG chair. See below.<br>
<br>
> Bottom line is, you're right - I don't have a paper for this m=
eeting.<br>
> Depending on how the meeting goes and what WG21 decides to do w.r.t. y=
our<br>
> paper-to-be-a-core-motion of putting the TS into the working paper, I =
might<br>
> or might not produce a paper on this topic. Whether I do or do not pro=
duce a<br>
> paper is not, however, going to stop me from discussing this in discus=
sions<br>
> that touch this topic.<br>
<br>
That's fine, but I recommend avoiding being disappointed if you have<br=
>
very strong views<br>
and concerns on Concepts or any proposal going on in the committee,<br>
and the committee fails to address<br>
your concerns because it has never heard of them.<br></blockquote><div><br>=
</div><div>Those concerns are probably going to be raised at the meeting in=
one form or another. I have strong views on this, but I recognize that the=
process is a democratic one and I won't fall into black despair if the=
committee decides to follow=C2=A0p0724r0.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<br>
--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/CAFk2RUYJwir2uPkxcOAVKPgbW5ey5apMCRfS=
k98hWD7%2BCjctSQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYJwir2uPkx=
cOAVKPgbW5ey5apMCRfSk98hWD7%2BCjctSQ%40mail.gmail.com</a>.<br>
</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/CAPCFJdTcLemkZc0oyqBM%3DnFXK73KM_g58a=
%3DMQUd8rwxsnybKyA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTcLemk=
Zc0oyqBM%3DnFXK73KM_g58a%3DMQUd8rwxsnybKyA%40mail.gmail.com</a>.<br />
--001a114ad32a62197c0553053438--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Jun 2017 16:35:12 +0300
Raw View
On 28 June 2017 at 16:31, Micha=C5=82 Dominiak <griwes@griwes.info> wrote:
> Those concerns are probably going to be raised at the meeting in one form=
or
> another. I have strong views on this, but I recognize that the process is=
a
> democratic one and I won't fall into black despair if the committee decid=
es
> to follow p0724r0.
Well, it's not quite democratic, it's very representational in the
sense that voting
members must be ISO voting members, and to be that, they must be NB members
as well. ;)
--=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/CAFk2RUYaW6kNmo1u-KEUskK2HGr-4wQhtD8bCiQ7VjcA4tb=
o9g%40mail.gmail.com.
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 28 Jun 2017 13:38:07 +0000
Raw View
--001a114f8ecaf631a80553054b2b
Content-Type: text/plain; charset="UTF-8"
On Wed, Jun 28, 2017 at 3:35 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> Well, it's not quite democratic, it's very representational in the
> sense that voting
> members must be ISO voting members, and to be that, they must be NB members
as well. ;)
It's approximately democratic in that there's voting taking place :P
> --
> 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/CAFk2RUYaW6kNmo1u-KEUskK2HGr-4wQhtD8bCiQ7VjcA4tbo9g%40mail.gmail.com
> .
>
--
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/CAPCFJdR3K3cH0cmkm9c12TVbQ7NP7wS-nBe-V1vwezKXXn_N5g%40mail.gmail.com.
--001a114f8ecaf631a80553054b2b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jun 28=
, 2017 at 3:35 PM Ville Voutilainen <<a href=3D"mailto:ville.voutilainen=
@gmail.com">ville.voutilainen@gmail.com</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">Well, it's not quite democratic, it's very repr=
esentational in the<br>
sense that voting<br>
members must be ISO voting members, and to be that, they must be NB members=
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">as well. ;)=C2=A0</blockquote><=
div><br></div><div>It's approximately democratic in that there's vo=
ting taking place :P</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/CAFk2RUYaW6kNmo1u-KEUskK2HGr-4wQhtD8b=
CiQ7VjcA4tbo9g%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYaW6kNmo1u-K=
EUskK2HGr-4wQhtD8bCiQ7VjcA4tbo9g%40mail.gmail.com</a>.<br>
</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/CAPCFJdR3K3cH0cmkm9c12TVbQ7NP7wS-nBe-=
V1vwezKXXn_N5g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdR3K3cH0cmk=
m9c12TVbQ7NP7wS-nBe-V1vwezKXXn_N5g%40mail.gmail.com</a>.<br />
--001a114f8ecaf631a80553054b2b--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Jun 2017 16:38:31 +0300
Raw View
On 28 June 2017 at 16:35, Ville Voutilainen <ville.voutilainen@gmail.com> w=
rote:
> On 28 June 2017 at 16:31, Micha=C5=82 Dominiak <griwes@griwes.info> wrote=
:
>> Those concerns are probably going to be raised at the meeting in one for=
m or
>> another. I have strong views on this, but I recognize that the process i=
s a
>> democratic one and I won't fall into black despair if the committee deci=
des
>> to follow p0724r0.
>
>
> Well, it's not quite democratic, it's very representational in the
> sense that voting
> members must be ISO voting members, and to be that, they must be NB membe=
rs
> as well. ;)
Also, p0724r0 (which, since Jason asked about it, can also be found here:
https://isocpp.org/files/papers/p0724r0.html) is merely suggesting an
as-is merge
to get Concepts one step forward, but it's not suggesting that they be
standardized
as is. I do understand that making the currently-proposed fixes to it
might still not be good
enough for you.
--=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/CAFk2RUb6%2Bg7DDt1dN3L-KGDxT5Yc4MG0JiOZ%2BOof7tF=
ZdDJh8g%40mail.gmail.com.
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 28 Jun 2017 13:40:37 +0000
Raw View
--94eb2c09340ee6afb305530554ab
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 28, 2017 at 3:38 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 28 June 2017 at 16:35, Ville Voutilainen <ville.voutilainen@gmail.com>
> wrote:
> > On 28 June 2017 at 16:31, Micha=C5=82 Dominiak <griwes@griwes.info> wro=
te:
> >> Those concerns are probably going to be raised at the meeting in one
> form or
> >> another. I have strong views on this, but I recognize that the process
> is a
> >> democratic one and I won't fall into black despair if the committee
> decides
> >> to follow p0724r0.
> >
> >
> > Well, it's not quite democratic, it's very representational in the
> > sense that voting
> > members must be ISO voting members, and to be that, they must be NB
> members
> > as well. ;)
>
> Also, p0724r0 (which, since Jason asked about it, can also be found here:
> https://isocpp.org/files/papers/p0724r0.html) is merely suggesting an
> as-is merge
> to get Concepts one step forward, but it's not suggesting that they be
> standardized
> as is. I do understand that making the currently-proposed fixes to it
> might still not be good
> enough for you.
>
Oh, good to know it's also publicly available. Yes, I understand that; and
yes, while iterating over the TS concepts within the standard WP can make
me dislike them less, it's probably not going to make me like them :)
>
> --
> 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/CAFk2RUb6%2B=
g7DDt1dN3L-KGDxT5Yc4MG0JiOZ%2BOof7tFZdDJh8g%40mail.gmail.com
> .
>
--=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/CAPCFJdS3ybt17Gs5E55LDy_DRiDRJGT9SWac3u70d1frVoe=
-aw%40mail.gmail.com.
--94eb2c09340ee6afb305530554ab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jun 28=
, 2017 at 3:38 PM Ville Voutilainen <<a href=3D"mailto:ville.voutilainen=
@gmail.com">ville.voutilainen@gmail.com</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On 28 June 2017 at 16:35, Ville Voutilainen <<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>> wrote:<br>
> On 28 June 2017 at 16:31, Micha=C5=82 Dominiak <<a href=3D"mailto:g=
riwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>> wrote:<br>
>> Those concerns are probably going to be raised at the meeting in o=
ne form or<br>
>> another. I have strong views on this, but I recognize that the pro=
cess is a<br>
>> democratic one and I won't fall into black despair if the comm=
ittee decides<br>
>> to follow p0724r0.<br>
><br>
><br>
> Well, it's not quite democratic, it's very representational in=
the<br>
> sense that voting<br>
> members must be ISO voting members, and to be that, they must be NB me=
mbers<br>
> as well. ;)<br>
<br>
Also, p0724r0 (which, since Jason asked about it, can also be found here:<b=
r>
<a href=3D"https://isocpp.org/files/papers/p0724r0.html" rel=3D"noreferrer"=
target=3D"_blank">https://isocpp.org/files/papers/p0724r0.html</a>) is mer=
ely suggesting an<br>
as-is merge<br>
to get Concepts one step forward, but it's not suggesting that they be<=
br>
standardized<br>
as is. I do understand that making the currently-proposed fixes to it<br>
might still not be good<br>
enough for you.<br></blockquote><div><br></div><div>Oh, good to know it'=
;s also publicly available. Yes, I understand that; and yes, while iteratin=
g over the TS concepts within the standard WP can make me dislike them less=
, it's probably not going to make me like them :)</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<br>
--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/CAFk2RUb6%2Bg7DDt1dN3L-KGDxT5Yc4MG0Ji=
OZ%2BOof7tFZdDJh8g%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb6%2Bg7D=
Dt1dN3L-KGDxT5Yc4MG0JiOZ%2BOof7tFZdDJh8g%40mail.gmail.com</a>.<br>
</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/CAPCFJdS3ybt17Gs5E55LDy_DRiDRJGT9SWac=
3u70d1frVoe-aw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdS3ybt17Gs5=
E55LDy_DRiDRJGT9SWac3u70d1frVoe-aw%40mail.gmail.com</a>.<br />
--94eb2c09340ee6afb305530554ab--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Wed, 28 Jun 2017 12:07:33 -0400
Raw View
--001a1147f2e2030e0a0553076312
Content-Type: text/plain; charset="UTF-8"
On Wed, Jun 28, 2017 at 7:22 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> I have no illusion of your reading this paper, but perhaps it will show to
> some others why SFINAE is laughably inferior:
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0225r0.html
p0225r0 says:
*In contrast, with Concepts, here's what this too-clever programmer will
write: template <class T> void f(T) requires requires (T t) {t.f();};
template <class T> void f(T);The overloads are mutually exclusive, and
everything is fine.*
I would dispute that a syntax that requires requires requires is fine.
--
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/CAHSYqdZKd0hMRzGrWASnasBj%2B1unCDq%3Df1EBhvBJsb1kDN7Ekg%40mail.gmail.com.
--001a1147f2e2030e0a0553076312
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jun 28, 2017 at 7:22 AM, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">I have no illusion of your reading this paper, but perhaps it will =
show to some others why SFINAE is laughably inferior:<br>
<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0225r0.html=
" rel=3D"noreferrer" target=3D"_blank">http://open-std.org/JTC1/SC22/<wbr>W=
G21/docs/papers/2016/p0225r0.<wbr>html</a></blockquote><div>=C2=A0</div><di=
v>p0225r0 says:<br><a name=3D"Overloading"><p><i><font color=3D"#000000" fa=
ce=3D"Times New Roman" size=3D"3">I</font>n contrast, with Concepts, here&#=
39;s what this too-clever programmer will write:<br><font face=3D"monospace=
, monospace">=C2=A0 =C2=A0 =C2=A0 template <class T> void f(T) requir=
es requires (T t) {t.f();};<br>=C2=A0 =C2=A0 =C2=A0 template <class T>=
; void f(T);</font><br>The overloads are mutually exclusive, and everything=
is fine.<br></i><br>I would dispute that a syntax that requires requires r=
equires is fine.</p></a></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/CAHSYqdZKd0hMRzGrWASnasBj%2B1unCDq%3D=
f1EBhvBJsb1kDN7Ekg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZKd0hM=
RzGrWASnasBj%2B1unCDq%3Df1EBhvBJsb1kDN7Ekg%40mail.gmail.com</a>.<br />
--001a1147f2e2030e0a0553076312--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Jun 2017 19:22:40 +0300
Raw View
On 28 June 2017 at 19:07, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Wed, Jun 28, 2017 at 7:22 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>> I have no illusion of your reading this paper, but perhaps it will show to
>> some others why SFINAE is laughably inferior:
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0225r0.html
>
>
> p0225r0 says:
>
> In contrast, with Concepts, here's what this too-clever programmer will
> write:
> template <class T> void f(T) requires requires (T t) {t.f();};
> template <class T> void f(T);
> The overloads are mutually exclusive, and everything is fine.
>
> I would dispute that a syntax that requires requires requires is fine.
Maybe, but that still beats the current language, which cannot be used
to write that overload
set without out-of-band trait definitions.
--
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/CAFk2RUZ13A8BgW1z4_VOTgFQJF8p6dUvx1Rx9d0ur4KJtMK5BQ%40mail.gmail.com.
.
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Sat, 1 Jul 2017 21:14:25 -0400
Raw View
--Apple-Mail=_F95020EA-BC59-4B52-B6B7-9BC0E586ABA8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Dear Jakob,=20
Somebody you might want to discuss the opinion you=E2=80=99ve been try=
ing get across in this thread with would be Alisdair Meredith. Having just=
recently watched his C++Now 2017 talk =E2=80=98C++20 Language Features for=
a New Library <https://www.youtube.com/watch?v=3DhizGxfDdc7M&index=3D13&li=
st=3DPL_AKIMJc4roXJldxjJGtH8PJb4dY6nN1D>,=E2=80=99 I can remark that he sta=
tes thoughts along the same lines as yours when transitioning from discussi=
ng concepts to discussing contracts (I=E2=80=99d give you a link to the exa=
ct point in time during his presentation where he does so, but I can=E2=80=
=99t exactly recall it at the moment; sorry about that.) =20
Hope that helps anyway,=20
Bryce Glover
RandomDSdevel@gmail.com
--=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/994E4487-3406-41CF-9B17-6010648256DE%40gmail.com=
..
--Apple-Mail=_F95020EA-BC59-4B52-B6B7-9BC0E586ABA8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">De=
ar Jakob, </div><div class=3D""><br class=3D""></div><div class=3D"">&=
nbsp; Somebody you might want to discuss the opinion you=E2=80=
=99ve been trying get across in this thread with would be Alisdair Meredith=
.. Having just recently watched his C++Now 2017 talk =E2=80=98<a href=
=3D"https://www.youtube.com/watch?v=3DhizGxfDdc7M&index=3D13&list=
=3DPL_AKIMJc4roXJldxjJGtH8PJb4dY6nN1D" class=3D"">C++20 Language Features f=
or a New Library</a>,=E2=80=99 I can remark that he states thoughts along t=
he same lines as yours when transitioning from discussing concepts to discu=
ssing contracts (I=E2=80=99d give you a link to the exact point in time dur=
ing his presentation where he does so, but I can=E2=80=99t exactly recall i=
t at the moment; sorry about that.) </div><br class=3D""><div class=
=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-w=
rap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-=
space;" class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-=
break: after-white-space;" class=3D""><div style=3D"color: rgb(0, 0, 0); le=
tter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; t=
ext-transform: none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">Ho=
pe that helps anyway, </div><div class=3D""> Bryce =
Glover</div><div class=3D""> <a href=3D"mailto:RandomDSd=
evel@gmail.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div></d=
iv></div></body></html>
<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/994E4487-3406-41CF-9B17-6010648256DE%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/994E4487-3406-41CF-9B17-6010648256DE%=
40gmail.com</a>.<br />
--Apple-Mail=_F95020EA-BC59-4B52-B6B7-9BC0E586ABA8--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Sat, 1 Jul 2017 23:22:05 -0700 (PDT)
Raw View
------=_Part_1137_1697606162.1498976525422
Content-Type: multipart/alternative;
boundary="----=_Part_1138_2126830778.1498976525422"
------=_Part_1138_2126830778.1498976525422
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Bryce!
nice to know that! I will get in touch with him. Thank you!
If you don't happen to find the spot, I'll watch the whole Presentation,=20
don't worry.
Cheers,
Jakob
PS: A Proposal is already started :)
Am Sonntag, 2. Juli 2017 03:14:29 UTC+2 schrieb Bryce Glover:
>
> Dear Jakob,=20
>
> Somebody you might want to discuss the opinion you=E2=80=99ve been t=
rying get=20
> across in this thread with would be Alisdair Meredith. Having just=20
> recently watched his C++Now 2017 talk =E2=80=98C++20 Language Features fo=
r a New=20
> Library=20
> <https://www.youtube.com/watch?v=3DhizGxfDdc7M&index=3D13&list=3DPL_AKIMJ=
c4roXJldxjJGtH8PJb4dY6nN1D>,=E2=80=99=20
> I can remark that he states thoughts along the same lines as yours when=
=20
> transitioning from discussing concepts to discussing contracts (I=E2=80=
=99d give=20
> you a link to the exact point in time during his presentation where he do=
es=20
> so, but I can=E2=80=99t exactly recall it at the moment; sorry about that=
..) =20
>
> Hope that helps anyway,=20
> Bryce Glover
> Random...@gmail.com <javascript:>
>
--=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/a2c8224b-1a6d-40d3-aee2-1bb9943b0610%40isocpp.or=
g.
------=_Part_1138_2126830778.1498976525422
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Bryce!<div><br></div><div>nice to know that! I will get=
in touch with him. Thank you!</div><div>If you don't happen to find th=
e spot, I'll watch the whole Presentation, don't worry.</div><div><=
br></div><div>Cheers,</div><div>Jakob</div><div><br></div><div>PS: A Propos=
al is already started :)</div><div><br>Am Sonntag, 2. Juli 2017 03:14:29 UT=
C+2 schrieb Bryce Glover:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
style=3D"word-wrap:break-word"><div>Dear Jakob,=C2=A0</div><div><br></div><=
div>=C2=A0 =C2=A0 =C2=A0Somebody you might want to discuss the opinion you=
=E2=80=99ve been trying get across in this thread with would be Alisdair Me=
redith. =C2=A0Having just recently watched his C++Now 2017 talk =E2=80=98<a=
href=3D"https://www.youtube.com/watch?v=3DhizGxfDdc7M&index=3D13&l=
ist=3DPL_AKIMJc4roXJldxjJGtH8PJb4dY6nN1D" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'https://www.youtube.com/watch?v\x3dhizGxf=
Ddc7M\x26index\x3d13\x26list\x3dPL_AKIMJc4roXJldxjJGtH8PJb4dY6nN1D';ret=
urn true;" onclick=3D"this.href=3D'https://www.youtube.com/watch?v\x3dh=
izGxfDdc7M\x26index\x3d13\x26list\x3dPL_AKIMJc4roXJldxjJGtH8PJb4dY6nN1D'=
;;return true;">C++20 Language Features for a New Library</a>,=E2=80=99 I c=
an remark that he states thoughts along the same lines as yours when transi=
tioning from discussing concepts to discussing contracts (I=E2=80=99d give =
you a link to the exact point in time during his presentation where he does=
so, but I can=E2=80=99t exactly recall it at the moment; sorry about that.=
) =C2=A0</div><br><div>
<div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wra=
p:break-word"><div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-ali=
gn:start;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px;word-wrap:break-word"><div style=3D"color:rgb(0,0,0);letter-spacing:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px;word-wrap:break-word"><div>Hope that helps anyway,=C2=
=A0</div><div>=C2=A0 =C2=A0 =C2=A0Bryce Glover</div><div>=C2=A0 =C2=A0 =C2=
=A0<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"3So7T=
hhIAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">Ra=
ndom...@gmail.com</a></div></div></div></div></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/a2c8224b-1a6d-40d3-aee2-1bb9943b0610%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a2c8224b-1a6d-40d3-aee2-1bb9943b0610=
%40isocpp.org</a>.<br />
------=_Part_1138_2126830778.1498976525422--
------=_Part_1137_1697606162.1498976525422--
.