Topic: A plea for a consistent, terse and intuitive
Author: Corentin <corentin.jabot@gmail.com>
Date: Mon, 6 Nov 2017 13:27:33 -0800 (PST)
Raw View
------=_Part_13720_1622031465.1510003653825
Content-Type: multipart/alternative;
boundary="----=_Part_13721_263866740.1510003653825"
------=_Part_13721_263866740.1510003653825
Content-Type: text/plain; charset="UTF-8"
Hello.
This proposal is a bit similar to Jakob Riedle's "Concepts are Adjectives,
not Nouns" which you can read about here
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8hmrsEfg8Oc
My goal was to have the same syntax, with the same semantic across lambda,
function and templates parameters, as well as variable declarations and
some other constructs.
I do that by allowing concepts ( aka constraints) to be applied to both
template and non-template type, using the notation that Jakob calls
"Adjectives" syntax.
Uniformity, intuitiveness and terseness were the main driving goals.
https://cor3ntin.github.io/CPPProposals/unified_concept_declaration_syntax/concepts.html
Please note that the document is not yet final, notably it is missing
references and acknowledgments.
I hope to here your feedback !
Regards, Corentin
--
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/1abe0443-19be-4aff-8627-e87d1807b901%40isocpp.org.
------=_Part_13721_263866740.1510003653825
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello.<div>This proposal is a bit similar to=C2=A0<span st=
yle=3D"white-space: nowrap;">Jakob Riedle's "</span><span style=3D=
"white-space: nowrap;"><font size=3D"2">Concepts are Adjectives, not Nouns&=
quot; which you can read about here=C2=A0</font></span><font size=3D"2"><sp=
an style=3D"white-space: nowrap;">https://groups.google.com/a/isocpp.org/fo=
rum/#!topic/std-proposals/8hmrsEfg8Oc</span></font></div><div><font size=3D=
"2"><span style=3D"white-space: nowrap;"><br></span></font></div><div><font=
size=3D"2"><span style=3D"white-space: nowrap;"><br></span></font></div><d=
iv><font size=3D"2"><span style=3D"white-space: nowrap;">My goal was to hav=
e the same syntax, with the same semantic across lambda, function and templ=
ates parameters, as well as variable declarations and some other constructs=
..</span></font></div><div><font size=3D"2"><span style=3D"white-space: nowr=
ap;">I do that by allowing concepts ( aka constraints) to be applied to bot=
h template and non-template type, using the notation that Jakob calls "=
;Adjectives" syntax.</span></font></div><div><font size=3D"2"><span st=
yle=3D"white-space: nowrap;"><br></span></font></div><div><font size=3D"2">=
<span style=3D"white-space: nowrap;">Uniformity, intuitiveness and tersenes=
s=C2=A0were the main driving goals.</span></font></div><div><br></div><div>=
<font size=3D"2"><span style=3D"white-space: nowrap;">https://cor3ntin.gith=
ub.io/CPPProposals/unified_concept_declaration_syntax/concepts.html</span><=
br></font></div><div><font size=3D"2"><span style=3D"white-space: nowrap;">=
<br></span></font></div><div><font size=3D"2"><span style=3D"white-space: n=
owrap;"><br></span></font></div><div><font size=3D"2"><span style=3D"white-=
space: nowrap;">Please note that the document is not yet final, notably it =
is missing references and acknowledgments.</span></font></div><div><font si=
ze=3D"2"><span style=3D"white-space: nowrap;"><br></span></font></div><div>=
<br></div><div>I hope to here your feedback !</div><div><br></div><div>Rega=
rds,=C2=A0 Corentin</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/1abe0443-19be-4aff-8627-e87d1807b901%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1abe0443-19be-4aff-8627-e87d1807b901=
%40isocpp.org</a>.<br />
------=_Part_13721_263866740.1510003653825--
------=_Part_13720_1622031465.1510003653825--
.
Author: florian.csdt@gmail.com
Date: Tue, 7 Nov 2017 00:58:18 -0800 (PST)
Raw View
------=_Part_14740_654388176.1510045098471
Content-Type: multipart/alternative;
boundary="----=_Part_14741_1818590596.1510045098471"
------=_Part_14741_1818590596.1510045098471
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello Corentin,
It looks good. I think the main issues are addressed, and the=20
uniformity/intuitiveness is clear.
However, I think you should address also how those concepts can be mix with=
=20
other qualifiers (const, volatile, *, &) in variable declarations and=20
function parameters.
There were no consensus on that in the previous thread (AFAIR).
Florian
Le lundi 6 novembre 2017 22:27:33 UTC+1, Corentin a =C3=A9crit :
>
> Hello.
> This proposal is a bit similar to Jakob Riedle's "Concepts are=20
> Adjectives, not Nouns" which you can read about here=20
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8hmrsE=
fg8Oc
>
>
> My goal was to have the same syntax, with the same semantic across lambda=
,=20
> function and templates parameters, as well as variable declarations and=
=20
> some other constructs.
> I do that by allowing concepts ( aka constraints) to be applied to both=
=20
> template and non-template type, using the notation that Jakob calls=20
> "Adjectives" syntax.
>
> Uniformity, intuitiveness and terseness were the main driving goals.
>
>
> https://cor3ntin.github.io/CPPProposals/unified_concept_declaration_synta=
x/concepts.html
>
>
> Please note that the document is not yet final, notably it is missing=20
> references and acknowledgments.
>
>
> I hope to here your feedback !
>
> Regards, Corentin
>
--=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/bcdb8301-7264-4def-9b14-745d76139909%40isocpp.or=
g.
------=_Part_14741_1818590596.1510045098471
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello Corentin,<br><br>It looks good. I think the main iss=
ues are addressed, and the uniformity/intuitiveness is clear.<br>However, I=
think you should address also how those concepts can be mix with other qua=
lifiers (const, volatile, *, &) in variable declarations and function p=
arameters.<br>There were no consensus on that in the previous thread (AFAIR=
).<br><br>Florian<br><br>Le lundi 6 novembre 2017 22:27:33 UTC+1, Corentin =
a =C3=A9crit=C2=A0:<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">Hello.<div>This proposal is a bit similar to=C2=A0<span style=3D"whit=
e-space:nowrap">Jakob Riedle's "</span><span style=3D"white-space:=
nowrap"><font size=3D"2">Concepts are Adjectives, not Nouns" which you=
can read about here=C2=A0</font></span><font size=3D"2"><span style=3D"whi=
te-space:nowrap"><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!=
topic/std-proposals/8hmrsEfg8Oc" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!top=
ic/std-proposals/8hmrsEfg8Oc';return true;" onclick=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8hmrsEf=
g8Oc';return true;">https://groups.google.<wbr>com/a/isocpp.org/forum/#=
!<wbr>topic/std-proposals/<wbr>8hmrsEfg8Oc</a></span></font></div><div><fon=
t size=3D"2"><span style=3D"white-space:nowrap"><br></span></font></div><di=
v><font size=3D"2"><span style=3D"white-space:nowrap"><br></span></font></d=
iv><div><font size=3D"2"><span style=3D"white-space:nowrap">My goal was to =
have the same syntax, with the same semantic across lambda, function and te=
mplates parameters, as well as variable declarations and some other constru=
cts.</span></font></div><div><font size=3D"2"><span style=3D"white-space:no=
wrap">I do that by allowing concepts ( aka constraints) to be applied to bo=
th template and non-template type, using the notation that Jakob calls &quo=
t;Adjectives" syntax.</span></font></div><div><font size=3D"2"><span s=
tyle=3D"white-space:nowrap"><br></span></font></div><div><font size=3D"2"><=
span style=3D"white-space:nowrap">Uniformity, intuitiveness and terseness=
=C2=A0were the main driving goals.</span></font></div><div><br></div><div><=
font size=3D"2"><span style=3D"white-space:nowrap"><a href=3D"https://cor3n=
tin.github.io/CPPProposals/unified_concept_declaration_syntax/concepts.html=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fcor3ntin.github.io%2FCPPProposals%2=
Funified_concept_declaration_syntax%2Fconcepts.html\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNGoUSYtAtfcroFxyCQluBMd3baSNg';return true;" onclick=3D=
"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fcor3ntin.gi=
thub.io%2FCPPProposals%2Funified_concept_declaration_syntax%2Fconcepts.html=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGoUSYtAtfcroFxyCQluBMd3baSNg';=
return true;">https://cor3ntin.github.io/<wbr>CPPProposals/unified_concept_=
<wbr>declaration_syntax/concepts.<wbr>html</a></span><br></font></div><div>=
<font size=3D"2"><span style=3D"white-space:nowrap"><br></span></font></div=
><div><font size=3D"2"><span style=3D"white-space:nowrap"><br></span></font=
></div><div><font size=3D"2"><span style=3D"white-space:nowrap">Please note=
that the document is not yet final, notably it is missing references and a=
cknowledgments.</span></font></div><div><font size=3D"2"><span style=3D"whi=
te-space:nowrap"><br></span></font></div><div><br></div><div>I hope to here=
your feedback !</div><div><br></div><div>Regards,=C2=A0 Corentin</div></di=
v></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/bcdb8301-7264-4def-9b14-745d76139909%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bcdb8301-7264-4def-9b14-745d76139909=
%40isocpp.org</a>.<br />
------=_Part_14741_1818590596.1510045098471--
------=_Part_14740_654388176.1510045098471--
.
Author: Corentin <corentin.jabot@gmail.com>
Date: Tue, 7 Nov 2017 01:18:31 -0800 (PST)
Raw View
------=_Part_15048_882252439.1510046311897
Content-Type: multipart/alternative;
boundary="----=_Part_15049_1863124531.1510046311897"
------=_Part_15049_1863124531.1510046311897
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I do address that a bit near the end of the document, maybe I should be=20
more detailed.
the idea ( and I'm sorry for not speaking standardeese well at all ) is to=
=20
say that the "concept-name-sequence type-id" is the entity to which the=20
qualifiers apply.
So const, volatile, *, &, etc will appear either before the concept=20
sequence or after the type name.
Of course, both the type and the concepts can have a nested name qualifier.
const std::Constructible auto & x =3D
constexpr bar::GreaterThan<42> std::size_t s =3D
const BadlyDesigned Foo *** const*** bar =3D =20
Or to put it more simply, concepts appear always immediately before the=20
type and concepts are immediately followed by a type.
I think it's the simplest, less confusing way to do it.
Was there alternative suggestions ?
Le mardi 7 novembre 2017 09:58:18 UTC+1, floria...@gmail.com a =C3=A9crit :
>
> Hello Corentin,
>
> It looks good. I think the main issues are addressed, and the=20
> uniformity/intuitiveness is clear.
> However, I think you should address also how those concepts can be mix=20
> with other qualifiers (const, volatile, *, &) in variable declarations an=
d=20
> function parameters.
> There were no consensus on that in the previous thread (AFAIR).
>
> Florian
>
> Le lundi 6 novembre 2017 22:27:33 UTC+1, Corentin a =C3=A9crit :
>>
>> Hello.
>> This proposal is a bit similar to Jakob Riedle's "Concepts are=20
>> Adjectives, not Nouns" which you can read about here=20
>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8hmrs=
Efg8Oc
>>
>>
>> My goal was to have the same syntax, with the same semantic across=20
>> lambda, function and templates parameters, as well as variable declarati=
ons=20
>> and some other constructs.
>> I do that by allowing concepts ( aka constraints) to be applied to both=
=20
>> template and non-template type, using the notation that Jakob calls=20
>> "Adjectives" syntax.
>>
>> Uniformity, intuitiveness and terseness were the main driving goals.
>>
>>
>> https://cor3ntin.github.io/CPPProposals/unified_concept_declaration_synt=
ax/concepts.html
>>
>>
>> Please note that the document is not yet final, notably it is missing=20
>> references and acknowledgments.
>>
>>
>> I hope to here your feedback !
>>
>> Regards, Corentin
>>
>
--=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/ec68e22f-b287-4310-95ec-6f343dda68c1%40isocpp.or=
g.
------=_Part_15049_1863124531.1510046311897
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I do address that a bit near the end of the document, mayb=
e I should be more detailed.<div>the idea ( and I'm sorry for not speak=
ing standardeese well at all )=C2=A0 is to say that the=C2=A0 "concept=
-name-sequence type-id" is the entity to which the qualifiers apply.</=
div><div>So const, volatile, *, &, etc will appear either before the co=
ncept sequence or after the type name.</div><div>Of course, both the type a=
nd the concepts can have a nested name qualifier.</div><div><br></div><div>=
const std::Constructible auto & x =3D</div><div>constexpr=C2=A0 bar::Gr=
eaterThan<42> std::size_t s =3D</div><div>const BadlyDesigned Foo ***=
const*** bar =3D=C2=A0=C2=A0</div><div><br></div><div>Or to put it more si=
mply, concepts appear always immediately before the type and concepts are i=
mmediately followed by a type.</div><div>I think it's the simplest, les=
s confusing way to do it.</div><div><br></div><div>Was there alternative su=
ggestions ?</div><div><br><br>Le mardi 7 novembre 2017 09:58:18 UTC+1, flor=
ia...@gmail.com a =C3=A9crit=C2=A0:<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">Hello Corentin,<br><br>It looks good. I think the ma=
in issues are addressed, and the uniformity/intuitiveness is clear.<br>Howe=
ver, I think you should address also how those concepts can be mix with oth=
er qualifiers (const, volatile, *, &) in variable declarations and func=
tion parameters.<br>There were no consensus on that in the previous thread =
(AFAIR).<br><br>Florian<br><br>Le lundi 6 novembre 2017 22:27:33 UTC+1, Cor=
entin a =C3=A9crit=C2=A0:<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">Hello.<div>This proposal is a bit similar to=C2=A0<span style=3D"w=
hite-space:nowrap">Jakob Riedle's "</span><span style=3D"white-spa=
ce:nowrap"><font size=3D"2">Concepts are Adjectives, not Nouns" which =
you can read about here=C2=A0</font></span><font size=3D"2"><span style=3D"=
white-space:nowrap"><a href=3D"https://groups.google.com/a/isocpp.org/forum=
/#!topic/std-proposals/8hmrsEfg8Oc" rel=3D"nofollow" target=3D"_blank" onmo=
usedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!=
topic/std-proposals/8hmrsEfg8Oc';return true;" onclick=3D"this.href=3D&=
#39;https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8hmr=
sEfg8Oc';return true;">https://groups.google.<wbr>com/a/isocpp.org/foru=
m/#!<wbr>topic/std-proposals/<wbr>8hmrsEfg8Oc</a></span></font></div><div><=
font size=3D"2"><span style=3D"white-space:nowrap"><br></span></font></div>=
<div><font size=3D"2"><span style=3D"white-space:nowrap"><br></span></font>=
</div><div><font size=3D"2"><span style=3D"white-space:nowrap">My goal was =
to have the same syntax, with the same semantic across lambda, function and=
templates parameters, as well as variable declarations and some other cons=
tructs.</span></font></div><div><font size=3D"2"><span style=3D"white-space=
:nowrap">I do that by allowing concepts ( aka constraints) to be applied to=
both template and non-template type, using the notation that Jakob calls &=
quot;Adjectives" syntax.</span></font></div><div><font size=3D"2"><spa=
n style=3D"white-space:nowrap"><br></span></font></div><div><font size=3D"2=
"><span style=3D"white-space:nowrap">Uniformity, intuitiveness and tersenes=
s=C2=A0were the main driving goals.</span></font></div><div><br></div><div>=
<font size=3D"2"><span style=3D"white-space:nowrap"><a href=3D"https://cor3=
ntin.github.io/CPPProposals/unified_concept_declaration_syntax/concepts.htm=
l" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https=
://www.google.com/url?q\x3dhttps%3A%2F%2Fcor3ntin.github.io%2FCPPProposals%=
2Funified_concept_declaration_syntax%2Fconcepts.html\x26sa\x3dD\x26sntz\x3d=
1\x26usg\x3dAFQjCNGoUSYtAtfcroFxyCQluBMd3baSNg';return true;" onclick=
=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fcor3ntin=
..github.io%2FCPPProposals%2Funified_concept_declaration_syntax%2Fconcepts.h=
tml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGoUSYtAtfcroFxyCQluBMd3baSNg=
9;;return true;">https://cor3ntin.github.io/<wbr>CPPProposals/unified_conce=
pt_<wbr>declaration_syntax/concepts.<wbr>html</a></span><br></font></div><d=
iv><font size=3D"2"><span style=3D"white-space:nowrap"><br></span></font></=
div><div><font size=3D"2"><span style=3D"white-space:nowrap"><br></span></f=
ont></div><div><font size=3D"2"><span style=3D"white-space:nowrap">Please n=
ote that the document is not yet final, notably it is missing references an=
d acknowledgments.</span></font></div><div><font size=3D"2"><span style=3D"=
white-space:nowrap"><br></span></font></div><div><br></div><div>I hope to h=
ere your feedback !</div><div><br></div><div>Regards,=C2=A0 Corentin</div><=
/div></blockquote></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/ec68e22f-b287-4310-95ec-6f343dda68c1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ec68e22f-b287-4310-95ec-6f343dda68c1=
%40isocpp.org</a>.<br />
------=_Part_15049_1863124531.1510046311897--
------=_Part_15048_882252439.1510046311897--
.
Author: florian.csdt@gmail.com
Date: Tue, 7 Nov 2017 01:34:10 -0800 (PST)
Raw View
------=_Part_14984_1726861047.1510047250873
Content-Type: multipart/alternative;
boundary="----=_Part_14985_762168997.1510047250873"
------=_Part_14985_762168997.1510047250873
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I'm also not a standard expert at all. So please take my words with a grain=
=20
of salt.
I'm completely fine with this grammar. But I think it should be more=20
explicit in the proposal.
I don't know if anybody has other suggestion.
Le mardi 7 novembre 2017 10:18:32 UTC+1, Corentin a =C3=A9crit :
>
> I do address that a bit near the end of the document, maybe I should be=
=20
> more detailed.
> the idea ( and I'm sorry for not speaking standardeese well at all ) is=
=20
> to say that the "concept-name-sequence type-id" is the entity to which t=
he=20
> qualifiers apply.
> So const, volatile, *, &, etc will appear either before the concept=20
> sequence or after the type name.
> Of course, both the type and the concepts can have a nested name qualifie=
r.
>
> const std::Constructible auto & x =3D
> constexpr bar::GreaterThan<42> std::size_t s =3D
> const BadlyDesigned Foo *** const*** bar =3D =20
>
> Or to put it more simply, concepts appear always immediately before the=
=20
> type and concepts are immediately followed by a type.
> I think it's the simplest, less confusing way to do it.
>
> Was there alternative suggestions ?
>
>
> Le mardi 7 novembre 2017 09:58:18 UTC+1, floria...@gmail.com a =C3=A9crit=
:
>>
>> Hello Corentin,
>>
>> It looks good. I think the main issues are addressed, and the=20
>> uniformity/intuitiveness is clear.
>> However, I think you should address also how those concepts can be mix=
=20
>> with other qualifiers (const, volatile, *, &) in variable declarations a=
nd=20
>> function parameters.
>> There were no consensus on that in the previous thread (AFAIR).
>>
>> Florian
>>
>> Le lundi 6 novembre 2017 22:27:33 UTC+1, Corentin a =C3=A9crit :
>>>
>>> Hello.
>>> This proposal is a bit similar to Jakob Riedle's "Concepts are=20
>>> Adjectives, not Nouns" which you can read about here=20
>>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8hmr=
sEfg8Oc
>>>
>>>
>>> My goal was to have the same syntax, with the same semantic across=20
>>> lambda, function and templates parameters, as well as variable declarat=
ions=20
>>> and some other constructs.
>>> I do that by allowing concepts ( aka constraints) to be applied to both=
=20
>>> template and non-template type, using the notation that Jakob calls=20
>>> "Adjectives" syntax.
>>>
>>> Uniformity, intuitiveness and terseness were the main driving goals.
>>>
>>>
>>> https://cor3ntin.github.io/CPPProposals/unified_concept_declaration_syn=
tax/concepts.html
>>>
>>>
>>> Please note that the document is not yet final, notably it is missing=
=20
>>> references and acknowledgments.
>>>
>>>
>>> I hope to here your feedback !
>>>
>>> Regards, Corentin
>>>
>>
--=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/33084b7d-4a71-4403-969f-57ec93d38ab7%40isocpp.or=
g.
------=_Part_14985_762168997.1510047250873
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm also not a standard expert at all. So please take =
my words with a grain of salt.<br><br>I'm completely fine with this gra=
mmar. But I think it should be more explicit in the proposal.<br>I don'=
t know if anybody has other suggestion.<br><br>Le mardi 7 novembre 2017 10:=
18:32 UTC+1, Corentin a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr">I do address that a bit near the end of the doc=
ument, maybe I should be more detailed.<div>the idea ( and I'm sorry fo=
r not speaking standardeese well at all )=C2=A0 is to say that the=C2=A0 &q=
uot;concept-name-sequence type-id" is the entity to which the qualifie=
rs apply.</div><div>So const, volatile, *, &, etc will appear either be=
fore the concept sequence or after the type name.</div><div>Of course, both=
the type and the concepts can have a nested name qualifier.</div><div><br>=
</div><div>const std::Constructible auto & x =3D</div><div>constexpr=C2=
=A0 bar::GreaterThan<42> std::size_t s =3D</div><div>const BadlyDesig=
ned Foo *** const*** bar =3D=C2=A0=C2=A0</div><div><br></div><div>Or to put=
it more simply, concepts appear always immediately before the type and con=
cepts are immediately followed by a type.</div><div>I think it's the si=
mplest, less confusing way to do it.</div><div><br></div><div>Was there alt=
ernative suggestions ?</div><div><br><br>Le mardi 7 novembre 2017 09:58:18 =
UTC+1, <a>floria...@gmail.com</a> a =C3=A9crit=C2=A0:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">Hello Corentin,<br><br>It looks good. I =
think the main issues are addressed, and the uniformity/intuitiveness is cl=
ear.<br>However, I think you should address also how those concepts can be =
mix with other qualifiers (const, volatile, *, &) in variable declarati=
ons and function parameters.<br>There were no consensus on that in the prev=
ious thread (AFAIR).<br><br>Florian<br><br>Le lundi 6 novembre 2017 22:27:3=
3 UTC+1, Corentin a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">Hello.<div>This proposal is a bit similar to=C2=A0<span =
style=3D"white-space:nowrap">Jakob Riedle's "</span><span style=3D=
"white-space:nowrap"><font size=3D"2">Concepts are Adjectives, not Nouns&qu=
ot; which you can read about here=C2=A0</font></span><font size=3D"2"><span=
style=3D"white-space:nowrap"><a href=3D"https://groups.google.com/a/isocpp=
..org/forum/#!topic/std-proposals/8hmrsEfg8Oc" rel=3D"nofollow" target=3D"_b=
lank" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.or=
g/forum/#!topic/std-proposals/8hmrsEfg8Oc';return true;" onclick=3D"thi=
s.href=3D'https://groups.google.com/a/isocpp.org/forum/#!topic/std-prop=
osals/8hmrsEfg8Oc';return true;">https://groups.google.<wbr>com/a/isocp=
p.org/forum/#!<wbr>topic/std-proposals/<wbr>8hmrsEfg8Oc</a></span></font></=
div><div><font size=3D"2"><span style=3D"white-space:nowrap"><br></span></f=
ont></div><div><font size=3D"2"><span style=3D"white-space:nowrap"><br></sp=
an></font></div><div><font size=3D"2"><span style=3D"white-space:nowrap">My=
goal was to have the same syntax, with the same semantic across lambda, fu=
nction and templates parameters, as well as variable declarations and some =
other constructs.</span></font></div><div><font size=3D"2"><span style=3D"w=
hite-space:nowrap">I do that by allowing concepts ( aka constraints) to be =
applied to both template and non-template type, using the notation that Jak=
ob calls "Adjectives" syntax.</span></font></div><div><font size=
=3D"2"><span style=3D"white-space:nowrap"><br></span></font></div><div><fon=
t size=3D"2"><span style=3D"white-space:nowrap">Uniformity, intuitiveness a=
nd terseness=C2=A0were the main driving goals.</span></font></div><div><br>=
</div><div><font size=3D"2"><span style=3D"white-space:nowrap"><a href=3D"h=
ttps://cor3ntin.github.io/CPPProposals/unified_concept_declaration_syntax/c=
oncepts.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fcor3ntin.github.io%2F=
CPPProposals%2Funified_concept_declaration_syntax%2Fconcepts.html\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNGoUSYtAtfcroFxyCQluBMd3baSNg';return tru=
e;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F=
%2Fcor3ntin.github.io%2FCPPProposals%2Funified_concept_declaration_syntax%2=
Fconcepts.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGoUSYtAtfcroFxyCQluB=
Md3baSNg';return true;">https://cor3ntin.github.io/<wbr>CPPProposals/un=
ified_concept_<wbr>declaration_syntax/concepts.<wbr>html</a></span><br></fo=
nt></div><div><font size=3D"2"><span style=3D"white-space:nowrap"><br></spa=
n></font></div><div><font size=3D"2"><span style=3D"white-space:nowrap"><br=
></span></font></div><div><font size=3D"2"><span style=3D"white-space:nowra=
p">Please note that the document is not yet final, notably it is missing re=
ferences and acknowledgments.</span></font></div><div><font size=3D"2"><spa=
n style=3D"white-space:nowrap"><br></span></font></div><div><br></div><div>=
I hope to here your feedback !</div><div><br></div><div>Regards,=C2=A0 Core=
ntin</div></div></blockquote></div></blockquote></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/33084b7d-4a71-4403-969f-57ec93d38ab7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/33084b7d-4a71-4403-969f-57ec93d38ab7=
%40isocpp.org</a>.<br />
------=_Part_14985_762168997.1510047250873--
------=_Part_14984_1726861047.1510047250873--
.
Author: Tom Honermann <tom@honermann.net>
Date: Wed, 15 Nov 2017 10:56:59 -0500
Raw View
This is a multi-part message in MIME format.
--------------CF3267B9BC32B0376FDDF143
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
In section 1.1, the template parameters list doesn't include template=20
template parameters:
=C2=A0 template <template <typename> class T>
I suggest also noting that in the concept constrained case, the kind of=20
template parameter can be any of type, non-type, or template (according=20
to the concept's prototype template parameter; see=20
http://eel.is/c++draft/temp.param#10)
In section 1.2, the example code binds 'r' to two different things (a=20
template parameter, and a function parameter).=C2=A0 Perhaps you meant this=
?
=C2=A0 template <Regular R>
=C2=A0 void foo(R & r);
In section 1.2, the statement that "lambda cannot be constrained" is no=20
longer true; P0766 [1] as adopted in Albuquerque provides for requires=20
clauses in lambda expressions.
In section 2.1: support for 'auto' as a function parameter was rejected=20
(for now) in Albuquerque when P0766 [1] was discussed. This will be=20
revisited in Jacksonville.
In section 2.4.2, I recommend making it ill-formed for *any* constraints=20
to be specified with the initial 'auto' in a function declaration that=20
includes a trailing return type (don't just require that the constraints=20
match).
I like the discussion in 2.4.4; I don't think I've seen anyone suggest=20
use of concept names in place of 'typename' for dependent name=20
disambiguation.=C2=A0 I'm not yet sure if this is a good idea, but it is=20
interesting to think about.=C2=A0 I presume that the named concept's=20
prototype parameter must be a type template parameter for use in place=20
of 'typename'.=C2=A0 Perhaps you could also allow a concept with a prototyp=
e=20
template template parameter to be used in place of 'template'=20
disambiguation.=C2=A0 Would you also allow a concept with a non-type=20
prototype template parameter to be used where 'typename' and 'template'=20
disambiguation is not required? I'm not sure that this is useful, nor=20
whether it is reasonably possible within the existing grammar.
In section 2.4.5, I believe it is already allowed to specify constrained=20
parameters in template alias declarations.=C2=A0 I don't understand the fin=
al=20
example; is 'Stream' effectively a concept alias (I assume 'Iterable'=20
names a concept)?=C2=A0 That declaration also looks like a partial=20
specialization of a template alias, but those don't exist.=C2=A0 Perhaps yo=
u=20
intended 'template<Serializable T> using Stream =3D Iterable<T>'?
In section 2.4.6, there is no explanation of *why* you feel constraints=20
would be actively harmful in the cases mentioned.=C2=A0 The meta-classes=20
proposal includes the ability to associate a constraint with a class=20
template definition that would require all instantiations to satisfy the=20
constraints; I find that potentially useful.
In section 2.5: I think it is potentially useful to allow constraints to=20
be specified on pointers and references just as we can with existing=20
type qualifiers.=C2=A0 For example:
=C2=A0 auto * PointerToIntegral p =3D ...;=C2=A0 // The type of 'p' must s=
atisfy=20
PointerToIntegral.
In section 3, note that 'void foo(ConceptName auto a, decltype(a) b)' is=20
*not* equivalent to the consistent resolution behavior specified in the=20
concepts TS because the type of the argument for 'b' does not contribute=20
to type deduction.=C2=A0 See P0725 [2] for some discussion of this.=C2=A0=
=20
Specifying consistent resolution when concept names are not required to=20
deduce the same type requires a template header.=C2=A0 For example:
=C2=A0 template<ConceptName typename T> void foo(T a, T b);
Overall, I think the paper would benefit from more separation of=20
motivation from what is actually proposed.=C2=A0 I find the discussion=20
sometimes makes it confusing exactly what is and is not proposed.
What I would really like to see is for you, Jacob Riedle and Thomas=20
K=C3=B6ppe to join forces and author a single paper that presents the=20
motivation for these designs, the design options and tradeoffs, and a=20
single proposal.=C2=A0 Ideally, the paper would be presented in a form that=
=20
enabled EWG to vote on (and finally, hopefully, settle) a number of=20
design issues:
- Whether an abbreviated function syntax must have a 'template' keyword=20
in the declaration.
- Consistent-resolution vs independent-resolution.
- Concepts-as-qualifiers (adjectives) vs concepts-as-type-specifiers.
Tom.
[1]: http://wg21.link/p0766
[2]: http://wg21.link/p0725
On 11/06/2017 04:27 PM, Corentin wrote:
> Hello.
> This proposal is a bit similar to Jakob Riedle's "Concepts are=20
> Adjectives, not Nouns" which you can read about here=20
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8hmrsE=
fg8Oc
>
>
> My goal was to have the same syntax, with the same semantic across=20
> lambda, function and templates parameters, as well as variable=20
> declarations and some other constructs.
> I do that by allowing concepts ( aka constraints) to be applied to=20
> both template and non-template type, using the notation that Jakob=20
> calls "Adjectives" syntax.
>
> Uniformity, intuitiveness and terseness=C2=A0were the main driving goals.
>
> https://cor3ntin.github.io/CPPProposals/unified_concept_declaration_synta=
x/concepts.html
>
>
> Please note that the document is not yet final, notably it is missing=20
> references and acknowledgments.
>
>
> I hope to here your feedback !
>
> Regards,=C2=A0 Corentin
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1abe0443-19b=
e-4aff-8627-e87d1807b901%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1abe0443-19=
be-4aff-8627-e87d1807b901%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/2ba4fe39-c1bc-c48c-52d3-10a2e61ac699%40honermann=
..net.
--------------CF3267B9BC32B0376FDDF143
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">In section 1.1, the template parameters
list doesn't include template template parameters:<br>
=C2=A0 template <template <typename> class T><br>
I suggest also noting that in the concept constrained case, the
kind of template parameter can be any of type, non-type, or
template (according to the concept's prototype template parameter;
see <a class=3D"moz-txt-link-freetext" href=3D"http://eel.is/c++draft=
/temp.param#10">http://eel.is/c++draft/temp.param#10</a>)<br>
<br>
In section 1.2, the example code binds 'r' to two different things
(a template parameter, and a function parameter).=C2=A0 Perhaps you
meant this?<br>
=C2=A0 template <Regular R><br>
=C2=A0 void foo(R & r);<br>
<br>
In section 1.2, the statement that "lambda cannot be constrained"
is no longer true; P0766 [1] as adopted in Albuquerque provides
for requires clauses in lambda expressions.<br>
<br>
In section 2.1: support for 'auto' as a function parameter was
rejected (for now) in Albuquerque when P0766 [1] was discussed.=C2=A0
This will be revisited in Jacksonville.<br>
<br>
In section 2.4.2, I recommend making it ill-formed for *any*
constraints to be specified with the initial 'auto' in a function
declaration that includes a trailing return type (don't just
require that the constraints match).<br>
<br>
I like the discussion in 2.4.4; I don't think I've seen anyone
suggest use of concept names in place of 'typename' for dependent
name disambiguation.=C2=A0 I'm not yet sure if this is a good idea, b=
ut
it is interesting to think about.=C2=A0 I presume that the named
concept's prototype parameter must be a type template parameter
for use in place of 'typename'.=C2=A0 Perhaps you could also allow a
concept with a prototype template template parameter to be used in
place of 'template' disambiguation.=C2=A0 Would you also allow a
concept with a non-type prototype template parameter to be used
where 'typename' and 'template' disambiguation is not required?=C2=A0
I'm not sure that this is useful, nor whether it is reasonably
possible within the existing grammar.<br>
<br>
In section 2.4.5, I believe it is already allowed to specify
constrained parameters in template alias declarations.=C2=A0 I don't
understand the final example; is 'Stream' effectively a concept
alias (I assume 'Iterable' names a concept)?=C2=A0 That declaration
also looks like a partial specialization of a template alias, but
those don't exist.=C2=A0 Perhaps you intended 'template<Serializab=
le
T> using Stream =3D Iterable<T>'?<br>
<br>
In section 2.4.6, there is no explanation of *why* you feel
constraints would be actively harmful in the cases mentioned.=C2=A0 T=
he
meta-classes proposal includes the ability to associate a
constraint with a class template definition that would require all
instantiations to satisfy the constraints; I find that potentially
useful.<br>
<br>
In section 2.5: I think it is potentially useful to allow
constraints to be specified on pointers and references just as we
can with existing type qualifiers.=C2=A0 For example:<br>
=C2=A0 auto * PointerToIntegral p =3D ...;=C2=A0 // The type of 'p' m=
ust
satisfy PointerToIntegral.<br>
<br>
In section 3, note that 'void foo(ConceptName auto a, decltype(a)
b)' is *not* equivalent to the consistent resolution behavior
specified in the concepts TS because the type of the argument for
'b' does not contribute to type deduction.=C2=A0 See P0725 [2] for so=
me
discussion of this.=C2=A0 Specifying consistent resolution when conce=
pt
names are not required to deduce the same type requires a template
header.=C2=A0 For example:<br>
=C2=A0 template<ConceptName typename T> void foo(T a, T b);<br>
<br>
Overall, I think the paper would benefit from more separation of
motivation from what is actually proposed.=C2=A0 I find the discussio=
n
sometimes makes it confusing exactly what is and is not proposed.<br>
<br>
What I would really like to see is for you, Jacob Riedle and
Thomas K=C3=B6ppe to join forces and author a single paper that
presents the motivation for these designs, the design options and
tradeoffs, and a single proposal.=C2=A0 Ideally, the paper would be
presented in a form that enabled EWG to vote on (and finally,
hopefully, settle) a number of design issues:<br>
- Whether an abbreviated function syntax must have a 'template'
keyword in the declaration.<br>
- Consistent-resolution vs independent-resolution.<br>
- Concepts-as-qualifiers (adjectives) vs
concepts-as-type-specifiers.<br>
<br>
Tom.<br>
<br>
[1]: <a class=3D"moz-txt-link-freetext" href=3D"http://wg21.link/p076=
6">http://wg21.link/p0766</a><br>
[2]: <a class=3D"moz-txt-link-freetext" href=3D"http://wg21.link/p072=
5">http://wg21.link/p0725</a><br>
<br>
On 11/06/2017 04:27 PM, Corentin wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:1abe0443-19be-4aff-8627-e87d1807b901@isocpp.org">
<div dir=3D"ltr">Hello.
<div>This proposal is a bit similar to=C2=A0<span style=3D"white-sp=
ace:
nowrap;">Jakob Riedle's "</span><span style=3D"white-space:
nowrap;"><font size=3D"2">Concepts are Adjectives, not Nouns"
which you can read about here=C2=A0</font></span><font size=
=3D"2"><span
style=3D"white-space: nowrap;"><a class=3D"moz-txt-link-freet=
ext" href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-propo=
sals/8hmrsEfg8Oc">https://groups.google.com/a/isocpp.org/forum/#!topic/std-=
proposals/8hmrsEfg8Oc</a></span></font></div>
<div><font size=3D"2"><span style=3D"white-space: nowrap;"><br>
</span></font></div>
<div><font size=3D"2"><span style=3D"white-space: nowrap;"><br>
</span></font></div>
<div><font size=3D"2"><span style=3D"white-space: nowrap;">My goal
was to have the same syntax, with the same semantic across
lambda, function and templates parameters, as well as
variable declarations and some other constructs.</span></font=
></div>
<div><font size=3D"2"><span style=3D"white-space: nowrap;">I do tha=
t
by allowing concepts ( aka constraints) to be applied to
both template and non-template type, using the notation
that Jakob calls "Adjectives" syntax.</span></font></div>
<div><font size=3D"2"><span style=3D"white-space: nowrap;"><br>
</span></font></div>
<div><font size=3D"2"><span style=3D"white-space: nowrap;">Uniformi=
ty,
intuitiveness and terseness=C2=A0were the main driving goals.=
</span></font></div>
<div><br>
</div>
<div><font size=3D"2"><span style=3D"white-space: nowrap;"><a class=
=3D"moz-txt-link-freetext" href=3D"https://cor3ntin.github.io/CPPProposals/=
unified_concept_declaration_syntax/concepts.html">https://cor3ntin.github.i=
o/CPPProposals/unified_concept_declaration_syntax/concepts.html</a></span><=
br>
</font></div>
<div><font size=3D"2"><span style=3D"white-space: nowrap;"><br>
</span></font></div>
<div><font size=3D"2"><span style=3D"white-space: nowrap;"><br>
</span></font></div>
<div><font size=3D"2"><span style=3D"white-space: nowrap;">Please
note that the document is not yet final, notably it is
missing references and acknowledgments.</span></font></div>
<div><font size=3D"2"><span style=3D"white-space: nowrap;"><br>
</span></font></div>
<div><br>
</div>
<div>I hope to here your feedback !</div>
<div><br>
</div>
<div>Regards,=C2=A0 Corentin</div>
</div>
-- <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 email to <a
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
moz-do-not-send=3D"true">std-proposals+unsubscribe@isocpp.org</a>.<=
br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" moz-do-not-send=3D"true">s=
td-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1abe04=
43-19be-4aff-8627-e87d1807b901%40isocpp.org?utm_medium=3Demail&utm_sour=
ce=3Dfooter"
moz-do-not-send=3D"true">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/1abe0443-19be-4aff-8627-e87d1807b901%40isocpp.org</a>.<b=
r>
</blockquote>
<p><br>
</p>
</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/2ba4fe39-c1bc-c48c-52d3-10a2e61ac699%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/2ba4fe39-c1bc-c48c-52d3-10a2e61ac=
699%40honermann.net</a>.<br />
--------------CF3267B9BC32B0376FDDF143--
.
Author: Corentin <corentin.jabot@gmail.com>
Date: Wed, 15 Nov 2017 17:22:32 +0000
Raw View
--001a113b1cbe59a6de055e08c033
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le mer. 15 nov. 2017 =C3=A0 16:57, Tom Honermann <tom@honermann.net> a =C3=
=A9crit :
> In section 1.1, the template parameters list doesn't include template
> template parameters:
> template <template <typename> class T>
> I suggest also noting that in the concept constrained case, the kind of
> template parameter can be any of type, non-type, or template (according t=
o
> the concept's prototype template parameter; see
> http://eel.is/c++draft/temp.param#10)
>
I indeed did not address template template parameters. I must admit I'm not
100% comfortable with them, but the idea would be to do something like
template <template <typename> [concept-name-list] [class] T>.
There are also proposal to extend what can constitute a non-type
non-template template parameter.
>
> In section 1.2, the example code binds 'r' to two different things (a
> template parameter, and a function parameter). Perhaps you meant this?
> template <Regular R>
> void foo(R & r)
>
Indeed, will fix. I can't believed that survived as many proof-reading as
it did.
> In section 1.2, the statement that "lambda cannot be constrained" is no
> longer true; P0766 [1] as adopted in Albuquerque provides for requires
> clauses in lambda expressions.
>
Great, I wasn't aware.
In section 2.1: support for 'auto' as a function parameter was rejected
> (for now) in Albuquerque when P0766 [1] was discussed. This will be
> revisited in Jacksonville.
>
I know it was, I am still try to fight for it. To the end.
>
> In section 2.4.2, I recommend making it ill-formed for *any* constraints
> to be specified with the initial 'auto' in a function declaration that
> includes a trailing return type (don't just require that the constraints
> match).
>
Your are certainly right, that's probably the most reasonable approach
>
> I like the discussion in 2.4.4; I don't think I've seen anyone suggest us=
e
> of concept names in place of 'typename' for dependent name disambiguation=
..
> I'm not yet sure if this is a good idea, but it is interesting to think
> about. I presume that the named concept's prototype parameter must be a
> type template parameter for use in place of 'typename'. Perhaps you coul=
d
> also allow a concept with a prototype template template parameter to be
> used in place of 'template' disambiguation. Would you also allow a conce=
pt
> with a non-type prototype template parameter to be used where 'typename'
> and 'template' disambiguation is not required? I'm not sure that this is
> useful, nor whether it is reasonably possible within the existing grammar=
..
>
The idea comes P0634, and the general observation that typename is one of
this thing that gets mindlessly and grudgingly added by junior developers
when the compiler is unhappy. Hopefully, replacing that keyword with actual
information will make people think more about what they are doing, and add
information for subsequent readers. And typename was already a constraint
in that it force the type of the identifier to be a type. If that make
sense.
If I understand you correctly, what your propose would be like having a
constrained "valuename" ? The compilers could probably deal with it,
however would it add readability ?
You probably don't want to loose the "this is a type" information for the
human reader.
>
> In section 2.4.5, I believe it is already allowed to specify constrained
> parameters in template alias declarations. I don't understand the final
> example; is 'Stream' effectively a concept alias (I assume 'Iterable' nam=
es
> a concept)? That declaration also looks like a partial specialization of=
a
> template alias, but those don't exist. Perhaps you intended
> 'template<Serializable T> using Stream =3D Iterable<T>'?
>
The idea that actually was suggested by several people independently, was
to allow a an alias of a template type to be more constrained than the
original type. in this poorly made and explained example, Stream is an
alias on the Iterate template type, however it puts additional
requirements on the type ( or non type ) of its template parameter. In
insight, it may be worth of its own paper. I wouldn't say it's a
specialization, since it does not affect the declaration.
> In section 2.4.6, there is no explanation of *why* you feel constraints
> would be actively harmful in the cases mentioned. The meta-classes
> proposal includes the ability to associate a constraint with a class
> template definition that would require all instantiations to satisfy the
> constraints; I find that potentially useful.
>
Because it couples concepts and types, and then it starts to look more like
interfaces or inheritance. But maybe you are right that people may want to
advertise that a type respect a set of constraints.
I feel like it could have unwanted consequences, in the way people use and
see concepts?
You certainly made me realize I have to think about that more.
> In section 2.5: I think it is potentially useful to allow constraints to
> be specified on pointers and references just as we can with existing type
> qualifiers. For example:
> auto * PointerToIntegral p =3D ...; // The type of 'p' must satisfy
> PointerToIntegral.
>
Maybe ? I feel like this would have very limited use. We have syntax to
describe qualifiers, I don't think concepts add a lot information there.
But why not, as long as compilers writers have no reasons to be opposed to
it.
>
> In section 3, note that 'void foo(ConceptName auto a, decltype(a) b)' is
> *not* equivalent to the consistent resolution behavior specified in the
> concepts TS because the type of the argument for 'b' does not contribute =
to
> type deduction. See P0725 [2] for some discussion of this. Specifying
> consistent resolution when concept names are not required to deduce the
> same type requires a template header. For example:
> template<ConceptName typename T> void foo(T a, T b);
>
That's true. And I'm not arguing against that syntax. I'm arguing that in
functions template with auto parameter, each constraint should only apply
to the type immediately following.
Note that this does not break your example, ConceptName only appears once
in front of T.
> Overall, I think the paper would benefit from more separation of
> motivation from what is actually proposed. I find the discussion sometim=
es
> makes it confusing exactly what is and is not proposed.
>
Hum. I will try to work on on that. I was suggested to offer a summary of
the proposed syntaxes and your confusion is probably a good tell that it is
indeed necessary.
>
> What I would really like to see is for you, Jacob Riedle and Thomas K=C3=
=B6ppe
> to join forces and author a single paper that presents the motivation for
> these designs, the design options and tradeoffs, and a single proposal.
> Ideally, the paper would be presented in a form that enabled EWG to vote =
on
> (and finally, hopefully, settle) a number of design issues:
> - Whether an abbreviated function syntax must have a 'template' keyword i=
n
> the declaration.
> - Consistent-resolution vs independent-resolution.
> - Concepts-as-qualifiers (adjectives) vs concepts-as-type-specifiers.
>
I did try to contact Jacob Riedle, we will see what comes from that.
You are right that we would benefit from more discussion, though we
definitively have different take on this issue, even though there are lot
of similarities.
I hope I answered your questions.
Your feedback was really valuable and appreciated.
Corentin
>
> Tom.
>
> [1]: http://wg21.link/p0766
> [2]: http://wg21.link/p0725
>
>
> On 11/06/2017 04:27 PM, Corentin wrote:
>
> Hello.
> This proposal is a bit similar to Jakob Riedle's "Concepts are
> Adjectives, not Nouns" which you can read about here
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8hmrsE=
fg8Oc
>
>
> My goal was to have the same syntax, with the same semantic across lambda=
,
> function and templates parameters, as well as variable declarations and
> some other constructs.
> I do that by allowing concepts ( aka constraints) to be applied to both
> template and non-template type, using the notation that Jakob calls
> "Adjectives" syntax.
>
> Uniformity, intuitiveness and terseness were the main driving goals.
>
>
> https://cor3ntin.github.io/CPPProposals/unified_concept_declaration_synta=
x/concepts.html
>
>
> Please note that the document is not yet final, notably it is missing
> references and acknowledgments.
>
>
> I hope to here your feedback !
>
> Regards, Corentin
> --
> 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/1abe0443-19b=
e-4aff-8627-e87d1807b901%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1abe0443-19=
be-4aff-8627-e87d1807b901%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/CA%2BOm%2BShA9VJpD7jeofsjDSu3tCfoa0bU91FTJrMG1zQ=
cDtjrMw%40mail.gmail.com.
--001a113b1cbe59a6de055e08c033
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Le=C2=A0mer. 15 nov. 2017 =C3=A0=C2=A016:57, Tom Hone=
rmann <<a href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@honerm=
ann.net</a>> a =C3=A9crit=C2=A0:<br></div><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"m_-6422831882804423008m_-5521108176961802266moz-cite-pref=
ix">In section 1.1, the template parameters
list doesn't include template template parameters:<br>
=C2=A0 template <template <typename> class T><br>
I suggest also noting that in the concept constrained case, the
kind of template parameter can be any of type, non-type, or
template (according to the concept's prototype template parameter=
;
see <a class=3D"m_-6422831882804423008m_-5521108176961802266moz-txt-l=
ink-freetext" href=3D"http://eel.is/c++draft/temp.param#10" target=3D"_blan=
k">http://eel.is/c++draft/temp.param#10</a>)<br></div></div></blockquote><d=
iv><br></div><div>I indeed did not address template template parameters. I =
must admit I'm not 100% comfortable with them, but the idea would be to=
do something like=C2=A0 template <template <typename> [concept-na=
me-list] [class] T>.</div><div>There are also proposal to extend what ca=
n constitute a non-type non-template template parameter.</div><div><br></di=
v><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 text=3D"#000000" bgc=
olor=3D"#FFFFFF"><div class=3D"m_-6422831882804423008m_-5521108176961802266=
moz-cite-prefix">
<br>
In section 1.2, the example code binds 'r' to two different t=
hings
(a template parameter, and a function parameter).=C2=A0 Perhaps you
meant this?<br>
=C2=A0 template <Regular R><br>
=C2=A0 void foo(R & r)<br></div></div></blockquote><div><br></div=
><div><span style=3D"color:rgb(33,33,33)">Indeed, will fix.</span>=C2=A0I c=
an't believed that survived as many proof-reading as it did.=C2=A0</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 text=3D"#000000" bgco=
lor=3D"#FFFFFF"><div class=3D"m_-6422831882804423008m_-5521108176961802266m=
oz-cite-prefix">
In section 1.2, the statement that "lambda cannot be constrained=
"
is no longer true; P0766 [1] as adopted in Albuquerque provides
for requires clauses in lambda expressions.<br></div></div></blockquo=
te><div><br></div><div><span style=3D"color:rgb(33,33,33)">Great, I wasn=
9;t aware.</span></div><div><br></div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div class=3D"m_-6422831=
882804423008m_-5521108176961802266moz-cite-prefix">
In section 2.1: support for 'auto' as a function parameter wa=
s
rejected (for now) in Albuquerque when P0766 [1] was discussed.=C2=A0
This will be revisited in Jacksonville.<br></div></div></blockquote><=
div><br></div><div>I know it was, I am still try to fight for it. To the en=
d.</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 text=3D"#00000=
0" bgcolor=3D"#FFFFFF"><div class=3D"m_-6422831882804423008m_-5521108176961=
802266moz-cite-prefix">
<br>
In section 2.4.2, I recommend making it ill-formed for *any*
constraints to be specified with the initial 'auto' in a func=
tion
declaration that includes a trailing return type (don't just
require that the constraints match).<br></div></div></blockquote><div=
><br></div><div><div dir=3D"ltr"><div><font color=3D"#212121">Your are cert=
ainly right, that's probably=C2=A0the most reasonable approach</font></=
div></div></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 text=
=3D"#000000" bgcolor=3D"#FFFFFF"><div class=3D"m_-6422831882804423008m_-552=
1108176961802266moz-cite-prefix">
<br>
I like the discussion in 2.4.4; I don't think I've seen anyon=
e
suggest use of concept names in place of 'typename' for depen=
dent
name disambiguation.=C2=A0 I'm not yet sure if this is a good ide=
a, but
it is interesting to think about.=C2=A0 I presume that the named
concept's prototype parameter must be a type template parameter
for use in place of 'typename'.=C2=A0 Perhaps you could also =
allow a
concept with a prototype template template parameter to be used in
place of 'template' disambiguation.=C2=A0 Would you also allo=
w a
concept with a non-type prototype template parameter to be used
where 'typename' and 'template' disambiguation is not=
required?=C2=A0
I'm not sure that this is useful, nor whether it is reasonably
possible within the existing grammar.<br></div></div></blockquote><di=
v><br></div><div>The idea comes=C2=A0P0634, and the general observation tha=
t=C2=A0typename is one of this thing that gets mindlessly and grudgingly ad=
ded by junior developers when the compiler is unhappy. Hopefully, replacing=
that keyword with actual information will make people think more about wha=
t they are doing, and add information for subsequent readers. And typename =
was already a constraint in that it force the type of the identifier to be =
a type. If that make sense.</div><div><br></div><div>If I understand you co=
rrectly, what your propose would be like having a constrained "valuena=
me" ? The compilers could probably deal with it, however would it add =
readability ?</div><div>You probably don't want to loose the "this=
is a type" information for the human reader.</div><div><br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div text=3D"#000000" bgcolor=
=3D"#FFFFFF"><div class=3D"m_-6422831882804423008m_-5521108176961802266moz-=
cite-prefix">
<br>
In section 2.4.5, I believe it is already allowed to specify
constrained parameters in template alias declarations.=C2=A0 I don=
9;t
understand the final example; is 'Stream' effectively a conce=
pt
alias (I assume 'Iterable' names a concept)?=C2=A0 That decla=
ration
also looks like a partial specialization of a template alias, but
those don't exist.=C2=A0 Perhaps you intended 'template<Se=
rializable
T> using Stream =3D Iterable<T>'?<br></div></div></block=
quote><div><br></div><div><font color=3D"#212121"><br class=3D"inbox-inbox-=
Apple-interchange-newline">The idea that actually was suggested by several =
people independently,=C2=A0 was to allow a an alias of a template type to b=
e more constrained than the original type. in this poorly made and explaine=
d example, Stream is an alias on the Iterate=C2=A0template type, however it=
puts additional requirements=C2=A0on the type ( or non type ) of its templ=
ate parameter. In insight, it may be worth of its own paper.=C2=A0</font><s=
pan style=3D"color:rgb(33,33,33)">I wouldn't say it's a specializat=
ion, since it does not affect the declaration.</span><br></div><div><span s=
tyle=3D"color:rgb(33,33,33)"><br></span></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 text=3D"#000000" bgcolor=3D"#FFFFFF"><div class=3D"=
m_-6422831882804423008m_-5521108176961802266moz-cite-prefix">
In section 2.4.6, there is no explanation of *why* you feel
constraints would be actively harmful in the cases mentioned.=C2=A0 T=
he
meta-classes proposal includes the ability to associate a
constraint with a class template definition that would require all
instantiations to satisfy the constraints; I find that potentially
useful.<br></div></div></blockquote><div><br></div><div>Because it co=
uples concepts and types, and then it starts to look more like interfaces o=
r inheritance. But maybe you are right that people may want to advertise th=
at a type respect a set of constraints.</div><div>I feel like it could have=
unwanted consequences, in the way people use and see concepts?</div><div><=
br></div><div>You certainly made me realize I have to think about that more=
..</div><div><br></div><div><br></div><div><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div cla=
ss=3D"m_-6422831882804423008m_-5521108176961802266moz-cite-prefix">
In section 2.5: I think it is potentially useful to allow
constraints to be specified on pointers and references just as we
can with existing type qualifiers.=C2=A0 For example:<br>
=C2=A0 auto * PointerToIntegral p =3D ...;=C2=A0 // The type of '=
p' must
satisfy PointerToIntegral.<br></div></div></blockquote><div><br></div=
><div>Maybe ? I feel like this would have very limited use.=C2=A0 =C2=A0We =
have syntax to describe qualifiers, I don't think concepts add a lot in=
formation there.=C2=A0=C2=A0</div><div>But why not, as long as compilers wr=
iters have no reasons to be opposed to it.<br></div><div><br></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 text=3D"#000000" bgcolor=3D"#F=
FFFFF"><div class=3D"m_-6422831882804423008m_-5521108176961802266moz-cite-p=
refix">
<br>
In section 3, note that 'void foo(ConceptName auto a, decltype(a)
b)' is *not* equivalent to the consistent resolution behavior
specified in the concepts TS because the type of the argument for
'b' does not contribute to type deduction.=C2=A0 See P0725 [2=
] for some
discussion of this.=C2=A0 Specifying consistent resolution when conce=
pt
names are not required to deduce the same type requires a template
header.=C2=A0 For example:<br>
=C2=A0 template<ConceptName typename T> void foo(T a, T b);<br>=
</div></div></blockquote><div><br></div><div>That's true. And I'm n=
ot arguing against that syntax. I'm arguing that in functions template =
with auto parameter, each constraint should only apply to the type immediat=
ely following.</div><div>Note that this does not break your example, Concep=
tName only appears once in front of T.=C2=A0</div><div><br></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 text=3D"#000000" bgcolor=3D"#F=
FFFFF"><div class=3D"m_-6422831882804423008m_-5521108176961802266moz-cite-p=
refix">
Overall, I think the paper would benefit from more separation of
motivation from what is actually proposed.=C2=A0 I find the discussio=
n
sometimes makes it confusing exactly what is and is not proposed.<br>=
</div></div></blockquote><div><br></div><div>Hum. I will try to work on on =
that. I was suggested to offer a summary of the proposed syntaxes and your =
confusion is probably a good tell that it is indeed necessary.</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 text=3D"#000000" bgcolor=3D=
"#FFFFFF"><div class=3D"m_-6422831882804423008m_-5521108176961802266moz-cit=
e-prefix">
<br>
What I would really like to see is for you, Jacob Riedle and
Thomas K=C3=B6ppe to join forces and author a single paper that
presents the motivation for these designs, the design options and
tradeoffs, and a single proposal.=C2=A0 Ideally, the paper would be
presented in a form that enabled EWG to vote on (and finally,
hopefully, settle) a number of design issues:<br>
- Whether an abbreviated function syntax must have a 'template=
9;
keyword in the declaration.<br>
- Consistent-resolution vs independent-resolution.<br>
- Concepts-as-qualifiers (adjectives) vs
concepts-as-type-specifiers.<br></div></div></blockquote><div><br></d=
iv><div>I did try to contact Jacob Riedle, we will see what comes from that=
..</div><div>You are right that we would benefit from more discussion, thoug=
h we definitively have different take on this issue, even though there are =
lot of similarities.</div><div><br></div><div><br></div><div>I hope I answe=
red your questions.</div><div>Your feedback was really valuable and appreci=
ated.=C2=A0</div><div><br></div><div>Corentin</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div clas=
s=3D"m_-6422831882804423008m_-5521108176961802266moz-cite-prefix">
<br>
Tom.<br>
<br>
[1]: <a class=3D"m_-6422831882804423008m_-5521108176961802266moz-txt-=
link-freetext" href=3D"http://wg21.link/p0766" target=3D"_blank">http://wg2=
1.link/p0766</a><br>
[2]: <a class=3D"m_-6422831882804423008m_-5521108176961802266moz-txt-=
link-freetext" href=3D"http://wg21.link/p0725" target=3D"_blank">http://wg2=
1.link/p0725</a></div></div><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div =
class=3D"m_-6422831882804423008m_-5521108176961802266moz-cite-prefix"><br>
<br>
On 11/06/2017 04:27 PM, Corentin wrote:<br>
</div></div><div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">Hello.
<div>This proposal is a bit similar to=C2=A0<span style=3D"white-sp=
ace:nowrap">Jakob Riedle's "</span><span style=3D"white-space:nowr=
ap"><font size=3D"2">Concepts are Adjectives, not Nouns"
which you can read about here=C2=A0</font></span><font size=
=3D"2"><span style=3D"white-space:nowrap"><a class=3D"m_-642283188280442300=
8m_-5521108176961802266moz-txt-link-freetext" href=3D"https://groups.google=
..com/a/isocpp.org/forum/#!topic/std-proposals/8hmrsEfg8Oc" target=3D"_blank=
">https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8hmrsE=
fg8Oc</a></span></font></div>
<div><font size=3D"2"><span style=3D"white-space:nowrap"><br>
</span></font></div>
<div><font size=3D"2"><span style=3D"white-space:nowrap"><br>
</span></font></div>
<div><font size=3D"2"><span style=3D"white-space:nowrap">My goal
was to have the same syntax, with the same semantic across
lambda, function and templates parameters, as well as
variable declarations and some other constructs.</span></font=
></div>
<div><font size=3D"2"><span style=3D"white-space:nowrap">I do that
by allowing concepts ( aka constraints) to be applied to
both template and non-template type, using the notation
that Jakob calls "Adjectives" syntax.</span></font>=
</div>
<div><font size=3D"2"><span style=3D"white-space:nowrap"><br>
</span></font></div>
<div><font size=3D"2"><span style=3D"white-space:nowrap">Uniformity=
,
intuitiveness and terseness=C2=A0were the main driving goals.=
</span></font></div>
<div><br>
</div>
<div><font size=3D"2"><span style=3D"white-space:nowrap"><a class=
=3D"m_-6422831882804423008m_-5521108176961802266moz-txt-link-freetext" href=
=3D"https://cor3ntin.github.io/CPPProposals/unified_concept_declaration_syn=
tax/concepts.html" target=3D"_blank">https://cor3ntin.github.io/CPPProposal=
s/unified_concept_declaration_syntax/concepts.html</a></span><br>
</font></div>
<div><font size=3D"2"><span style=3D"white-space:nowrap"><br>
</span></font></div>
<div><font size=3D"2"><span style=3D"white-space:nowrap"><br>
</span></font></div>
<div><font size=3D"2"><span style=3D"white-space:nowrap">Please
note that the document is not yet final, notably it is
missing references and acknowledgments.</span></font></div>
<div><font size=3D"2"><span style=3D"white-space:nowrap"><br>
</span></font></div>
<div><br>
</div>
<div>I hope to here your feedback !</div>
<div><br>
</div>
<div>Regards,=C2=A0 Corentin</div>
</div>
-- <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 email to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.o=
rg" 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.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/1abe0443-19be-4aff-8627-e87d180=
7b901%40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_b=
lank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1abe0443=
-19be-4aff-8627-e87d1807b901%40isocpp.org</a>.<br>
</blockquote>
<p><br>
</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/CA%2BOm%2BShA9VJpD7jeofsjDSu3tCfoa0bU=
91FTJrMG1zQcDtjrMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BShA=
9VJpD7jeofsjDSu3tCfoa0bU91FTJrMG1zQcDtjrMw%40mail.gmail.com</a>.<br />
--001a113b1cbe59a6de055e08c033--
.
Author: Tom Honermann <tom@honermann.net>
Date: Wed, 15 Nov 2017 22:59:17 -0500
Raw View
This is a multi-part message in MIME format.
--------------BAF0C1BA1D53EF3681439BB9
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 11/15/2017 12:22 PM, Corentin wrote:
> Le=C2=A0mer. 15 nov. 2017 =C3=A0=C2=A016:57, Tom Honermann <tom@honermann=
..net=20
> <mailto:tom@honermann.net>> a =C3=A9crit=C2=A0:
>
>
> I like the discussion in 2.4.4; I don't think I've seen anyone
> suggest use of concept names in place of 'typename' for dependent
> name disambiguation.=C2=A0 I'm not yet sure if this is a good idea, b=
ut
> it is interesting to think about.=C2=A0 I presume that the named
> concept's prototype parameter must be a type template parameter
> for use in place of 'typename'.=C2=A0 Perhaps you could also allow a
> concept with a prototype template template parameter to be used in
> place of 'template' disambiguation.=C2=A0 Would you also allow a
> concept with a non-type prototype template parameter to be used
> where 'typename' and 'template' disambiguation is not required?=C2=A0
> I'm not sure that this is useful, nor whether it is reasonably
> possible within the existing grammar.
>
>
> The idea comes=C2=A0P0634, and the general observation that=C2=A0typename=
is one=20
> of this thing that gets mindlessly and grudgingly added by junior=20
> developers when the compiler is unhappy. Hopefully, replacing that=20
> keyword with actual information will make people think more about what=20
> they are doing, and add information for subsequent readers. And=20
> typename was already a constraint in that it force the type of the=20
> identifier to be a type. If that make sense.
>
> If I understand you correctly, what your propose would be like having=20
> a constrained "valuename" ? The compilers could probably deal with it,=20
> however would it add readability ?
> You probably don't want to loose the "this is a type" information for=20
> the human reader.
I didn't intent to propose it, nor suggest that it might be useful, but=20
maybe worth thinking about.=C2=A0 Maybe.=C2=A0 I can't think of a reasonabl=
y=20
motivating example.=C2=A0 In each example I've thought of, I find myself=20
thinking the constraint belongs in the requires clause of the template.=C2=
=A0=20
But that seems likely to be true for cases where you would specify a=20
concept name in place of 'typename' or 'template' as well, so maybe=20
there just isn't much motivation for this at all.
>
> In section 2.4.5, I believe it is already allowed to specify
> constrained parameters in template alias declarations.=C2=A0 I don't
> understand the final example; is 'Stream' effectively a concept
> alias (I assume 'Iterable' names a concept)?=C2=A0 That declaration
> also looks like a partial specialization of a template alias, but
> those don't exist.=C2=A0 Perhaps you intended 'template<Serializable =
T>
> using Stream =3D Iterable<T>'?
>
>
>
> The idea that actually was suggested by several people independently,=C2=
=A0=20
> was to allow a an alias of a template type to be more constrained than=20
> the original type. in this poorly made and explained example, Stream=20
> is an alias on the Iterate=C2=A0template type, however it puts additional=
=20
> requirements=C2=A0on the type ( or non type ) of its template parameter. =
In=20
> insight, it may be worth of its own paper. I wouldn't say it's a=20
> specialization, since it does not affect the declaration.
The semantics are still unclear to me; I think this section could use=20
some more explanation as well as an example.=C2=A0 How do I use this 'Strea=
m'=20
alias?=C2=A0 Is 'Stream<MyType> X;' a valid declaration that is only=20
well-formed if 'MyType' satisfies both 'Iterable' and 'Serializable'?=C2=A0=
=20
Can I use 'Stream' as a constrained-parameter as in 'template<Stream T>=20
class X;'?=C2=A0 If so, this seems to be introducing a concept alias as=20
opposed to a type alias; which seems unnecessary since=20
'template<typename T> concept Stream =3D requires Serializable<T> &&=20
Iterable<T>' achieves the same result.
Assuming I'm following correctly, I think a different syntax is=20
necessary since 'template<Serializable T> using Stream<T> =3D ...' is the=
=20
syntax that would be expected for a partial specialization of an alias=20
template (if such things existed).=C2=A0 This is why I asked if the '<T>' a=
t=20
the end of 'Stream' is really intended.
> In section 2.5: I think it is potentially useful to allow
> constraints to be specified on pointers and references just as we
> can with existing type qualifiers.=C2=A0 For example:
> =C2=A0 auto * PointerToIntegral p =3D ...;=C2=A0 // The type of 'p' m=
ust
> satisfy PointerToIntegral.
>
>
> Maybe ? I feel like this would have very limited use. =C2=A0We have synta=
x=20
> to describe qualifiers, I don't think concepts add a lot information=20
> there.
> But why not, as long as compilers writers have no reasons to be=20
> opposed to it.
I agree the uses would be relatively rare, but I like that this follows=20
the existing rules for type qualifiers.=C2=A0 It does complicate interactio=
n=20
with 'const' and 'volatile', but perhaps no more so than is necessary=20
anyway.=C2=A0 I think your section 2.5 could provide an example like the=20
following:
=C2=A0 const Fooable auto foo =3D {};
=C2=A0 Fooable const auto foo =3D {};
=C2=A0 const auto foo Fooable =3D {};=C2=A0 // ill-formed because the cons=
traint=20
follows the name?
=C2=A0 Fooable auto foo const =3D {};
=C2=A0 auto foo const Fooable =3D {};=C2=A0 // ill-formed because the cons=
traint=20
follows the name?
=C2=A0 auto foo Fooable const =3D {};=C2=A0 // ill-formed because the cons=
traint=20
follows the name?
Are all of these semantically equivalent?=C2=A0 Are some ill-formed as indi=
cated?
>
>
> In section 3, note that 'void foo(ConceptName auto a, decltype(a)
> b)' is *not* equivalent to the consistent resolution behavior
> specified in the concepts TS because the type of the argument for
> 'b' does not contribute to type deduction.=C2=A0 See P0725 [2] for so=
me
> discussion of this.=C2=A0 Specifying consistent resolution when conce=
pt
> names are not required to deduce the same type requires a template
> header.=C2=A0 For example:
> =C2=A0 template<ConceptName typename T> void foo(T a, T b);
>
>
> That's true. And I'm not arguing against that syntax. I'm arguing that=20
> in functions template with auto parameter, each constraint should only=20
> apply to the type immediately following.
> Note that this does not break your example, ConceptName only appears=20
> once in front of T.
Right, you are arguing for independent resolution; which I'm in favor of=20
as well.=C2=A0 The point I was trying to make is that 'void foo(ConceptName=
=20
auto a, decltype(a) b)' is probably *not* the desired semantics in most=20
cases (though it is in some cases).
Tom.
--=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/8fe31af5-e98c-3253-0030-85ffe64685d5%40honermann=
..net.
--------------BAF0C1BA1D53EF3681439BB9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">On 11/15/2017 12:22 PM, Corentin wrote:<=
br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:CA+Om+ShA9VJpD7jeofsjDSu3tCfoa0bU91FTJrMG1zQcDtjrMw@mail.gmail.=
com">
<div dir=3D"ltr">
<div>Le=C2=A0mer. 15 nov. 2017 =C3=A0=C2=A016:57, Tom Honermann <=
;<a
href=3D"mailto:tom@honermann.net" target=3D"_blank"
moz-do-not-send=3D"true">tom@honermann.net</a>> a =C3=A9crit=
=C2=A0:<br>
</div>
<div class=3D"gmail_quote">=C2=A0
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div
class=3D"m_-6422831882804423008m_-5521108176961802266moz-ci=
te-prefix">
<br>
I like the discussion in 2.4.4; I don't think I've seen
anyone suggest use of concept names in place of
'typename' for dependent name disambiguation.=C2=A0 I'm not
yet sure if this is a good idea, but it is interesting
to think about.=C2=A0 I presume that the named concept's
prototype parameter must be a type template parameter
for use in place of 'typename'.=C2=A0 Perhaps you could als=
o
allow a concept with a prototype template template
parameter to be used in place of 'template'
disambiguation.=C2=A0 Would you also allow a concept with a
non-type prototype template parameter to be used where
'typename' and 'template' disambiguation is not
required?=C2=A0 I'm not sure that this is useful, nor wheth=
er
it is reasonably possible within the existing grammar.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>The idea comes=C2=A0P0634, and the general observation
that=C2=A0typename is one of this thing that gets mindlessly an=
d
grudgingly added by junior developers when the compiler is
unhappy. Hopefully, replacing that keyword with actual
information will make people think more about what they are
doing, and add information for subsequent readers. And
typename was already a constraint in that it force the type
of the identifier to be a type. If that make sense.</div>
<div><br>
</div>
<div>If I understand you correctly, what your propose would be
like having a constrained "valuename" ? The compilers could
probably deal with it, however would it add readability ?</div>
<div>You probably don't want to loose the "this is a type"
information for the human reader.</div>
</div>
</div>
</blockquote>
<br>
I didn't intent to propose it, nor suggest that it might be useful,
but maybe worth thinking about.=C2=A0 Maybe.=C2=A0 I can't think of a
reasonably motivating example.=C2=A0 In each example I've thought of, I
find myself thinking the constraint belongs in the requires clause
of the template.=C2=A0 But that seems likely to be true for cases where
you would specify a concept name in place of 'typename' or
'template' as well, so maybe there just isn't much motivation for
this at all.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:CA+Om+ShA9VJpD7jeofsjDSu3tCfoa0bU91FTJrMG1zQcDtjrMw@mail.gmail.=
com">
<div dir=3D"ltr">
<div class=3D"gmail_quote">
<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 text=3D"#000000" bgcolor=3D"#FFFFFF">
<div
class=3D"m_-6422831882804423008m_-5521108176961802266moz-ci=
te-prefix">
<br>
In section 2.4.5, I believe it is already allowed to
specify constrained parameters in template alias
declarations.=C2=A0 I don't understand the final example; i=
s
'Stream' effectively a concept alias (I assume
'Iterable' names a concept)?=C2=A0 That declaration also
looks like a partial specialization of a template alias,
but those don't exist.=C2=A0 Perhaps you intended
'template<Serializable T> using Stream =3D
Iterable<T>'?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><font color=3D"#212121"><br
class=3D"inbox-inbox-Apple-interchange-newline">
The idea that actually was suggested by several people
independently,=C2=A0 was to allow a an alias of a template ty=
pe
to be more constrained than the original type. in this
poorly made and explained example, Stream is an alias on
the Iterate=C2=A0template type, however it puts additional
requirements=C2=A0on the type ( or non type ) of its template
parameter. In insight, it may be worth of its own paper.=C2=
=A0</font><span
style=3D"color:rgb(33,33,33)">I wouldn't say it's a
specialization, since it does not affect the declaration.</sp=
an><br>
</div>
</div>
</div>
</blockquote>
<br>
The semantics are still unclear to me; I think this section could
use some more explanation as well as an example.=C2=A0 How do I use thi=
s
'Stream' alias?=C2=A0 Is 'Stream<MyType> X;' a valid declaration
that is only well-formed if 'MyType' satisfies both 'Iterable' and
'Serializable'?=C2=A0 Can I use 'Stream' as a constrained-parameter as =
in
'template<Stream T> class X;'?=C2=A0 If so, this seems to be
introducing a concept alias as opposed to a type alias; which seems
unnecessary since 'template<typename T> concept Stream =3D
requires Serializable<T> && Iterable<T>'
achieves the same result.<br>
<br>
Assuming I'm following correctly, I think a different syntax is
necessary since 'template<Serializable T> using
Stream<T> =3D ...' is the syntax that would be expected for a
partial specialization of an alias template (if such things
existed).=C2=A0 This is why I asked if the '<T>' at the end of
'Stream' is really intended.<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:CA+Om+ShA9VJpD7jeofsjDSu3tCfoa0bU91FTJrMG1zQcDtjrMw@mail.gmail.=
com">
<div dir=3D"ltr">
<div class=3D"gmail_quote">
<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 text=3D"#000000" bgcolor=3D"#FFFFFF">
<div
class=3D"m_-6422831882804423008m_-5521108176961802266moz-ci=
te-prefix">
In section 2.5: I think it is potentially useful to
allow constraints to be specified on pointers and
references just as we can with existing type
qualifiers.=C2=A0 For example:<br>
=C2=A0 auto * PointerToIntegral p =3D ...;=C2=A0 // The typ=
e of 'p'
must satisfy PointerToIntegral.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Maybe ? I feel like this would have very limited use.=C2=A0
=C2=A0We have syntax to describe qualifiers, I don't think
concepts add a lot information there.=C2=A0=C2=A0</div>
<div>But why not, as long as compilers writers have no reasons
to be opposed to it.<br>
</div>
</div>
</div>
</blockquote>
<br>
I agree the uses would be relatively rare, but I like that this
follows the existing rules for type qualifiers.=C2=A0 It does complicat=
e
interaction with 'const' and 'volatile', but perhaps no more so than
is necessary anyway.=C2=A0 I think your section 2.5 could provide an
example like the following:<br>
<br>
=C2=A0 const Fooable auto foo =3D {};<br>
=C2=A0 Fooable const auto foo =3D {};<br>
=C2=A0 const auto foo Fooable =3D {};=C2=A0 // ill-formed because the c=
onstraint
follows the name?<br>
=C2=A0 Fooable auto foo const =3D {};<br>
=C2=A0 auto foo const Fooable =3D {};=C2=A0 // ill-formed because the c=
onstraint
follows the name?<br>
=C2=A0 auto foo Fooable const =3D {};=C2=A0 // ill-formed because the c=
onstraint
follows the name?<br>
<br>
Are all of these semantically equivalent?=C2=A0 Are some ill-formed as
indicated?<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:CA+Om+ShA9VJpD7jeofsjDSu3tCfoa0bU91FTJrMG1zQcDtjrMw@mail.gmail.=
com">
<div dir=3D"ltr">
<div class=3D"gmail_quote">
<div><br>
</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 text=3D"#000000" bgcolor=3D"#FFFFFF">
<div
class=3D"m_-6422831882804423008m_-5521108176961802266moz-ci=
te-prefix">
<br>
In section 3, note that 'void foo(ConceptName auto a,
decltype(a) b)' is *not* equivalent to the consistent
resolution behavior specified in the concepts TS because
the type of the argument for 'b' does not contribute to
type deduction.=C2=A0 See P0725 [2] for some discussion of
this.=C2=A0 Specifying consistent resolution when concept
names are not required to deduce the same type requires
a template header.=C2=A0 For example:<br>
=C2=A0 template<ConceptName typename T> void foo(T a,=
T
b);<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>That's true. And I'm not arguing against that syntax. I'm
arguing that in functions template with auto parameter, each
constraint should only apply to the type immediately
following.</div>
<div>Note that this does not break your example, ConceptName
only appears once in front of T. <br>
</div>
</div>
</div>
</blockquote>
<br>
Right, you are arguing for independent resolution; which I'm in
favor of as well.=C2=A0 The point I was trying to make is that 'void
foo(ConceptName auto a, decltype(a) b)' is probably *not* the
desired semantics in most cases (though it is in some cases).<br>
<br>
Tom.<br>
</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/8fe31af5-e98c-3253-0030-85ffe64685d5%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/8fe31af5-e98c-3253-0030-85ffe6468=
5d5%40honermann.net</a>.<br />
--------------BAF0C1BA1D53EF3681439BB9--
.
Author: mihailnajdenov@gmail.com
Date: Sat, 6 Jan 2018 05:14:52 -0800 (PST)
Raw View
------=_Part_8303_1252375727.1515244492709
Content-Type: multipart/alternative;
boundary="----=_Part_8304_1535418908.1515244492710"
------=_Part_8304_1535418908.1515244492710
Content-Type: text/plain; charset="UTF-8"
Hello, I wanted to share my thoughts on the broad topic of "Concepts as
Adjectives".
I believe they are not as innocent as presented.
*First,* a new category of user provided entities is silently introduced -
type decorators. This is bigger a change then implied.
Up until this point all decorations were either keywords or attributes, and
now we have something which looks like a type (or even a template!), used
as a qualifier to some other (real) type or auto.
Sooner or later people will start asking, why I just can write only the
decorator and the type be deduced, which the paper actually allow. In that
case question arises do why do we need this new category in the first place.
*Second*. Consider const Point arg. const is not about the type, *it's
about the variable. *The fact that C++ handles const as a different type of
Point is an implementation detail.
However "type decorations" will be all about the type, in that one line we
will have some decorations which *semantically* are about the variable and
others about the type of it! This is bound to lead to confusion.
Also. const int a; will always bind to an int b, but a MyClass c, might not
bind to MyConstraign Class d; Yet both are spelled out with the same
syntax, both are "a case where one is just more constrained then the
other", but in practice mean different things.
*Third. *Consider A auto a = ...; B int b = ...; From the C++ rules so far
we might consider both of these are semantically the same, just in the
second case the auto is spelled out. In fact however these two, are
*radically* different - the first is constrained *type*, the other is
constrained *value*. This can be confusing no matter how we look at it - if
we look from variable declaration PoV we expect *both to be types *(but
they are not) if we look at template argument declaration PoV (<auto I>,
<int I>) we expect *both to be a value, *which is also not true!
The confusion with out continues with the fact A auto means one thing in
code (as return value, variable or argument) and different as template
param.
f(A auto a){}; A auto a; A auto f() {} are (*radically*) different then template<B
auto I>.
Yes, one can argue this is already the case, but this does not help either,
not to mention auto as function params is not yet in.
Forth*. *Decorations are, by there nature, an ad hoc tool - to have
something existing and to further specify it in the place of use.
Constrained types are not like that, ad hoc constrain creation is unlikely. Swappable
Sortable Writable foo; in the real world will likely be just FooConcept
foo; semantically. It is very unlikely one will need to mix and match
constrains on the go and pay the syntax, maintenance, visual noise tax.
I believe we should streamline Concepts as much as possible actually
removing features and "optional syntaxes" before adding new ones. By
streamline I don't mean a "terse syntax", just a sane one, be it a verbose
one (at first).
And BTW a non-sane syntax is to have both function and variable way to
declare a concept, to have that stupid bool and so on, in other words most
(but not all) of what is written in Concepts TS revisited
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0587r0.pdf>
Thanks
MN
--
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/3c6d5694-b335-4aa1-983f-3218843a738e%40isocpp.org.
------=_Part_8304_1535418908.1515244492710
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hello, I wanted to share my thoughts on the broad top=
ic of "Concepts as Adjectives".=C2=A0</div><div><br></div><div>I =
believe they are not as innocent as presented.</div><div><br></div><div><br=
></div><div><b>First,</b> a new category of user provided entities is=C2=A0=
<span style=3D"display: inline !important; float: none; background-color: t=
ransparent; color: rgb(34, 34, 34); font-family: "Arial","He=
lvetica",sans-serif; font-size: 13px; font-style: normal; font-variant=
: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align:=
left; text-decoration: none; text-indent: 0px; text-transform: none; -webk=
it-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">silentl=
y introduced</span> - type decorators. This is bigger a change then implied=
..<font face=3D"arial,sans-serif"><b><i></i></b></font></div><div><br></div>=
<div>Up until this point all decorations were either keywords or attributes=
, and now we have something which looks like a type (or even a template!), =
used as a qualifier to some other (real) type or auto.=C2=A0</div><div>Soon=
er or later people will start asking, why I just can write only the decorat=
or and the type be deduced, which the paper actually allow. In that case qu=
estion arises do why do we need this new category in the first place.</div>=
<div><b><br></b></div><div><b><br></b></div><div><b>Second</b>. Consider <f=
ont face=3D"courier new,monospace">const Point arg.</font><font face=3D"ari=
al,sans-serif"> <font face=3D"courier new,monospace">const</font> is not ab=
out the type, <i>it's about the variable. </i><font face=3D"arial,sans-=
serif">The fact that C++ handles const as a different type of Point is an i=
mplementation detail.</font></font></div><div>However "type decoration=
s" will be all about the type, in that one line we will have some deco=
rations which <i>semantically</i> are about the variable and others about t=
he type of it! This is bound to lead to confusion.</div><div><br></div><div=
>Also. <font face=3D"courier new,monospace">const int a; </font><font face=
=3D"arial,sans-serif">will always bind to an </font><font face=3D"courier n=
ew,monospace">int b, </font><font face=3D"arial,sans-serif">but a <font fac=
e=3D"courier new,monospace">MyClass c</font>, might not bind to </font><fon=
t face=3D"courier new,monospace">MyConstraign Class d; <font face=3D"arial,=
sans-serif">Yet both are spelled out with the same syntax, both are "a=
case where one is just more constrained then the other", but in pract=
ice mean different things. =C2=A0</font></font></div><div><br></div><div><b=
r></div><div><b>Third. </b>Consider <font face=3D"courier new,monospace">A =
auto a =3D ...; B int b =3D ...; <font face=3D"arial,sans-serif">From the C=
++ rules </font></font><font face=3D"arial,sans-serif">so far we might cons=
ider both of these are semantically the same, just in the second case the a=
uto is spelled out. In fact however these two, are <b>radically</b> differe=
nt - the first is constrained <i>type</i>, the other is constrained <i>valu=
e</i>. This can be confusing no matter how we look at it - if we look from =
variable declaration PoV we expect <i>both to be types </i>(but they are no=
t) if we look at template argument declaration PoV (<auto I>, <int=
I>) we expect <i>both to be a value, </i>which is also not true!</font>=
</div><div><br></div><div>The confusion with out continues with the fact <f=
ont face=3D"courier new,monospace">A auto</font> means one thing in code (a=
s return value, variable or argument) and different as template param. </di=
v><div><font face=3D"courier new,monospace">f(A auto a){}; A auto a; A auto=
f() {}</font> are (<i>radically</i>) different then <font face=3D"courier =
new,monospace">template<B auto I>.</font></div><div><font face=3D"ari=
al,sans-serif">Yes, one can argue this is already the case, but this does n=
ot help either, not to mention auto as function params is not yet in.</font=
></div><div><br></div><div><br></div><div><span style=3D"background-color: =
transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: non=
e; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: s=
tretch; border-image-slice: 100%; border-image-source: none; border-image-w=
idth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; borde=
r-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style:=
none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-t=
op-style: none; border-top-width: 0px; color: rgb(34, 34, 34); display: inl=
ine; float: none; font-family: &quot;Arial&quot;,&quot;Helvetic=
a&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: =
normal; font-weight: 700; letter-spacing: normal; margin-bottom: 0px; margi=
n-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom=
: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align:=
left; text-decoration: none; text-indent: 0px; text-transform: none; -webk=
it-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">Forth</=
span><b style=3D"background-attachment: scroll; background-clip: border-box=
; background-color: transparent; background-image: none; background-origin:=
padding-box; background-position-x: 0%; background-position-y: 0%; backgro=
und-repeat: repeat; background-size: auto; border-bottom-color: rgb(34, 34,=
34); border-bottom-style: none; border-bottom-width: 0px; border-image-out=
set: 0; border-image-repeat: stretch; border-image-slice: 100%; border-imag=
e-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); =
border-left-style: none; border-left-width: 0px; border-right-color: rgb(34=
, 34, 34); border-right-style: none; border-right-width: 0px; border-top-co=
lor: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color:=
rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetic=
a&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: =
normal; font-weight: 700; height: auto; letter-spacing: normal; margin-bott=
om: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-width: 0=
px; orphans: 2; overflow: visible; overflow-x: visible; overflow-y: visible=
; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: =
0px; text-align: left; text-decoration: none; text-indent: 0px; text-transf=
orm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacin=
g: 0px;">. </b><span style=3D"display: inline !important; float: none; back=
ground-color: transparent; color: rgb(34, 34, 34); font-family: "Arial=
","Helvetica",sans-serif; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans:=
2; text-align: left; text-decoration: none; text-indent: 0px; text-transfo=
rm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing=
: 0px;">Decorations are, by there nature, an ad hoc tool - to have somethin=
g existing and to further specify it in the place of use. Constrained types=
are not like that, ad hoc constrain creation is unlikely.=C2=A0</span><fon=
t face=3D"courier new,monospace" style=3D"background-color: transparent; bo=
rder-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-botto=
m-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border-=
image-slice: 100%; border-image-source: none; border-image-width: 1; border=
-left-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0=
px; border-right-color: rgb(34, 34, 34); border-right-style: none; border-r=
ight-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none;=
border-top-width: 0px; color: rgb(34, 34, 34); font-family: courier new,mo=
nospace; font-size: 13px; font-style: normal; font-variant: normal; font-we=
ight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; ma=
rgin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-=
left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-dec=
oration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-=
width: 0px; white-space: normal; word-spacing: 0px;">Swappable Sortable Wri=
table foo; <font face=3D"arial,sans-serif" style=3D"border-bottom-color: rg=
b(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-=
image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bo=
rder-image-source: none; border-image-width: 1; border-left-color: rgb(34, =
34, 34); border-left-style: none; border-left-width: 0px; border-right-colo=
r: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bord=
er-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0p=
x; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px=
; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: =
0px;">in the real world will likely be just</font> FooConcept foo; </font><=
font face=3D"arial,sans-serif" style=3D"background-color: transparent; bord=
er-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-=
width: 0px; border-image-outset: 0; border-image-repeat: stretch; border-im=
age-slice: 100%; border-image-source: none; border-image-width: 1; border-l=
eft-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px=
; border-right-color: rgb(34, 34, 34); border-right-style: none; border-rig=
ht-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; b=
order-top-width: 0px; color: rgb(34, 34, 34); font-family: arial,sans-serif=
; font-size: 13px; font-style: normal; font-variant: normal; font-weight: 4=
00; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-ri=
ght: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0=
px; padding-right: 0px; padding-top: 0px; text-align: left; text-decoration=
: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: =
0px; white-space: normal; word-spacing: 0px;">semantically. It is very unli=
kely one will need to mix and match constrains on the go and pay the syntax=
, maintenance, visual noise tax.</font></div><div><b><br></b></div><div><br=
></div><div>I believe we should streamline Concepts as much as possible act=
ually removing features and "optional syntaxes" before adding new=
ones. By streamline I don't mean a "terse syntax", just a sa=
ne one, be it a verbose one (at first).</div><div>And BTW a non-sane syntax=
is to have both function and variable way to declare a concept, to have th=
at stupid bool and so on, in other words most (but not all) of what is writ=
ten in=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
017/p0587r0.pdf">Concepts TS revisited</a> </div><div><br></div><div>Thanks=
</div><div>MN</div><div><font face=3D"arial,sans-serif"><i><b><u><sub><br><=
/sub></u></b></i></font></div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3c6d5694-b335-4aa1-983f-3218843a738e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c6d5694-b335-4aa1-983f-3218843a738e=
%40isocpp.org</a>.<br />
------=_Part_8304_1535418908.1515244492710--
------=_Part_8303_1252375727.1515244492709--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Mon, 8 Jan 2018 07:42:50 -0800 (PST)
Raw View
------=_Part_4018_1346879922.1515426170351
Content-Type: multipart/alternative;
boundary="----=_Part_4019_1183625537.1515426170351"
------=_Part_4019_1183625537.1515426170351
Content-Type: text/plain; charset="UTF-8"
Am Samstag, 6. Januar 2018 14:14:52 UTC+1 schrieb mihailn...@gmail.com:
>
> Hello, I wanted to share my thoughts on the broad topic of "Concepts as
> Adjectives".
>
> I believe they are not as innocent as presented.
>
Yes, in my opinion, Concepts as adjectives/qualifiers are very very
powerful and in no way a diffident solution.
*First,* a new category of user provided entities is silently introduced -
> type decorators. This is bigger a change then implied.
>
When I first wrote "Concepts are Adjectives, Not Nouns", I very well
perceived them to be ground breaking.
Up until this point all decorations were either keywords or attributes, and
> now we have something which looks like a type (or even a template!), used
> as a qualifier to some other (real) type or auto.
>
I agree, that it introduces identifiers (in constrast to keyword) as
qualifiers, which is unprecedented by now.
However, this identifier is hardly visually ambiguated with a type name,
because it ultimately is followed by a concrete type (least common case),
"auto" or "typename" (most common cases).
In all situations, the noun is (in 9 of 10 cases) the last identifier,
which sets it visually apart.
In the latter two cases, the noun is a keyword and therefore additionally
visually set apart.
Sooner or later people will start asking, why I just can write only the
> decorator and the type be deduced, which the paper actually allow. In that
> case question arises do why do we need this new category in the first place.
>
Because sometimes, we want to declare a constrained type (Sortable typename
S) and sometimes we want to declare a variable of constrained type
(Sortable auto s).
If you ask me, I am against making the noun optional in any case. Actually
for the same reason that C++ discourages "const" to implicitly stand for
"const int" (as in C).
*Second*. Consider const Point arg. const is not about the type, *it's
> about the variable. *The fact that C++ handles const as a different type
> of Point is an implementation detail.
> However "type decorations" will be all about the type, in that one line we
> will have some decorations which *semantically* are about the variable
> and others about the type of it! This is bound to lead to confusion.
>
Wait, do you think going from "template<typename T>" (without concepts) to
"template<Sortable T>" is less confusing?
Suddenly, we don't know whether T is a type after all?!
Also. const int a; will always bind to an int b, but a MyClass c, might not
> bind to MyConstraign MyClass d; Yet both are spelled out with the same
> syntax, both are "a case where one is just more constrained then the
> other", but in practice mean different things.
>
Firstly, this argument is not working for me, since const int& will not
bind to a int&. Secondly:
If (which I assume) MyClass is a concrete type,
- either MyConstrain is a Value-Constraint
(in which case we face same "issue" (IMO, that's a feature), that
Concept TS faces),
- or MyConstrain is a Type-Constraint
(in which case "MyClass" does very well bind to "MyConstraint MyClass",
given MyClass after all meets MyConstraint and doesn't generate a compiler
error).
*Third. *Consider A auto a = ...; B int b = ...; From the C++ rules so far
> we might consider both of these are semantically the same, just in the
> second case the auto is spelled out. In fact however these two, are
> *radically* different - the first is constrained *type*, the other is
> constrained *value*. This can be confusing no matter how we look at it -
> if we look from variable declaration PoV we expect *both to be types *(but
> they are not) if we look at template argument declaration PoV (<auto I>,
> <int I>) we expect *both to be a value, *which is also not true!
>
I understand your concerns. However, this is not how I and Corentin propose
Concepts.
Whether a Concept constraints the type or the value of a variable depends
on the concept, not on whether we "spell out the auto".
"Even" in the phrases "Even int i" and "Even auto i", will always constrain
the values of i.
In the latter phrase however, "auto" is allowed to deduce to any type
(including int),
for which the property "Even" is decidable (depending on the definition,
probably for number-like types).
The confusion with out continues with the fact A auto means one thing in
> code (as return value, variable or argument) and different as template
> param.
> f(A auto a){}; A auto a; A auto f() {} are (*radically*) different then template<B
> auto I>.
> Yes, one can argue this is already the case, but this does not help
> either, not to mention auto as function params is not yet in.
>
I AM in favor of "auto" having the same meaning (regarding your concerns)
across its usages.
This is the way I proposed it and I believe Corentin would too.
Forth*. *Decorations are, by there nature, an ad hoc tool - to have
> something existing and to further specify it in the place of use.
> Constrained types are not like that, ad hoc constrain creation is unlikely. Swappable
> Sortable Writable foo; in the real world will likely be just FooConcept
> foo; semantically. It is very unlikely one will need to mix and match
> constrains on the go and pay the syntax, maintenance, visual noise tax.
>
For the sake of argument, it's irrelevant how likely this feature is used.
But if at all unlikely, this is a feature, not a bug. Nobody forces you to
chain concepts this way.
Apart from that, I hardly believe, you will write a named concept for each
and every such Concept-based function.
Why would you do so, if you only needed to chain the Concepts once for the
whole function?
I believe we should streamline Concepts as much as possible actually
> removing features and "optional syntaxes" before adding new ones.
>
I agree with you here, although I don't find "Concepts TS revisited" to
make things consistent enough.
When ansering to your concerns, I hope to have understood you correctly for
the most part.
If not, please clarify those mistakes.
Yours,
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/16c7eb00-967f-49d4-8bd8-38900f4c5cae%40isocpp.org.
------=_Part_4019_1183625537.1515426170351
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Am Samstag, 6. Januar 2018 14:14:52 UTC+1 schrieb =
mihailn...@gmail.com:<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>Hello, I wanted to share my thoughts on the broad topic of &q=
uot;Concepts as Adjectives".=C2=A0</div><div><br></div><div>I believe =
they are not as innocent as presented.</div></div></blockquote><div>=C2=A0<=
/div><div>Yes, in my opinion, Concepts as adjectives/qualifiers are very ve=
ry powerful and in no way a diffident solution.</div><div>=C2=A0</div><div>=
<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div><b>First,</b> a new category of user provided entities is=
=C2=A0<span style=3D"display:inline!important;float:none;background-color:t=
ransparent;color:rgb(34,34,34);font-family:"Arial","Helvetic=
a",sans-serif;font-size:13px;font-style:normal;font-variant:normal;fon=
t-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;tex=
t-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">silen=
tly introduced</span> - type decorators. This is bigger a change then impli=
ed.</div></div></blockquote><div>=C2=A0</div><div>When I first wrote "=
Concepts are Adjectives, Not Nouns", I very well perceived them to be =
ground breaking.</div><div>=C2=A0</div><div><br></div><div><br></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><font face=3D"=
arial,sans-serif"><b><i></i></b></font></div><div>Up until this point all d=
ecorations were either keywords or attributes, and now we have something wh=
ich looks like a type (or even a template!), used as a qualifier to some ot=
her (real) type or auto.=C2=A0<br></div></div></blockquote><div>=C2=A0</div=
><div>I agree, that it introduces identifiers (in constrast to keyword) as =
qualifiers, which is unprecedented by now.</div><div>However, this identifi=
er is hardly visually ambiguated with a type name, because it ultimately is=
followed by a concrete type (least common case), "auto" or "=
;typename" (most common cases).</div><div>In all situations, the noun =
is (in 9 of 10 cases) the last identifier, which sets it visually apart.</d=
iv><div>In the latter two cases, the noun is a keyword and therefore additi=
onally visually set apart.</div><div>=C2=A0</div><div><br></div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></di=
v><div>Sooner or later people will start asking, why I just can write only =
the decorator and the type be deduced, which the paper actually allow. In t=
hat case question arises do why do we need this new category in the first p=
lace.</div></div></blockquote><div>=C2=A0</div><div>Because sometimes, we w=
ant to declare a constrained type (Sortable typename S) and sometimes we wa=
nt to declare a variable of constrained type (Sortable auto s).</div><div>I=
f you ask me, I am against making the noun optional in any case. Actually f=
or the same reason that C++ discourages "const" to implicitly sta=
nd for "const int" (as in C).</div><div><br></div><div><br></div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><b>Second</b>. Consider <font face=3D"courier new,monospace">const P=
oint arg.</font><font face=3D"arial,sans-serif"> <font face=3D"courier new,=
monospace">const</font> is not about the type, <i>it's about the variab=
le. </i><font face=3D"arial,sans-serif">The fact that C++ handles const as =
a different type of Point is an implementation detail.</font></font><br></d=
iv><div>However "type decorations" will be all about the type, in=
that one line we will have some decorations which <i>semantically</i> are =
about the variable and others about the type of it! This is bound to lead t=
o confusion.</div></div></blockquote><div>=C2=A0</div><div>Wait, do you thi=
nk going from "template<typename T>" (without concepts) to =
"template<Sortable T>" is less confusing?</div><div>Suddenl=
y, we don't know whether T is a type after all?!</div><div>=C2=A0</div>=
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div>Also. <font face=3D"courier new,monospace">const int =
a; </font><font face=3D"arial,sans-serif">will always bind to an </font><fo=
nt face=3D"courier new,monospace">int b, </font><font face=3D"arial,sans-se=
rif">but a <font face=3D"courier new,monospace">MyClass c</font>, might not=
bind to </font><font face=3D"courier new,monospace">MyConstraign MyClass d=
; <font face=3D"arial,sans-serif">Yet both are spelled out with the same sy=
ntax, both are "a case where one is just more constrained then the oth=
er", but in practice mean different things.</font></font></div></div><=
/blockquote><div>=C2=A0</div><div>Firstly, this argument is not working for=
me, since const int& will not bind to a int&. Secondly:</div><div>=
If (which I assume) MyClass=C2=A0 is a concrete type,</div><div><ul><li>eit=
her MyConstrain is a Value-Constraint<br>(in which case we face same "=
issue" (IMO, that's a feature), that Concept TS faces),<br></li><l=
i>or MyConstrain is a Type-Constraint<br>(in which case "MyClass"=
does very well bind to "MyConstraint MyClass", given MyClass aft=
er all meets MyConstraint and doesn't generate a compiler error).</li><=
/ul></div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div><b>Third. </b>Consider <font face=3D"courie=
r new,monospace">A auto a =3D ...; B int b =3D ...; <font face=3D"arial,san=
s-serif">From the C++ rules </font></font><font face=3D"arial,sans-serif">s=
o far we might consider both of these are semantically the same, just in th=
e second case the auto is spelled out. In fact however these two, are <b>ra=
dically</b> different - the first is constrained <i>type</i>, the other is =
constrained <i>value</i>. This can be confusing no matter how we look at it=
- if we look from variable declaration PoV we expect <i>both to be types <=
/i>(but they are not) if we look at template argument declaration PoV (<=
auto I>, <int I>) we expect <i>both to be a value, </i>which is al=
so not true!</font></div></div></blockquote><div>=C2=A0</div><div>I underst=
and your concerns. However, this is not how I and Corentin propose Concepts=
..</div><div>Whether a Concept constraints the type or the value of a variab=
le depends on the concept, not on whether we "spell out the auto"=
..</div><div>"Even" in the phrases "Even int i" and &quo=
t;Even auto i", will always constrain the values of i.</div><div>In th=
e latter phrase however, "auto" is allowed to deduce to any type =
(including int),</div><div>for which the property "Even" is decid=
able (depending on the definition, probably for number-like types).</div><d=
iv>=C2=A0</div><div><br></div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div>The confusion with out continues with =
the fact <font face=3D"courier new,monospace">A auto</font> means one thing=
in code (as return value, variable or argument) and different as template =
param.<br></div><div><font face=3D"courier new,monospace">f(A auto a){}; A =
auto a; A auto f() {}</font> are (<i>radically</i>) different then <font fa=
ce=3D"courier new,monospace">template<B auto I>.</font></div><div><fo=
nt face=3D"arial,sans-serif">Yes, one can argue this is already the case, b=
ut this does not help either, not to mention auto as function params is not=
yet in.</font></div></div></blockquote><div><br></div><div>I AM in favor o=
f "auto" having the same meaning (regarding your concerns) across=
its usages.</div><div>This is the way I proposed it and I believe Corentin=
would too.</div><div>=C2=A0</div><div><br></div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Forth<b>. </b><span=
style=3D"background-color: transparent; font-variant-numeric: normal; font=
-variant-east-asian: normal;">Decorations are, by there nature, an ad hoc t=
ool - to have something existing and to further specify it in the place of =
use. Constrained types are not like that, ad hoc constrain creation is unli=
kely.=C2=A0</span><font face=3D"courier new,monospace" style=3D"background-=
color: transparent; border-color: rgb(34, 34, 34); border-style: none; font=
-family: "courier new", monospace; font-variant-numeric: normal; =
font-variant-east-asian: normal;">Swappable Sortable Writable foo; <font fa=
ce=3D"arial,sans-serif" style=3D"border-color: rgb(34, 34, 34); border-styl=
e: none;">in the real world will likely be just</font> FooConcept foo; </fo=
nt><font face=3D"arial,sans-serif" style=3D"background-color: transparent; =
border-color: rgb(34, 34, 34); border-style: none; font-family: arial, sans=
-serif; font-variant-numeric: normal; font-variant-east-asian: normal;">sem=
antically. It is very unlikely one will need to mix and match constrains on=
the go and pay the syntax, maintenance, visual noise tax.</font></div></di=
v></blockquote><div><br></div><div>For the sake of argument, it's irrel=
evant how likely this feature is used.</div><div>But if at all unlikely, th=
is is a feature, not a bug. Nobody forces you to chain concepts this way.</=
div><div>Apart from that, I hardly believe, you will write a named concept =
for each and every such Concept-based function.</div><div>Why would you do =
so, if you only needed to chain the Concepts once for the whole function?</=
div><div>=C2=A0</div><div><br></div><div><br></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"><div>I believe we should streamline C=
oncepts as much as possible actually removing features and "optional s=
yntaxes" before adding new ones.=C2=A0</div></div></blockquote><div><b=
r></div><div>I agree with you here, although I don't find "Concept=
s TS revisited" to make things consistent enough.</div><div><br></div>=
<div><br></div><div><br></div><div>When ansering to your concerns, I hope t=
o have understood you correctly for the most part.</div><div>If not, please=
clarify those mistakes.</div><div><br></div><div>Yours,</div><div>Jakob</d=
iv></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/16c7eb00-967f-49d4-8bd8-38900f4c5cae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/16c7eb00-967f-49d4-8bd8-38900f4c5cae=
%40isocpp.org</a>.<br />
------=_Part_4019_1183625537.1515426170351--
------=_Part_4018_1346879922.1515426170351--
.
Author: Corentin <corentin.jabot@gmail.com>
Date: Mon, 08 Jan 2018 17:03:16 +0000
Raw View
--001a113d53bcd70cd0056246c6bd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Please find my answers bellow, they merely complement the great answers
given by jakob.
I hope they help, otherwise let me know !
Corentin
Le lun. 8 janv. 2018 =C3=A0 16:42, Jakob Riedle <jakob.riedle@gmail.com> a
=C3=A9crit :
>
>
> Am Samstag, 6. Januar 2018 14:14:52 UTC+1 schrieb mihailn...@gmail.com:
>>
>> Hello, I wanted to share my thoughts on the broad topic of "Concepts as
>> Adjectives".
>>
>> I believe they are not as innocent as presented.
>>
>
> Yes, in my opinion, Concepts as adjectives/qualifiers are very very
> powerful and in no way a diffident solution.
>
> *First,* a new category of user provided entities is silently introduced
>> - type decorators. This is bigger a change then implied.
>>
>
> When I first wrote "Concepts are Adjectives, Not Nouns", I very well
> perceived them to be ground breaking.
>
Yet I'm convinced they make *using* the language easier and are it's not a
complex feature either. I think it's a natural extension of the current
Concepts TS.
>
> Up until this point all decorations were either keywords or attributes,
>> and now we have something which looks like a type (or even a template!),
>> used as a qualifier to some other (real) type or auto.
>>
>
> I agree, that it introduces identifiers (in constrast to keyword) as
> qualifiers, which is unprecedented by now.
> However, this identifier is hardly visually ambiguated with a type name,
> because it ultimately is followed by a concrete type (least common case),
> "auto" or "typename" (most common cases).
> In all situations, the noun is (in 9 of 10 cases) the last identifier,
> which sets it visually apart.
> In the latter two cases, the noun is a keyword and therefore additionally
> visually set apart.
>
Note that constraints do have an impact on overload resolution, but they do
not "qualify" the name in that a Sortable Foo is still a Foo.
The list of concepts and the name should be read a single entity to which
you apply any other qualifier;
(cv) type (ptr-declarator), except now the type may be preceded by a list
of concepts names. So I don't think there is any ambiguity.
>
> Sooner or later people will start asking, why I just can write only the
>> decorator and the type be deduced, which the paper actually allow. In th=
at
>> case question arises do why do we need this new category in the first pl=
ace.
>>
>
> Because sometimes, we want to declare a constrained type (Sortable
> typename S) and sometimes we want to declare a variable of constrained ty=
pe
> (Sortable auto s).
> If you ask me, I am against making the noun optional in any case. Actuall=
y
> for the same reason that C++ discourages "const" to implicitly stand for
> "const int" (as in C).
>
While Jakob and I have some disagreements regarding whether auto could be
optional, in any case, I don't think there could be any confusion.
And why would you use a concept name rather than auto? Because in most
cases auto is too vague. especially as a type parameter of a function.
Our hope is that a wide use of concepts will lead to cleaner, more
comprehensive generic apis.
>
>
> *Second*. Consider const Point arg. const is not about the type, *it's
>> about the variable. *The fact that C++ handles const as a different type
>> of Point is an implementation detail.
>> However "type decorations" will be all about the type, in that one line
>> we will have some decorations which *semantically* are about the
>> variable and others about the type of it! This is bound to lead to
>> confusion.
>>
>
> Wait, do you think going from "template<typename T>" (without concepts) t=
o
> "template<Sortable T>" is less confusing?
> Suddenly, we don't know whether T is a type after all?!
>
>
>
> Also. const int a; will always bind to an int b, but a MyClass c, might
>> not bind to MyConstraign MyClass d; Yet both are spelled out with the
>> same syntax, both are "a case where one is just more constrained then th=
e
>> other", but in practice mean different things.
>>
>
> Firstly, this argument is not working for me, since const int& will not
> bind to a int&. Secondly:
> If (which I assume) MyClass is a concrete type,
>
> - either MyConstrain is a Value-Constraint
> (in which case we face same "issue" (IMO, that's a feature), that
> Concept TS faces),
> - or MyConstrain is a Type-Constraint
> (in which case "MyClass" does very well bind to "MyConstraint
> MyClass", given MyClass after all meets MyConstraint and doesn't gener=
ate a
> compiler error)
>
> Exactly, constraints are assertions on types, not transformations.
>
> *Third. *Consider A auto a =3D ...; B int b =3D ...; From the C++ rules s=
o
>> far we might consider both of these are semantically the same, just in t=
he
>> second case the auto is spelled out. In fact however these two, are
>> *radically* different - the first is constrained *type*, the other is
>> constrained *value*. This can be confusing no matter how we look at it -
>> if we look from variable declaration PoV we expect *both to be types *(b=
ut
>> they are not) if we look at template argument declaration PoV (<auto I>,
>> <int I>) we expect *both to be a value, *which is also not true!
>>
>
> I understand your concerns. However, this is not how I and Corentin
> propose Concepts.
> Whether a Concept constraints the type or the value of a variable depends
> on the concept, not on whether we "spell out the auto".
> "Even" in the phrases "Even int i" and "Even auto i", will always
> constrain the values of i.
> In the latter phrase however, "auto" is allowed to deduce to any type
> (including int),
> for which the property "Even" is decidable (depending on the definition,
> probably for number-like types).
>
>
>
> The confusion with out continues with the fact A auto means one thing in
>> code (as return value, variable or argument) and different as template
>> param.
>> f(A auto a){}; A auto a; A auto f() {} are (*radically*) different then =
template<B
>> auto I>.
>> Yes, one can argue this is already the case, but this does not help
>> either, not to mention auto as function params is not yet in.
>>
>
> I AM in favor of "auto" having the same meaning (regarding your concerns)
> across its usages.
> This is the way I proposed it and I believe Corentin would too.
>
In all the above cases the constrained are applied to a value.
What you may find confusing is just the nature of non type non template
template parameters. Which is something I certainly can relate too.
Forth*. *Decorations are, by there nature, an ad hoc tool - to have
>> something existing and to further specify it in the place of use.
>> Constrained types are not like that, ad hoc constrain creation is unlike=
ly. Swappable
>> Sortable Writable foo; in the real world will likely be just FooConcept
>> foo; semantically. It is very unlikely one will need to mix and match
>> constrains on the go and pay the syntax, maintenance, visual noise tax.
>>
>
> For the sake of argument, it's irrelevant how likely this feature is used=
..
> But if at all unlikely, this is a feature, not a bug. Nobody forces you t=
o
> chain concepts this way.
> Apart from that, I hardly believe, you will write a named concept for eac=
h
> and every such Concept-based function.
> Why would you do so, if you only needed to chain the Concepts once for th=
e
> whole function?
>
Additionally, You may want to manipulate multiple properties of an object
within the same function. You are not implicitly creating a new concept,
you are relying on several.
There is a subtle, yet important distinction.
Using the same list of concepts name over and over would be a good sign
that you indeed, need a new concept name.
>
>
> I believe we should streamline Concepts as much as possible actually
>> removing features and "optional syntaxes" before adding new ones.
>>
>
> I agree with you here, although I don't find "Concepts TS revisited" to
> make things consistent enough.
>
>
>
> When ansering to your concerns, I hope to have understood you correctly
> for the most part.
> If not, please clarify those mistakes.
>
> Yours,
> 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/16c7eb00-967=
f-49d4-8bd8-38900f4c5cae%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/16c7eb00-96=
7f-49d4-8bd8-38900f4c5cae%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/CA%2BOm%2BSiAYc_BLH2fhH599v9R8oo8HvjhwJnx3d7PVBy=
Sa157BA%40mail.gmail.com.
--001a113d53bcd70cd0056246c6bd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Please find my answers bellow, they merely complement the =
great answers given by jakob.<div>I hope they help, otherwise let me know !=
<br><div><div><div><br></div><div>Corentin<br><br><div class=3D"gmail_quote=
"><div dir=3D"ltr">Le=C2=A0lun. 8 janv. 2018 =C3=A0=C2=A016:42, Jakob Riedl=
e <<a href=3D"mailto:jakob.riedle@gmail.com">jakob.riedle@gmail.com</a>&=
gt; a =C3=A9crit=C2=A0:<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"><br><br>Am Samstag, 6. Januar 2018 14:14:52 UTC+1 schrieb <a href=3D"=
mailto:mihailn...@gmail.com" target=3D"_blank">mihailn...@gmail.com</a>:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hello, I wanted =
to share my thoughts on the broad topic of "Concepts as Adjectives&quo=
t;.=C2=A0</div><div><br></div><div>I believe they are not as innocent as pr=
esented.</div></div></blockquote><div>=C2=A0</div></div><div dir=3D"ltr"><d=
iv>Yes, in my opinion, Concepts as adjectives/qualifiers are very very powe=
rful and in no way a diffident solution.</div></div></blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div></div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><b>First,</b> a new cate=
gory of user provided entities is=C2=A0<span style=3D"display:inline!import=
ant;float:none;background-color:transparent;color:rgb(34,34,34);font-family=
:"Arial","Helvetica",sans-serif;font-size:13px;font-sty=
le:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-al=
ign:left;text-decoration:none;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px">silently introduced</span> - type decorators. T=
his is bigger a change then implied.</div></div></blockquote><div>=C2=A0</d=
iv></div><div dir=3D"ltr"><div>When I first wrote "Concepts are Adject=
ives, Not Nouns", I very well perceived them to be ground breaking.</d=
iv></div></blockquote><div><br></div><div>Yet I'm convinced they make *=
using* the language easier and are it's not a complex feature either. I=
think it's a natural extension of the current Concepts TS.=C2=A0=C2=A0=
</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=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><f=
ont face=3D"arial,sans-serif"><b><i></i></b></font></div><div>Up until this=
point all decorations were either keywords or attributes, and now we have =
something which looks like a type (or even a template!), used as a qualifie=
r to some other (real) type or auto.=C2=A0<br></div></div></blockquote><div=
>=C2=A0</div></div><div dir=3D"ltr"><div>I agree, that it introduces identi=
fiers (in constrast to keyword) as qualifiers, which is unprecedented by no=
w.</div><div>However, this identifier is hardly visually ambiguated with a =
type name, because it ultimately is followed by a concrete type (least comm=
on case), "auto" or "typename" (most common cases).</di=
v><div>In all situations, the noun is (in 9 of 10 cases) the last identifie=
r, which sets it visually apart.</div><div>In the latter two cases, the nou=
n is a keyword and therefore additionally visually set apart.</div></div></=
blockquote><div><br></div><div>Note that constraints do have an impact on o=
verload resolution, but they do not "qualify" the name in that a =
Sortable Foo is still a Foo.</div><div>The list of concepts and the name sh=
ould be read a single entity to which you apply any other qualifier;</div><=
div>(cv) type (ptr-declarator), except now the type may be preceded by a li=
st of concepts names. So I don't think there is any ambiguity.=C2=A0=C2=
=A0</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></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div></div><div>Sooner or later people will start asking, why I ju=
st can write only the decorator and the type be deduced, which the paper ac=
tually allow. In that case question arises do why do we need this new categ=
ory in the first place.</div></div></blockquote><div>=C2=A0</div></div><div=
dir=3D"ltr"><div>Because sometimes, we want to declare a constrained type =
(Sortable typename S) and sometimes we want to declare a variable of constr=
ained type (Sortable auto s).</div><div>If you ask me, I am against making =
the noun optional in any case. Actually for the same reason that C++ discou=
rages "const" to implicitly stand for "const int" (as i=
n C).</div></div></blockquote><div><br></div><div>While Jakob and I have so=
me disagreements regarding whether auto could be optional, in any case, I d=
on't think there could be any confusion.</div><div>And why would you us=
e a concept name rather than auto? Because in most cases auto is too vague.=
especially as a type parameter of a function.</div><div>Our hope is that a=
wide use of concepts will lead to cleaner, more comprehensive generic apis=
..=C2=A0</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></div><di=
v><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><b>Second</b>. Consider <font face=3D"courier new,monospace">=
const Point arg.</font><font face=3D"arial,sans-serif"> <font face=3D"couri=
er new,monospace">const</font> is not about the type, <i>it's about the=
variable. </i><font face=3D"arial,sans-serif">The fact that C++ handles co=
nst as a different type of Point is an implementation detail.</font></font>=
<br></div><div>However "type decorations" will be all about the t=
ype, in that one line we will have some decorations which <i>semantically</=
i> are about the variable and others about the type of it! This is bound to=
lead to confusion.</div></div></blockquote><div>=C2=A0</div></div><div dir=
=3D"ltr"><div>Wait, do you think going from "template<typename T>=
;" (without concepts) to "template<Sortable T>" is les=
s confusing?</div><div>Suddenly, we don't know whether T is a type afte=
r all?!</div><div>=C2=A0</div><div><br></div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div>Also. <font face=3D"courier =
new,monospace">const int a; </font><font face=3D"arial,sans-serif">will alw=
ays bind to an </font><font face=3D"courier new,monospace">int b, </font><f=
ont face=3D"arial,sans-serif">but a <font face=3D"courier new,monospace">My=
Class c</font>, might not bind to </font><font face=3D"courier new,monospac=
e">MyConstraign MyClass d; <font face=3D"arial,sans-serif">Yet both are spe=
lled out with the same syntax, both are "a case where one is just more=
constrained then the other", but in practice mean different things.</=
font></font></div></div></blockquote><div>=C2=A0</div><div>Firstly, this ar=
gument is not working for me, since const int& will not bind to a int&a=
mp;. Secondly:</div><div>If (which I assume) MyClass=C2=A0 is a concrete ty=
pe,</div><div><ul><li>either MyConstrain is a Value-Constraint<br>(in which=
case we face same "issue" (IMO, that's a feature), that Conc=
ept TS faces),<br></li><li>or MyConstrain is a Type-Constraint<br>(in which=
case "MyClass" does very well bind to "MyConstraint MyClass=
", given MyClass after all meets MyConstraint and doesn't generate=
a compiler error)</li></ul></div></div></blockquote><div>Exactly, constrai=
nts are assertions on types, not transformations.</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><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><b>Third. </b>Con=
sider <font face=3D"courier new,monospace">A auto a =3D ...; B int b =3D ..=
..; <font face=3D"arial,sans-serif">From the C++ rules </font></font><font f=
ace=3D"arial,sans-serif">so far we might consider both of these are semanti=
cally the same, just in the second case the auto is spelled out. In fact ho=
wever these two, are <b>radically</b> different - the first is constrained =
<i>type</i>, the other is constrained <i>value</i>. This can be confusing n=
o matter how we look at it - if we look from variable declaration PoV we ex=
pect <i>both to be types </i>(but they are not) if we look at template argu=
ment declaration PoV (<auto I>, <int I>) we expect <i>both to b=
e a value, </i>which is also not true!</font></div></div></blockquote><div>=
=C2=A0</div></div><div dir=3D"ltr"><div>I understand your concerns. However=
, this is not how I and Corentin propose Concepts.</div><div>Whether a Conc=
ept constraints the type or the value of a variable depends on the concept,=
not on whether we "spell out the auto".</div><div>"Even&quo=
t; in the phrases "Even int i" and "Even auto i", will =
always constrain the values of i.</div><div>In the latter phrase however, &=
quot;auto" is allowed to deduce to any type (including int),</div><div=
>for which the property "Even" is decidable (depending on the def=
inition, probably for number-like types).</div></div><div dir=3D"ltr"><div>=
=C2=A0</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>The confusion with out continues with the fact=
<font face=3D"courier new,monospace">A auto</font> means one thing in code=
(as return value, variable or argument) and different as template param.<b=
r></div><div><font face=3D"courier new,monospace">f(A auto a){}; A auto a; =
A auto f() {}</font> are (<i>radically</i>) different then <font face=3D"co=
urier new,monospace">template<B auto I>.</font></div><div><font face=
=3D"arial,sans-serif">Yes, one can argue this is already the case, but this=
does not help either, not to mention auto as function params is not yet in=
..</font></div></div></blockquote><div><br></div></div><div dir=3D"ltr"><div=
>I AM in favor of "auto" having the same meaning (regarding your =
concerns) across its usages.</div><div>This is the way I proposed it and I =
believe Corentin would too.</div></div></blockquote><div><br></div><div>In =
all the above cases the constrained are applied to a value.</div><div>What =
you may find confusing is just the nature of non type non template template=
parameters. Which is something I certainly can relate too.=C2=A0=C2=A0</di=
v><div>=C2=A0</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"><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>Fort=
h<b>. </b><span style=3D"background-color:transparent;font-variant-numeric:=
normal;font-variant-east-asian:normal">Decorations are, by there nature, an=
ad hoc tool - to have something existing and to further specify it in the =
place of use. Constrained types are not like that, ad hoc constrain creatio=
n is unlikely.=C2=A0</span><font face=3D"courier new,monospace" style=3D"ba=
ckground-color:transparent;border-color:rgb(34,34,34);border-style:none;fon=
t-family:"courier new",monospace;font-variant-numeric:normal;font=
-variant-east-asian:normal">Swappable Sortable Writable foo; <font face=3D"=
arial,sans-serif" style=3D"border-color:rgb(34,34,34);border-style:none">in=
the real world will likely be just</font> FooConcept foo; </font><font fac=
e=3D"arial,sans-serif" style=3D"background-color:transparent;border-color:r=
gb(34,34,34);border-style:none;font-family:arial,sans-serif;font-variant-nu=
meric:normal;font-variant-east-asian:normal">semantically. It is very unlik=
ely one will need to mix and match constrains on the go and pay the syntax,=
maintenance, visual noise tax.</font></div></div></blockquote><div><br></d=
iv></div><div dir=3D"ltr"><div>For the sake of argument, it's irrelevan=
t how likely this feature is used.</div><div>But if at all unlikely, this i=
s a feature, not a bug. Nobody forces you to chain concepts this way.</div>=
<div>Apart from that, I hardly believe, you will write a named concept for =
each and every such Concept-based function.</div><div>Why would you do so, =
if you only needed to chain the Concepts once for the whole function?</div>=
</div><div dir=3D"ltr"><div></div></div></blockquote><div><br></div><div>Ad=
ditionally, You may want to manipulate multiple properties of an object wit=
hin the same function. You are not implicitly creating a new concept, you a=
re relying on several.</div><div>There is a subtle, yet important distincti=
on.</div><div>Using the same list of concepts name over and over would be a=
good sign that you indeed, need a new concept name.</div><div><br></div><b=
lockquote 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</div><div><br></d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>I believe we should streamline Concepts as much as possible actually r=
emoving features and "optional syntaxes" before adding new ones.=
=C2=A0</div></div></blockquote><div><br></div></div><div dir=3D"ltr"><div>I=
agree with you here, although I don't find "Concepts TS revisited=
" to make things consistent enough.</div><div><br></div><div><br></div=
><div><br></div><div>When ansering to your concerns, I hope to have underst=
ood you correctly for the most part.</div><div>If not, please clarify those=
mistakes.</div><div><br></div><div>Yours,</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/16c7eb00-967f-49d4-8bd8-38900f4c5cae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/16c7eb00-967f-=
49d4-8bd8-38900f4c5cae%40isocpp.org</a>.<br>
</blockquote></div></div></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/CA%2BOm%2BSiAYc_BLH2fhH599v9R8oo8Hvjh=
wJnx3d7PVBySa157BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSiA=
Yc_BLH2fhH599v9R8oo8HvjhwJnx3d7PVBySa157BA%40mail.gmail.com</a>.<br />
--001a113d53bcd70cd0056246c6bd--
.
Author: mihailnajdenov@gmail.com
Date: Mon, 8 Jan 2018 09:22:13 -0800 (PST)
Raw View
------=_Part_8449_1219530408.1515432133538
Content-Type: multipart/alternative;
boundary="----=_Part_8450_591950369.1515432133539"
------=_Part_8450_591950369.1515432133539
Content-Type: text/plain; charset="UTF-8"
On Monday, January 8, 2018 at 5:42:50 PM UTC+2, Jakob Riedle wrote:
>
>
>
> Am Samstag, 6. Januar 2018 14:14:52 UTC+1 schrieb mihailn...@gmail.com:
>>
>> Hello, I wanted to share my thoughts on the broad topic of "Concepts as
>> Adjectives".
>>
>> I believe they are not as innocent as presented.
>>
>
> Yes, in my opinion, Concepts as adjectives/qualifiers are very very
> powerful and in no way a diffident solution.
>
>
>
> *First,* a new category of user provided entities is silently introduced
>> - type decorators. This is bigger a change then implied.
>>
>
> When I first wrote "Concepts are Adjectives, Not Nouns", I very well
> perceived them to be ground breaking.
>
>
>
> Up until this point all decorations were either keywords or attributes,
>> and now we have something which looks like a type (or even a template!),
>> used as a qualifier to some other (real) type or auto.
>>
>
> I agree, that it introduces identifiers (in constrast to keyword) as
> qualifiers, which is unprecedented by now.
> However, this identifier is hardly visually ambiguated with a type name,
> because it ultimately is followed by a concrete type (least common case),
> "auto" or "typename" (most common cases).
> In all situations, the noun is (in 9 of 10 cases) the last identifier,
> which sets it visually apart.
> In the latter two cases, the noun is a keyword and therefore additionally
> visually set apart.
>
>
>
> Sooner or later people will start asking, why I just can write only the
>> decorator and the type be deduced, which the paper actually allow. In that
>> case question arises do why do we need this new category in the first place.
>>
>
> Because sometimes, we want to declare a constrained type (Sortable
> typename S) and sometimes we want to declare a variable of constrained type
> (Sortable auto s).
> If you ask me, I am against making the noun optional in any case. Actually
> for the same reason that C++ discourages "const" to implicitly stand for
> "const int" (as in C).
>
>
>
> *Second*. Consider const Point arg. const is not about the type, *it's
>> about the variable. *The fact that C++ handles const as a different type
>> of Point is an implementation detail.
>> However "type decorations" will be all about the type, in that one line
>> we will have some decorations which *semantically* are about the
>> variable and others about the type of it! This is bound to lead to
>> confusion.
>>
>
> Wait, do you think going from "template<typename T>" (without concepts) to
> "template<Sortable T>" is less confusing?
> Suddenly, we don't know whether T is a type after all?!
>
>
>
> Also. const int a; will always bind to an int b, but a MyClass c, might
>> not bind to MyConstraign MyClass d; Yet both are spelled out with the
>> same syntax, both are "a case where one is just more constrained then the
>> other", but in practice mean different things.
>>
>
> Firstly, this argument is not working for me, since const int& will not
> bind to a int&. Secondly:
> If (which I assume) MyClass is a concrete type,
>
> - either MyConstrain is a Value-Constraint
> (in which case we face same "issue" (IMO, that's a feature), that
> Concept TS faces),
> - or MyConstrain is a Type-Constraint
> (in which case "MyClass" does very well bind to "MyConstraint
> MyClass", given MyClass after all meets MyConstraint and doesn't generate a
> compiler error).
>
>
My example was not very clear, but issue is still there, I believe -
copyConstructable T will not bind to any T, however const T does not impose
restrictions to the incoming T.
const is not a required clause, copyConstructable is, yet both are used
exactly the same way.
This mixing of qualifiers could be confusing - sometimes it is about the
*type*, sometimes it is about the *value*, sometime it is about the
*variable*.
>
> *Third. *Consider A auto a = ...; B int b = ...; From the C++ rules so
>> far we might consider both of these are semantically the same, just in the
>> second case the auto is spelled out. In fact however these two, are
>> *radically* different - the first is constrained *type*, the other is
>> constrained *value*. This can be confusing no matter how we look at it -
>> if we look from variable declaration PoV we expect *both to be types *(but
>> they are not) if we look at template argument declaration PoV (<auto I>,
>> <int I>) we expect *both to be a value, *which is also not true!
>>
>
> I understand your concerns. However, this is not how I and Corentin
> propose Concepts.
> Whether a Concept constraints the type or the value of a variable depends
> on the concept, not on whether we "spell out the auto".
> "Even" in the phrases "Even int i" and "Even auto i", will always
> constrain the values of i.
> In the latter phrase however, "auto" is allowed to deduce to any type
> (including int),
> for which the property "Even" is decidable (depending on the definition,
> probably for number-like types).
>
Then we still can't tell if the concept is about the type or the value.
Wasn't it one of the original goals to have that distinction?
In any case, I understand variable declaration is a separate issue!
>
>
>
> The confusion with out continues with the fact A auto means one thing in
>> code (as return value, variable or argument) and different as template
>> param.
>> f(A auto a){}; A auto a; A auto f() {} are (*radically*) different then template<B
>> auto I>.
>> Yes, one can argue this is already the case, but this does not help
>> either, not to mention auto as function params is not yet in.
>>
>
> I AM in favor of "auto" having the same meaning (regarding your concerns)
> across its usages.
> This is the way I proposed it and I believe Corentin would too.
>
>
>
> Forth*. *Decorations are, by there nature, an ad hoc tool - to have
>> something existing and to further specify it in the place of use.
>> Constrained types are not like that, ad hoc constrain creation is unlikely. Swappable
>> Sortable Writable foo; in the real world will likely be just FooConcept
>> foo; semantically. It is very unlikely one will need to mix and match
>> constrains on the go and pay the syntax, maintenance, visual noise tax.
>>
>
> For the sake of argument, it's irrelevant how likely this feature is used.
> But if at all unlikely, this is a feature, not a bug. Nobody forces you to
> chain concepts this way.
> Apart from that, I hardly believe, you will write a named concept for each
> and every such Concept-based function.
> Why would you do so, if you only needed to chain the Concepts once for the
> whole function?
>
>
>
> I believe we should streamline Concepts as much as possible actually
>> removing features and "optional syntaxes" before adding new ones.
>>
>
> I agree with you here, although I don't find "Concepts TS revisited" to
> make things consistent enough.
>
>
>
> When ansering to your concerns, I hope to have understood you correctly
> for the most part.
> If not, please clarify those mistakes.
>
> Yours,
> 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/c7a4678b-5a2f-457e-9be4-3979506ce4dd%40isocpp.org.
------=_Part_8450_591950369.1515432133539
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, January 8, 2018 at 5:42:50 PM UTC+2, Ja=
kob Riedle wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br><br>Am Samstag, 6. Januar 2018 14:14:52 UTC+1 schrieb <a>mihailn...=
@gmail.com</a>:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>Hello, I wanted to share my thoughts on the broad topic of "Concepts=
as Adjectives".=C2=A0</div><div><br></div><div>I believe they are not=
as innocent as presented.</div></div></blockquote><div>=C2=A0</div><div>Ye=
s, in my opinion, Concepts as adjectives/qualifiers are very very powerful =
and in no way a diffident solution.</div><div>=C2=A0</div><div><br></div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<b>First,</b> a new category of user provided entities is=C2=A0<span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:"Arial","Helvetica",sans-seri=
f;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;lett=
er-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px">silently introduced</s=
pan> - type decorators. This is bigger a change then implied.</div></div></=
blockquote><div>=C2=A0</div><div>When I first wrote "Concepts are Adje=
ctives, Not Nouns", I very well perceived them to be ground breaking.<=
/div><div>=C2=A0</div><div><br></div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><font face=3D"arial,sans-serif"><b><=
i></i></b></font></div><div>Up until this point all decorations were either=
keywords or attributes, and now we have something which looks like a type =
(or even a template!), used as a qualifier to some other (real) type or aut=
o.=C2=A0<br></div></div></blockquote><div>=C2=A0</div><div>I agree, that it=
introduces identifiers (in constrast to keyword) as qualifiers, which is u=
nprecedented by now.</div><div>However, this identifier is hardly visually =
ambiguated with a type name, because it ultimately is followed by a concret=
e type (least common case), "auto" or "typename" (most =
common cases).</div><div>In all situations, the noun is (in 9 of 10 cases) =
the last identifier, which sets it visually apart.</div><div>In the latter =
two cases, the noun is a keyword and therefore additionally visually set ap=
art.</div><div>=C2=A0</div><div><br></div><div><br></div><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></div><div>Sooner or later peo=
ple will start asking, why I just can write only the decorator and the type=
be deduced, which the paper actually allow. In that case question arises d=
o why do we need this new category in the first place.</div></div></blockqu=
ote><div>=C2=A0</div><div>Because sometimes, we want to declare a constrain=
ed type (Sortable typename S) and sometimes we want to declare a variable o=
f constrained type (Sortable auto s).</div><div>If you ask me, I am against=
making the noun optional in any case. Actually for the same reason that C+=
+ discourages "const" to implicitly stand for "const int&quo=
t; (as in C).</div><div><br></div><div><br></div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><b>Second</b>. Consider =
<font face=3D"courier new,monospace">const Point arg.</font><font face=3D"a=
rial,sans-serif"> <font face=3D"courier new,monospace">const</font> is not =
about the type, <i>it's about the variable. </i><font face=3D"arial,san=
s-serif">The fact that C++ handles const as a different type of Point is an=
implementation detail.</font></font><br></div><div>However "type deco=
rations" will be all about the type, in that one line we will have som=
e decorations which <i>semantically</i> are about the variable and others a=
bout the type of it! This is bound to lead to confusion.</div></div></block=
quote><div>=C2=A0</div><div>Wait, do you think going from "template<=
;typename T>" (without concepts) to "template<Sortable T>=
;" is less confusing?</div><div>Suddenly, we don't know whether T =
is a type after all?!=C2=A0</div></div></blockquote><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><div><br></div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Al=
so. <font face=3D"courier new,monospace">const int a; </font><font face=3D"=
arial,sans-serif">will always bind to an </font><font face=3D"courier new,m=
onospace">int b, </font><font face=3D"arial,sans-serif">but a <font face=3D=
"courier new,monospace">MyClass c</font>, might not bind to </font><font fa=
ce=3D"courier new,monospace">MyConstraign MyClass d; <font face=3D"arial,sa=
ns-serif">Yet both are spelled out with the same syntax, both are "a c=
ase where one is just more constrained then the other", but in practic=
e mean different things.</font></font></div></div></blockquote><div>=C2=A0<=
/div><div>Firstly, this argument is not working for me, since const int&=
; will not bind to a int&. Secondly:</div><div>If (which I assume) MyCl=
ass=C2=A0 is a concrete type,</div><div><ul><li>either MyConstrain is a Val=
ue-Constraint<br>(in which case we face same "issue" (IMO, that&#=
39;s a feature), that Concept TS faces),<br></li><li>or MyConstrain is a Ty=
pe-Constraint<br>(in which case "MyClass" does very well bind to =
"MyConstraint MyClass", given MyClass after all meets MyConstrain=
t and doesn't generate a compiler error).</li></ul></div></div></blockq=
uote><div><br></div><div>My example was not very clear, but issue is still =
there, I believe - copyConstructable T will not bind to any T, however cons=
t T does not impose restrictions to the incoming T.</div><div> const is not=
a required clause, <span style=3D"display: inline !important; float: none;=
background-color: transparent; color: rgb(34, 34, 34); font-family: "=
Arial","Helvetica",sans-serif; font-size: 13px; font-style: =
normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orp=
hans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-tr=
ansform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-sp=
acing: 0px;">copyConstructable is, yet both are used exactly the same way. =
=C2=A0</span></div><div><br></div><div><span style=3D"display: inline !impo=
rtant; float: none; background-color: transparent; color: rgb(34, 34, 34); =
font-family: "Arial","Helvetica",sans-serif; font-size:=
13px; font-style: normal; font-variant: normal; font-weight: 400; letter-s=
pacing: normal; orphans: 2; text-align: left; text-decoration: none; text-i=
ndent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-spa=
ce: normal; word-spacing: 0px;">This mixing of qualifiers could be confusin=
g - sometimes it is about the <i>type</i>, sometimes it is about the <i>val=
ue</i>, sometime it is about the <i>variable</i>.</span></div><div><b><br><=
/b></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><br></div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div><b>Third. </b>Consider <font face=3D"courier ne=
w,monospace">A auto a =3D ...; B int b =3D ...; <font face=3D"arial,sans-se=
rif">From the C++ rules </font></font><font face=3D"arial,sans-serif">so fa=
r we might consider both of these are semantically the same, just in the se=
cond case the auto is spelled out. In fact however these two, are <b>radica=
lly</b> different - the first is constrained <i>type</i>, the other is cons=
trained <i>value</i>. This can be confusing no matter how we look at it - i=
f we look from variable declaration PoV we expect <i>both to be types </i>(=
but they are not) if we look at template argument declaration PoV (<auto=
I>, <int I>) we expect <i>both to be a value, </i>which is also n=
ot true!</font></div></div></blockquote><div>=C2=A0</div><div>I understand =
your concerns. However, this is not how I and Corentin propose Concepts.</d=
iv><div>Whether a Concept constraints the type or the value of a variable d=
epends on the concept, not on whether we "spell out the auto".</d=
iv><div>"Even" in the phrases "Even int i" and "Ev=
en auto i", will always constrain the values of i.</div><div>In the la=
tter phrase however, "auto" is allowed to deduce to any type (inc=
luding int),</div><div>for which the property "Even" is decidable=
(depending on the definition, probably for number-like types).</div></div>=
</blockquote><div><br></div><div>Then we still can't tell if the concep=
t is about the type or the value. Wasn't it one of the original goals t=
o have that distinction? </div><div>In any case, I understand variable decl=
aration is a separate issue!=C2=A0</div><div><br></div><div>=C2=A0</div><bl=
ockquote 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>=C2=A0</div=
><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div>The confusion with out continues with the fact <font face=
=3D"courier new,monospace">A auto</font> means one thing in code (as return=
value, variable or argument) and different as template param.<br></div><di=
v><font face=3D"courier new,monospace">f(A auto a){}; A auto a; A auto f() =
{}</font> are (<i>radically</i>) different then <font face=3D"courier new,m=
onospace">template<B auto I>.</font></div><div><font face=3D"arial,sa=
ns-serif">Yes, one can argue this is already the case, but this does not he=
lp either, not to mention auto as function params is not yet in.</font></di=
v></div></blockquote><div><br></div><div>I AM in favor of "auto" =
having the same meaning (regarding your concerns) across its usages.</div><=
div>This is the way I proposed it and I believe Corentin would too.</div><d=
iv>=C2=A0</div><div><br></div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>Forth<b>. </b><span style=3D"background-col=
or:transparent">Decorations are, by there nature, an ad hoc tool - to have =
something existing and to further specify it in the place of use. Constrain=
ed types are not like that, ad hoc constrain creation is unlikely.=C2=A0</s=
pan><font face=3D"courier new,monospace" style=3D"background-color:transpar=
ent;border-color:rgb(34,34,34);border-style:none;font-family:"courier =
new",monospace">Swappable Sortable Writable foo; <font face=3D"arial,s=
ans-serif" style=3D"border-color:rgb(34,34,34);border-style:none">in the re=
al world will likely be just</font> FooConcept foo; </font><font face=3D"ar=
ial,sans-serif" style=3D"background-color:transparent;border-color:rgb(34,3=
4,34);border-style:none;font-family:arial,sans-serif">semantically. It is v=
ery unlikely one will need to mix and match constrains on the go and pay th=
e syntax, maintenance, visual noise tax.</font></div></div></blockquote><di=
v><br></div><div>For the sake of argument, it's irrelevant how likely t=
his feature is used.</div><div>But if at all unlikely, this is a feature, n=
ot a bug. Nobody forces you to chain concepts this way.</div><div>Apart fro=
m that, I hardly believe, you will write a named concept for each and every=
such Concept-based function.</div><div>Why would you do so, if you only ne=
eded to chain the Concepts once for the whole function?</div><div>=C2=A0</d=
iv><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>I believe we should streamline Concepts as much as poss=
ible actually removing features and "optional syntaxes" before ad=
ding new ones.=C2=A0</div></div></blockquote><div><br></div><div>I agree wi=
th you here, although I don't find "Concepts TS revisited" to=
make things consistent enough.</div><div><br></div><div><br></div><div><br=
></div><div>When ansering to your concerns, I hope to have understood you c=
orrectly for the most part.</div><div>If not, please clarify those mistakes=
..</div><div><br></div><div>Yours,</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/c7a4678b-5a2f-457e-9be4-3979506ce4dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c7a4678b-5a2f-457e-9be4-3979506ce4dd=
%40isocpp.org</a>.<br />
------=_Part_8450_591950369.1515432133539--
------=_Part_8449_1219530408.1515432133538--
.
Author: Corentin <corentin.jabot@gmail.com>
Date: Mon, 08 Jan 2018 17:39:08 +0000
Raw View
--001a11471ee22692590562474726
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Constraints are associated to a type most of the type.
Values as in non type non template template parameter are odd enough, and
rare enough to begin with that I don't really see them as an issue.
Note that a concept can never apply to both a value and a type. `Even` is a
value concept.
In all other cases, the constrains are associated to a type. Either a
single value of that type (auto) , or a type as a whole (typename).
Le lun. 8 janv. 2018 =C3=A0 18:22, <mihailnajdenov@gmail.com> a =C3=A9crit =
:
>
>
> On Monday, January 8, 2018 at 5:42:50 PM UTC+2, Jakob Riedle wrote:
>>
>>
>>
>> Am Samstag, 6. Januar 2018 14:14:52 UTC+1 schrieb mihailn...@gmail.com:
>>>
>>> Hello, I wanted to share my thoughts on the broad topic of "Concepts as
>>> Adjectives".
>>>
>>> I believe they are not as innocent as presented.
>>>
>>
>> Yes, in my opinion, Concepts as adjectives/qualifiers are very very
>> powerful and in no way a diffident solution.
>>
>>
>>
>> *First,* a new category of user provided entities is silently introduced
>>> - type decorators. This is bigger a change then implied.
>>>
>>
>> When I first wrote "Concepts are Adjectives, Not Nouns", I very well
>> perceived them to be ground breaking.
>>
>>
>>
>> Up until this point all decorations were either keywords or attributes,
>>> and now we have something which looks like a type (or even a template!)=
,
>>> used as a qualifier to some other (real) type or auto.
>>>
>>
>> I agree, that it introduces identifiers (in constrast to keyword) as
>> qualifiers, which is unprecedented by now.
>> However, this identifier is hardly visually ambiguated with a type name,
>> because it ultimately is followed by a concrete type (least common case)=
,
>> "auto" or "typename" (most common cases).
>> In all situations, the noun is (in 9 of 10 cases) the last identifier,
>> which sets it visually apart.
>> In the latter two cases, the noun is a keyword and therefore additionall=
y
>> visually set apart.
>>
>>
>>
>> Sooner or later people will start asking, why I just can write only the
>>> decorator and the type be deduced, which the paper actually allow. In t=
hat
>>> case question arises do why do we need this new category in the first p=
lace.
>>>
>>
>> Because sometimes, we want to declare a constrained type (Sortable
>> typename S) and sometimes we want to declare a variable of constrained t=
ype
>> (Sortable auto s).
>> If you ask me, I am against making the noun optional in any case.
>> Actually for the same reason that C++ discourages "const" to implicitly
>> stand for "const int" (as in C).
>>
>>
>>
>> *Second*. Consider const Point arg. const is not about the type, *it's
>>> about the variable. *The fact that C++ handles const as a different
>>> type of Point is an implementation detail.
>>> However "type decorations" will be all about the type, in that one line
>>> we will have some decorations which *semantically* are about the
>>> variable and others about the type of it! This is bound to lead to
>>> confusion.
>>>
>>
>> Wait, do you think going from "template<typename T>" (without concepts)
>> to "template<Sortable T>" is less confusing?
>> Suddenly, we don't know whether T is a type after all?!
>>
>
>>
>>
>> Also. const int a; will always bind to an int b, but a MyClass c, might
>>> not bind to MyConstraign MyClass d; Yet both are spelled out with the
>>> same syntax, both are "a case where one is just more constrained then t=
he
>>> other", but in practice mean different things.
>>>
>>
>> Firstly, this argument is not working for me, since const int& will not
>> bind to a int&. Secondly:
>> If (which I assume) MyClass is a concrete type,
>>
>> - either MyConstrain is a Value-Constraint
>> (in which case we face same "issue" (IMO, that's a feature), that
>> Concept TS faces),
>> - or MyConstrain is a Type-Constraint
>> (in which case "MyClass" does very well bind to "MyConstraint
>> MyClass", given MyClass after all meets MyConstraint and doesn't gene=
rate a
>> compiler error).
>>
>>
> My example was not very clear, but issue is still there, I believe -
> copyConstructable T will not bind to any T, however const T does not impo=
se
> restrictions to the incoming T.
> const is not a required clause, copyConstructable is, yet both are used
> exactly the same way.
>
> This mixing of qualifiers could be confusing - sometimes it is about the
> *type*, sometimes it is about the *value*, sometime it is about the
> *variable*.
>
>
>
>>
>> *Third. *Consider A auto a =3D ...; B int b =3D ...; From the C++ rules =
so
>>> far we might consider both of these are semantically the same, just in =
the
>>> second case the auto is spelled out. In fact however these two, are
>>> *radically* different - the first is constrained *type*, the other is
>>> constrained *value*. This can be confusing no matter how we look at it
>>> - if we look from variable declaration PoV we expect *both to be types =
*(but
>>> they are not) if we look at template argument declaration PoV (<auto I>=
,
>>> <int I>) we expect *both to be a value, *which is also not true!
>>>
>>
>> I understand your concerns. However, this is not how I and Corentin
>> propose Concepts.
>> Whether a Concept constraints the type or the value of a variable depend=
s
>> on the concept, not on whether we "spell out the auto".
>> "Even" in the phrases "Even int i" and "Even auto i", will always
>> constrain the values of i.
>> In the latter phrase however, "auto" is allowed to deduce to any type
>> (including int),
>> for which the property "Even" is decidable (depending on the definition,
>> probably for number-like types).
>>
>
> Then we still can't tell if the concept is about the type or the value.
> Wasn't it one of the original goals to have that distinction?
> In any case, I understand variable declaration is a separate issue!
>
>
>
>>
>>
>>
>> The confusion with out continues with the fact A auto means one thing in
>>> code (as return value, variable or argument) and different as template
>>> param.
>>> f(A auto a){}; A auto a; A auto f() {} are (*radically*) different then=
template<B
>>> auto I>.
>>> Yes, one can argue this is already the case, but this does not help
>>> either, not to mention auto as function params is not yet in.
>>>
>>
>> I AM in favor of "auto" having the same meaning (regarding your concerns=
)
>> across its usages.
>> This is the way I proposed it and I believe Corentin would too.
>>
>>
>>
>> Forth*. *Decorations are, by there nature, an ad hoc tool - to have
>>> something existing and to further specify it in the place of use.
>>> Constrained types are not like that, ad hoc constrain creation is unlik=
ely. Swappable
>>> Sortable Writable foo; in the real world will likely be just FooConcept
>>> foo; semantically. It is very unlikely one will need to mix and match
>>> constrains on the go and pay the syntax, maintenance, visual noise tax.
>>>
>>
>> For the sake of argument, it's irrelevant how likely this feature is use=
d.
>> But if at all unlikely, this is a feature, not a bug. Nobody forces you
>> to chain concepts this way.
>> Apart from that, I hardly believe, you will write a named concept for
>> each and every such Concept-based function.
>> Why would you do so, if you only needed to chain the Concepts once for
>> the whole function?
>>
>>
>>
>> I believe we should streamline Concepts as much as possible actually
>>> removing features and "optional syntaxes" before adding new ones.
>>>
>>
>> I agree with you here, although I don't find "Concepts TS revisited" to
>> make things consistent enough.
>>
>>
>>
>> When ansering to your concerns, I hope to have understood you correctly
>> for the most part.
>> If not, please clarify those mistakes.
>>
>> Yours,
>> 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/c7a4678b-5a2=
f-457e-9be4-3979506ce4dd%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c7a4678b-5a=
2f-457e-9be4-3979506ce4dd%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/CA%2BOm%2BSi_HR%3DzjW%3DJi57ve2K8fV4ZSUbyhZXL%2B=
Z5RqoRz6Bp5kw%40mail.gmail.com.
--001a11471ee22692590562474726
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Constraints are associated to a type most of the type.<div=
><br><div>Values as in non type non template template parameter are odd eno=
ugh, and rare enough to begin with that I don't really see them as an i=
ssue.</div><div><br></div><div>Note that a concept can never apply to both =
a value and a type. `Even` is a value concept.</div><div><br></div><div>In =
all other cases, the constrains are associated to a type. Either a single v=
alue of that type (auto) , or a type as a whole (typename).</div><div><br><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0lun. 8 janv. 2=
018 =C3=A0=C2=A018:22, <<a href=3D"mailto:mihailnajdenov@gmail.com">miha=
ilnajdenov@gmail.com</a>> a =C3=A9crit=C2=A0:<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>On Monday, January 8, 2018 at 5:42:5=
0 PM UTC+2, Jakob Riedle wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><br><br>Am Samstag, 6. Januar 2018 14:14:52 UTC+1 schrieb <a>m=
ihailn...@gmail.com</a>:<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, I wanted to share my thoughts on the broad topic of "=
;Concepts as Adjectives".=C2=A0</div><div><br></div><div>I believe the=
y are not as innocent as presented.</div></div></blockquote><div>=C2=A0</di=
v><div>Yes, in my opinion, Concepts as adjectives/qualifiers are very very =
powerful and in no way a diffident solution.</div><div>=C2=A0</div><div><br=
></div><div><br></div><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"l=
tr"><div><b>First,</b> a new category of user provided entities is=C2=A0<sp=
an style=3D"display:inline!important;float:none;background-color:transparen=
t;color:rgb(34,34,34);font-family:"Arial","Helvetica",s=
ans-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:=
400;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px">silently intro=
duced</span> - type decorators. This is bigger a change then implied.</div>=
</div></blockquote><div>=C2=A0</div><div>When I first wrote "Concepts =
are Adjectives, Not Nouns", I very well perceived them to be ground br=
eaking.</div><div>=C2=A0</div><div><br></div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div><font face=3D"arial,sans-ser=
if"><b><i></i></b></font></div><div>Up until this point all decorations wer=
e either keywords or attributes, and now we have something which looks like=
a type (or even a template!), used as a qualifier to some other (real) typ=
e or auto.=C2=A0<br></div></div></blockquote><div>=C2=A0</div><div>I agree,=
that it introduces identifiers (in constrast to keyword) as qualifiers, wh=
ich is unprecedented by now.</div><div>However, this identifier is hardly v=
isually ambiguated with a type name, because it ultimately is followed by a=
concrete type (least common case), "auto" or "typename"=
; (most common cases).</div><div>In all situations, the noun is (in 9 of 10=
cases) the last identifier, which sets it visually apart.</div><div>In the=
latter two cases, the noun is a keyword and therefore additionally visuall=
y set apart.</div><div>=C2=A0</div><div><br></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></div><div>Sooner or la=
ter people will start asking, why I just can write only the decorator and t=
he type be deduced, which the paper actually allow. In that case question a=
rises do why do we need this new category in the first place.</div></div></=
blockquote><div>=C2=A0</div><div>Because sometimes, we want to declare a co=
nstrained type (Sortable typename S) and sometimes we want to declare a var=
iable of constrained type (Sortable auto s).</div><div>If you ask me, I am =
against making the noun optional in any case. Actually for the same reason =
that C++ discourages "const" to implicitly stand for "const =
int" (as in C).</div><div><br></div><div><br></div><div><br></div><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><b>Second</b>. Co=
nsider <font face=3D"courier new,monospace">const Point arg.</font><font fa=
ce=3D"arial,sans-serif"> <font face=3D"courier new,monospace">const</font> =
is not about the type, <i>it's about the variable. </i><font face=3D"ar=
ial,sans-serif">The fact that C++ handles const as a different type of Poin=
t is an implementation detail.</font></font><br></div><div>However "ty=
pe decorations" will be all about the type, in that one line we will h=
ave some decorations which <i>semantically</i> are about the variable and o=
thers about the type of it! This is bound to lead to confusion.</div></div>=
</blockquote><div>=C2=A0</div><div>Wait, do you think going from "temp=
late<typename T>" (without concepts) to "template<Sortab=
le T>" is less confusing?</div><div>Suddenly, we don't know whe=
ther T is a type after all?!=C2=A0</div></div></blockquote><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</div><div><br></div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
Also. <font face=3D"courier new,monospace">const int a; </font><font face=
=3D"arial,sans-serif">will always bind to an </font><font face=3D"courier n=
ew,monospace">int b, </font><font face=3D"arial,sans-serif">but a <font fac=
e=3D"courier new,monospace">MyClass c</font>, might not bind to </font><fon=
t face=3D"courier new,monospace">MyConstraign MyClass d; <font face=3D"aria=
l,sans-serif">Yet both are spelled out with the same syntax, both are "=
;a case where one is just more constrained then the other", but in pra=
ctice mean different things.</font></font></div></div></blockquote><div>=C2=
=A0</div><div>Firstly, this argument is not working for me, since const int=
& will not bind to a int&. Secondly:</div><div>If (which I assume) =
MyClass=C2=A0 is a concrete type,</div><div><ul><li>either MyConstrain is a=
Value-Constraint<br>(in which case we face same "issue" (IMO, th=
at's a feature), that Concept TS faces),<br></li><li>or MyConstrain is =
a Type-Constraint<br>(in which case "MyClass" does very well bind=
to "MyConstraint MyClass", given MyClass after all meets MyConst=
raint and doesn't generate a compiler error).</li></ul></div></div></bl=
ockquote><div><br></div></div><div dir=3D"ltr"><div>My example was not very=
clear, but issue is still there, I believe - copyConstructable T will not =
bind to any T, however const T does not impose restrictions to the incoming=
T.</div><div> const is not a required clause, <span style=3D"display:inlin=
e!important;float:none;background-color:transparent;color:rgb(34,34,34);fon=
t-family:"Arial","Helvetica",sans-serif;font-size:13px;=
font-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal=
;text-align:left;text-decoration:none;text-indent:0px;text-transform:none;w=
hite-space:normal;word-spacing:0px">copyConstructable is, yet both are used=
exactly the same way. =C2=A0</span></div><div><br></div><div><span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:"Arial","Helvetica",sans-seri=
f;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;lett=
er-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px">This mixing of qualifi=
ers could be confusing - sometimes it is about the <i>type</i>, sometimes i=
t is about the <i>value</i>, sometime it is about the <i>variable</i>.</spa=
n></div></div><div dir=3D"ltr"><div><b><br></b></div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><b>Third=
.. </b>Consider <font face=3D"courier new,monospace">A auto a =3D ...; B int=
b =3D ...; <font face=3D"arial,sans-serif">From the C++ rules </font></fon=
t><font face=3D"arial,sans-serif">so far we might consider both of these ar=
e semantically the same, just in the second case the auto is spelled out. I=
n fact however these two, are <b>radically</b> different - the first is con=
strained <i>type</i>, the other is constrained <i>value</i>. This can be co=
nfusing no matter how we look at it - if we look from variable declaration =
PoV we expect <i>both to be types </i>(but they are not) if we look at temp=
late argument declaration PoV (<auto I>, <int I>) we expect <i>=
both to be a value, </i>which is also not true!</font></div></div></blockqu=
ote><div>=C2=A0</div><div>I understand your concerns. However, this is not =
how I and Corentin propose Concepts.</div><div>Whether a Concept constraint=
s the type or the value of a variable depends on the concept, not on whethe=
r we "spell out the auto".</div><div>"Even" in the phra=
ses "Even int i" and "Even auto i", will always constra=
in the values of i.</div><div>In the latter phrase however, "auto"=
; is allowed to deduce to any type (including int),</div><div>for which the=
property "Even" is decidable (depending on the definition, proba=
bly for number-like types).</div></div></blockquote><div><br></div></div><d=
iv dir=3D"ltr"><div>Then we still can't tell if the concept is about th=
e type or the value. Wasn't it one of the original goals to have that d=
istinction? </div><div>In any case, I understand variable declaration is a =
separate issue!=C2=A0</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>=C2=
=A0</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>The confusion with out continues with the fact <f=
ont face=3D"courier new,monospace">A auto</font> means one thing in code (a=
s return value, variable or argument) and different as template param.<br><=
/div><div><font face=3D"courier new,monospace">f(A auto a){}; A auto a; A a=
uto f() {}</font> are (<i>radically</i>) different then <font face=3D"couri=
er new,monospace">template<B auto I>.</font></div><div><font face=3D"=
arial,sans-serif">Yes, one can argue this is already the case, but this doe=
s not help either, not to mention auto as function params is not yet in.</f=
ont></div></div></blockquote><div><br></div><div>I AM in favor of "aut=
o" having the same meaning (regarding your concerns) across its usages=
..</div><div>This is the way I proposed it and I believe Corentin would too.=
</div><div>=C2=A0</div><div><br></div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>Forth<b>. </b><span style=3D"backgr=
ound-color:transparent">Decorations are, by there nature, an ad hoc tool - =
to have something existing and to further specify it in the place of use. C=
onstrained types are not like that, ad hoc constrain creation is unlikely.=
=C2=A0</span><font face=3D"courier new,monospace" style=3D"background-color=
:transparent;border-color:rgb(34,34,34);border-style:none;font-family:"=
;courier new",monospace">Swappable Sortable Writable foo; <font face=
=3D"arial,sans-serif" style=3D"border-color:rgb(34,34,34);border-style:none=
">in the real world will likely be just</font> FooConcept foo; </font><font=
face=3D"arial,sans-serif" style=3D"background-color:transparent;border-col=
or:rgb(34,34,34);border-style:none;font-family:arial,sans-serif">semantical=
ly. It is very unlikely one will need to mix and match constrains on the go=
and pay the syntax, maintenance, visual noise tax.</font></div></div></blo=
ckquote><div><br></div><div>For the sake of argument, it's irrelevant h=
ow likely this feature is used.</div><div>But if at all unlikely, this is a=
feature, not a bug. Nobody forces you to chain concepts this way.</div><di=
v>Apart from that, I hardly believe, you will write a named concept for eac=
h and every such Concept-based function.</div><div>Why would you do so, if =
you only needed to chain the Concepts once for the whole function?</div><di=
v>=C2=A0</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;padding-l=
eft:1ex"><div dir=3D"ltr"><div>I believe we should streamline Concepts as m=
uch as possible actually removing features and "optional syntaxes"=
; before adding new ones.=C2=A0</div></div></blockquote><div><br></div><div=
>I agree with you here, although I don't find "Concepts TS revisit=
ed" to make things consistent enough.</div><div><br></div><div><br></d=
iv><div><br></div><div>When ansering to your concerns, I hope to have under=
stood you correctly for the most part.</div><div>If not, please clarify tho=
se mistakes.</div><div><br></div><div>Yours,</div><div>Jakob</div></div></b=
lockquote></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/c7a4678b-5a2f-457e-9be4-3979506ce4dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c7a4678b-5a2f-=
457e-9be4-3979506ce4dd%40isocpp.org</a>.<br>
</blockquote></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/CA%2BOm%2BSi_HR%3DzjW%3DJi57ve2K8fV4Z=
SUbyhZXL%2BZ5RqoRz6Bp5kw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm=
%2BSi_HR%3DzjW%3DJi57ve2K8fV4ZSUbyhZXL%2BZ5RqoRz6Bp5kw%40mail.gmail.com</a>=
..<br />
--001a11471ee22692590562474726--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Mon, 8 Jan 2018 10:51:52 -0800 (PST)
Raw View
------=_Part_15327_430861946.1515437512776
Content-Type: multipart/alternative;
boundary="----=_Part_15328_1655760090.1515437512777"
------=_Part_15328_1655760090.1515437512777
Content-Type: text/plain; charset="UTF-8"
Am Montag, 8. Januar 2018 18:22:13 UTC+1 schrieb mihailn...@gmail.com:
>
> My example was not very clear, but issue is still there, I believe -
> copyConstructable T will not bind to any T, however const T does not impose
> restrictions to the incoming T.
> const is not a required clause, copyConstructable is, yet both are used
> exactly the same way.
>
> This mixing of qualifiers could be confusing - sometimes it is about the
> *type*, sometimes it is about the *value*, sometime it is about the
> *variable*.
>
Well, your example probably was intended to go the other way around, right?
I see your point. As I think about it: const *relaxes* the constraints
implicitly put on a variable.
While a non-const-qualified Variable is expected to be modifieable (that's
an implicit constraint),
a const-qualified variable does not require this constraint to be met.
Now comes the point: You can always cast from something more constrained to
something less constrained (see contract-based-programming).
The confuse comes into play because this topic has never been touched by
anyone before (TMK) :P
Does that make sense?
Similarly, "volatile" doesn't require the variable to be appropriately
loadable from cache.
While a normal variable is implicitly expected to not change from outside
the programs environment, a volatile variable is allowed to do that.
Again: relaxed Constraints.
That's really interesting for me right now!
Funnily, the constraints on a normal variable are not "zero" and you can
lower constraints below that!
Thank you for this enlightening comment of yours!
*Third. *Consider A auto a = ...; B int b = ...; From the C++ rules so far
>>> we might consider both of these are semantically the same, just in the
>>> second case the auto is spelled out. In fact however these two, are
>>> *radically* different - the first is constrained *type*, the other is
>>> constrained *value*. This can be confusing no matter how we look at it
>>> - if we look from variable declaration PoV we expect *both to be types *(but
>>> they are not) if we look at template argument declaration PoV (<auto I>,
>>> <int I>) we expect *both to be a value, *which is also not true!
>>>
>>
>> I understand your concerns. However, this is not how I and Corentin
>> propose Concepts.
>> Whether a Concept constraints the type or the value of a variable depends
>> on the concept, not on whether we "spell out the auto".
>> "Even" in the phrases "Even int i" and "Even auto i", will always
>> constrain the values of i.
>> In the latter phrase however, "auto" is allowed to deduce to any type
>> (including int),
>> for which the property "Even" is decidable (depending on the definition,
>> probably for number-like types).
>>
>
> Then we still can't tell if the concept is about the type or the value.
> Wasn't it one of the original goals to have that distinction?
> In any case, I understand variable declaration is a separate issue!
>
No, the original goal was to know, whether an identifier constrained by a
concept refers a type or value.
Obviously, Value-Concepts can only constrain values, but Type-Concepts can
both constrain "auto" variables and "typename" variables.
However, Value-Concepts can - depending on their definition - implicitly
constrain the type of an "auto" Variable, because a given property is only
decidable for a given set of datatypes.
--
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/38b70213-bea0-4a62-86c7-6c5ee91254f6%40isocpp.org.
------=_Part_15328_1655760090.1515437512777
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Am Montag, 8. Januar 2018 18:22:13 UTC+1 schrieb m=
ihailn...@gmail.com:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>My example was not very clear, but issue is still there, I be=
lieve - copyConstructable T will not bind to any T, however const T does no=
t impose restrictions to the incoming T.<br></div><div> const is not a requ=
ired clause, <span style=3D"display:inline!important;float:none;background-=
color:transparent;color:rgb(34,34,34);font-family:"Arial","H=
elvetica",sans-serif;font-size:13px;font-style:normal;font-variant:nor=
mal;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:n=
one;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px=
">copyConstructable is, yet both are used exactly the same way. =C2=A0</spa=
n></div><div><br></div><div><span style=3D"display:inline!important;float:n=
one;background-color:transparent;color:rgb(34,34,34);font-family:"Aria=
l","Helvetica",sans-serif;font-size:13px;font-style:normal;f=
ont-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;te=
xt-decoration:none;text-indent:0px;text-transform:none;white-space:normal;w=
ord-spacing:0px">This mixing of qualifiers could be confusing - sometimes i=
t is about the <i>type</i>, sometimes it is about the <i>value</i>, sometim=
e it is about the <i>variable</i>.</span></div></div></blockquote><div><br>=
</div><div>Well, your example probably was intended to go the other way aro=
und, right?</div><div>I see your point. As I think about it: const=C2=A0<i>=
relaxes</i> the constraints implicitly put on a variable.</div><div>While a=
non-const-qualified Variable is expected to be modifieable (that's an =
implicit constraint),</div><div>a const-qualified variable does not require=
this constraint to be met.</div><div><br></div><div>Now comes the point: Y=
ou can always cast from something more constrained to something less constr=
ained (see contract-based-programming).</div><div>The confuse comes into pl=
ay because this topic has never been touched by anyone before (TMK)=C2=A0 :=
P</div><div><br></div><div>Does that make sense?</div><div><br></div><div><=
br></div><div>Similarly, "volatile" doesn't require the varia=
ble to be appropriately loadable from cache.</div><div>While a normal varia=
ble is implicitly expected to not change from outside the programs environm=
ent, a volatile variable is allowed to do that.</div><div>Again: relaxed Co=
nstraints.</div><div><br></div><div>That's really interesting for me ri=
ght now!</div><div>Funnily, the constraints on a normal variable are not &q=
uot;zero" and you can lower constraints below that!</div><div><br></di=
v><div>Thank you for this enlightening comment of yours!</div><div>=C2=A0</=
div><div><br></div><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"><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"><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><b>Third. </b>Consider <f=
ont face=3D"courier new,monospace">A auto a =3D ...; B int b =3D ...; <font=
face=3D"arial,sans-serif">From the C++ rules </font></font><font face=3D"a=
rial,sans-serif">so far we might consider both of these are semantically th=
e same, just in the second case the auto is spelled out. In fact however th=
ese two, are <b>radically</b> different - the first is constrained <i>type<=
/i>, the other is constrained <i>value</i>. This can be confusing no matter=
how we look at it - if we look from variable declaration PoV we expect <i>=
both to be types </i>(but they are not) if we look at template argument dec=
laration PoV (<auto I>, <int I>) we expect <i>both to be a valu=
e, </i>which is also not true!</font></div></div></blockquote><div>=C2=A0</=
div><div>I understand your concerns. However, this is not how I and Corenti=
n propose Concepts.</div><div>Whether a Concept constraints the type or the=
value of a variable depends on the concept, not on whether we "spell =
out the auto".</div><div>"Even" in the phrases "Even in=
t i" and "Even auto i", will always constrain the values of =
i.</div><div>In the latter phrase however, "auto" is allowed to d=
educe to any type (including int),</div><div>for which the property "E=
ven" is decidable (depending on the definition, probably for number-li=
ke types).</div></div></blockquote><div><br></div><div>Then we still can=
9;t tell if the concept is about the type or the value. Wasn't it one o=
f the original goals to have that distinction? </div><div>In any case, I un=
derstand variable declaration is a separate issue!=C2=A0</div></div></block=
quote><div><br></div><div>No, the original goal was to know, whether an ide=
ntifier constrained by a concept refers a type or value.</div><div>Obviousl=
y, Value-Concepts can only constrain values, but Type-Concepts can both con=
strain "auto" variables and "typename" variables.</div>=
<div>However, Value-Concepts can - depending on their definition - implicit=
ly constrain the type of an "auto" Variable, because a given prop=
erty is only decidable for a given set of datatypes.</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/38b70213-bea0-4a62-86c7-6c5ee91254f6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/38b70213-bea0-4a62-86c7-6c5ee91254f6=
%40isocpp.org</a>.<br />
------=_Part_15328_1655760090.1515437512777--
------=_Part_15327_430861946.1515437512776--
.
Author: mihailnajdenov@gmail.com
Date: Mon, 8 Jan 2018 11:49:35 -0800 (PST)
Raw View
------=_Part_15338_1178159398.1515440975514
Content-Type: multipart/alternative;
boundary="----=_Part_15339_1160685593.1515440975515"
------=_Part_15339_1160685593.1515440975515
Content-Type: text/plain; charset="UTF-8"
On Monday, January 8, 2018 at 8:51:52 PM UTC+2, Jakob Riedle wrote:
>
>
>
> Am Montag, 8. Januar 2018 18:22:13 UTC+1 schrieb mihailn...@gmail.com:
>>
>> My example was not very clear, but issue is still there, I believe -
>> copyConstructable T will not bind to any T, however const T does not impose
>> restrictions to the incoming T.
>> const is not a required clause, copyConstructable is, yet both are used
>> exactly the same way.
>>
>> This mixing of qualifiers could be confusing - sometimes it is about the
>> *type*, sometimes it is about the *value*, sometime it is about the
>> *variable*.
>>
>
> Well, your example probably was intended to go the other way around, right?
> I see your point. As I think about it: const *relaxes* the constraints
> implicitly put on a variable.
> While a non-const-qualified Variable is expected to be modifieable (that's
> an implicit constraint),
> a const-qualified variable does not require this constraint to be met.
>
> Now comes the point: You can always cast from something more constrained
> to something less constrained (see contract-based-programming).
> The confuse comes into play because this topic has never been touched by
> anyone before (TMK) :P
>
> Does that make sense?
>
>
> Similarly, "volatile" doesn't require the variable to be appropriately
> loadable from cache.
> While a normal variable is implicitly expected to not change from outside
> the programs environment, a volatile variable is allowed to do that.
> Again: relaxed Constraints.
>
> That's really interesting for me right now!
> Funnily, the constraints on a normal variable are not "zero" and you can
> lower constraints below that!
>
> Thank you for this enlightening comment of yours!
>
>
> *Third. *Consider A auto a = ...; B int b = ...; From the C++ rules so
>>>> far we might consider both of these are semantically the same, just in the
>>>> second case the auto is spelled out. In fact however these two, are
>>>> *radically* different - the first is constrained *type*, the other is
>>>> constrained *value*. This can be confusing no matter how we look at it
>>>> - if we look from variable declaration PoV we expect *both to be types
>>>> *(but they are not) if we look at template argument declaration PoV
>>>> (<auto I>, <int I>) we expect *both to be a value, *which is also not
>>>> true!
>>>>
>>>
>>> I understand your concerns. However, this is not how I and Corentin
>>> propose Concepts.
>>> Whether a Concept constraints the type or the value of a variable
>>> depends on the concept, not on whether we "spell out the auto".
>>> "Even" in the phrases "Even int i" and "Even auto i", will always
>>> constrain the values of i.
>>> In the latter phrase however, "auto" is allowed to deduce to any type
>>> (including int),
>>> for which the property "Even" is decidable (depending on the definition,
>>> probably for number-like types).
>>>
>>
>> Then we still can't tell if the concept is about the type or the value.
>> Wasn't it one of the original goals to have that distinction?
>> In any case, I understand variable declaration is a separate issue!
>>
>
> No, the original goal was to know, whether an identifier constrained by a
> concept refers a type or value.
> Obviously, Value-Concepts can only constrain values, but Type-Concepts can
> both constrain "auto" variables and "typename" variables.
> However, Value-Concepts can - depending on their definition - implicitly
> constrain the type of an "auto" Variable, because a given property is only
> decidable for a given set of datatypes.
>
The fact stays, one can't tell if a Concept is a value or type one, right?
The compiler knows, of course, but the user must look up the definition (or
judge by the name), not unlike in the original problem.
And I am still concerned, we now have not just a new category
(user-provided type decorator), but we add two new decorator categories.
Where before we just for the variable, now we have two more (for type and
value), all spelled right next to each other.
Now, that I think about it I mainly have a problems with variable
declarations, as template params I am not that worried. But, then, all
papers revolve primarily around variable declarations, to solve the terse
syntax argument problem.
As I said initially, I am more worried right now, Concepts might be a bit
messy, from what I saw, which is unfortunate, considering the more or less
the clean slate. And the messy part for me is the *definition*, not the
usage.
--
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/44af2de4-711b-4042-aae7-7439db92e896%40isocpp.org.
------=_Part_15339_1160685593.1515440975515
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, January 8, 2018 at 8:51:52 PM UTC+2, Ja=
kob Riedle wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br><br>Am Montag, 8. Januar 2018 18:22:13 UTC+1 schrieb <a>mihailn...@=
gmail.com</a>:<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=
>My example was not very clear, but issue is still there, I believe - copyC=
onstructable T will not bind to any T, however const T does not impose rest=
rictions to the incoming T.<br></div><div> const is not a required clause, =
<span style=3D"display:inline!important;float:none;background-color:transpa=
rent;color:rgb(34,34,34);font-family:"Arial","Helvetica"=
;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-weig=
ht:400;letter-spacing:normal;text-align:left;text-decoration:none;text-inde=
nt:0px;text-transform:none;white-space:normal;word-spacing:0px">copyConstru=
ctable is, yet both are used exactly the same way. =C2=A0</span></div><div>=
<br></div><div><span style=3D"display:inline!important;float:none;backgroun=
d-color:transparent;color:rgb(34,34,34);font-family:"Arial","=
;Helvetica",sans-serif;font-size:13px;font-style:normal;font-variant:n=
ormal;font-weight:400;letter-spacing:normal;text-align:left;text-decoration=
:none;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0=
px">This mixing of qualifiers could be confusing - sometimes it is about th=
e <i>type</i>, sometimes it is about the <i>value</i>, sometime it is about=
the <i>variable</i>.</span></div></div></blockquote><div><br></div><div>We=
ll, your example probably was intended to go the other way around, right?</=
div><div>I see your point. As I think about it: const=C2=A0<i>relaxes</i> t=
he constraints implicitly put on a variable.</div><div>While a non-const-qu=
alified Variable is expected to be modifieable (that's an implicit cons=
traint),</div><div>a const-qualified variable does not require this constra=
int to be met.</div><div><br></div><div>Now comes the point: You can always=
cast from something more constrained to something less constrained (see co=
ntract-based-programming).</div><div>The confuse comes into play because th=
is topic has never been touched by anyone before (TMK)=C2=A0 :P</div><div><=
br></div><div>Does that make sense?</div><div><br></div><div><br></div><div=
>Similarly, "volatile" doesn't require the variable to be app=
ropriately loadable from cache.</div><div>While a normal variable is implic=
itly expected to not change from outside the programs environment, a volati=
le variable is allowed to do that.</div><div>Again: relaxed Constraints.</d=
iv><div><br></div><div>That's really interesting for me right now!</div=
><div>Funnily, the constraints on a normal variable are not "zero"=
; and you can lower constraints below that!</div><div><br></div><div>Thank =
you for this enlightening comment of yours!</div><div>=C2=A0</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><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"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><b>Third. </b>Consider <font face=3D"courie=
r new,monospace">A auto a =3D ...; B int b =3D ...; <font face=3D"arial,san=
s-serif">From the C++ rules </font></font><font face=3D"arial,sans-serif">s=
o far we might consider both of these are semantically the same, just in th=
e second case the auto is spelled out. In fact however these two, are <b>ra=
dically</b> different - the first is constrained <i>type</i>, the other is =
constrained <i>value</i>. This can be confusing no matter how we look at it=
- if we look from variable declaration PoV we expect <i>both to be types <=
/i>(but they are not) if we look at template argument declaration PoV (<=
auto I>, <int I>) we expect <i>both to be a value, </i>which is al=
so not true!</font></div></div></blockquote><div>=C2=A0</div><div>I underst=
and your concerns. However, this is not how I and Corentin propose Concepts=
..</div><div>Whether a Concept constraints the type or the value of a variab=
le depends on the concept, not on whether we "spell out the auto"=
..</div><div>"Even" in the phrases "Even int i" and &quo=
t;Even auto i", will always constrain the values of i.</div><div>In th=
e latter phrase however, "auto" is allowed to deduce to any type =
(including int),</div><div>for which the property "Even" is decid=
able (depending on the definition, probably for number-like types).</div></=
div></blockquote><div><br></div><div>Then we still can't tell if the co=
ncept is about the type or the value. Wasn't it one of the original goa=
ls to have that distinction? </div><div>In any case, I understand variable =
declaration is a separate issue!=C2=A0</div></div></blockquote><div><br></d=
iv><div>No, the original goal was to know, whether an identifier constraine=
d by a concept refers a type or value.</div><div>Obviously, Value-Concepts =
can only constrain values, but Type-Concepts can both constrain "auto&=
quot; variables and "typename" variables.</div><div>However, Valu=
e-Concepts can - depending on their definition - implicitly constrain the t=
ype of an "auto" Variable, because a given property is only decid=
able for a given set of datatypes.</div></div></blockquote><div><br></div><=
div><br></div><div>The fact stays, one can't tell if a Concept is a val=
ue or type one, right?=C2=A0 The compiler knows, of course, but the user mu=
st look up the definition (or judge by the name), not unlike in the origina=
l problem.</div><div><br></div><div>And I am still concerned, we now have n=
ot just a new category (user-provided type decorator), but we add two new d=
ecorator categories. Where before we just for the variable, now we have two=
more (for type and value), all spelled right next to each other.</div><div=
><br></div><div><br></div><div>Now, that I think about it I mainly have a p=
roblems with variable declarations, as template params I am not that worrie=
d. But, then, all papers revolve primarily around variable declarations, to=
solve the terse syntax argument problem.</div><div><br></div><div><br></di=
v><div>As I said initially, I am more worried right now, Concepts might be =
a bit messy, from what I saw, which is unfortunate, considering the more or=
less the clean slate. And the messy part for me is the <i>definition</i>, =
not the usage.</div><div>=C2=A0</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/44af2de4-711b-4042-aae7-7439db92e896%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/44af2de4-711b-4042-aae7-7439db92e896=
%40isocpp.org</a>.<br />
------=_Part_15339_1160685593.1515440975515--
------=_Part_15338_1178159398.1515440975514--
.