Topic: Concepts Lite: why retain function concepts?
Author: David Krauss <potswa@gmail.com>
Date: Sun, 24 Aug 2014 13:15:28 +0800
Raw View
Hi Andrew /cc std-proposals,
I wonder, what do function concepts do that variable concepts don't? The re=
striction on a function concept to comprise a single return statement is si=
milar to C++11 constexpr functions, but now with relaxed constexpr it seems=
foreign. With the remaining restrictions, it looks like any function conce=
pt trivially simplifies to a variable concept.
Variable templates are still in the early stages of implementation so I won=
der if function concepts mainly serve(d) to help prototype in the absence o=
f variable template support.
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Andrew Sutton <asutton@uakron.edu>
Date: Sun, 24 Aug 2014 07:37:40 -0400
Raw View
> I wonder, what do function concepts do that variable concepts don=E2=80=
=99t?
You can overload function templates (and concepts), but not variable
templates (or concepts).
> Variable templates are still in the early stages of implementation so I w=
onder if function concepts mainly serve(d) to help prototype in the absence=
of variable template support.
True. Variable templates didn't exist when Concepts Lite was first
being designed, and GCC didn't have an implementation until very
recently.
Andrew
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 25 Aug 2014 09:54:18 +0800
Raw View
--Apple-Mail=_52968ABC-00FA-4A8C-A8D4-2E34B5E1D52D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-24, at 7:37 PM, Andrew Sutton <asutton@uakron.edu> wrote:
> You can overload function templates (and concepts), but not variable
> templates (or concepts).
Richard Smith has interpreted the variable template spec that it already su=
pports partial specialization. IIRC, the language subtly mentions that a pa=
rtial specialization may declare a variable template. See StackOverflow, Cl=
ang Doxygen.
Partial specialization isn't quite as expressive as overloading because you=
can't change arity or type/non-type. But the former is possible with defau=
lt arguments, and the latter is a bit of a red flag, users might be better =
off without.
> True. Variable templates didn't exist when Concepts Lite was first
> being designed, and GCC didn't have an implementation until very
> recently.
So far, I've found Clang's implementation not yet to be usable. A variable =
template cannot be instantiated by another template, but only from non-temp=
late code. I'd expect the bug to break all variable concepts, if Clang had =
concepts. I've barely used GCC's variable templates so far.
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_52968ABC-00FA-4A8C-A8D4-2E34B5E1D52D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–24, at 7:37 PM, Andrew Sutton <<a href=3D"mailto:asutton@=
uakron.edu">asutton@uakron.edu</a>> wrote:</div><br class=3D"Apple-inter=
change-newline"><blockquote type=3D"cite">You can overload function templat=
es (and concepts), but not variable<br>templates (or concepts).<br></blockq=
uote><div><br></div><div>Richard Smith has interpreted the variable templat=
e spec that it already supports partial specialization. IIRC, the language =
subtly mentions that a partial specialization may declare a variable templa=
te. See <a href=3D"http://stackoverflow.com/a/21319055/153285">StackOv=
erflow</a>, <a href=3D"http://clang.llvm.org/doxygen/classclang_1_1Var=
TemplatePartialSpecializationDecl.html">Clang Doxygen</a>.</div><div><br></=
div><div>Partial specialization isn’t quite as expressive as overload=
ing because you can’t change arity or type/non-type. But the former i=
s possible with default arguments, and the latter is a bit of a red flag, u=
sers might be better off without.</div><br><blockquote type=3D"cite">True. =
Variable templates didn't exist when Concepts Lite was first<br>being desig=
ned, and GCC didn't have an implementation until very<br>recently.<br></blo=
ckquote><div><br></div></div>So far, I’ve found Clang’s impleme=
ntation not yet to be usable. A variable template cannot be instantiated by=
another template, but only from non-template code. I’d expect <=
a href=3D"http://llvm.org/bugs/show_bug.cgi?id=3D19571">the bug</a> to=
break all variable concepts, if Clang had concepts. I’ve barely used=
GCC’s variable templates so far.<div><br></div></body></html>
<p></p>
-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_52968ABC-00FA-4A8C-A8D4-2E34B5E1D52D--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 24 Aug 2014 21:38:28 -0700
Raw View
--047d7b343a4c1e29d505016cc201
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Aug 24, 2014 at 6:54 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9308=E2=80=9324, at 7:37 PM, Andrew Sutton <asutton@uakron.=
edu> wrote:
>
> You can overload function templates (and concepts), but not variable
> templates (or concepts).
>
>
> Richard Smith has interpreted the variable template spec that it already
> supports partial specialization. IIRC, the language subtly mentions that =
a
> partial specialization may declare a variable template. See StackOverflow
> <http://stackoverflow.com/a/21319055/153285>, Clang Doxygen
> <http://clang.llvm.org/doxygen/classclang_1_1VarTemplatePartialSpecializa=
tionDecl.html>
> .
>
> Partial specialization isn=E2=80=99t quite as expressive as overloading b=
ecause
> you can=E2=80=99t change arity or type/non-type. But the former is possib=
le with
> default arguments, and the latter is a bit of a red flag, users might be
> better off without.
>
> True. Variable templates didn't exist when Concepts Lite was first
> being designed, and GCC didn't have an implementation until very
> recently.
>
>
> So far, I=E2=80=99ve found Clang=E2=80=99s implementation not yet to be u=
sable. A variable
> template cannot be instantiated by another template, but only from
> non-template code.
>
FYI, that bug has been fixed for many months. =3D)
I=E2=80=99d expect the bug <http://llvm.org/bugs/show_bug.cgi?id=3D19571> t=
o break
> all variable concepts,
>
That's a different -- much more specific -- bug, and is also fixed.
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7b343a4c1e29d505016cc201
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 S=
un, Aug 24, 2014 at 6:54 PM, David Krauss <span dir=3D"ltr"><<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div=
><div class=3D""><div>On 2014=E2=80=9308=E2=80=9324, at 7:37 PM, Andrew Sut=
ton <<a href=3D"mailto:asutton@uakron.edu" target=3D"_blank">asutton@uak=
ron.edu</a>> wrote:</div>
<br><blockquote type=3D"cite">You can overload function templates (and conc=
epts), but not variable<br>templates (or concepts).<br></blockquote><div><b=
r></div></div><div>Richard Smith has interpreted the variable template spec=
that it already supports partial specialization. IIRC, the language subtly=
mentions that a partial specialization may declare a variable template. Se=
e=C2=A0<a href=3D"http://stackoverflow.com/a/21319055/153285" target=3D"_bl=
ank">StackOverflow</a>,=C2=A0<a href=3D"http://clang.llvm.org/doxygen/class=
clang_1_1VarTemplatePartialSpecializationDecl.html" target=3D"_blank">Clang=
Doxygen</a>.</div>
<div><br></div><div>Partial specialization isn=E2=80=99t quite as expressiv=
e as overloading because you can=E2=80=99t change arity or type/non-type. B=
ut the former is possible with default arguments, and the latter is a bit o=
f a red flag, users might be better off without.</div>
<div class=3D""><br><blockquote type=3D"cite">True. Variable templates didn=
't exist when Concepts Lite was first<br>being designed, and GCC didn&#=
39;t have an implementation until very<br>recently.<br></blockquote><div><b=
r>
</div></div></div>So far, I=E2=80=99ve found Clang=E2=80=99s implementation=
not yet to be usable. A variable template cannot be instantiated by anothe=
r template, but only from non-template code.</div></blockquote><div><br></d=
iv><div>FYI, that bug has been fixed for many months. =3D)</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 style=3D"word-wrap:break=
-word">I=E2=80=99d expect=C2=A0<a href=3D"http://llvm.org/bugs/show_bug.cgi=
?id=3D19571" target=3D"_blank">the bug</a>=C2=A0to break all variable conce=
pts,</div>
</blockquote><div><br></div><div>That's a different -- much more specif=
ic -- bug, and is also fixed.</div></div></div></div>
<p></p>
-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b343a4c1e29d505016cc201--
.
Author: Andrew Sutton <asutton@uakron.edu>
Date: Mon, 25 Aug 2014 10:15:09 -0400
Raw View
> You can overload function templates (and concepts), but not variable
> templates (or concepts).
>
> Partial specialization isn=E2=80=99t quite as expressive as overloading b=
ecause you
> can=E2=80=99t change arity or type/non-type. But the former is possible w=
ith default
> arguments, and the latter is a bit of a red flag, users might be better o=
ff
> without.
You can't partially or explicitly specialize a concept.
Andrew
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 26 Aug 2014 11:07:59 +0800
Raw View
--Apple-Mail=_CD2D1A63-ACF0-4EC8-A4BB-5D9DCC3EA594
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-25, at 10:15 PM, Andrew Sutton <asutton@uakron.edu> wrote:
>> Partial specialization isn't quite as expressive as overloading because =
you
>> can't change arity or type/non-type. But the former is possible with def=
ault
>> arguments, and the latter is a bit of a red flag, users might be better =
off
>> without.
>=20
> You can't partially or explicitly specialize a concept.
Well, you don't need to, because requires-expressions are expected to do pa=
ttern matching internally. And if I'm reading the spec correctly, overloadi=
ng is prohibited except in the cases I said were redundant or questionable =
(N4040 =A74.1.4/7, =A74.1.3/8). (I'm just getting up to speed, please bear =
with me...)
Function concepts support overloading (in terms of mechanism) but the only =
added capability is to allow completely different constraints depending on =
number of arguments or type- or non-typeness of an argument. These cases se=
em to go against the spirit of =A74.1.4/7, that each concept should have a =
unified specification, because requires-expressions are sufficiently expres=
sive.
Default arguments or packs should be able to do whatever overloading can do=
for variable arity:
template<typename T, typename U =3D unused>
concept bool C =3D is_unused< U >? unary_reqs< T > : binary_reqs< T, U >;
template<typename T, typename ... U>
concept bool D =3D common_reqs< T > && variadic_reqs< U ... >;
In practice, concepts sharing the same name should have some overlap among =
the cases; total exclusivity seems like a bad thing.
Defaulting non-type arguments may not be as simple as the above strategies =
but this seems like a corner case.
Even if special support for these cases is necessary, I wonder if it should=
be particular to functions -- perhaps variable concepts (or all variable t=
emplates) should be allowed to overload?
Long story short, variables seem like a better fit for all but narrow corne=
r cases, and in practice I'd be inclined to stretch the capability of varia=
bles rather than switch to functions.
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_CD2D1A63-ACF0-4EC8-A4BB-5D9DCC3EA594
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–25, at 10:15 PM, Andrew Sutton <<a href=3D"mailto:asutton=
@uakron.edu">asutton@uakron.edu</a>> wrote:</div><br class=3D"Apple-inte=
rchange-newline"><blockquote type=3D"cite"><blockquote type=3D"cite">Partia=
l specialization isn’t quite as expressive as overloading because you=
<br>can’t change arity or type/non-type. But the former is possible w=
ith default<br>arguments, and the latter is a bit of a red flag, users migh=
t be better off<br>without.<br></blockquote><br>You can't partially or expl=
icitly specialize a concept.<br></blockquote></div><br><div>Well, you don&r=
squo;t need to, because <i>requires-expressions</i> are expected to do patt=
ern matching internally. And if I’m reading the spec correctly, overl=
oading is prohibited except in the cases I said were redundant or questiona=
ble (N4040 =A74.1.4/7, =A74.1.3/8). (I’m just getting up to speed, pl=
ease bear with me…)</div><div><br></div><div>Function concepts suppo=
rt overloading (in terms of mechanism) but the only added capability is to =
allow completely different constraints depending on number of arguments or =
type- or non-typeness of an argument. These cases seem to go against the sp=
irit of =A74.1.4/7, that each concept should have a unified specification, =
because requires-expressions are sufficiently expressive.</div><div><br></d=
iv><div><div>Default arguments or packs should be able to do whatever overl=
oading can do for variable arity:</div><div><br></div><div><font face=3D"Co=
urier">template<typename T, typename U =3D unused></font></div><div><=
font face=3D"Courier">concept bool C =3D is_unused< U >? unary_reqs&l=
t; T > : binary_reqs< T, U >;</font></div></div><div><br></div><di=
v><div><font face=3D"Courier">template<typename T, typename ... U></f=
ont></div><div><font face=3D"Courier">concept bool D </font><span styl=
e=3D"font-family: Courier;">=3D common_reqs< T > && variadic_=
reqs< U ... >;</span></div></div><div><font face=3D"Courier"><br></fo=
nt></div><div>In practice, concepts sharing the same name should have some =
overlap among the cases; total exclusivity seems like a bad thing.</div><di=
v><br></div><div>Defaulting non-type arguments may not be as simple as the =
above strategies but this seems like a corner case.</div><div><br></di=
v><div>Even if special support for these cases is necessary, I wonder if it=
should be particular to functions — perhaps variable concepts (or al=
l variable templates) should be allowed to overload?</div><div><br></div><d=
iv>Long story short, variables seem like a better fit for all but narrow co=
rner cases, and in practice I’d be inclined to stretch the capability=
of variables rather than switch to functions.</div><div><br></div></body><=
/html>
<p></p>
-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_CD2D1A63-ACF0-4EC8-A4BB-5D9DCC3EA594--
.
Author: Andrew Sutton <asutton@uakron.edu>
Date: Tue, 26 Aug 2014 09:20:02 -0400
Raw View
> Well, you don=E2=80=99t need to, because requires-expressions are expecte=
d to do
> pattern matching internally. And if I=E2=80=99m reading the spec correctl=
y,
> overloading is prohibited except in the cases I said were redundant or
> questionable (N4040 =C2=A74.1.4/7, =C2=A74.1.3/8). (I=E2=80=99m just gett=
ing up to speed,
> please bear with me=E2=80=A6)
You should probably start with the non-standardese proposals, starting
with n3351. They give a much better overview of how things should
work.
Plus, the wording will change quite a bit by November.
Also, I'm not sure what you mean by a requires-expression doing
pattern matching. They don't actually *do* anything except get
transformed into conjunctions of atomic constraints.
> Function concepts support overloading (in terms of mechanism) but the onl=
y
> added capability is to allow completely different constraints depending o=
n
> number of arguments or type- or non-typeness of an argument. These cases
> seem to go against the spirit of =C2=A74.1.4/7, that each concept should =
have a
> unified specification, because requires-expressions are sufficiently
> expressive.
This is exactly the reason that they are desirable. We have a number
of examples in n3351 where we overload concepts on arity to express
very concrete generalizations of a relation, Equality_comparable and
Totally_ordered are best such examples
Obviously, defining two concepts with the same name and wildly
different requirements is a bad idea. But that's not something that
should go into the language spec.
> Default arguments or packs should be able to do whatever overloading can =
do
> for variable arity:
>
> template<typename T, typename U =3D unused>
> concept bool C =3D is_unused< U >? unary_reqs< T > : binary_reqs< T, U >;
>
> template<typename T, typename ... U>
> concept bool D =3D common_reqs< T > && variadic_reqs< U ... >;
That only works if C or D isn't involved in overloads where partial
ordering of function templates is required. The constraint language
doesn't define any logical meaning for conditional-expressions, so C's
entire definition is just a single atomic constraint. For D,
variadic_reqs<U...> almost certainly refers to a a system of partially
specialized class or variable templates, either of which would be an
atomic constraint.
So, you can get true or false from C and D, but not much in the way of
deeper introspection. That includes diagnostics, too.
> Long story short, variables seem like a better fit for all but narrow cor=
ner
> cases, and in practice I=E2=80=99d be inclined to stretch the capability =
of
> variables rather than switch to functions.
I think the longer story is that I'd really prefer to have a separate
declaration for concepts instead of relying functions or variables to
define them, since they can cause some confusion. But I would still
want overloading of those declarations by arity.
Andrew
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Thu, 28 Aug 2014 04:54:36 -0700
Raw View
Andrew Sutton <asutton@uakron.edu> writes:
[...]
| I think the longer story is that I'd really prefer to have a separate
| declaration for concepts instead of relying functions or variables to
| define them, since they can cause some confusion. But I would still
| want overloading of those declarations by arity.
Agreed.
-- Gaby
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Tue, 2 Sep 2014 00:15:30 -0700 (PDT)
Raw View
------=_Part_2503_1832587893.1409642130892
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu wtorek, 26 sierpnia 2014 15:20:25 UTC+2 u=C5=BCytkownik Andrew Sutto=
n=20
napisa=C5=82:
>
>
> > Long story short, variables seem like a better fit for all but narrow=
=20
> corner=20
> > cases, and in practice I=E2=80=99d be inclined to stretch the capabilit=
y of=20
> > variables rather than switch to functions.=20
>
> I think the longer story is that I'd really prefer to have a separate=20
> declaration for concepts instead of relying functions or variables to=20
> define them, since they can cause some confusion. But I would still=20
> want overloading of those declarations by arity.=20
>
Given that the change you describe appears to be welcome by everyone,=20
should we expect this change to occur in the Concepts TS?
Regards,
&rzej
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2503_1832587893.1409642130892
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu wtorek, 26 sierpnia 2014 15:20:25 UTC+2 u=
=C5=BCytkownik Andrew Sutton napisa=C5=82:<blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><br>> Long story short, variables seem like a better fit for=
all but narrow corner
<br>> cases, and in practice I=E2=80=99d be inclined to stretch the capa=
bility of
<br>> variables rather than switch to functions.
<br>
<br>I think the longer story is that I'd really prefer to have a separate
<br>declaration for concepts instead of relying functions or variables to
<br>define them, since they can cause some confusion. But I would still
<br>want overloading of those declarations by arity.
<br></blockquote><div><br>Given that the change you describe appears to be =
welcome by everyone, should we expect this change to occur in the Concepts =
TS?<br><br>Regards,<br>&rzej<br></div></div>
<p></p>
-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2503_1832587893.1409642130892--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 2 Sep 2014 15:58:44 +0800
Raw View
--Apple-Mail=_F762A3A5-FF2E-456B-BD2F-32BEB92183B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On 2014=E2=80=9309=E2=80=9302, at 3:15 PM, Andrzej Krzemie=C5=84ski <akrzem=
i1@gmail.com> wrote:
> Given that the change you describe appears to be welcome by everyone, sho=
uld we expect this change to occur in the Concepts TS?
My impression (perhaps not 100% informed) is that concepts need to map to s=
omething that otherwise exists to be considered =E2=80=9CLite.=E2=80=9D How=
ever, there is already the concept keyword, so the mapping doesn=E2=80=99t =
need to be (in the long run, won=E2=80=99t be) 1:1.
I do think a one-size-fits-all solution would be better than a variable/fun=
ction dichotomy. Variable template overloads-by-arity should work with mini=
mal fuss given a few extra requirements, such as an ODR requirement that th=
e same overloads must be declared before use (or equivalently, every use of=
a given concept must look into the same overload set). Even that may not b=
e necessary.
However, I=E2=80=99m not really convinced by the examples. EqualityComparab=
ility of a type is similar, but not exactly the same concept as mutual Equa=
lityComparability of two types. Even in the generic case where you might ha=
ve two different types or only one, SelfEqualityComparable< T > is the same=
as MutuallyEqualityComparable< T, T >, and a metaprogram is more likely to=
compute the latter, than to switch between the two overloads. The same goe=
s for complete ordering. This seems to rule out overloading having an effec=
t on program semantics; it=E2=80=99s only stylistic.
Overloading just for the sake of name selection, as opposed to pattern-matc=
hing-style static computation, doesn=E2=80=99t seem worth the added complex=
ity of function concepts. And, pattern matching should be encapsulated insi=
de each concept, not done in an outer scope where potentially divergent con=
cepts are selected. That=E2=80=99s the domain of the function overloading w=
e already have.
The concept keyword could be a useful indicator of unified definition in a =
sea of arcane metaprogramming. It would be the seed of a top-down approach,=
and with future facilities the language could ultimately do away with intr=
ospective overloading and partial specialization entirely, making common us=
er-defined concepts self-contained, top-to-bottom.
On 2014=E2=80=9308=E2=80=9326, at 9:20 PM, Andrew Sutton <asutton@uakron.ed=
u> wrote:
>> template<typename T, typename ... U>
>> concept bool D =3D common_reqs< T > && variadic_reqs< U ... >;
>=20
> That only works if C or D isn't involved in overloads where partial
> ordering of function templates is required. The constraint language
> doesn't define any logical meaning for conditional-expressions, so C's
> entire definition is just a single atomic constraint. For D,
> variadic_reqs<U...> almost certainly refers to a a system of partially
> specialized class or variable templates, either of which would be an
> atomic constraint.
>=20
> So, you can get true or false from C and D, but not much in the way of
> deeper introspection. That includes diagnostics, too.
It=E2=80=99s an illustration of how a variadic concept might be factored, n=
ot of how concepts should be written. Of course, actual use would use the r=
equires keyword and its implicit conjunctions. And, you could say the same =
of many Boolean metafunctions, where the implementation requires a class te=
mplate partial specialization but the preferred interface is a variable tem=
plate. I don=E2=80=99t think anything is lost by requiring the concept keyw=
ord to introduce a friendly interface, as opposed to a complete implementat=
ion.
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_F762A3A5-FF2E-456B-BD2F-32BEB92183B4
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;"><br><div><div>On 2014=E2=80=
=9309=E2=80=9302, at 3:15 PM, Andrzej Krzemie=C5=84ski <<a href=3D"mailt=
o:akrzemi1@gmail.com">akrzemi1@gmail.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite"><span style=3D"font-fam=
ily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; white-spac=
e: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
float: none; display: inline !important;">Given that the change you descri=
be appears to be welcome by everyone, should we expect this change to occur=
in the Concepts TS?</span><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></div><br><d=
iv>My impression (perhaps not 100% informed) is that concepts need to map t=
o something that otherwise exists to be considered =E2=80=9CLite.=E2=
=80=9D However, there is already the <font face=3D"Courier">concept</font> =
keyword, so the mapping doesn=E2=80=99t need to be (in the long run, won=E2=
=80=99t be) 1:1.</div><div><br></div><div>I do think a one-size-fits-all so=
lution would be better than a variable/function dichotomy. Variable templat=
e overloads-by-arity should work with minimal fuss given a few extra requir=
ements, such as an ODR requirement that the same overloads must be declared=
before use (or equivalently, every use of a given concept must look into t=
he same overload set). Even that may not be necessary.</div><div><br></div>=
<div>However, I=E2=80=99m not really convinced by the examples. EqualityCom=
parability of a type is similar, but not exactly the same concept as mutual=
EqualityComparability of two types. Even in the generic case where you mig=
ht have two different types or only one, <font face=3D"Courier">SelfEqualit=
yComparable< T ></font> is the same as <font face=3D"Courier">Mutuall=
yEqualityComparable< T, T ></font>, and a metaprogram is more likely =
to compute the latter, than to switch between the two overloads. The same g=
oes for complete ordering. This seems to rule out overloading having an eff=
ect on program semantics; it=E2=80=99s only stylistic.</div><div><br></div>=
<div>Overloading just for the sake of name selection, as opposed to pattern=
-matching-style static computation, doesn=E2=80=99t seem worth the added co=
mplexity of function concepts. And, pattern matching should be encapsulated=
inside each concept, not done in an outer scope where potentially divergen=
t concepts are selected. That=E2=80=99s the domain of the function overload=
ing we already have.</div><div><br></div><div>The <font face=3D"Courier">co=
ncept</font> keyword could be a useful indicator of unified definition in a=
sea of arcane metaprogramming. It would be the seed of a top-down approach=
, and with future facilities the language could ultimately do away with int=
rospective overloading and partial specialization entirely, making common u=
ser-defined concepts self-contained, top-to-bottom.</div><div><br></div><di=
v><br></div><div><div>On 2014=E2=80=9308=E2=80=9326, at 9:20 PM, Andrew Sut=
ton <<a href=3D"mailto:asutton@uakron.edu">asutton@uakron.edu</a>> wr=
ote:</div><div><br></div><blockquote type=3D"cite"><blockquote type=3D"cite=
">template<typename T, typename ... U><br>concept bool D =3D common_r=
eqs< T > && variadic_reqs< U ... >;<br></blockquote><br=
>That only works if C or D isn't involved in overloads where partial<br>ord=
ering of function templates is required. The constraint language<br>doesn't=
define any logical meaning for conditional-expressions, so C's<br>entire d=
efinition is just a single atomic constraint. For D,<br>variadic_reqs<U.=
...> almost certainly refers to a a system of partially<br>specialized cl=
ass or variable templates, either of which would be an<br>atomic constraint=
..<br><br>So, you can get true or false from C and D, but not much in the wa=
y of<br>deeper introspection. That includes diagnostics, too.<br></blockquo=
te><br></div><div>It=E2=80=99s an illustration of how a variadic concept mi=
ght be factored, not of how concepts should be written. Of course, actual u=
se would use the <font face=3D"Courier">requires</font> keyword and its imp=
licit conjunctions. And, you could say the same of many Boolean metafunctio=
ns, where the implementation requires a class template partial specializati=
on but the preferred interface is a variable template. I don=E2=80=99t thin=
k anything is lost by requiring the <font face=3D"Courier">concept</font> k=
eyword to introduce a friendly interface, as opposed to a complete implemen=
tation.</div><div><br></div></body></html>
<p></p>
-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_F762A3A5-FF2E-456B-BD2F-32BEB92183B4--
.
Author: Andrew Sutton <asutton@uakron.edu>
Date: Tue, 2 Sep 2014 09:50:55 -0400
Raw View
>> I think the longer story is that I'd really prefer to have a separate
>> declaration for concepts instead of relying functions or variables to
>> define them, since they can cause some confusion. But I would still
>> want overloading of those declarations by arity.
>
>
> Given that the change you describe appears to be welcome by everyone, should
> we expect this change to occur in the Concepts TS?
Not for the TS. That ship sailed a couple years ago :)
Andrew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Sutton <asutton@uakron.edu>
Date: Tue, 2 Sep 2014 10:57:26 -0400
Raw View
> However, I=E2=80=99m not really convinced by the examples. EqualityCompar=
ability of
> a type is similar, but not exactly the same concept as mutual
> EqualityComparability of two types. Even in the generic case where you mi=
ght
> have two different types or only one, SelfEqualityComparable< T > is the
> same as MutuallyEqualityComparable< T, T >, and a metaprogram is more lik=
ely
> to compute the latter, than to switch between the two overloads. The same
> goes for complete ordering. This seems to rule out overloading having an
> effect on program semantics; it=E2=80=99s only stylistic.
I've been down this road before. There are three problems.
The first two are technical. First, as I said earlier, we lose the
ability to support overloading based on the requirements of concepts
implemented using a template metaprograms. Second, we can't support
separate checking for template definitions for concepts that are
implemented using template metaprograms.
The third is a general observation: if defining trivial concepts
requires any significant amount of template metaprogramming, then I
would consider Concepts Lite a failed experiment.
> Overloading just for the sake of name selection, as opposed to
> pattern-matching-style static computation, doesn=E2=80=99t seem worth the=
added
> complexity of function concepts. And, pattern matching should be
> encapsulated inside each concept, not done in an outer scope where
> potentially divergent concepts are selected. That=E2=80=99s the domain of=
the
> function overloading we already have.
No. Overloading based on constraints extends the existing pattern
matching facilities of the language to create, for lack of a better
term, specialization hierarchies based on both the pattern of types
and implications of their constraints. This is how concepts are used
in practice in the STL and elsewhere.
> The concept keyword could be a useful indicator of unified definition in =
a
> sea of arcane metaprogramming. It would be the seed of a top-down approac=
h,
> and with future facilities the language could ultimately do away with
> introspective overloading and partial specialization entirely, making com=
mon
> user-defined concepts self-contained, top-to-bottom.
You must be thinking of some other language feature, because no
version of concepts has ever come close to this.
Andrew
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 3 Sep 2014 11:23:20 +0800
Raw View
--Apple-Mail=_676C680C-1802-4DB5-8B9E-EF97DE16FA9C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-02, at 10:57 PM, Andrew Sutton <asutton@uakron.edu> wrote:
> First, as I said earlier, we lose the
> ability to support overloading based on the requirements of concepts
> implemented using a template metaprograms.
The overloading simply needs to be moved into the metaprogram. Concepts are=
supposed to express invariant requirements, they shouldn't have prerequisi=
tes before application.
> Second, we can't support
> separate checking for template definitions for concepts that are
> implemented using template metaprograms.
The separation would be done in the template specialization, or whatever th=
e concepts encapsulate.
There's no technical argument here, it's a question of which metaprocessing=
may be done in a concept's immediate definition and which must be done out=
side.
> The third is a general observation: if defining trivial concepts
> requires any significant amount of template metaprogramming, then I
> would consider Concepts Lite a failed experiment.
Concept overloading is itself template metaprogramming, and that's the reas=
on I'm arguing against it.
If everyday concepts cannot be captured in a requires clause, then it's a f=
ailed experiment. However, most everyday concepts will express a generic in=
terface, requiring that certain expressions are well-defined, hence require=
s. The benefit is less duck typing. I don't think we need to get too hung u=
p on TMP. Selecting between several requires clauses -- alternative, mutual=
ly-exclusive, perhaps partially-generic interfaces -- sounds like an anti-p=
attern, and programmers that need it can easily find a workaround.
> Overloading based on constraints extends the existing pattern
> matching facilities of the language to create, for lack of a better
> term, specialization hierarchies based on both the pattern of types
> and implications of their constraints. This is how concepts are used
> in practice in the STL and elsewhere.
Then why is partial concept specialization forbidden? For that matter, expl=
icit specialization? You seem to be contradicting N4040 =A74.1.4/7. Also, y=
ou just said that TMP is a bad direction, so why use the paragon of TMP as =
a design guide?
Practice in the STL is based on whatever facilities the implementers could =
work with at the time. Concepts shouldn't necessarily ensconce the wackines=
s.
Where the means of checking a concept varies from template to template, the=
author may fall back on TMP and specialization for one constraint or anoth=
er. But encouraging re-implementation of all constraints by top-level overl=
oading will often send users and library authors back to square one.
>> The concept keyword could be a useful indicator of unified definition in=
a
>> sea of arcane metaprogramming. It would be the seed of a top-down approa=
ch,
>> and with future facilities the language could ultimately do away with
>> introspective overloading and partial specialization entirely, making co=
mmon
>> user-defined concepts self-contained, top-to-bottom.
>=20
> You must be thinking of some other language feature, because no
> version of concepts has ever come close to this.
Yes. I'm talking about something more like local template declarations, and=
/or pattern-matching without a dummy primary template.
--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_676C680C-1802-4DB5-8B9E-EF97DE16FA9C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–02, at 10:57 PM, Andrew Sutton <<a href=3D"mailto:asutton=
@uakron.edu">asutton@uakron.edu</a>> wrote:</div><br class=3D"Apple-inte=
rchange-newline"><blockquote type=3D"cite">First, as I said earlier, we los=
e the<br>ability to support overloading based on the requirements of concep=
ts<br>implemented using a template metaprograms. </blockquote><div><br></di=
v><div>The overloading simply needs to be moved into the metaprogram. Conce=
pts are supposed to express invariant requirements, they shouldn’t ha=
ve prerequisites before application.</div><br><blockquote type=3D"cite">Sec=
ond, we can't support<br>separate checking for template definitions for con=
cepts that are<br>implemented using template metaprograms.<br></blockquote>=
<div><br></div><div>The separation would be done in the template specializa=
tion, or whatever the concepts encapsulate.</div><div><br></div><div>There&=
rsquo;s no technical argument here, it’s a question of which metaproc=
essing may be done in a concept’s immediate definition and which must=
be done outside.</div><br><blockquote type=3D"cite">The third is a general=
observation: if defining trivial concepts<br>requires any significant amou=
nt of template metaprogramming, then I<br>would consider Concepts Lite a fa=
iled experiment.<br></blockquote><div><br></div><div>Concept overloading is=
itself template metaprogramming, and that’s the reason I’m arg=
uing against it.</div><div><br></div><div>If everyday concepts cannot be ca=
ptured in a <font face=3D"Courier">requires</font> clause, then it’s =
a failed experiment. However, most everyday concepts will express a generic=
interface, requiring that certain expressions are well-defined, hence <fon=
t face=3D"Courier">requires</font>. The benefit is less duck typing. I don&=
rsquo;t think we need to get too hung up on TMP. Selecting between several =
<font face=3D"Courier">requires</font> clauses — alternative, mutuall=
y-exclusive, perhaps partially-generic interfaces — sounds like an an=
ti-pattern, and programmers that need it can easily find a workaround.</div=
><br><blockquote type=3D"cite">Overloading based on constraints extends the=
existing pattern<br>matching facilities of the language to create, for lac=
k of a better<br>term, specialization hierarchies based on both the pattern=
of types<br>and implications of their constraints. This is how concepts ar=
e used<br>in practice in the STL and elsewhere.<br></blockquote><div><br></=
div><div>Then why is partial concept specialization forbidden? For that mat=
ter, explicit specialization? You seem to be contradicting N4040 =A74.1.4/7=
.. Also, you just said that TMP is a bad direction, so why use the paragon o=
f TMP as a design guide?</div><div><br></div><div>Practice in the STL is ba=
sed on whatever facilities the implementers could work with at the time. Co=
ncepts shouldn’t necessarily ensconce the wackiness.</div><div><br></=
div><div>Where the means of checking a concept varies from template to temp=
late, the author may fall back on TMP and specialization for one constraint=
or another. But encouraging re-implementation of all constraints by top-le=
vel overloading will often send users and library authors back to square on=
e.</div><br><blockquote type=3D"cite"><blockquote type=3D"cite">The concept=
keyword could be a useful indicator of unified definition in a<br>sea of a=
rcane metaprogramming. It would be the seed of a top-down approach,<br>and =
with future facilities the language could ultimately do away with<br>intros=
pective overloading and partial specialization entirely, making common<br>u=
ser-defined concepts self-contained, top-to-bottom.<br></blockquote><br>You=
must be thinking of some other language feature, because no<br>version of =
concepts has ever come close to this.<br></blockquote><div><br></div>Yes. I=
’m talking about something more like local template declarations, and=
/or pattern-matching without a dummy primary template.</div><div><br></div>=
</body></html>
<p></p>
-- <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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_676C680C-1802-4DB5-8B9E-EF97DE16FA9C--
.