------=_Part_23263_1786757396.1529400834810
Content-Type: multipart/alternative;
 boundary="----=_Part_23264_643230127.1529400834812"

------=_Part_23264_643230127.1529400834812
Content-Type: text/plain; charset="UTF-8"

OK, right now in flight are about FOUR proposals, trying to "simplify" and
"make more clear" concepts usage.

This is madness. It is madness, because NONE of it make it more clear!
None.

By inviting new language constructs one does not make things "more clear",
it only adds more things to learn.

The worst part is - *we have working solution that is clear. Granted
verbose, but clear. *

If one makes it Not verbose but Not clear (not self-explanatory, need
learning) also one gains nothing!


Consider

template<Iterator Iter1, Iterator Iter2>
     requires Comparable_though_iterators<Iter1, Iter2>
bool equal(Iter1 first, Iter1 last, Iter2)
{}

This code is *clear to ANYONE who EVER worked with C++*, even to a time
traveler from 30 years ago!

Comparable_through_iterators{Iter1,Iter2}
bool equal(Iter1 first, Iter1 last, Iter2)
{}

This is *NOT clear*!

*First* Comparable_ can be confused with a return type when one starts to
read.
*Second* The syntax is COMPLETELY alien to templates - de facto new
language.
*Third *there is no obvious connection b/w the function and the clause  -
it just sits there like a separate declaration
*Forth *Automatic names introductions is very uncommon and will be
confusing for sure.

The gain of one-less-line is DWARFED by the HEAP of "new stuff" that does
NOT grant "new powers"!


 --- Let's continue


Between

void sort(Sortable& s);

and

template void sort(Sortable& s);

*The second is more confusing! *Why? Because it abuses an already
established syntax for something *completely* different.

Is the first confusing? Might be. What is the solution?

Solution 1:

If this is your code, and you might be confused - don't use it, use the
more verbose, but more clear syntax!

Solution 2:

Just ctrl-click on Sortable (hell, just hover over it) and all you doubts
will be solved!


Inventing completely new syntax in the form of  Sortable{} is even worse:

Consider

Number x{};
[](Number{} x)
{}
[x = Number{}]()
{}

Again, any gains are dwarfed by introducing new syntax to learn and/or new
ways to read old constructs!
And the biggest problem is - that syntax right now donates *an action *and
here it will not, it will be just an indicator!


 --- Let's continue further

Another non-issue is "the problem one cannot differentiate b/w constrained
value and a type concept"

template<Concept T, Value v> void f() {}

Why this is non-issue?

*First* Because templates are inline, usage is visible and Types and Value
are used RADICALLY differently.
In real word it will *always* be clear which is which!

*Second* as already mentioned in one of the papers - one can use a naming
convection.

*Third* the more verbose syntax (the a requires clause) is still available!

And BTW lets not forget we have class template arguments now, so the
template arguments are bound to be a bit overloaded now!

template<Concept T, Value v, Class c> void f() {}

Nothing wrong with that - we can use naming conventions and we have good
IDEs to help us - no need for syntax noise.


*The Solution To All This*


For now, include *only* the syntax clear to a time traveler! Do not include
ANYTHING new to learn!

We are JUST introducing Concepts to the general public - *that alone is
enough new  material!*

For Simple cases

template<Sortable S>
void sort(S& s);

For Complex cases

template<Iterator Iter1, Iterator Iter2>
     requires Comparable_though_iterators<Iter1, Iter2>
bool equal(Iter1 first, Iter1 last, Iter2)
{}

      *THATS IT. DONE. *

*No*
template void sort(Sortable& s);

*No*
void sort(Sortable{}& s);

*No*
template<Arithmetic{N}, Arithmetic {} n> void f(N);

*No*
template<auto Arithmetic N> void f();

*No*
template<Comparable_through_iterators{Iter1,Iter2}>
bool equal(Iter1 first, Iter1 last, Iter2)
{}

*And HELL No*
Comparable_through_iterators{Iter1,Iter2}
bool equal(Iter1 first, Iter1 last, Iter2)
{}

*Why?*

*A. Because of the time traveler!!!*

*B. Let the users have theirs say IN THE REAL WORD.*

*C. We can ALWAYS add "simpler" syntax later, say in 5 years!*


*Future Directions*

Why not let arguments be comma separated lists if we care so much about
typing

template<class In1, In2, Out>
   requires Mergeable<In1, In2, Out>
Out merge(In1,In1,In2,In2,Out);

Why not instead of the new syntax for names introducing we simply

requires Mergeable<In1, In2, Out>
Out merge(In1,In1,In2,In2,Out);





--
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/19c57a60-e883-4474-b106-7ff2ebc122ee%40isocpp.org.

------=_Part_23264_643230127.1529400834812
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>OK, right now in flight are about FOUR proposals, try=
ing to &quot;simplify&quot; and &quot;make more clear&quot; concepts usage.=
</div><div><br></div><div>This is madness. It is madness, because NONE of i=
t make it more clear! None.=C2=A0</div><div><br></div><div>By inviting new =
language constructs one does not make things &quot;more clear&quot;, it onl=
y adds more things to learn.</div><div><br></div><div>The worst part is - <=
i>we have working solution that is clear. Granted verbose, but clear.=C2=A0=
</i></div><div><i></i><br></div><div>If one makes it Not verbose but Not cl=
ear (not self-explanatory, need learning) also one gains nothing!=C2=A0</di=
v><div><br></div><div><br></div><div>Consider</div><div><br></div><div><fon=
t face=3D"courier new,monospace">template&lt;Iterator Iter1, Iterator Iter2=
&gt;=C2=A0</font></div><div><font face=3D"courier new,monospace">=C2=A0 =C2=
=A0=C2=A0 requires Comparable_though_iterators&lt;Iter1, Iter2&gt;</font></=
div><div><font face=3D"courier new,monospace">bool equal(Iter1 first, Iter1=
 last, Iter2)=C2=A0</font></div><div><font face=3D"courier new,monospace">{=
}=C2=A0</font></div><div><br></div><div>This code is <b>clear to ANYONE who=
 EVER worked with C++</b>, even to a time traveler from 30 years ago!</div>=
<div><br></div><div><font face=3D"courier new,monospace">Comparable_through=
_iterators{Iter1,Iter2}=C2=A0</font></div><div><font face=3D"courier new,mo=
nospace">bool equal(Iter1 first, Iter1 last, Iter2)=C2=A0</font></div><div>=
<font face=3D"courier new,monospace">{}=C2=A0</font></div><div><br></div><d=
iv>This is <b>NOT clear</b>!=C2=A0</div><div><br></div><div><b>First</b> <s=
pan style=3D"display: inline !important; float: none; background-color: tra=
nsparent; color: rgb(34, 34, 34); font-family: courier new,monospace; font-=
size: 13px; font-style: normal; font-variant: normal; font-weight: 400; let=
ter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; t=
ext-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whit=
e-space: normal; word-spacing: 0px;">Comparable<font face=3D"&quot;Arial&qu=
ot;,&quot;Helvetica&quot;,sans-serif">_</font></span> can be confused with =
a return type when one starts to read.=C2=A0</div><div><b>Second</b> The sy=
ntax is COMPLETELY alien to templates - de facto new language.=C2=A0</div><=
div><b>Third </b>there is no obvious connection b/w the function and the cl=
ause=C2=A0 - it just sits there like a separate declaration</div><div><b>Fo=
rth </b>Automatic names introductions is very uncommon and will be confusin=
g for sure.</div><div><br></div><div>The gain of one-less-line is DWARFED b=
y the HEAP of &quot;new stuff&quot; that does NOT grant &quot;new powers&qu=
ot;!</div><div><br></div><div><br></div><div>=C2=A0--- Let&#39;s continue</=
div><div><br></div><div><br></div><div>Between=C2=A0</div><div><br></div><d=
iv><font face=3D"courier new,monospace">void sort(Sortable&amp; s); =C2=A0<=
/font><font face=3D"courier new,monospace"><br></font></div><div><font face=
=3D"courier new,monospace"><br></font></div><div><font face=3D"courier new,=
monospace">and</font></div><div><font face=3D"courier new,monospace"><br></=
font></div><div><font face=3D"courier new,monospace">template void sort(Sor=
table&amp; s);=C2=A0</font></div><div><font face=3D"courier new,monospace">=
<br></font></div><div><i>The second is more confusing! </i>Why? Because it =
abuses an already established syntax for something <i>completely</i> differ=
ent.=C2=A0</div><div><br></div><div>Is the first confusing? Might be. What =
is the solution?</div><div><br></div><div>Solution 1:</div><div><br></div><=
div>If this is your code, and you might be confused - don&#39;t use it, use=
 the more verbose, but more clear syntax!</div><div><br></div><div>Solution=
 2:</div><div><br></div><div>Just ctrl-click on Sortable (hell, just hover =
over it) and all you doubts will be solved!=C2=A0</div><div><br></div><div>=
<br></div><div>Inventing completely new syntax in the form of=C2=A0=C2=A0<s=
pan style=3D"display: inline !important; float: none; background-color: tra=
nsparent; color: rgb(34, 34, 34); font-family: courier new,monospace; font-=
size: 13px; font-style: normal; font-variant: normal; font-weight: 400; let=
ter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; t=
ext-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whit=
e-space: normal; word-spacing: 0px;">Sortable{} <font face=3D"arial,sans-se=
rif">is even worse:</font></span></div><div><span style=3D"display: inline =
!important; float: none; background-color: transparent; color: rgb(34, 34, =
34); font-family: courier new,monospace; 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;"><font face=3D"arial,sans-serif"><br></font></span></div><div><span =
style=3D"display: inline !important; float: none; background-color: transpa=
rent; color: rgb(34, 34, 34); font-family: courier new,monospace; 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; -webkit-text-stroke-width: 0px; white-sp=
ace: normal; word-spacing: 0px;"><font face=3D"arial,sans-serif">Consider=
=C2=A0</font></span></div><div><font face=3D"times new roman,serif"><i><b><=
/b><u></u><sub></sub><sup></sup><strike></strike><b></b><u></u><sub></sub><=
sup></sup><strike></strike><font face=3D"arial,sans-serif"></font><br></i><=
/font></div><div><span style=3D"text-align: left; color: rgb(34, 34, 34); t=
ext-transform: none; text-indent: 0px; letter-spacing: normal; font-size: 1=
3px; font-style: normal; font-variant: normal; font-weight: 400; text-decor=
ation: none; word-spacing: 0px; display: inline !important; white-space: no=
rmal; orphans: 2; float: none; -webkit-text-stroke-width: 0px; background-c=
olor: transparent;"><font face=3D"courier new,monospace">Number x{};</font>=
</span><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></di=
v><div><font face=3D"courier new,monospace">[](Number{} x)=C2=A0</font></di=
v><div><font face=3D"courier new,monospace">{} </font></div><div><div style=
=3D"background-color: transparent; border-bottom-color: rgb(34, 34, 34); bo=
rder-bottom-style: none; border-bottom-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-l=
eft-style: none; border-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-top-style: none; border-top-width: 0px; color: rgb(34,=
 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;qu=
ot;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; =
font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: =
0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; p=
adding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; t=
ext-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-=
stroke-width: 0px; white-space: normal; word-spacing: 0px;">[<font face=3D"=
courier new,monospace" style=3D"border-bottom-color: rgb(34, 34, 34); borde=
r-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; bor=
der-image-repeat: stretch; border-image-slice: 100%; border-image-source: n=
one; 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-color: rgb(34=
, 34, 34); border-top-style: none; border-top-width: 0px; margin-bottom: 0p=
x; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0p=
x; padding-left: 0px; padding-right: 0px; padding-top: 0px;">x =3D Number{}=
]()</font></div><div style=3D"background-color: transparent; border-bottom-=
color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-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: 0px; border-r=
ight-color: rgb(34, 34, 34); border-right-style: none; border-right-width: =
0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-=
width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,=
&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: norm=
al; font-variant: normal; font-weight: 400; letter-spacing: normal; margin-=
bottom: 0px; margin-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-tran=
sform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spac=
ing: 0px;"><font face=3D"courier new,monospace" style=3D"border-bottom-colo=
r: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bo=
rder-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: 0px; border-right=
-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px;=
 border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-widt=
h: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top=
: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-=
top: 0px;">{}=C2=A0</font><br></div></div><div><font face=3D"courier new,mo=
nospace"></font><br></div><div>Again, any gains are dwarfed by introducing =
new syntax to learn and/or new ways to read old constructs!=C2=A0</div><div=
>And the biggest problem is - that syntax right now donates <b><i>an action=
</i> </b>and here it will not, it will be just an indicator!=C2=A0</div><di=
v><i></i><i></i><br></div><div><br></div><div><span style=3D"display: inlin=
e !important; float: none; background-color: transparent; color: rgb(34, 34=
, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; fon=
t-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; l=
etter-spacing: normal; orphans: 2; text-align: left; text-decoration: none;=
 text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; wh=
ite-space: normal; word-spacing: 0px;">=C2=A0--- Let&#39;s continue further=
</span></div><div><b></b><i></i><u></u><sub></sub><sup></sup><strike></stri=
ke><br></div><div>Another non-issue is &quot;the problem one cannot differe=
ntiate b/w constrained value and a type concept&quot;=C2=A0</div><div><br><=
/div><div><font face=3D"courier new,monospace">template&lt;Concept T, Value=
 v&gt; void f() {}</font></div><div><font face=3D"courier new,monospace"></=
font><br></div><div>Why this is non-issue?=C2=A0</div><div><br></div><div><=
b>First</b> Because templates are inline, usage is visible and Types and Va=
lue are used RADICALLY differently.</div><div>In real word it will <i>alway=
s</i> be clear which is which!=C2=A0</div><div><br></div><div><b>Second</b>=
 as already mentioned in one of the papers - one can use a naming convectio=
n.</div><div><br></div><div><b>Third</b> the more verbose syntax (the a <fo=
nt face=3D"courier new,monospace">requires</font> clause) is still availabl=
e!=C2=A0</div><div><b></b><b></b><br></div><div>And BTW lets not forget we =
have class template arguments now, so the template arguments are bound to b=
e a bit overloaded now!<br></div><div><div style=3D"background-color: trans=
parent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bo=
rder-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretc=
h; border-image-slice: 100%; border-image-source: none; border-image-width:=
 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-lef=
t-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-top-st=
yle: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp=
;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: =
13px; font-style: normal; font-variant: normal; font-weight: 400; letter-sp=
acing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; mar=
gin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-r=
ight: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-=
indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-sp=
ace: normal; word-spacing: 0px;"><br style=3D"background-attachment: scroll=
; background-clip: border-box; background-color: transparent; background-im=
age: none; background-origin: padding-box; background-position-x: 0%; backg=
round-position-y: 0%; background-repeat: repeat; background-size: auto; bor=
der-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom=
-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border-i=
mage-slice: 100%; border-image-source: none; border-image-width: 1; border-=
left-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0p=
x; border-right-color: rgb(34, 34, 34); border-right-style: none; border-ri=
ght-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; =
border-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial=
&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; heigh=
t: auto; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-to=
p: 0px; min-width: 0px; overflow: visible; overflow-x: visible; overflow-y:=
 visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; paddi=
ng-top: 0px;"></div><div style=3D"background-color: transparent; border-bot=
tom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width:=
 0px; border-image-outset: 0; border-image-repeat: stretch; border-image-sl=
ice: 100%; border-image-source: none; border-image-width: 1; border-left-co=
lor: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; bord=
er-right-color: rgb(34, 34, 34); border-right-style: none; border-right-wid=
th: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-=
top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;qu=
ot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: =
normal; font-variant: normal; font-weight: 400; letter-spacing: normal; mar=
gin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orph=
ans: 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; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;"><font face=3D"courier new,monospace" style=3D"border-bottom-=
color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-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: 0px; border-r=
ight-color: rgb(34, 34, 34); border-right-style: none; border-right-width: =
0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-=
width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin=
-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padd=
ing-top: 0px;">template&lt;Concept T, Value v, Class c&gt; void f() {}</fon=
t></div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></d=
iv><div>Nothing wrong with that - we can use naming conventions and we have=
 good IDEs to help us - no need for syntax noise. =C2=A0</div><div><br></di=
v><div><br></div><div><b>The Solution To All This</b></div><div><b><br></b>=
</div><div><b><br></b></div><div>For now, include <i>only</i> the syntax cl=
ear to a time traveler! Do not include ANYTHING new to learn!=C2=A0</div><d=
iv><br></div><div>We are JUST introducing Concepts to the general public - =
<i>that alone is enough new=C2=A0 material!</i><br></div><div><i></i><i></i=
><br></div><div>For Simple cases</div><div><br></div><div><span style=3D"di=
splay: inline !important; float: none; background-color: transparent; color=
: rgb(34, 34, 34); font-family: courier new,monospace; font-size: 13px; fon=
t-style: normal; font-variant: normal; font-weight: 400; letter-spacing: no=
rmal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;">template&lt;Sortable S&gt;=C2=A0</span></div><div><sp=
an style=3D"display: inline !important; float: none; background-color: tran=
sparent; color: rgb(34, 34, 34); font-family: courier new,monospace; font-s=
ize: 13px; font-style: normal; font-variant: normal; font-weight: 400; lett=
er-spacing: normal; orphans: 2; text-align: left; text-decoration: none; te=
xt-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white=
-space: normal; word-spacing: 0px;">void sort(S&amp; s);=C2=A0</span></div>=
<div><span style=3D"display: inline !important; float: none; background-col=
or: transparent; color: rgb(34, 34, 34); font-family: courier new,monospace=
; font-size: 13px; font-style: normal; font-variant: normal; font-weight: 4=
00; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: =
none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0p=
x; white-space: normal; word-spacing: 0px;"><br></span></div><div><span sty=
le=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none; text-=
indent: 0px; letter-spacing: normal; font-size: 13px; font-style: normal; f=
ont-variant: normal; font-weight: 400; text-decoration: none; word-spacing:=
 0px; display: inline !important; white-space: normal; orphans: 2; float: n=
one; -webkit-text-stroke-width: 0px; background-color: transparent;"><font =
face=3D"arial,sans-serif">For Complex cases</font></span></div><div><span s=
tyle=3D"display: inline !important; float: none; background-color: transpar=
ent; color: rgb(34, 34, 34); font-family: courier new,monospace; 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;"><font face=3D"arial,sans-serif"></font><br>=
</span></div><div><span style=3D"text-align: left; color: rgb(34, 34, 34); =
text-transform: none; text-indent: 0px; letter-spacing: normal; font-family=
: courier new,monospace; font-size: 13px; font-variant: normal; word-spacin=
g: 0px; display: inline !important; white-space: normal; orphans: 2; float:=
 none; -webkit-text-stroke-width: 0px; background-color: transparent;"><div=
 style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); border-im=
age: none; text-align: left; color: rgb(34, 34, 34); text-transform: none; =
text-indent: 0px; letter-spacing: normal; font-size: 13px; font-variant: no=
rmal; word-spacing: 0px; white-space: normal; orphans: 2; -webkit-text-stro=
ke-width: 0px; background-color: transparent;"><span style=3D"margin: 0px; =
padding: 0px; border: 0px rgb(34, 34, 34); border-image: none; text-align: =
left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; lette=
r-spacing: normal; font-family: courier new,monospace; font-size: 13px; fon=
t-variant: normal; word-spacing: 0px; display: inline; white-space: normal;=
 orphans: 2; float: none; -webkit-text-stroke-width: 0px; background-color:=
 transparent;"><div style=3D"background-color: transparent; border-bottom-c=
olor: rgb(34, 34, 34); border-bottom-style: none; border-bottom-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: 0px; border-ri=
ght-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0=
px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-w=
idth: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&=
amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: 400; letter-spacing: normal; margin-b=
ottom: 0px; margin-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-trans=
form: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spaci=
ng: 0px;"><font face=3D"courier new,monospace" style=3D"border-bottom-color=
: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bor=
der-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: 0px; border-right-=
color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; =
border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width=
: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top:=
 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-t=
op: 0px;">template&lt;Iterator Iter1, Iterator Iter2&gt;=C2=A0</font></div>=
<div style=3D"background-color: transparent; border-bottom-color: rgb(34, 3=
4, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-o=
utset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-im=
age-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-=
color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; colo=
r: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvet=
ica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant=
: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; mar=
gin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bott=
om: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-alig=
n: left; text-decoration: none; text-indent: 0px; text-transform: none; -we=
bkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><font=
 face=3D"courier new,monospace" style=3D"border-bottom-color: rgb(34, 34, 3=
4); border-bottom-style: none; border-bottom-width: 0px; border-image-outse=
t: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image-=
source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); bo=
rder-left-style: none; border-left-width: 0px; border-right-color: rgb(34, =
34, 34); border-right-style: none; border-right-width: 0px; border-top-colo=
r: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; margin-b=
ottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-b=
ottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">=C2=
=A0 =C2=A0=C2=A0 requires Comparable_though_iterators&lt;Iter1, Iter2&gt;</=
font></div><div style=3D"background-color: transparent; border-bottom-color=
: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bor=
der-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: 0px; border-right-=
color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; =
border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width=
: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;=
quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; f=
ont-variant: normal; font-weight: 400; letter-spacing: normal; margin-botto=
m: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; p=
adding-bottom: 0px; padding-left: 0px; 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;"><font face=3D"courier new,monospace" 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;">bool equal(Iter1 first, Iter1 last, Iter2)=C2=A0</font></div><div sty=
le=3D"background-color: transparent; border-bottom-color: rgb(34, 34, 34); =
border-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0=
; border-image-repeat: stretch; border-image-slice: 100%; border-image-sour=
ce: 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-color: r=
gb(34, 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(3=
4, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;=
quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal=
; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-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; -webkit-tex=
t-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><font face=3D=
"courier new,monospace" style=3D"border-bottom-color: rgb(34, 34, 34); bord=
er-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; bo=
rder-image-repeat: stretch; border-image-slice: 100%; border-image-source: =
none; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-lef=
t-style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34);=
 border-right-style: none; border-right-width: 0px; border-top-color: rgb(3=
4, 34, 34); border-top-style: none; border-top-width: 0px; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0=
px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">{}=C2=A0</fon=
t></div></span></div><b></b><i></i><u></u><sub></sub><sup></sup><strike></s=
trike><br></span></div><div>=C2=A0 =C2=A0 =C2=A0 <b>THATS IT. DONE.=C2=A0</=
b></div><div><b><br></b></div><div><b>No</b></div><div><span style=3D"displ=
ay: inline !important; float: none; background-color: transparent; color: r=
gb(34, 34, 34); font-family: courier new,monospace; font-size: 13px; font-s=
tyle: normal; font-variant: normal; font-weight: 400; letter-spacing: norma=
l; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; t=
ext-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; w=
ord-spacing: 0px;">template void sort(Sortable&amp; s);=C2=A0</span></div><=
div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><=
div><b>No</b></div><div><span style=3D"display: inline !important; float: n=
one; background-color: transparent; color: rgb(34, 34, 34); font-family: co=
urier new,monospace; font-size: 13px; font-style: normal; font-variant: nor=
mal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left=
; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-te=
xt-stroke-width: 0px; white-space: normal; word-spacing: 0px;">void sort(So=
rtable{}&amp; s);=C2=A0</span></div><div><span style=3D"display: inline !im=
portant; float: none; background-color: transparent; color: rgb(34, 34, 34)=
; font-family: courier new,monospace; 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; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0=
px;"><br></span></div><div><span style=3D"text-align: left; color: rgb(34, =
34, 34); text-transform: none; text-indent: 0px; letter-spacing: normal; fo=
nt-family: courier new,monospace; font-size: 13px; font-variant: normal; wo=
rd-spacing: 0px; display: inline !important; white-space: normal; orphans: =
2; float: none; -webkit-text-stroke-width: 0px; background-color: transpare=
nt;"><div style=3D"background-color: transparent; border-bottom-color: rgb(=
34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-im=
age-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bord=
er-image-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-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px;=
 color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;H=
elvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-va=
riant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px=
; margin-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=
; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">=
<span style=3D"background-color: transparent; border-bottom-color: rgb(34, =
34, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-=
outset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-i=
mage-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=
-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; col=
or: rgb(34, 34, 34); display: inline; float: none; font-family: &amp;quot;A=
rial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; f=
ont-style: normal; font-variant: normal; font-weight: 400; letter-spacing: =
normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top=
: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0=
px; padding-top: 0px; text-align: left; text-decoration: none; text-indent:=
 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: no=
rmal; word-spacing: 0px;"><div 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-size: 13px; font-style: =
normal; font-variant: normal; font-weight: 400; letter-spacing: normal; mar=
gin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orph=
ans: 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; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;"><span style=3D"background-color: transparent; border-bottom-=
color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-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: 0px; border-r=
ight-color: rgb(34, 34, 34); border-right-style: none; border-right-width: =
0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-=
width: 0px; color: rgb(34, 34, 34); display: inline; float: none; font-fami=
ly: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; fon=
t-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; l=
etter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: =
0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; p=
adding-right: 0px; padding-top: 0px; text-align: left; text-decoration: non=
e; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; =
white-space: normal; word-spacing: 0px;"><font face=3D"arial,sans-serif" st=
yle=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bor=
der-bottom-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: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none;=
 border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-sty=
le: none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; marg=
in-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; pad=
ding-right: 0px; padding-top: 0px;"><b style=3D"border-bottom-color: rgb(34=
, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-imag=
e-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: 0px; border-right-color: r=
gb(34, 34, 34); border-right-style: none; border-right-width: 0px; border-t=
op-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; m=
argin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; pa=
dding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;=
">No</b></font><font face=3D"courier new,monospace" style=3D"border-bottom-=
color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-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: 0px; border-r=
ight-color: rgb(34, 34, 34); border-right-style: none; border-right-width: =
0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-=
width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin=
-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padd=
ing-top: 0px;">=C2=A0</font></span><br style=3D"border-bottom-color: rgb(34=
, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-imag=
e-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: 0px; border-right-color: r=
gb(34, 34, 34); border-right-style: none; border-right-width: 0px; border-t=
op-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; m=
argin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; pa=
dding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;=
"></div></span></div><div style=3D"background-color: transparent; border-bo=
ttom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width=
: 0px; border-image-outset: 0; border-image-repeat: stretch; border-image-s=
lice: 100%; border-image-source: none; border-image-width: 1; border-left-c=
olor: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; bor=
der-right-color: rgb(34, 34, 34); border-right-style: none; border-right-wi=
dth: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border=
-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;q=
uot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style:=
 normal; font-variant: normal; font-weight: 400; letter-spacing: normal; ma=
rgin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orp=
hans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; paddin=
g-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;"><span style=3D"background-color: transparent; border-bottom=
-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0p=
x; 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: 0px; border-=
right-color: rgb(34, 34, 34); border-right-style: none; border-right-width:=
 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top=
-width: 0px; color: rgb(34, 34, 34); display: inline; float: none; font-fam=
ily: courier new,monospace; font-size: 13px; font-style: normal; font-varia=
nt: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; m=
argin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bo=
ttom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-al=
ign: left; text-decoration: none; text-indent: 0px; text-transform: none; -=
webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><b =
style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; b=
order-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stret=
ch; border-image-slice: 100%; border-image-source: none; border-image-width=
: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-le=
ft-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: non=
e; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-s=
tyle: none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; ma=
rgin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; p=
adding-right: 0px; padding-top: 0px;"></b><i style=3D"border-bottom-color: =
rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; borde=
r-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: 0px; border-right-co=
lor: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bo=
rder-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: =
0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0=
px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top=
: 0px;"></i><u style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom=
-style: none; border-bottom-width: 0px; border-image-outset: 0; border-imag=
e-repeat: stretch; border-image-slice: 100%; border-image-source: none; bor=
der-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-r=
ight-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34=
); border-top-style: none; border-top-width: 0px; margin-bottom: 0px; margi=
n-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; paddi=
ng-left: 0px; padding-right: 0px; padding-top: 0px;"></u><sub style=3D"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; margin-bottom: 0px; margin-left: 0px; margin-right: 0=
px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right:=
 0px; padding-top: 0px;"></sub><sup style=3D"border-bottom-color: rgb(34, 3=
4, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-o=
utset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-im=
age-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-=
color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; marg=
in-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; paddi=
ng-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"><=
/sup><strike style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-s=
tyle: none; border-bottom-width: 0px; border-image-outset: 0; border-image-=
repeat: stretch; border-image-slice: 100%; border-image-source: none; borde=
r-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: no=
ne; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-rig=
ht-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34);=
 border-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-=
left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding=
-left: 0px; padding-right: 0px; padding-top: 0px;"></strike>template&lt;Ari=
thmetic{N}, Arithmetic {} n&gt; void f(N);</span><br></div></span></div><di=
v><span style=3D"text-align: left; color: rgb(34, 34, 34); text-transform: =
none; text-indent: 0px; letter-spacing: normal; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; text-decoration: none; wo=
rd-spacing: 0px; display: inline !important; white-space: normal; orphans: =
2; float: none; -webkit-text-stroke-width: 0px; background-color: transpare=
nt;"><font face=3D"courier new,monospace"></font><b></b><i></i><u></u><sub>=
</sub><sup></sup><strike></strike><br></span></div><div><span style=3D"text=
-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0p=
x; letter-spacing: normal; font-size: 13px; font-variant: normal; word-spac=
ing: 0px; display: inline !important; white-space: normal; orphans: 2; floa=
t: none; -webkit-text-stroke-width: 0px; background-color: transparent;"><d=
iv style=3D"background-color: transparent; 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: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetic=
a&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: =
normal; font-weight: 400; 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;"><b styl=
e=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%; background-repeat: =
repeat; background-size: auto; border-bottom-color: rgb(34, 34, 34); border=
-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; bord=
er-image-repeat: stretch; border-image-slice: 100%; border-image-source: no=
ne; 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); b=
order-right-style: none; border-right-width: 0px; border-top-color: rgb(34,=
 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34,=
 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,=
sans-serif; font-size: 13px; height: auto; margin-bottom: 0px; margin-left:=
 0px; margin-right: 0px; margin-top: 0px; min-width: 0px; overflow: visible=
; overflow-x: visible; overflow-y: visible; padding-bottom: 0px; padding-le=
ft: 0px; padding-right: 0px; padding-top: 0px;"><font face=3D"arial,sans-se=
rif">No</font></b></div><div style=3D"background-color: transparent; border=
-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-wi=
dth: 0px; border-image-outset: 0; border-image-repeat: stretch; border-imag=
e-slice: 100%; border-image-source: none; border-image-width: 1; border-lef=
t-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-color: rgb(34, 34, 34); border-top-style: none; bor=
der-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&am=
p;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-sty=
le: normal; font-variant: normal; font-weight: 400; letter-spacing: normal;=
 margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; =
orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; pad=
ding-top: 0px; text-align: left; text-decoration: none; text-indent: 0px; t=
ext-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; w=
ord-spacing: 0px;"><span style=3D"margin: 0px; padding: 0px; border: 0px rg=
b(34, 34, 34); border-image: none; text-align: left; color: rgb(34, 34, 34)=
; text-transform: none; text-indent: 0px; letter-spacing: normal; font-size=
: 13px; font-style: normal; font-variant: normal; font-weight: 400; text-de=
coration: none; word-spacing: 0px; display: inline; white-space: normal; or=
phans: 2; float: none; -webkit-text-stroke-width: 0px; background-color: tr=
ansparent;"><font face=3D"courier new,monospace">template&lt;auto Arithmeti=
c N&gt; void f();</font></span></div></span><div style=3D"background-color:=
 transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: no=
ne; border-bottom-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; bord=
er-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-=
top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family=
: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-=
size: 13px; font-style: normal; font-variant: normal; font-weight: 400; let=
ter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0p=
x; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; pad=
ding-right: 0px; padding-top: 0px; text-align: left; text-decoration: none;=
 text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; wh=
ite-space: normal; word-spacing: 0px;"><span style=3D"display: inline !impo=
rtant; float: none; background-color: transparent; color: rgb(34, 34, 34); =
font-family: courier new,monospace; font-size: 13px; font-style: normal; fo=
nt-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; t=
ext-align: left; text-decoration: none; text-indent: 0px; text-transform: n=
one; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px=
;"><br></span></div></div><div><span style=3D"text-align: left; color: rgb(=
34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing: normal=
; font-size: 13px; font-style: normal; font-variant: normal; text-decoratio=
n: none; word-spacing: 0px; display: inline !important; white-space: normal=
; orphans: 2; float: none; -webkit-text-stroke-width: 0px; background-color=
: transparent;"><b><font face=3D"arial,sans-serif">No</font></b></span></di=
v><div><div style=3D"background-color: transparent; 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; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot=
;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-=
variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddi=
ng-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; te=
xt-align: left; text-decoration: none; text-indent: 0px; text-transform: no=
ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;=
"><font face=3D"courier new,monospace" style=3D"border-bottom-color: rgb(34=
, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-imag=
e-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: 0px; border-right-color: r=
gb(34, 34, 34); border-right-style: none; border-right-width: 0px; border-t=
op-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; m=
argin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; pa=
dding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;=
">template&lt;Comparable_through_iterators{Iter1,Iter2}&gt;</font></div><di=
v style=3D"background-color: transparent; border-bottom-color: rgb(34, 34, =
34); border-bottom-style: none; border-bottom-width: 0px; border-image-outs=
et: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image=
-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); b=
order-left-style: none; border-left-width: 0px; border-right-color: rgb(34,=
 34, 34); border-right-style: none; border-right-width: 0px; border-top-col=
or: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color: =
rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica=
&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: n=
ormal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin=
-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; -webki=
t-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><font fa=
ce=3D"courier new,monospace" style=3D"border-bottom-color: rgb(34, 34, 34);=
 border-bottom-style: none; border-bottom-width: 0px; border-image-outset: =
0; border-image-repeat: stretch; border-image-slice: 100%; border-image-sou=
rce: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); borde=
r-left-style: none; border-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-top-style: none; border-top-width: 0px; margin-bott=
om: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bott=
om: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">bool equ=
al(Iter1 first, Iter1 last, Iter2)=C2=A0</font></div><div style=3D"backgrou=
nd-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-=
style: none; border-bottom-width: 0px; border-image-outset: 0; border-image=
-repeat: stretch; border-image-slice: 100%; border-image-source: none; bord=
er-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: n=
one; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-ri=
ght-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34)=
; border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); fo=
nt-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-ser=
if; font-size: 13px; font-style: normal; font-variant: normal; font-weight:=
 400; letter-spacing: normal; margin-bottom: 0px; margin-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-decorati=
on: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width=
: 0px; white-space: normal; word-spacing: 0px;"><font face=3D"courier new,m=
onospace" style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-styl=
e: none; border-bottom-width: 0px; border-image-outset: 0; border-image-rep=
eat: stretch; border-image-slice: 100%; border-image-source: none; border-i=
mage-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-color: rgb(34, 34, 34); bo=
rder-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-lef=
t: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-le=
ft: 0px; padding-right: 0px; padding-top: 0px;">{}=C2=A0</font></div><b></b=
><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><div><b>And=
 HELL No</b></div><div><div style=3D"background-color: transparent; border-=
bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-wid=
th: 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: 0px; b=
order-right-color: rgb(34, 34, 34); border-right-style: none; border-right-=
width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; bord=
er-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp=
;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-styl=
e: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; =
margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; o=
rphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padd=
ing-top: 0px; text-align: left; text-decoration: none; text-indent: 0px; te=
xt-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; wo=
rd-spacing: 0px;"><font face=3D"courier new,monospace" style=3D"border-bott=
om-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: =
0px; border-image-outset: 0; border-image-repeat: stretch; border-image-sli=
ce: 100%; border-image-source: none; border-image-width: 1; border-left-col=
or: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; borde=
r-right-color: rgb(34, 34, 34); border-right-style: none; border-right-widt=
h: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-t=
op-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; mar=
gin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; p=
adding-top: 0px;">Comparable_through_iterators{Iter1,Iter2}=C2=A0</font></d=
iv><div style=3D"background-color: transparent; border-bottom-color: rgb(34=
, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-imag=
e-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: 0px; border-right-color: r=
gb(34, 34, 34); border-right-style: none; border-right-width: 0px; border-t=
op-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; c=
olor: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Hel=
vetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-vari=
ant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; =
margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-b=
ottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-a=
lign: left; text-decoration: none; text-indent: 0px; text-transform: none; =
-webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><f=
ont face=3D"courier new,monospace" style=3D"border-bottom-color: rgb(34, 34=
, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-ou=
tset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-ima=
ge-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(3=
4, 34, 34); border-right-style: none; border-right-width: 0px; border-top-c=
olor: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; margi=
n-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; paddin=
g-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">bo=
ol equal(Iter1 first, Iter1 last, Iter2)=C2=A0</font></div><div style=3D"ba=
ckground-color: transparent; border-bottom-color: rgb(34, 34, 34); border-b=
ottom-style: none; border-bottom-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-st=
yle: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); bor=
der-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 3=
4, 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 3=
4); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sa=
ns-serif; font-size: 13px; font-style: normal; font-variant: normal; font-w=
eight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; m=
argin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding=
-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-de=
coration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke=
-width: 0px; white-space: normal; word-spacing: 0px;"><font face=3D"courier=
 new,monospace" style=3D"border-bottom-color: rgb(34, 34, 34); border-botto=
m-style: none; border-bottom-width: 0px; border-image-outset: 0; border-ima=
ge-repeat: stretch; border-image-slice: 100%; border-image-source: none; bo=
rder-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-color: rgb(34, 34, 3=
4); border-top-style: none; border-top-width: 0px; margin-bottom: 0px; marg=
in-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padd=
ing-left: 0px; padding-right: 0px; padding-top: 0px;">{}=C2=A0</font><br></=
div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><=
div><b>Why?</b></div><div><b></b><i></i><br></div><div><i>A. Because of the=
 time traveler!!!</i></div><div><i><br></i></div><div><i>B. Let the users h=
ave theirs say IN THE REAL WORD.</i></div><div><i><br></i></div><div><i>C. =
We can ALWAYS add &quot;simpler&quot; syntax later, say in 5 years!</i></di=
v><div><i><br></i></div><div><i><br></i></div><div><b>Future Directions</b>=
</div><div><b><br></b></div><div>Why not let arguments be comma separated l=
ists if we care so much about typing</div><div><span style=3D"margin: 0px; =
padding: 0px; border: 0px rgb(34, 34, 34); border-image: none; text-align: =
left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; lette=
r-spacing: normal; font-size: 13px; font-style: normal; font-variant: norma=
l; font-weight: 400; text-decoration: none; word-spacing: 0px; display: inl=
ine; white-space: normal; orphans: 2; float: none; -webkit-text-stroke-widt=
h: 0px; background-color: transparent;"><br style=3D"border-bottom-color: r=
gb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border=
-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; b=
order-image-source: none; border-image-width: 1; border-left-color: rgb(34,=
 34, 34); border-left-style: none; border-left-width: 0px; border-right-col=
or: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bor=
der-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0=
px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top:=
 0px;"></span></div><div><div style=3D"background-color: transparent; borde=
r-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-w=
idth: 0px; border-image-outset: 0; border-image-repeat: stretch; border-ima=
ge-slice: 100%; border-image-source: none; border-image-width: 1; border-le=
ft-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-righ=
t-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; bo=
rder-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&a=
mp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-st=
yle: normal; font-variant: normal; font-weight: 400; letter-spacing: normal=
; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;=
 orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; pa=
dding-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;"><span style=3D"margin: 0px; padding: 0px; border: 0px r=
gb(34, 34, 34); border-image: none; text-align: left; color: rgb(34, 34, 34=
); text-transform: none; text-indent: 0px; letter-spacing: normal; font-siz=
e: 13px; font-style: normal; font-variant: normal; font-weight: 400; text-d=
ecoration: none; word-spacing: 0px; display: inline; white-space: normal; o=
rphans: 2; float: none; -webkit-text-stroke-width: 0px; background-color: t=
ransparent;"><div style=3D"background-color: transparent; border-bottom-col=
or: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; b=
order-image-outset: 0; border-image-repeat: stretch; border-image-slice: 10=
0%; border-image-source: none; border-image-width: 1; border-left-color: rg=
b(34, 34, 34); border-left-style: none; border-left-width: 0px; border-righ=
t-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px=
; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-wid=
th: 0px; color: rgb(34, 34, 34); font-size: 13px; font-style: normal; font-=
variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddi=
ng-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; te=
xt-align: left; text-decoration: none; text-indent: 0px; text-transform: no=
ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;=
"><span style=3D"margin: 0px; padding: 0px; border: 0px rgb(34, 34, 34); bo=
rder-image: none; text-align: left; color: rgb(34, 34, 34); text-transform:=
 none; text-indent: 0px; letter-spacing: normal; font-size: 13px; font-styl=
e: normal; font-variant: normal; font-weight: 400; text-decoration: none; w=
ord-spacing: 0px; display: inline; white-space: normal; orphans: 2; float: =
none; -webkit-text-stroke-width: 0px; background-color: transparent;"><div =
style=3D"background-color: transparent; border-bottom-color: rgb(34, 34, 34=
); border-bottom-style: none; border-bottom-width: 0px; border-image-outset=
: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image-s=
ource: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); bor=
der-left-style: none; border-left-width: 0px; border-right-color: rgb(34, 3=
4, 34); border-right-style: none; border-right-width: 0px; border-top-color=
: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color: rg=
b(34, 34, 34); font-size: 13px; font-style: normal; font-variant: normal; f=
ont-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0=
px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; pa=
dding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; te=
xt-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-s=
troke-width: 0px; white-space: normal; word-spacing: 0px;"><font face=3D"co=
urier new,monospace" style=3D"border-bottom-color: rgb(34, 34, 34); border-=
bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; borde=
r-image-repeat: stretch; border-image-slice: 100%; border-image-source: non=
e; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-s=
tyle: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); bo=
rder-right-style: none; border-right-width: 0px; border-top-color: rgb(34, =
34, 34); border-top-style: none; border-top-width: 0px; margin-bottom: 0px;=
 margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px;=
 padding-left: 0px; padding-right: 0px; padding-top: 0px;">template&lt;clas=
s In1, In2, Out&gt;=C2=A0</font></div><div style=3D"background-color: trans=
parent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bo=
rder-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretc=
h; border-image-slice: 100%; border-image-source: none; border-image-width:=
 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-lef=
t-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-top-st=
yle: none; border-top-width: 0px; color: rgb(34, 34, 34); font-size: 13px; =
font-style: normal; font-variant: normal; font-weight: 400; letter-spacing:=
 normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-to=
p: 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; -webkit-text-stroke-width: 0px; white-space: n=
ormal; word-spacing: 0px;"><font face=3D"courier new,monospace" style=3D"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; margin-bottom: 0px; margin-left: 0px; margin-right:=
 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-righ=
t: 0px; padding-top: 0px;">=C2=A0=C2=A0 requires Mergeable&lt;In1, In2, Out=
&gt; =C2=A0</font></div><div style=3D"background-color: transparent; border=
-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-wi=
dth: 0px; border-image-outset: 0; border-image-repeat: stretch; border-imag=
e-slice: 100%; border-image-source: none; border-image-width: 1; border-lef=
t-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-color: rgb(34, 34, 34); border-top-style: none; bor=
der-top-width: 0px; color: rgb(34, 34, 34); font-size: 13px; font-style: no=
rmal; font-variant: normal; font-weight: 400; letter-spacing: normal; margi=
n-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphan=
s: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-t=
op: 0px; 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;"><font face=3D"courier new,monospace" style=3D"border-bottom-co=
lor: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; =
border-image-outset: 0; border-image-repeat: stretch; border-image-slice: 1=
00%; border-image-source: none; border-image-width: 1; border-left-color: r=
gb(34, 34, 34); border-left-style: none; border-left-width: 0px; border-rig=
ht-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0p=
x; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-wi=
dth: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-t=
op: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; paddin=
g-top: 0px;">Out merge(In1,In1,In2,In2,Out);</font></div></span></div></spa=
n></div><font face=3D"courier new,monospace"></font><br></div><div>Why not =
instead of the new syntax for names introducing we simply</div><div><br></d=
iv><div><div style=3D"background-color: transparent; border-bottom-color: r=
gb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border=
-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; b=
order-image-source: none; border-image-width: 1; border-left-color: rgb(34,=
 34, 34); border-left-style: none; border-left-width: 0px; border-right-col=
or: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bor=
der-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0=
px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quo=
t;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font=
-variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: =
0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padd=
ing-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; t=
ext-align: left; text-decoration: none; text-indent: 0px; text-transform: n=
one; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px=
;"><font face=3D"courier new,monospace" style=3D"border-bottom-color: rgb(3=
4, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-ima=
ge-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; borde=
r-image-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-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; =
margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; p=
adding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px=
;">requires Mergeable&lt;In1, In2, Out&gt; =C2=A0</font></div><div style=3D=
"background-color: transparent; border-bottom-color: rgb(34, 34, 34); borde=
r-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; bor=
der-image-repeat: stretch; border-image-slice: 100%; border-image-source: n=
one; 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-color: rgb(34=
, 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34=
, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;=
,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; fon=
t-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px=
; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padd=
ing-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text=
-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-str=
oke-width: 0px; white-space: normal; word-spacing: 0px;"><font face=3D"cour=
ier new,monospace" style=3D"border-bottom-color: rgb(34, 34, 34); border-bo=
ttom-style: none; border-bottom-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-sty=
le: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); bord=
er-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 34=
, 34); border-top-style: none; border-top-width: 0px; margin-bottom: 0px; m=
argin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; p=
adding-left: 0px; padding-right: 0px; padding-top: 0px;">Out merge(In1,In1,=
In2,In2,Out);</font></div><div 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: &amp;quot;Arial&=
amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-s=
tyle: normal; font-variant: normal; font-weight: 400; letter-spacing: norma=
l; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px=
; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; p=
adding-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;"><font face=3D"courier new,monospace" style=3D"border-b=
ottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-widt=
h: 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: 0px; bo=
rder-right-color: rgb(34, 34, 34); border-right-style: none; border-right-w=
idth: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; borde=
r-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; =
margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px=
; padding-top: 0px;"><br></font></div><div style=3D"background-color: trans=
parent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bo=
rder-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretc=
h; border-image-slice: 100%; border-image-source: none; border-image-width:=
 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-lef=
t-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-top-st=
yle: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp=
;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: =
13px; font-style: normal; font-variant: normal; font-weight: 400; letter-sp=
acing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; mar=
gin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-r=
ight: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-=
indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-sp=
ace: normal; word-spacing: 0px;"><br></div></div><div><br></div><div><b></b=
><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><div><font =
face=3D"times new roman,serif"></font></div><div><font face=3D"times new ro=
man,serif"><i><br></i></font></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/19c57a60-e883-4474-b106-7ff2ebc122ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/19c57a60-e883-4474-b106-7ff2ebc122ee=
%40isocpp.org</a>.<br />

------=_Part_23264_643230127.1529400834812--

------=_Part_23263_1786757396.1529400834810--

.

------=_Part_23286_63031709.1529402091186
Content-Type: multipart/alternative;
 boundary="----=_Part_23287_2008754139.1529402091187"

------=_Part_23287_2008754139.1529402091187
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I mostly agree with you. I don't think a "terse" syntax is needed.

However, let's not forget something: if you cannot read/write C++ without=
=20
an IDE, then C++ has got too complex for any human being. So I strongly=20
disagree with your "ctrl-click" argument.
There are many cases where we need to read code and cannot ask an IDE=20
(because it's a single file extracted from the project like in an email for=
=20
instance).

Le mardi 19 juin 2018 11:33:54 UTC+2, mihailn...@gmail.com a =C3=A9crit :
>
> OK, right now in flight are about FOUR proposals, trying to "simplify" an=
d=20
> "make more clear" concepts usage.
>
> This is madness. It is madness, because NONE of it make it more clear!=20
> None.=20
>
> By inviting new language constructs one does not make things "more clear"=
,=20
> it only adds more things to learn.
>
> The worst part is - *we have working solution that is clear. Granted=20
> verbose, but clear. *
>
> If one makes it Not verbose but Not clear (not self-explanatory, need=20
> learning) also one gains nothing!=20
>
>
> Consider
>
> template<Iterator Iter1, Iterator Iter2>=20
>      requires Comparable_though_iterators<Iter1, Iter2>
> bool equal(Iter1 first, Iter1 last, Iter2)=20
> {}=20
>
> This code is *clear to ANYONE who EVER worked with C++*, even to a time=
=20
> traveler from 30 years ago!
>
> Comparable_through_iterators{Iter1,Iter2}=20
> bool equal(Iter1 first, Iter1 last, Iter2)=20
> {}=20
>
> This is *NOT clear*!=20
>
> *First* Comparable_ can be confused with a return type when one starts to=
=20
> read.=20
> *Second* The syntax is COMPLETELY alien to templates - de facto new=20
> language.=20
> *Third *there is no obvious connection b/w the function and the clause  -=
=20
> it just sits there like a separate declaration
> *Forth *Automatic names introductions is very uncommon and will be=20
> confusing for sure.
>
> The gain of one-less-line is DWARFED by the HEAP of "new stuff" that does=
=20
> NOT grant "new powers"!
>
>
>  --- Let's continue
>
>
> Between=20
>
> void sort(Sortable& s); =20
>
> and
>
> template void sort(Sortable& s);=20
>
> *The second is more confusing! *Why? Because it abuses an already=20
> established syntax for something *completely* different.=20
>
> Is the first confusing? Might be. What is the solution?
>
> Solution 1:
>
> If this is your code, and you might be confused - don't use it, use the=
=20
> more verbose, but more clear syntax!
>
> Solution 2:
>
> Just ctrl-click on Sortable (hell, just hover over it) and all you doubts=
=20
> will be solved!=20
>
>
> Inventing completely new syntax in the form of  Sortable{} is even worse:
>
> Consider=20
>
> Number x{};
> [](Number{} x)=20
> {}=20
> [x =3D Number{}]()
> {}=20
>
> Again, any gains are dwarfed by introducing new syntax to learn and/or ne=
w=20
> ways to read old constructs!=20
> And the biggest problem is - that syntax right now donates *an action *an=
d=20
> here it will not, it will be just an indicator!=20
>
>
>  --- Let's continue further
>
> Another non-issue is "the problem one cannot differentiate b/w constraine=
d=20
> value and a type concept"=20
>
> template<Concept T, Value v> void f() {}
>
> Why this is non-issue?=20
>
> *First* Because templates are inline, usage is visible and Types and=20
> Value are used RADICALLY differently.
> In real word it will *always* be clear which is which!=20
>
> *Second* as already mentioned in one of the papers - one can use a naming=
=20
> convection.
>
> *Third* the more verbose syntax (the a requires clause) is still=20
> available!=20
>
> And BTW lets not forget we have class template arguments now, so the=20
> template arguments are bound to be a bit overloaded now!
>
> template<Concept T, Value v, Class c> void f() {}
>
> Nothing wrong with that - we can use naming conventions and we have good=
=20
> IDEs to help us - no need for syntax noise. =20
>
>
> *The Solution To All This*
>
>
> For now, include *only* the syntax clear to a time traveler! Do not=20
> include ANYTHING new to learn!=20
>
> We are JUST introducing Concepts to the general public - *that alone is=
=20
> enough new  material!*
>
> For Simple cases
>
> template<Sortable S>=20
> void sort(S& s);=20
>
> For Complex cases
>
> template<Iterator Iter1, Iterator Iter2>=20
>      requires Comparable_though_iterators<Iter1, Iter2>
> bool equal(Iter1 first, Iter1 last, Iter2)=20
> {}=20
>
>       *THATS IT. DONE. *
>
> *No*
> template void sort(Sortable& s);=20
>
> *No*
> void sort(Sortable{}& s);=20
>
> *No*=20
> template<Arithmetic{N}, Arithmetic {} n> void f(N);
>
> *No*
> template<auto Arithmetic N> void f();
>
> *No*
> template<Comparable_through_iterators{Iter1,Iter2}>
> bool equal(Iter1 first, Iter1 last, Iter2)=20
> {}=20
>
> *And HELL No*
> Comparable_through_iterators{Iter1,Iter2}=20
> bool equal(Iter1 first, Iter1 last, Iter2)=20
> {}=20
>
> *Why?*
>
> *A. Because of the time traveler!!!*
>
> *B. Let the users have theirs say IN THE REAL WORD.*
>
> *C. We can ALWAYS add "simpler" syntax later, say in 5 years!*
>
>
> *Future Directions*
>
> Why not let arguments be comma separated lists if we care so much about=
=20
> typing
>
> template<class In1, In2, Out>=20
>    requires Mergeable<In1, In2, Out> =20
> Out merge(In1,In1,In2,In2,Out);
>
> Why not instead of the new syntax for names introducing we simply
>
> requires Mergeable<In1, In2, Out> =20
> Out merge(In1,In1,In2,In2,Out);
>
>
>
>
>
>

--=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/eb8259f3-a2ca-4c4a-99d8-3a5d635458cf%40isocpp.or=
g.

------=_Part_23287_2008754139.1529402091187
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I mostly agree with you. I don&#39;t think a &quot;terse&q=
uot; syntax is needed.<br><br>However, let&#39;s not forget something: if y=
ou cannot read/write C++ without an IDE, then C++ has got too complex for a=
ny human being. So I strongly disagree with your &quot;ctrl-click&quot; arg=
ument.<br>There are many cases where we need to read code and cannot ask an=
 IDE (because it&#39;s a single file extracted from the project like in an =
email for instance).<br><br>Le mardi 19 juin 2018 11:33:54 UTC+2, mihailn..=
..@gmail.com a =C3=A9crit=C2=A0:<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>OK, right now in flight are about FOUR proposals, tr=
ying to &quot;simplify&quot; and &quot;make more clear&quot; concepts usage=
..</div><div><br></div><div>This is madness. It is madness, because NONE of =
it make it more clear! None.=C2=A0</div><div><br></div><div>By inviting new=
 language constructs one does not make things &quot;more clear&quot;, it on=
ly adds more things to learn.</div><div><br></div><div>The worst part is - =
<i>we have working solution that is clear. Granted verbose, but clear.=C2=
=A0</i></div><div><i></i><br></div><div>If one makes it Not verbose but Not=
 clear (not self-explanatory, need learning) also one gains nothing!=C2=A0<=
/div><div><br></div><div><br></div><div>Consider</div><div><br></div><div><=
font face=3D"courier new,monospace">template&lt;Iterator Iter1, Iterator It=
er2&gt;=C2=A0</font></div><div><font face=3D"courier new,monospace">=C2=A0 =
=C2=A0=C2=A0 requires Comparable_though_iterators&lt;<wbr>Iter1, Iter2&gt;<=
/font></div><div><font face=3D"courier new,monospace">bool equal(Iter1 firs=
t, Iter1 last, Iter2)=C2=A0</font></div><div><font face=3D"courier new,mono=
space">{}=C2=A0</font></div><div><br></div><div>This code is <b>clear to AN=
YONE who EVER worked with C++</b>, even to a time traveler from 30 years ag=
o!</div><div><br></div><div><font face=3D"courier new,monospace">Comparable=
_through_iterators{<wbr>Iter1,Iter2}=C2=A0</font></div><div><font face=3D"c=
ourier new,monospace">bool equal(Iter1 first, Iter1 last, Iter2)=C2=A0</fon=
t></div><div><font face=3D"courier new,monospace">{}=C2=A0</font></div><div=
><br></div><div>This is <b>NOT clear</b>!=C2=A0</div><div><br></div><div><b=
>First</b> <span style=3D"display:inline!important;float:none;background-co=
lor:transparent;color:rgb(34,34,34);font-family:courier new,monospace;font-=
size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spac=
ing:normal;text-align:left;text-decoration:none;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px">Comparable<font face=3D"&quot=
;Arial&quot;,&quot;Helvetica&quot;,sans-serif">_</font></span> can be confu=
sed with a return type when one starts to read.=C2=A0</div><div><b>Second</=
b> The syntax is COMPLETELY alien to templates - de facto new language.=C2=
=A0</div><div><b>Third </b>there is no obvious connection b/w the function =
and the clause=C2=A0 - it just sits there like a separate declaration</div>=
<div><b>Forth </b>Automatic names introductions is very uncommon and will b=
e confusing for sure.</div><div><br></div><div>The gain of one-less-line is=
 DWARFED by the HEAP of &quot;new stuff&quot; that does NOT grant &quot;new=
 powers&quot;!</div><div><br></div><div><br></div><div>=C2=A0--- Let&#39;s =
continue</div><div><br></div><div><br></div><div>Between=C2=A0</div><div><b=
r></div><div><font face=3D"courier new,monospace">void sort(Sortable&amp; s=
); =C2=A0</font><font face=3D"courier new,monospace"><br></font></div><div>=
<font face=3D"courier new,monospace"><br></font></div><div><font face=3D"co=
urier new,monospace">and</font></div><div><font face=3D"courier new,monospa=
ce"><br></font></div><div><font face=3D"courier new,monospace">template voi=
d sort(Sortable&amp; s);=C2=A0</font></div><div><font face=3D"courier new,m=
onospace"><br></font></div><div><i>The second is more confusing! </i>Why? B=
ecause it abuses an already established syntax for something <i>completely<=
/i> different.=C2=A0</div><div><br></div><div>Is the first confusing? Might=
 be. What is the solution?</div><div><br></div><div>Solution 1:</div><div><=
br></div><div>If this is your code, and you might be confused - don&#39;t u=
se it, use the more verbose, but more clear syntax!</div><div><br></div><di=
v>Solution 2:</div><div><br></div><div>Just ctrl-click on Sortable (hell, j=
ust hover over it) and all you doubts will be solved!=C2=A0</div><div><br><=
/div><div><br></div><div>Inventing completely new syntax in the form of=C2=
=A0=C2=A0<span style=3D"display:inline!important;float:none;background-colo=
r:transparent;color:rgb(34,34,34);font-family:courier new,monospace;font-si=
ze:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacin=
g:normal;text-align:left;text-decoration:none;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px">Sortable{} <font face=3D"arial,=
sans-serif">is even worse:</font></span></div><div><span style=3D"display:i=
nline!important;float:none;background-color:transparent;color:rgb(34,34,34)=
;font-family:courier new,monospace;font-size:13px;font-style:normal;font-va=
riant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-dec=
oration:none;text-indent:0px;text-transform:none;white-space:normal;word-sp=
acing:0px"><font face=3D"arial,sans-serif"><br></font></span></div><div><sp=
an style=3D"display:inline!important;float:none;background-color:transparen=
t;color:rgb(34,34,34);font-family:courier new,monospace;font-size:13px;font=
-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;tex=
t-align:left;text-decoration:none;text-indent:0px;text-transform:none;white=
-space:normal;word-spacing:0px"><font face=3D"arial,sans-serif">Consider=C2=
=A0</font></span></div><div><font face=3D"times new roman,serif"><i><b></b>=
<u></u><sub></sub><sup></sup><strike></strike><b></b><u></u><sub></sub><sup=
></sup><strike></strike><font face=3D"arial,sans-serif"></font><br></i></fo=
nt></div><div><span style=3D"text-align:left;color:rgb(34,34,34);text-trans=
form:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-style:n=
ormal;font-variant:normal;font-weight:400;text-decoration:none;word-spacing=
:0px;display:inline!important;white-space:normal;float:none;background-colo=
r:transparent"><font face=3D"courier new,monospace">Number x{};</font></spa=
n><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><di=
v><font face=3D"courier new,monospace">[](Number{} x)=C2=A0</font></div><di=
v><font face=3D"courier new,monospace">{} </font></div><div><div>[<font sty=
le=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bot=
tom-width:0px;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;bo=
rder-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;b=
order-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;marg=
in-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-to=
p:0px" face=3D"courier new,monospace">x =3D Number{}]()</font></div><div><f=
ont style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;bor=
der-bottom-width:0px;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-color:rgb(34,34,34);border-top-style=
:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0=
px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;pad=
ding-top:0px" face=3D"courier new,monospace">{}=C2=A0</font><br></div></div=
><div><font face=3D"courier new,monospace"></font><br></div><div>Again, any=
 gains are dwarfed by introducing new syntax to learn and/or new ways to re=
ad old constructs!=C2=A0</div><div>And the biggest problem is - that syntax=
 right now donates <b><i>an action</i> </b>and here it will not, it will be=
 just an indicator!=C2=A0</div><div><i></i><i></i><br></div><div><br></div>=
<div><span style=3D"display:inline!important;float:none;background-color:tr=
ansparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica=
&quot;,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;white-space:normal;word-spacing:0px">=C2=A0=
--- Let&#39;s continue further</span></div><div><b></b><i></i><u></u><sub><=
/sub><sup></sup><strike></strike><br></div><div>Another non-issue is &quot;=
the problem one cannot differentiate b/w constrained value and a type conce=
pt&quot;=C2=A0</div><div><br></div><div><font face=3D"courier new,monospace=
">template&lt;Concept T, Value v&gt; void f() {}</font></div><div><font fac=
e=3D"courier new,monospace"></font><br></div><div>Why this is non-issue?=C2=
=A0</div><div><br></div><div><b>First</b> Because templates are inline, usa=
ge is visible and Types and Value are used RADICALLY differently.</div><div=
>In real word it will <i>always</i> be clear which is which!=C2=A0</div><di=
v><br></div><div><b>Second</b> as already mentioned in one of the papers - =
one can use a naming convection.</div><div><br></div><div><b>Third</b> the =
more verbose syntax (the a <font face=3D"courier new,monospace">requires</f=
ont> clause) is still available!=C2=A0</div><div><b></b><b></b><br></div><d=
iv>And BTW lets not forget we have class template arguments now, so the tem=
plate arguments are bound to be a bit overloaded now!<br></div><div><div><b=
r></div><div><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom=
-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-=
left-style:none;border-left-width:0px;border-right-color:rgb(34,34,34);bord=
er-right-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);b=
order-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px=
;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;paddin=
g-right:0px;padding-top:0px" face=3D"courier new,monospace">template&lt;Con=
cept T, Value v, Class c&gt; void f() {}</font></div><b></b><i></i><u></u><=
sub></sub><sup></sup><strike></strike><br></div><div>Nothing wrong with tha=
t - we can use naming conventions and we have good IDEs to help us - no nee=
d for syntax noise. =C2=A0</div><div><br></div><div><br></div><div><b>The S=
olution To All This</b></div><div><b><br></b></div><div><b><br></b></div><d=
iv>For now, include <i>only</i> the syntax clear to a time traveler! Do not=
 include ANYTHING new to learn!=C2=A0</div><div><br></div><div>We are JUST =
introducing Concepts to the general public - <i>that alone is enough new=C2=
=A0 material!</i><br></div><div><i></i><i></i><br></div><div>For Simple cas=
es</div><div><br></div><div><span style=3D"display:inline!important;float:n=
one;background-color:transparent;color:rgb(34,34,34);font-family:courier ne=
w,monospace;font-size:13px;font-style:normal;font-variant:normal;font-weigh=
t:400;letter-spacing:normal;text-align:left;text-decoration:none;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px">template&lt;=
Sortable S&gt;=C2=A0</span></div><div><span style=3D"display:inline!importa=
nt;float:none;background-color:transparent;color:rgb(34,34,34);font-family:=
courier new,monospace;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">vo=
id sort(S&amp; s);=C2=A0</span></div><div><span style=3D"display:inline!imp=
ortant;float:none;background-color:transparent;color:rgb(34,34,34);font-fam=
ily:courier new,monospace;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=
"><br></span></div><div><span style=3D"text-align:left;color:rgb(34,34,34);=
text-transform:none;text-indent:0px;letter-spacing:normal;font-size:13px;fo=
nt-style:normal;font-variant:normal;font-weight:400;text-decoration:none;wo=
rd-spacing:0px;display:inline!important;white-space:normal;float:none;backg=
round-color:transparent"><font face=3D"arial,sans-serif">For Complex cases<=
/font></span></div><div><span style=3D"display:inline!important;float:none;=
background-color:transparent;color:rgb(34,34,34);font-family:courier new,mo=
nospace;font-size:13px;font-style:normal;font-variant:normal;font-weight:40=
0;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0p=
x;text-transform:none;white-space:normal;word-spacing:0px"><font face=3D"ar=
ial,sans-serif"></font><br></span></div><div><span style=3D"text-align:left=
;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:nor=
mal;font-family:courier new,monospace;font-size:13px;font-variant:normal;wo=
rd-spacing:0px;display:inline!important;white-space:normal;float:none;backg=
round-color:transparent"><div style=3D"margin:0px;padding:0px;border:0px rg=
b(34,34,34);text-align:left;color:rgb(34,34,34);text-transform:none;text-in=
dent:0px;letter-spacing:normal;font-size:13px;font-variant:normal;word-spac=
ing:0px;white-space:normal;background-color:transparent"><span style=3D"mar=
gin:0px;padding:0px;border:0px rgb(34,34,34);text-align:left;color:rgb(34,3=
4,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-family=
:courier new,monospace;font-size:13px;font-variant:normal;word-spacing:0px;=
display:inline;white-space:normal;float:none;background-color:transparent">=
<div><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:n=
one;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-sty=
le:none;border-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-to=
p-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-=
right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:=
0px;padding-top:0px" face=3D"courier new,monospace">template&lt;Iterator It=
er1, Iterator Iter2&gt;=C2=A0</font></div><div><font style=3D"border-bottom=
-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;borde=
r-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;bor=
der-right-color:rgb(34,34,34);border-right-style:none;border-right-width:0p=
x;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px=
;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-=
bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=3D"cour=
ier new,monospace">=C2=A0 =C2=A0=C2=A0 requires Comparable_though_iterators=
&lt;<wbr>Iter1, Iter2&gt;</font></div><div><font style=3D"border-bottom-col=
or:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-le=
ft-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;bo=
rder-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;mar=
gin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bott=
om:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=3D"courier =
new,monospace">bool equal(Iter1 first, Iter1 last, Iter2)=C2=A0</font></div=
><div><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:=
none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-st=
yle:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-righ=
t-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-t=
op-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin=
-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right=
:0px;padding-top:0px" face=3D"courier new,monospace">{}=C2=A0</font></div><=
/span></div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br=
></span></div><div>=C2=A0 =C2=A0 =C2=A0 <b>THATS IT. DONE.=C2=A0</b></div><=
div><b><br></b></div><div><b>No</b></div><div><span style=3D"display:inline=
!important;float:none;background-color:transparent;color:rgb(34,34,34);font=
-family:courier new,monospace;font-size:13px;font-style:normal;font-variant=
:normal;font-weight:400;letter-spacing:normal;text-align:left;text-decorati=
on:none;text-indent:0px;text-transform:none;white-space:normal;word-spacing=
:0px">template void sort(Sortable&amp; s);=C2=A0</span></div><div><b></b><i=
></i><u></u><sub></sub><sup></sup><strike></strike><br></div><div><b>No</b>=
</div><div><span style=3D"display:inline!important;float:none;background-co=
lor:transparent;color:rgb(34,34,34);font-family:courier new,monospace;font-=
size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spac=
ing:normal;text-align:left;text-decoration:none;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px">void sort(Sortable{}&amp; s);=
=C2=A0</span></div><div><span style=3D"display:inline!important;float:none;=
background-color:transparent;color:rgb(34,34,34);font-family:courier new,mo=
nospace;font-size:13px;font-style:normal;font-variant:normal;font-weight:40=
0;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0p=
x;text-transform:none;white-space:normal;word-spacing:0px"><br></span></div=
><div><span style=3D"text-align:left;color:rgb(34,34,34);text-transform:non=
e;text-indent:0px;letter-spacing:normal;font-family:courier new,monospace;f=
ont-size:13px;font-variant:normal;word-spacing:0px;display:inline!important=
;white-space:normal;float:none;background-color:transparent"><div><span><di=
v style=3D"background-color:transparent;border-bottom-color:rgb(34,34,34);b=
order-bottom-style:none;border-bottom-width:0px;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-color:rgb=
(34,34,34);border-top-style:none;border-top-width:0px;color:rgb(34,34,34);f=
ont-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-=
spacing:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-to=
p:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px=
;text-align:left;text-decoration:none;text-indent:0px;text-transform:none;w=
hite-space:normal;word-spacing:0px"><span><font style=3D"border-bottom-colo=
r:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-lef=
t-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-r=
ight-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;bor=
der-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;marg=
in-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-botto=
m:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=3D"arial,san=
s-serif"><b style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:=
none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-st=
yle:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-righ=
t-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-t=
op-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin=
-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right=
:0px;padding-top:0px">No</b></font><font style=3D"border-bottom-color:rgb(3=
4,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-color=
:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-right-co=
lor:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-top=
-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bott=
om:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;p=
adding-left:0px;padding-right:0px;padding-top:0px" face=3D"courier new,mono=
space">=C2=A0</font></span><br style=3D"border-bottom-color:rgb(34,34,34);b=
order-bottom-style:none;border-bottom-width:0px;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-color:rgb=
(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;mar=
gin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-lef=
t:0px;padding-right:0px;padding-top:0px"></div></span></div><div><span styl=
e=3D"background-color:transparent;border-bottom-color:rgb(34,34,34);border-=
bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);b=
order-left-style:none;border-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-top-style:none;border-top-width:0px;color:rgb(34,34,34);display=
:inline;float:none;font-family:courier new,monospace;font-size:13px;font-st=
yle:normal;font-variant:normal;font-weight:400;letter-spacing:normal;margin=
-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:=
0px;padding-left:0px;padding-right:0px;padding-top:0px;text-align:left;text=
-decoration:none;text-indent:0px;text-transform:none;white-space:normal;wor=
d-spacing:0px"><b style=3D"border-bottom-color:rgb(34,34,34);border-bottom-=
style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-l=
eft-style:none;border-left-width:0px;border-right-color:rgb(34,34,34);borde=
r-right-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);bo=
rder-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;=
margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding=
-right:0px;padding-top:0px"></b><i style=3D"border-bottom-color:rgb(34,34,3=
4);border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(3=
4,34,34);border-left-style:none;border-left-width:0px;border-right-color:rg=
b(34,34,34);border-right-style:none;border-right-width:0px;border-top-color=
:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px=
;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding=
-left:0px;padding-right:0px;padding-top:0px"></i><u style=3D"border-bottom-=
color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border=
-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;bord=
er-right-color:rgb(34,34,34);border-right-style:none;border-right-width:0px=
;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;=
margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-b=
ottom:0px;padding-left:0px;padding-right:0px;padding-top:0px"></u><sub styl=
e=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bott=
om-width:0px;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;bor=
der-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;bo=
rder-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margi=
n-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top=
:0px"></sub><sup style=3D"border-bottom-color:rgb(34,34,34);border-bottom-s=
tyle:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-le=
ft-style:none;border-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);bor=
der-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;m=
argin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-=
right:0px;padding-top:0px"></sup><strike style=3D"border-bottom-color:rgb(3=
4,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-color=
:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-right-co=
lor:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-top=
-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bott=
om:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;p=
adding-left:0px;padding-right:0px;padding-top:0px"></strike>template&lt;Ari=
thmetic{N}, Arithmetic {} n&gt; void f(N);</span><br></div></span></div><di=
v><span style=3D"text-align:left;color:rgb(34,34,34);text-transform:none;te=
xt-indent:0px;letter-spacing:normal;font-size:13px;font-style:normal;font-v=
ariant:normal;font-weight:400;text-decoration:none;word-spacing:0px;display=
:inline!important;white-space:normal;float:none;background-color:transparen=
t"><font face=3D"courier new,monospace"></font><b></b><i></i><u></u><sub></=
sub><sup></sup><strike></strike><br></span></div><div><span style=3D"text-a=
lign:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-sp=
acing:normal;font-size:13px;font-variant:normal;word-spacing:0px;display:in=
line!important;white-space:normal;float:none;background-color:transparent">=
<div><b><font face=3D"arial,sans-serif">No</font></b></div><div><span style=
=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-align:left;color:r=
gb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font=
-size:13px;font-style:normal;font-variant:normal;font-weight:400;text-decor=
ation:none;word-spacing:0px;display:inline;white-space:normal;float:none;ba=
ckground-color:transparent"><font face=3D"courier new,monospace">template&l=
t;auto Arithmetic N&gt; void f();</font></span></div></span><div><span styl=
e=3D"display:inline!important;float:none;background-color:transparent;color=
:rgb(34,34,34);font-family:courier new,monospace;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"><br></span></div></div><div><span style=3D"text-al=
ign:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spa=
cing:normal;font-size:13px;font-style:normal;font-variant:normal;text-decor=
ation:none;word-spacing:0px;display:inline!important;white-space:normal;flo=
at:none;background-color:transparent"><b><font face=3D"arial,sans-serif">No=
</font></b></span></div><div><div><font style=3D"border-bottom-color:rgb(34=
,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-color:=
rgb(34,34,34);border-left-style:none;border-left-width:0px;border-right-col=
or:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-top-=
color:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-botto=
m:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;pa=
dding-left:0px;padding-right:0px;padding-top:0px" face=3D"courier new,monos=
pace">template&lt;Comparable_through_<wbr>iterators{Iter1,Iter2}&gt;</font>=
</div><div><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-s=
tyle:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-le=
ft-style:none;border-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);bor=
der-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;m=
argin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-=
right:0px;padding-top:0px" face=3D"courier new,monospace">bool equal(Iter1 =
first, Iter1 last, Iter2)=C2=A0</font></div><div><font style=3D"border-bott=
om-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;bor=
der-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;b=
order-right-color:rgb(34,34,34);border-right-style:none;border-right-width:=
0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0=
px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;paddin=
g-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=3D"co=
urier new,monospace">{}=C2=A0</font></div><b></b><i></i><u></u><sub></sub><=
sup></sup><strike></strike><br></div><div><b>And HELL No</b></div><div><div=
><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;=
border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:n=
one;border-left-width:0px;border-right-color:rgb(34,34,34);border-right-sty=
le:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-st=
yle:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-righ=
t:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;=
padding-top:0px" face=3D"courier new,monospace">Comparable_through_iterator=
s{<wbr>Iter1,Iter2}=C2=A0</font></div><div><font style=3D"border-bottom-col=
or:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-le=
ft-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;bo=
rder-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;mar=
gin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bott=
om:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=3D"courier =
new,monospace">bool equal(Iter1 first, Iter1 last, Iter2)=C2=A0</font></div=
><div><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:=
none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-st=
yle:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-righ=
t-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-t=
op-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin=
-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right=
:0px;padding-top:0px" face=3D"courier new,monospace">{}=C2=A0</font><br></d=
iv><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><d=
iv><b>Why?</b></div><div><b></b><i></i><br></div><div><i>A. Because of the =
time traveler!!!</i></div><div><i><br></i></div><div><i>B. Let the users ha=
ve theirs say IN THE REAL WORD.</i></div><div><i><br></i></div><div><i>C. W=
e can ALWAYS add &quot;simpler&quot; syntax later, say in 5 years!</i></div=
><div><i><br></i></div><div><i><br></i></div><div><b>Future Directions</b><=
/div><div><b><br></b></div><div>Why not let arguments be comma separated li=
sts if we care so much about typing</div><div><span style=3D"margin:0px;pad=
ding:0px;border:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);text-=
transform:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-st=
yle:normal;font-variant:normal;font-weight:400;text-decoration:none;word-sp=
acing:0px;display:inline;white-space:normal;float:none;background-color:tra=
nsparent"><br style=3D"border-bottom-color:rgb(34,34,34);border-bottom-styl=
e:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-=
style:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-ri=
ght-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);border=
-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;marg=
in-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-rig=
ht:0px;padding-top:0px"></span></div><div><div><span style=3D"margin:0px;pa=
dding:0px;border:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);text=
-transform:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-s=
tyle:normal;font-variant:normal;font-weight:400;text-decoration:none;word-s=
pacing:0px;display:inline;white-space:normal;float:none;background-color:tr=
ansparent"><div style=3D"background-color:transparent;border-bottom-color:r=
gb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-c=
olor:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-righ=
t-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;border=
-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;color:r=
gb(34,34,34);font-size:13px;font-style:normal;font-variant:normal;font-weig=
ht:400;letter-spacing:normal;margin-bottom:0px;margin-left:0px;margin-right=
:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;p=
adding-top:0px;text-align:left;text-decoration:none;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px"><span style=3D"margin:0px=
;padding:0px;border:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);t=
ext-transform:none;text-indent:0px;letter-spacing:normal;font-size:13px;fon=
t-style:normal;font-variant:normal;font-weight:400;text-decoration:none;wor=
d-spacing:0px;display:inline;white-space:normal;float:none;background-color=
:transparent"><div style=3D"background-color:transparent;border-bottom-colo=
r:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-lef=
t-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-r=
ight-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;bor=
der-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;colo=
r:rgb(34,34,34);font-size:13px;font-style:normal;font-variant:normal;font-w=
eight:400;letter-spacing:normal;margin-bottom:0px;margin-left:0px;margin-ri=
ght:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0p=
x;padding-top:0px;text-align:left;text-decoration:none;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px"><font style=3D"border-=
bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px=
;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-right-wi=
dth:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-wid=
th:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;pa=
dding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=
=3D"courier new,monospace">template&lt;class In1, In2, Out&gt;=C2=A0</font>=
</div><div style=3D"background-color:transparent;border-bottom-color:rgb(34=
,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-color:=
rgb(34,34,34);border-left-style:none;border-left-width:0px;border-right-col=
or:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-top-=
color:rgb(34,34,34);border-top-style:none;border-top-width:0px;color:rgb(34=
,34,34);font-size:13px;font-style:normal;font-variant:normal;font-weight:40=
0;letter-spacing:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;=
margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;paddin=
g-top:0px;text-align:left;text-decoration:none;text-indent:0px;text-transfo=
rm:none;white-space:normal;word-spacing:0px"><font style=3D"border-bottom-c=
olor:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-=
left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;borde=
r-right-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;=
border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;m=
argin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bo=
ttom:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=3D"courie=
r new,monospace">=C2=A0=C2=A0 requires Mergeable&lt;In1, In2, Out&gt; =C2=
=A0</font></div><div style=3D"background-color:transparent;border-bottom-co=
lor:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;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-right-width:0px;b=
order-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;co=
lor:rgb(34,34,34);font-size:13px;font-style:normal;font-variant:normal;font=
-weight:400;letter-spacing:normal;margin-bottom:0px;margin-left:0px;margin-=
right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:=
0px;padding-top:0px;text-align:left;text-decoration:none;text-indent:0px;te=
xt-transform:none;white-space:normal;word-spacing:0px"><font style=3D"borde=
r-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0=
px;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-color:rgb(34,34,34);border-top-style:none;border-top-w=
idth:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;=
padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=
=3D"courier new,monospace">Out merge(In1,In1,In2,In2,Out);</font></div></sp=
an></div></span></div><font face=3D"courier new,monospace"></font><br></div=
><div>Why not instead of the new syntax for names introducing we simply</di=
v><div><br></div><div><div><font style=3D"border-bottom-color:rgb(34,34,34)=
;border-bottom-style:none;border-bottom-width:0px;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-color:r=
gb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;m=
argin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-l=
eft:0px;padding-right:0px;padding-top:0px" face=3D"courier new,monospace">r=
equires Mergeable&lt;In1, In2, Out&gt; =C2=A0</font></div><div><font style=
=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-botto=
m-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-l=
eft-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;bord=
er-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;bor=
der-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin=
-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:=
0px" face=3D"courier new,monospace">Out merge(In1,In1,In2,In2,Out);</font><=
/div><div><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-st=
yle:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-lef=
t-style:none;border-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);bord=
er-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;ma=
rgin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-r=
ight:0px;padding-top:0px" face=3D"courier new,monospace"><br></font></div><=
div><br></div></div><div><br></div><div><b></b><i></i><u></u><sub></sub><su=
p></sup><strike></strike><br></div><div><font face=3D"times new roman,serif=
"></font></div><div><font face=3D"times new roman,serif"><i><br></i></font>=
</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&quot; 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/eb8259f3-a2ca-4c4a-99d8-3a5d635458cf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eb8259f3-a2ca-4c4a-99d8-3a5d635458cf=
%40isocpp.org</a>.<br />

------=_Part_23287_2008754139.1529402091187--

------=_Part_23286_63031709.1529402091186--

.

------=_Part_23966_1685809116.1529411378680
Content-Type: multipart/alternative;
 boundary="----=_Part_23967_1451650620.1529411378680"

------=_Part_23967_1451650620.1529411378680
Content-Type: text/plain; charset="UTF-8"



On Tuesday, June 19, 2018 at 12:54:51 PM UTC+3, floria...@gmail.com wrote:
>
> I mostly agree with you. I don't think a "terse" syntax is needed.
>
> However, let's not forget something: if you cannot read/write C++ without
> an IDE, then C++ has got too complex for any human being. So I strongly
> disagree with your "ctrl-click" argument.
>
There are many cases where we need to read code and cannot ask an IDE
> (because it's a single file extracted from the project like in an email for
> instance).
>


Honest question. Are there any case syntax is *added* for *humans only*? I
can think of many places where it is *removed* (auto, for(:), etc ect), but
not a single case where it is *added*.


In any case, names meaning potentially multiple things is nothing new.
Variables and constants are prime example - scope local, function static,
function argument, static, member, template non-type argument.

We use both tools *and* naming conventions to aid us.

template<Container C, Integer i, Class c>
void f()
{}

This is the natural upgrade to

template<class C, int i>
void f(Class c)
{}

that the time traveler will have *no* problems with.

--
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/8d9f8893-7f64-441d-b7ae-950d66651af7%40isocpp.org.

------=_Part_23967_1451650620.1529411378680
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, June 19, 2018 at 12:54:51 PM UTC+3, fl=
oria...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">I mostly agree with you. I don&#39;t think a &quot;terse&quot; s=
yntax is needed.<br><br>However, let&#39;s not forget something: if you can=
not read/write C++ without an IDE, then C++ has got too complex for any hum=
an being. So I strongly disagree with your &quot;ctrl-click&quot; argument.=
=C2=A0</div></blockquote><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">There are many cases where we need to read code and cannot ask =
an IDE (because it&#39;s a single file extracted from the project like in a=
n email for instance).<br></div></blockquote><div><br></div><div><br></div>=
<div><span style=3D"display: inline !important; float: none; background-col=
or: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&qu=
ot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font-va=
riant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-a=
lign: left; text-decoration: none; text-indent: 0px; text-transform: none; =
-webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">Ho=
nest question.=C2=A0</span><span 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); display: inline; float: non=
e; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,san=
s-serif; 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;">Are there any case syn=
tax is </span><i style=3D"background: none; margin: 0px; padding: 0px; bord=
er: 0px rgb(34, 34, 34); border-image: none; height: auto; text-align: left=
; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter-sp=
acing: normal; overflow: visible; font-size: 13px; font-style: italic; font=
-variant: normal; text-decoration: none; word-spacing: 0px; white-space: no=
rmal; overflow-x: visible; overflow-y: visible; min-width: 0px; orphans: 2;=
 -webkit-text-stroke-width: 0px;"><b>added</b></i><span style=3D"background=
-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-st=
yle: none; border-bottom-width: 0px; border-image-outset: 0; border-image-r=
epeat: stretch; border-image-slice: 100%; border-image-source: none; border=
-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: non=
e; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-righ=
t-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); =
border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); disp=
lay: inline; float: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;=
Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0p=
x; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddin=
g-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; tex=
t-align: left; text-decoration: none; text-indent: 0px; text-transform: non=
e; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"=
> for <i>humans only</i>? I can think of many places where it is <i>removed=
</i> (auto, for(:), etc ect), but not a single case where it is <i>added</i=
>.=C2=A0</span></div><div><br></div><div><br></div><div>In any case, names =
meaning potentially multiple things is nothing new. Variables and constants=
 are prime example - scope local, function static, function argument, stati=
c, member, template non-type argument.=C2=A0</div><div><br></div><div>We us=
e both tools <i>and</i> naming conventions to aid us.<br></div><div><br></d=
iv><div><span style=3D"text-align: left; color: rgb(34, 34, 34); text-trans=
form: none; text-indent: 0px; letter-spacing: normal; font-size: 13px; font=
-style: normal; font-variant: normal; font-weight: 400; text-decoration: no=
ne; word-spacing: 0px; display: inline !important; white-space: normal; orp=
hans: 2; float: none; -webkit-text-stroke-width: 0px; background-color: tra=
nsparent;"><font color=3D"#0000ff" face=3D"courier new,monospace">template<=
/font><font face=3D"courier new,monospace">&lt;<font color=3D"#bf9000">Cont=
ainer</font> C, <font color=3D"#0000ff">Integer </font>i, <font color=3D"#3=
d85c6">Class</font> c&gt;</font></span></div><div><span style=3D"text-align=
: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; let=
ter-spacing: normal; font-size: 13px; font-style: normal; font-variant: nor=
mal; font-weight: 400; text-decoration: none; word-spacing: 0px; display: i=
nline !important; white-space: normal; orphans: 2; float: none; -webkit-tex=
t-stroke-width: 0px; background-color: transparent;"><font face=3D"courier =
new,monospace"><font color=3D"#0000ff">void</font> f()=C2=A0</font></span><=
/div><div><span style=3D"text-align: left; color: rgb(34, 34, 34); text-tra=
nsform: none; text-indent: 0px; letter-spacing: normal; font-size: 13px; fo=
nt-style: normal; font-variant: normal; font-weight: 400; text-decoration: =
none; word-spacing: 0px; display: inline !important; white-space: normal; o=
rphans: 2; float: none; -webkit-text-stroke-width: 0px; background-color: t=
ransparent;"><font face=3D"courier new,monospace">{</font></span><span styl=
e=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none; text-i=
ndent: 0px; letter-spacing: normal; font-size: 13px; font-style: normal; fo=
nt-variant: normal; font-weight: 400; text-decoration: none; word-spacing: =
0px; display: inline !important; white-space: normal; orphans: 2; float: no=
ne; -webkit-text-stroke-width: 0px; background-color: transparent;"><font f=
ace=3D"courier new,monospace">}</font></span></div><div><span style=3D"text=
-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0p=
x; letter-spacing: normal; font-size: 13px; font-style: normal; font-varian=
t: normal; font-weight: 400; text-decoration: none; word-spacing: 0px; disp=
lay: inline !important; white-space: normal; orphans: 2; float: none; -webk=
it-text-stroke-width: 0px; background-color: transparent;"><font face=3D"ar=
ial,sans-serif"></font><br></span></div><div><span style=3D"text-align: lef=
t; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter-s=
pacing: normal; font-size: 13px; font-style: normal; font-variant: normal; =
font-weight: 400; text-decoration: none; word-spacing: 0px; display: inline=
 !important; white-space: normal; orphans: 2; float: none; -webkit-text-str=
oke-width: 0px; background-color: transparent;"><font face=3D"arial,sans-se=
rif">This is the natural upgrade to</font></span><span style=3D"text-align:=
 left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; lett=
er-spacing: normal; font-size: 13px; font-style: normal; font-variant: norm=
al; font-weight: 400; text-decoration: none; word-spacing: 0px; display: in=
line !important; white-space: normal; orphans: 2; float: none; -webkit-text=
-stroke-width: 0px; background-color: transparent;"><font face=3D"arial,san=
s-serif"><br></font></span></div><div><span style=3D"text-align: left; colo=
r: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing:=
 normal; font-size: 13px; font-style: normal; font-variant: normal; font-we=
ight: 400; text-decoration: none; word-spacing: 0px; display: inline !impor=
tant; white-space: normal; orphans: 2; float: none; -webkit-text-stroke-wid=
th: 0px; background-color: transparent;"><font face=3D"arial,sans-serif">=
=C2=A0=C2=A0<div style=3D"background-color: transparent; border-bottom-colo=
r: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bo=
rder-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: 0px; border-right=
-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px;=
 border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-widt=
h: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp=
;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; =
font-variant: normal; font-weight: 400; letter-spacing: normal; margin-bott=
om: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; =
padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0p=
x; text-align: left; text-decoration: none; text-indent: 0px; text-transfor=
m: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing:=
 0px;"><span style=3D"background-color: transparent; border-bottom-color: r=
gb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border=
-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; b=
order-image-source: none; border-image-width: 1; border-left-color: rgb(34,=
 34, 34); border-left-style: none; border-left-width: 0px; border-right-col=
or: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bor=
der-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0=
px; color: rgb(34, 34, 34); display: inline; float: none; font-family: &amp=
;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: =
13px; font-style: normal; font-variant: normal; font-weight: 400; letter-sp=
acing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; mar=
gin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-r=
ight: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-=
indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-sp=
ace: normal; word-spacing: 0px;"><font color=3D"#0000ff" face=3D"courier ne=
w,monospace" style=3D"border-bottom-color: rgb(0, 0, 255); border-bottom-st=
yle: none; border-bottom-width: 0px; border-image-outset: 0; border-image-r=
epeat: stretch; border-image-slice: 100%; border-image-source: none; border=
-image-width: 1; border-left-color: rgb(0, 0, 255); border-left-style: none=
; border-left-width: 0px; border-right-color: rgb(0, 0, 255); border-right-=
style: none; border-right-width: 0px; border-top-color: rgb(0, 0, 255); bor=
der-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-left=
: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-lef=
t: 0px; padding-right: 0px; padding-top: 0px;">template</font><font face=3D=
"courier new,monospace" style=3D"border-bottom-color: rgb(34, 34, 34); bord=
er-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; bo=
rder-image-repeat: stretch; border-image-slice: 100%; border-image-source: =
none; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-lef=
t-style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34);=
 border-right-style: none; border-right-width: 0px; border-top-color: rgb(3=
4, 34, 34); border-top-style: none; border-top-width: 0px; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0=
px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">&lt;<font col=
or=3D"#0000ff" style=3D"border-bottom-color: rgb(191, 144, 0); border-botto=
m-style: none; border-bottom-width: 0px; border-image-outset: 0; border-ima=
ge-repeat: stretch; border-image-slice: 100%; border-image-source: none; bo=
rder-image-width: 1; border-left-color: rgb(191, 144, 0); border-left-style=
: none; border-left-width: 0px; border-right-color: rgb(191, 144, 0); borde=
r-right-style: none; border-right-width: 0px; border-top-color: rgb(191, 14=
4, 0); border-top-style: none; border-top-width: 0px; margin-bottom: 0px; m=
argin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; p=
adding-left: 0px; padding-right: 0px; padding-top: 0px;">class </font>C, <f=
ont color=3D"#0000ff" style=3D"border-bottom-color: rgb(0, 0, 255); border-=
bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; borde=
r-image-repeat: stretch; border-image-slice: 100%; border-image-source: non=
e; border-image-width: 1; border-left-color: rgb(0, 0, 255); border-left-st=
yle: none; border-left-width: 0px; border-right-color: rgb(0, 0, 255); bord=
er-right-style: none; border-right-width: 0px; border-top-color: rgb(0, 0, =
255); border-top-style: none; border-top-width: 0px; margin-bottom: 0px; ma=
rgin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; pa=
dding-left: 0px; padding-right: 0px; padding-top: 0px;">int </font>i&gt;</f=
ont></span></div><div style=3D"background-color: transparent; border-bottom=
-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0p=
x; 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: 0px; border-=
right-color: rgb(34, 34, 34); border-right-style: none; border-right-width:=
 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top=
-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;=
,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: nor=
mal; font-variant: normal; font-weight: 400; letter-spacing: normal; margin=
-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans=
: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-to=
p: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-tra=
nsform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spa=
cing: 0px;"><span style=3D"background-color: transparent; border-bottom-col=
or: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; b=
order-image-outset: 0; border-image-repeat: stretch; border-image-slice: 10=
0%; border-image-source: none; border-image-width: 1; border-left-color: rg=
b(34, 34, 34); border-left-style: none; border-left-width: 0px; border-righ=
t-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px=
; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-wid=
th: 0px; color: rgb(34, 34, 34); display: inline; float: none; font-family:=
 &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-s=
ize: 13px; font-style: normal; font-variant: normal; font-weight: 400; lett=
er-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px=
; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padd=
ing-right: 0px; padding-top: 0px; text-align: left; text-decoration: none; =
text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whi=
te-space: normal; word-spacing: 0px;"><font face=3D"courier new,monospace" =
style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; b=
order-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stret=
ch; border-image-slice: 100%; border-image-source: none; border-image-width=
: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-le=
ft-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: non=
e; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-s=
tyle: none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; ma=
rgin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; p=
adding-right: 0px; padding-top: 0px;"><font color=3D"#0000ff" style=3D"bord=
er-bottom-color: rgb(0, 0, 255); border-bottom-style: none; border-bottom-w=
idth: 0px; border-image-outset: 0; border-image-repeat: stretch; border-ima=
ge-slice: 100%; border-image-source: none; border-image-width: 1; border-le=
ft-color: rgb(0, 0, 255); border-left-style: none; border-left-width: 0px; =
border-right-color: rgb(0, 0, 255); border-right-style: none; border-right-=
width: 0px; border-top-color: rgb(0, 0, 255); border-top-style: none; borde=
r-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; =
margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px=
; padding-top: 0px;">void</font> f(<font color=3D"#3d85c6">Class</font> c)=
=C2=A0</font></span></div><div 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: &amp;quot;Arial&=
amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-s=
tyle: normal; font-variant: normal; font-weight: 400; letter-spacing: norma=
l; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px=
; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; p=
adding-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;"><span style=3D"background-color: transparent; border-b=
ottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-widt=
h: 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: 0px; bo=
rder-right-color: rgb(34, 34, 34); border-right-style: none; border-right-w=
idth: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; borde=
r-top-width: 0px; color: rgb(34, 34, 34); display: inline; float: none; fon=
t-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-seri=
f; font-size: 13px; font-style: normal; font-variant: normal; font-weight: =
400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-r=
ight: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: =
0px; padding-right: 0px; padding-top: 0px; text-align: left; text-decoratio=
n: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width:=
 0px; white-space: normal; word-spacing: 0px;"><font face=3D"courier new,mo=
nospace" style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style=
: none; border-bottom-width: 0px; border-image-outset: 0; border-image-repe=
at: stretch; border-image-slice: 100%; border-image-source: none; border-im=
age-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-s=
tyle: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bor=
der-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-left=
: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-lef=
t: 0px; padding-right: 0px; padding-top: 0px;">{</font></span><span style=
=3D"background-color: transparent; border-bottom-color: rgb(34, 34, 34); bo=
rder-bottom-style: none; border-bottom-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-l=
eft-style: none; border-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-top-style: none; border-top-width: 0px; color: rgb(34,=
 34, 34); display: inline; float: none; font-family: &amp;quot;Arial&amp;qu=
ot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: =
normal; font-variant: normal; font-weight: 400; letter-spacing: normal; mar=
gin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orph=
ans: 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; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;"><font face=3D"courier new,monospace" style=3D"border-bottom-=
color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-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: 0px; border-r=
ight-color: rgb(34, 34, 34); border-right-style: none; border-right-width: =
0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-=
width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin=
-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padd=
ing-top: 0px;">}</font></span></div><div style=3D"background-color: transpa=
rent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bord=
er-bottom-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: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; =
border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-styl=
e: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;q=
uot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13=
px; font-style: normal; font-variant: normal; font-weight: 400; letter-spac=
ing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margi=
n-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-rig=
ht: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-in=
dent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-spac=
e: normal; word-spacing: 0px;"><span style=3D"background-color: transparent=
; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-b=
ottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; bor=
der-image-slice: 100%; border-image-source: none; border-image-width: 1; bo=
rder-left-color: rgb(34, 34, 34); border-left-style: none; border-left-widt=
h: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; bord=
er-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: n=
one; border-top-width: 0px; color: rgb(34, 34, 34); display: inline; float:=
 none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;=
,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; fon=
t-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px=
; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padd=
ing-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text=
-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-str=
oke-width: 0px; white-space: normal; word-spacing: 0px;"><font face=3D"cour=
ier new,monospace" style=3D"border-bottom-color: rgb(34, 34, 34); border-bo=
ttom-style: none; border-bottom-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-sty=
le: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); bord=
er-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 34=
, 34); border-top-style: none; border-top-width: 0px; margin-bottom: 0px; m=
argin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; p=
adding-left: 0px; padding-right: 0px; padding-top: 0px;"><br></font></span>=
</div></font></span><div style=3D"background-color: transparent; border-bot=
tom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width:=
 0px; border-image-outset: 0; border-image-repeat: stretch; border-image-sl=
ice: 100%; border-image-source: none; border-image-width: 1; border-left-co=
lor: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; bord=
er-right-color: rgb(34, 34, 34); border-right-style: none; border-right-wid=
th: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-=
top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;qu=
ot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: =
normal; font-variant: normal; font-weight: 400; letter-spacing: normal; mar=
gin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orph=
ans: 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; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;"><span style=3D"text-align: left; color: rgb(34, 34, 34); tex=
t-transform: none; text-indent: 0px; letter-spacing: normal; font-size: 13p=
x; font-style: normal; font-variant: normal; font-weight: 400; text-decorat=
ion: none; word-spacing: 0px; display: inline !important; white-space: norm=
al; orphans: 2; float: none; -webkit-text-stroke-width: 0px; background-col=
or: transparent;"><font face=3D"arial,sans-serif">t<span style=3D"backgroun=
d-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-s=
tyle: none; border-bottom-width: 0px; border-image-outset: 0; border-image-=
repeat: stretch; border-image-slice: 100%; border-image-source: none; borde=
r-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: no=
ne; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-rig=
ht-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34);=
 border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); dis=
play: inline; float: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot=
;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-=
variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddi=
ng-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; te=
xt-align: left; text-decoration: none; text-indent: 0px; text-transform: no=
ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;=
"><font style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style:=
 none; border-bottom-width: 0px; border-image-outset: 0; border-image-repea=
t: stretch; border-image-slice: 100%; border-image-source: none; border-ima=
ge-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; b=
order-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-st=
yle: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bord=
er-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-left:=
 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left=
: 0px; padding-right: 0px; padding-top: 0px;">hat the time traveler will ha=
ve <i>no</i> problems with.=C2=A0</font></span></font></span><br></div></di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/8d9f8893-7f64-441d-b7ae-950d66651af7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8d9f8893-7f64-441d-b7ae-950d66651af7=
%40isocpp.org</a>.<br />

------=_Part_23967_1451650620.1529411378680--

------=_Part_23966_1685809116.1529411378680--

.

------=_Part_24108_1080386687.1529412467260
Content-Type: multipart/alternative;
 boundary="----=_Part_24109_675447998.1529412467261"

------=_Part_24109_675447998.1529412467261
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Le mardi 19 juin 2018 14:29:38 UTC+2, mihailn...@gmail.com a =C3=A9crit :
>
>
>
> On Tuesday, June 19, 2018 at 12:54:51 PM UTC+3, floria...@gmail.com wrote=
:
>>
>> I mostly agree with you. I don't think a "terse" syntax is needed.
>>
>> However, let's not forget something: if you cannot read/write C++ withou=
t=20
>> an IDE, then C++ has got too complex for any human being. So I strongly=
=20
>> disagree with your "ctrl-click" argument.=20
>>
> There are many cases where we need to read code and cannot ask an IDE=20
>> (because it's a single file extracted from the project like in an email =
for=20
>> instance).
>>
>
>
> Honest question. Are there any case syntax is *added* for *humans only*?=
=20
> I can think of many places where it is *removed* (auto, for(:), etc ect),=
=20
> but not a single case where it is *added*.=20
>

You over-interpreted what I said. And all your examples are primarily for=
=20
humans.
What is the most understandable for a human:=20
std::vector<int> vec;
for (std::vector<int>::iterator it =3D vec.begin(); it !=3D vec.end(); ++it=
) {
  int& i =3D *it;
  /* do some stuff with i */
}
or
std::vector<int> vec;
for(auto& i : vec) {
  /* do some stuff with i */
}
?

Obviously, most people find the second one easier to read/write. And they=
=20
absolutely don't an IDE for that.
Your "ctrl-click" argument transposed to this loop example would be to say=
=20
we could have an IDE that has an option to generate the first loop when=20
clicked on a container variable, so we don't need this fancy range-based=20
for-loop.
At least, that's how I see your "ctrl-click" argument.

But don't get me wrong, I fully agree with your time-traveler argument.


>
> In any case, names meaning potentially multiple things is nothing new.=20
> Variables and constants are prime example - scope local, function static,=
=20
> function argument, static, member, template non-type argument.=20
>
> We use both tools *and* naming conventions to aid us.
>
> template<Container C, Integer i, Class c>
> void f()=20
> {}
>
> This is the natural upgrade to
>  =20
> template<class C, int i>
> void f(Class c)=20
> {}
>
> that the time traveler will have *no* problems with.=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a91f9fcf-df34-44b1-aa2f-3fd77943a349%40isocpp.or=
g.

------=_Part_24109_675447998.1529412467261
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le mardi 19 juin 2018 14:29:38 UTC+2, mihailn...@g=
mail.com a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><br><br>On Tuesday, June 19, 2018 at 12:54:51 PM UTC+3, <a>f=
loria...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">I mostly agree with you. I don&#39;t think a &quot;terse&quot; s=
yntax is needed.<br><br>However, let&#39;s not forget something: if you can=
not read/write C++ without an IDE, then C++ has got too complex for any hum=
an being. So I strongly disagree with your &quot;ctrl-click&quot; argument.=
=C2=A0</div></blockquote><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">There are many cases where we need to read code and cannot ask an =
IDE (because it&#39;s a single file extracted from the project like in an e=
mail for instance).<br></div></blockquote><div><br></div><div><br></div><di=
v><span style=3D"display:inline!important;float:none;background-color:trans=
parent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&qu=
ot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-we=
ight:400;letter-spacing:normal;text-align:left;text-decoration:none;text-in=
dent:0px;text-transform:none;white-space:normal;word-spacing:0px">Honest qu=
estion.=C2=A0</span><span>Are there any case syntax is </span><i style=3D"b=
ackground:none;margin:0px;padding:0px;border:0px rgb(34,34,34);min-height:a=
uto;text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px=
;letter-spacing:normal;overflow:visible;font-size:13px;font-style:italic;fo=
nt-variant:normal;text-decoration:none;word-spacing:0px;white-space:normal;=
overflow-x:visible;overflow-y:visible;min-width:0px"><b>added</b></i><span>=
 for <i>humans only</i>? I can think of many places where it is <i>removed<=
/i> (auto, for(:), etc ect), but not a single case where it is <i>added</i>=
..=C2=A0</span></div></div></blockquote><div><br></div><div>You over-interpr=
eted what I said. And all your examples are primarily for humans.</div><div=
>What is the most understandable for a human: <div style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">vector</span><span style=3D"color: #080;" class=3D"=
styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> vec</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
for</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">vector</span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">iterator it </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> vec</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">begin</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> it </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">!=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> vec</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">end</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">++</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">it</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> i </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">it</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">/* do some=
 stuff with i */</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n></div></code></div>or</div><div><div style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">vector</span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> vec</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">for</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> vec</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">/* do some s=
tuff with i */</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
</div></code></div></div><div>?<br></div><div><br></div><div>Obviously, mos=
t people find the second one easier to read/write. And they absolutely don&=
#39;t an IDE for that.<br>Your &quot;ctrl-click&quot; argument transposed t=
o this loop example would be to say we could have an IDE that has an option=
 to generate the first loop when clicked on a container variable, so we don=
&#39;t need this fancy range-based for-loop.<br></div><div>At least, that&#=
39;s how I see your &quot;ctrl-click&quot; argument.<br></div><div><br></di=
v><div>But don&#39;t get me wrong, I fully agree with your time-traveler ar=
gument.<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><br></div><div><br></div><div>In any case, names me=
aning potentially multiple things is nothing new. Variables and constants a=
re prime example - scope local, function static, function argument, static,=
 member, template non-type argument.=C2=A0</div><div><br></div><div>We use =
both tools <i>and</i> naming conventions to aid us.<br></div><div><br></div=
><div><span style=3D"text-align:left;color:rgb(34,34,34);text-transform:non=
e;text-indent:0px;letter-spacing:normal;font-size:13px;font-style:normal;fo=
nt-variant:normal;font-weight:400;text-decoration:none;word-spacing:0px;dis=
play:inline!important;white-space:normal;float:none;background-color:transp=
arent"><font color=3D"#0000ff" face=3D"courier new,monospace">template</fon=
t><font face=3D"courier new,monospace">&lt;<font color=3D"#bf9000">Containe=
r</font> C, <font color=3D"#0000ff">Integer </font>i, <font color=3D"#3d85c=
6">Class</font> c&gt;</font></span></div><div><span style=3D"text-align:lef=
t;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:no=
rmal;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;t=
ext-decoration:none;word-spacing:0px;display:inline!important;white-space:n=
ormal;float:none;background-color:transparent"><font face=3D"courier new,mo=
nospace"><font color=3D"#0000ff">void</font> f()=C2=A0</font></span></div><=
div><span style=3D"text-align:left;color:rgb(34,34,34);text-transform:none;=
text-indent:0px;letter-spacing:normal;font-size:13px;font-style:normal;font=
-variant:normal;font-weight:400;text-decoration:none;word-spacing:0px;displ=
ay:inline!important;white-space:normal;float:none;background-color:transpar=
ent"><font face=3D"courier new,monospace">{</font></span><span style=3D"tex=
t-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter=
-spacing:normal;font-size:13px;font-style:normal;font-variant:normal;font-w=
eight:400;text-decoration:none;word-spacing:0px;display:inline!important;wh=
ite-space:normal;float:none;background-color:transparent"><font face=3D"cou=
rier new,monospace">}</font></span></div><div><span style=3D"text-align:lef=
t;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:no=
rmal;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;t=
ext-decoration:none;word-spacing:0px;display:inline!important;white-space:n=
ormal;float:none;background-color:transparent"><font face=3D"arial,sans-ser=
if"></font><br></span></div><div><span style=3D"text-align:left;color:rgb(3=
4,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-siz=
e:13px;font-style:normal;font-variant:normal;font-weight:400;text-decoratio=
n:none;word-spacing:0px;display:inline!important;white-space:normal;float:n=
one;background-color:transparent"><font face=3D"arial,sans-serif">This is t=
he natural upgrade to</font></span><span style=3D"text-align:left;color:rgb=
(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-s=
ize:13px;font-style:normal;font-variant:normal;font-weight:400;text-decorat=
ion:none;word-spacing:0px;display:inline!important;white-space:normal;float=
:none;background-color:transparent"><font face=3D"arial,sans-serif"><br></f=
ont></span></div><div><span style=3D"text-align:left;color:rgb(34,34,34);te=
xt-transform:none;text-indent:0px;letter-spacing:normal;font-size:13px;font=
-style:normal;font-variant:normal;font-weight:400;text-decoration:none;word=
-spacing:0px;display:inline!important;white-space:normal;float:none;backgro=
und-color:transparent"><font face=3D"arial,sans-serif">=C2=A0=C2=A0<div><sp=
an><font style=3D"border-bottom-color:rgb(0,0,255);border-bottom-style:none=
;border-bottom-width:0px;border-left-color:rgb(0,0,255);border-left-style:n=
one;border-left-width:0px;border-right-color:rgb(0,0,255);border-right-styl=
e:none;border-right-width:0px;border-top-color:rgb(0,0,255);border-top-styl=
e:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:=
0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;pa=
dding-top:0px" color=3D"#0000ff" face=3D"courier new,monospace">template</f=
ont><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:no=
ne;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-styl=
e:none;border-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-top=
-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-r=
ight:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0=
px;padding-top:0px" face=3D"courier new,monospace">&lt;<font style=3D"borde=
r-bottom-color:rgb(191,144,0);border-bottom-style:none;border-bottom-width:=
0px;border-left-color:rgb(191,144,0);border-left-style:none;border-left-wid=
th:0px;border-right-color:rgb(191,144,0);border-right-style:none;border-rig=
ht-width:0px;border-top-color:rgb(191,144,0);border-top-style:none;border-t=
op-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:=
0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" =
color=3D"#0000ff">class </font>C, <font style=3D"border-bottom-color:rgb(0,=
0,255);border-bottom-style:none;border-bottom-width:0px;border-left-color:r=
gb(0,0,255);border-left-style:none;border-left-width:0px;border-right-color=
:rgb(0,0,255);border-right-style:none;border-right-width:0px;border-top-col=
or:rgb(0,0,255);border-top-style:none;border-top-width:0px;margin-bottom:0p=
x;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;paddin=
g-left:0px;padding-right:0px;padding-top:0px" color=3D"#0000ff">int </font>=
i&gt;</font></span></div><div><span><font style=3D"border-bottom-color:rgb(=
34,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-colo=
r:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-right-c=
olor:rgb(34,34,34);border-right-style:none;border-right-width:0px;border-to=
p-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bot=
tom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;=
padding-left:0px;padding-right:0px;padding-top:0px" face=3D"courier new,mon=
ospace"><font style=3D"border-bottom-color:rgb(0,0,255);border-bottom-style=
:none;border-bottom-width:0px;border-left-color:rgb(0,0,255);border-left-st=
yle:none;border-left-width:0px;border-right-color:rgb(0,0,255);border-right=
-style:none;border-right-width:0px;border-top-color:rgb(0,0,255);border-top=
-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-r=
ight:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0=
px;padding-top:0px" color=3D"#0000ff">void</font> f(<font color=3D"#3d85c6"=
>Class</font> c)=C2=A0</font></span></div><div><span><font style=3D"border-=
bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px=
;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-right-wi=
dth:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-wid=
th:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;pa=
dding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=
=3D"courier new,monospace">{</font></span><span><font style=3D"border-botto=
m-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;bord=
er-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;bo=
rder-right-color:rgb(34,34,34);border-right-style:none;border-right-width:0=
px;border-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" face=3D"cou=
rier new,monospace">}</font></span></div><div><span><font style=3D"border-b=
ottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;=
border-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0p=
x;border-right-color:rgb(34,34,34);border-right-style:none;border-right-wid=
th:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-widt=
h:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;pad=
ding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=3D=
"courier new,monospace"><br></font></span></div></font></span><div><span st=
yle=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:=
0px;letter-spacing:normal;font-size:13px;font-style:normal;font-variant:nor=
mal;font-weight:400;text-decoration:none;word-spacing:0px;display:inline!im=
portant;white-space:normal;float:none;background-color:transparent"><font f=
ace=3D"arial,sans-serif">t<span><font style=3D"border-bottom-color:rgb(34,3=
4,34);border-bottom-style:none;border-bottom-width:0px;border-left-color:rg=
b(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;margin-bottom:=
0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padd=
ing-left:0px;padding-right:0px;padding-top:0px">hat the time traveler will =
have <i>no</i> problems with.=C2=A0</font></span></font></span><br></div></=
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&quot; 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/a91f9fcf-df34-44b1-aa2f-3fd77943a349%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a91f9fcf-df34-44b1-aa2f-3fd77943a349=
%40isocpp.org</a>.<br />

------=_Part_24109_675447998.1529412467261--

------=_Part_24108_1080386687.1529412467260--

.

--000000000000f1ede9056effac57
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 19, 2018 at 5:33 AM <mihailnajdenov@gmail.com> wrote:

> OK, right now in flight are about FOUR proposals, trying to "simplify" and
> "make more clear" concepts usage.
> This is madness. It is madness, because NONE of it make it more clear!
> None.
>

I agree with you, but I think there's one piece of new syntax that is OK.
To wit:

For Simple cases
> template<Sortable S>
> void sort(S& s);
>

I don't like this.  I think it overlaps too much with non-type parameters.
I would prefer

void sort(auto<Sortable>& s);

1) The angle brackets signal that templates are involved.
2) The auto signals that the compiler is deducing something.
3) The keyword followed by a name in angle brackets signal that
something is being constrained; it almost has the feeling of a cast.

--
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/CAHSYqdbCvgGxQJi5a8yjCBxwn%3Dta2RrKgTyF1d1WrXEjuVF3vg%40mail.gmail.com.

--000000000000f1ede9056effac57
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 19=
, 2018 at 5:33 AM &lt;<a href=3D"mailto:mihailnajdenov@gmail.com">mihailnaj=
denov@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div>OK, right now in flight are about FOUR proposals, trying =
to &quot;simplify&quot; and &quot;make more clear&quot; concepts usage.</di=
v><div>This is madness. It is madness, because NONE of it make it more clea=
r! None.=C2=A0</div></div></blockquote><div><br>I agree with you, but I thi=
nk there&#39;s one piece of new syntax that is OK.<br>To wit:<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>For Simple cases</div>=
<div><span style=3D"display:inline!important;float:none;background-color:tr=
ansparent;color:rgb(34,34,34);font-family:courier new,monospace;font-size:1=
3px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:no=
rmal;text-align:left;text-decoration:none;text-indent:0px;text-transform:no=
ne;white-space:normal;word-spacing:0px">template&lt;Sortable S&gt;=C2=A0</s=
pan></div><div><span style=3D"display:inline!important;float:none;backgroun=
d-color:transparent;color:rgb(34,34,34);font-family:courier new,monospace;f=
ont-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-=
spacing:normal;text-align:left;text-decoration:none;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px">void sort(S&amp; s);</spa=
n></div></div></blockquote><div><br>I don&#39;t like this.=C2=A0 I think it=
 overlaps too much with non-type parameters.=C2=A0 I would prefer<br><br><f=
ont face=3D"monospace, monospace">void sort(auto&lt;Sortable&gt;&amp; s);</=
font><br><br>1) The angle brackets signal that templates are involved.<br>2=
) The <font face=3D"monospace, monospace">auto</font> signals that the comp=
iler is deducing something.<br>3) The keyword followed by a name in angle b=
rackets signal that<br>something is being constrained; it almost has the fe=
eling of a cast.</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAHSYqdbCvgGxQJi5a8yjCBxwn%3Dta2RrKgT=
yF1d1WrXEjuVF3vg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbCvgGxQJ=
i5a8yjCBxwn%3Dta2RrKgTyF1d1WrXEjuVF3vg%40mail.gmail.com</a>.<br />

--000000000000f1ede9056effac57--

.

------=_Part_24297_2093627580.1529419788937
Content-Type: multipart/alternative;
 boundary="----=_Part_24298_1718030435.1529419788938"

------=_Part_24298_1718030435.1529419788938
Content-Type: text/plain; charset="UTF-8"



On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, mihailn...@gmail.com wrote:
>
> OK, right now in flight are about FOUR proposals, trying to "simplify" and
> "make more clear" concepts usage.
>
> This is madness. It is madness, because NONE of it make it more clear!
> None.
>
> By inviting new language constructs one does not make things "more clear",
> it only adds more things to learn.
>
> The worst part is - *we have working solution that is clear. Granted
> verbose, but clear. *
>
> If one makes it Not verbose but Not clear (not self-explanatory, need
> learning) also one gains nothing!
>

Clarity is ultimately a measure of time. Variadic templates are not "clear"
to people who've never seen them. UDLs are not "clear" to people who've
never seen them. Lambdas are not "clear" to people who've never seen them.
Structured bindings are not "clear" to people who've never seen them. And
God knows rvalue references and forwarding references would utterly baffle
people who've never seen them.

All of these things are clear to us now because we are *used to them*.
That's the only reason why they are clear. Your hypothetical time traveler
from the C++98/03 days would be confused by the simplest of modern C++11
code.

And that's OK.

Saying that a syntax is wrong just because we're not used to it is not
helpful. It's far more useful to look at things from a cost/benefit
analysis.

Lambdas are probably the best example, because they don't do *anything*
that you couldn't do yourself, either with in-situ struct declarations or
out-of-function declarations. So their benefit is purely convenience.

Lambdas have a *huge* syntactic cost. They have novel introduction syntax,
re-appropriating something that looks like an array into a function/class
declaration. They are functions that can be declared without parameters,
without even `()`. They deduce the return value unless you specify
otherwise. They allow `auto` in parameter lists. They can capture
values/expressions in a myriad of ways. And so forth.

All of this represents a syntactic variance relative to regular functions.
And thus, it is a burden, a cost for entry that people have to learn.

But all of those costs pale into insignificance next to the *gains* from
the syntax. Lambdas are game-changers for C++. Pre-C++11, people would
avoid simple algorithms like `transform`, because writing out the
equivalent code was often easier than providing a functor. That's no longer
the case.

Now, I'm not saying that any of the terse syntaxes are as valuable as
lambdas are. But my point is that novel syntax should not be avoided simply
because it is novel; you *have* to look at the benefits of it.

This is the reason why I hate concept introduction syntax. It's not that it
has novel syntax; it's that the novel syntax doesn't buy much. Yes, concept
introduction is shorter than the full `requires` clause. But it's not
shorter *enough* in enough cases to be worth the syntactic burden.

The nice thing about Herb's syntax is how regular it is. It works the same
everywhere. It provides the same benefit everywhere. It may be novel
syntax, but it solves many problems due to its regularity. It allows you to
concisely fairly obvious things.

Now, you may argue that no terse syntax is worth the syntactic burden. I
rather disagree: there are too many cases where the function parameters and
template parameters match each other to say that making that function
declaration shorter isn't worth the time and effort. Applying concepts to
variables, even function parameters, makes too much sense to not be worth
pursuing.

--
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/83850f66-75f2-4497-86f3-afd5fa91a067%40isocpp.org.

------=_Part_24298_1718030435.1529419788938
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, mih=
ailn...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>OK, right now in flight are about FOUR proposals, trying to=
 &quot;simplify&quot; and &quot;make more clear&quot; concepts usage.</div>=
<div><br></div><div>This is madness. It is madness, because NONE of it make=
 it more clear! None.=C2=A0</div><div><br></div><div>By inviting new langua=
ge constructs one does not make things &quot;more clear&quot;, it only adds=
 more things to learn.</div><div><br></div><div>The worst part is - <i>we h=
ave working solution that is clear. Granted verbose, but clear.=C2=A0</i></=
div><div><i></i><br></div><div>If one makes it Not verbose but Not clear (n=
ot self-explanatory, need learning) also one gains nothing!</div></div></bl=
ockquote><div><br></div><div>Clarity is ultimately a measure of time. Varia=
dic templates are not &quot;clear&quot; to people who&#39;ve never seen the=
m. UDLs are not &quot;clear&quot; to people who&#39;ve never seen them. Lam=
bdas are not &quot;clear&quot; to people who&#39;ve never seen them. Struct=
ured bindings are not &quot;clear&quot; to people who&#39;ve never seen the=
m. And God knows rvalue references and forwarding references would utterly =
baffle people who&#39;ve never seen them.</div><div><br></div><div>All of t=
hese things are clear to us now because we are <i>used to them</i>. That&#3=
9;s the only reason why they are clear. Your hypothetical time traveler fro=
m the C++98/03 days would be confused by the simplest of modern C++11 code.=
</div><div><br></div><div>And that&#39;s OK.</div><div><br></div><div>Sayin=
g that a syntax is wrong just because we&#39;re not used to it is not helpf=
ul. It&#39;s far more useful to look at things from a cost/benefit analysis=
..</div><div><br></div><div>Lambdas are probably the best example, because t=
hey don&#39;t do <i>anything</i> that you couldn&#39;t do yourself, either =
with in-situ struct declarations or out-of-function declarations. So their =
benefit is purely convenience.<br></div><div><br></div><div>Lambdas have a =
<i>huge</i> syntactic cost. They have novel introduction syntax, re-appropr=
iating something that looks like an array into a function/class declaration=
.. They are functions that can be declared without parameters, without even =
`()`. They deduce the return value unless you specify otherwise. They allow=
 `auto` in parameter lists. They can capture values/expressions in a myriad=
 of ways. And so forth.</div><div><br></div><div>All of this represents a s=
yntactic variance relative to regular functions. And thus, it is a burden, =
a cost for entry that people have to learn.</div><div><br></div><div>But al=
l of those costs pale into insignificance next to the <i>gains</i> from the=
 syntax. Lambdas are game-changers for C++. Pre-C++11, people would avoid s=
imple algorithms like `transform`, because writing out the equivalent code =
was often easier than providing a functor. That&#39;s no longer the case.</=
div><div><br></div><div>Now, I&#39;m not saying that any of the terse synta=
xes are as valuable as lambdas are. But my point is that novel syntax shoul=
d not be avoided simply because it is novel; you <i>have</i> to look at the=
 benefits of it.</div><div><br></div><div>This is the reason why I hate con=
cept introduction syntax. It&#39;s not that it has novel syntax; it&#39;s t=
hat the novel syntax doesn&#39;t buy much. Yes, concept introduction is sho=
rter than the full `requires` clause. But it&#39;s not shorter <i>enough</i=
> in enough cases to be worth the syntactic burden.</div><div><br></div><di=
v>The nice thing about Herb&#39;s syntax is how regular it is. It works the=
 same everywhere. It provides the same benefit everywhere. It may be novel =
syntax, but it solves many problems due to its regularity. It allows you to=
 concisely fairly obvious things.</div><div><br></div><div>Now, you may arg=
ue that no terse syntax is worth the syntactic burden. I rather disagree: t=
here are too many cases where the function parameters and template paramete=
rs match each other to say that making that function declaration shorter is=
n&#39;t worth the time and effort. Applying concepts to variables, even fun=
ction parameters, makes too much sense to not be worth pursuing.<br></div><=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/83850f66-75f2-4497-86f3-afd5fa91a067%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/83850f66-75f2-4497-86f3-afd5fa91a067=
%40isocpp.org</a>.<br />

------=_Part_24298_1718030435.1529419788938--

------=_Part_24297_2093627580.1529419788937--

.

------=_Part_24677_2134357699.1529419947856
Content-Type: multipart/alternative;
 boundary="----=_Part_24678_1105618714.1529419947857"

------=_Part_24678_1105618714.1529419947857
Content-Type: text/plain; charset="UTF-8"

On Tuesday, June 19, 2018 at 10:41:23 AM UTC-4, Hyman Rosen wrote:
>
> I don't like this.  I think it overlaps too much with non-type parameters.
>

Yes, it does overlap with them. But since type parameters are *by far* the
most prevalent, let's give them the synatx they deserve.

--
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/4991c0fa-6e5e-4b59-bada-555400412507%40isocpp.org.

------=_Part_24678_1105618714.1529419947857
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, June 19, 2018 at 10:41:23 AM UTC-4, Hyman Rose=
n wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div =
class=3D"gmail_quote"><div>I don&#39;t like this.=C2=A0 I think it overlaps=
 too much with non-type parameters.</div></div></div></blockquote><div><br>=
</div><div>Yes, it does overlap with them. But since type parameters are <i=
>by far</i> the most prevalent, let&#39;s give them the synatx they deserve=
..</div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/4991c0fa-6e5e-4b59-bada-555400412507%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4991c0fa-6e5e-4b59-bada-555400412507=
%40isocpp.org</a>.<br />

------=_Part_24678_1105618714.1529419947857--

------=_Part_24677_2134357699.1529419947856--

.

--000000000000e331a0056f00485b
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 19, 2018 at 10:52 AM Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, June 19, 2018 at 10:41:23 AM UTC-4, Hyman Rosen wrote:
>>
>> I don't like this.  I think it overlaps too much with non-type parameters.
>>
>
> Yes, it does overlap with them. But since type parameters are *by far*
> the most prevalent, let's give them the synatx they deserve.
>

Type parameters are by far the most prevalent, yet we nevertheless call
them out as such:
template <typename SumType, typename Iter>
SumType accumulate(Iter begin, Iter end, SumType init);

The point of language design isn't to come up with the most compact syntax.
It's to have a syntax that makes code lucid to its readers.  So by analogy,

template <concept Sortable S>
void sort(S &s);

would be the way to go.

And as to your point on lambdas, they definitely should have had a keyword
introducer,
(lambda is good!) and trailing return types should have been introduced by
return, not
by ->.  Among other things, the reluctance to break old syntax is causing
new features
to be expressed as gibberish.

(Notice that I said old *syntax*, not old *programs*!  Beating my dead
hobby horse again,
I say that compiler writers are all too eager to break old programs by
"optimizing" away
undefined behavior that used to "just work.")

--
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/CAHSYqdbp%2BD3XnfRt5qj_g5FMgEvRqCs0kapYqucMEvzS-04bpw%40mail.gmail.com.

--000000000000e331a0056f00485b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 19=
, 2018 at 10:52 AM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">j=
mckesson@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr">On Tuesday, June 19, 2018 at 10:41:23 AM UTC-4, Hyman Rosen=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div>I don&#39;t like this.=C2=A0 I think it overlaps too =
much with non-type parameters.</div></div></div></blockquote><div><br></div=
><div>Yes, it does overlap with them. But since type parameters are <i>by f=
ar</i> the most prevalent, let&#39;s give them the synatx they deserve.</di=
v></div></blockquote><div><br>Type parameters are by far the most prevalent=
, yet we nevertheless call them out as such:<br><font face=3D"monospace, mo=
nospace">template &lt;typename SumType, typename Iter&gt;<br>SumType accumu=
late(Iter begin, Iter end, SumType init);</font><br><br>The point of langua=
ge design isn&#39;t to come up with the most compact syntax.<br>It&#39;s to=
 have a syntax that makes code lucid to its readers.=C2=A0 So by analogy,</=
div><div><br><font face=3D"monospace, monospace">template &lt;concept Sorta=
ble S&gt;<br>void sort(S &amp;s);</font></div><div><font face=3D"monospace,=
 monospace"><br></font>would be the way to go.<br><br>And as to your point =
on lambdas, they definitely should have had a keyword introducer,<br>(<font=
 face=3D"monospace, monospace">lambda</font> is good!) and trailing return =
types should have been introduced by <font face=3D"monospace, monospace">re=
turn</font>, not<br>by <font face=3D"monospace, monospace">-&gt;</font>.=C2=
=A0 Among other things, the reluctance to break old syntax is causing new f=
eatures<br>to be expressed as gibberish.<br><br>(Notice that I said old <i>=
syntax</i>, not old <i>programs</i>!=C2=A0 Beating my dead hobby horse agai=
n,<br>I say that compiler writers are all too eager to break old programs b=
y &quot;optimizing&quot; away<br>undefined behavior that used to &quot;just=
 work.&quot;)</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAHSYqdbp%2BD3XnfRt5qj_g5FMgEvRqCs0ka=
pYqucMEvzS-04bpw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbp%2BD3X=
nfRt5qj_g5FMgEvRqCs0kapYqucMEvzS-04bpw%40mail.gmail.com</a>.<br />

--000000000000e331a0056f00485b--

.

On 06/19/18 17:41, Hyman Rosen wrote:
> On Tue, Jun 19, 2018 at 5:33 AM <mihailnajdenov@gmail.com=20
> <mailto:mihailnajdenov@gmail.com>> wrote:
>=20
>     OK, right now in flight are about FOUR proposals, trying to
>     "simplify" and "make more clear" concepts usage.
>     This is madness. It is madness, because NONE of it make it more
>     clear! None.=20
>=20
> I agree with you, but I think there's one piece of new syntax that is OK.
> To wit:
>=20
>     For Simple cases
>     template<Sortable S>
>     void sort(S& s);
>=20
> I don't like this.=C2=A0 I think it overlaps too much with non-type=20
> parameters.

As long as the compiler is able to see what Sortable is, there is no=20
problem in disambiguating it. A human may not be able to deduce it at=20
once, but either the naming or the use of the identifier will give a=20
clue. For example, in your declaration S is used as a type in the=20
arguments list, so it is clearly not a value and Sortable cannot be an=20
enum or a typedef of an integral type.

>=C2=A0 I would prefer
>=20
> void sort(auto<Sortable>& s);

I don't like this as it replaces the existing syntax of template=20
declaration with a new one.

> 1) The angle brackets signal that templates are involved.

Yes, but not in the way they should. This is a syntax of template=20
specialization, not a template declaration, which always starts with the=20
keyword `template`. Well, except for lambdas, but they are sufficiently=20
alien already.

> 2) The auto signals that the compiler is deducing something.
> 3) The keyword followed by a name in angle brackets signal that
> something is being constrained; it almost has the feeling of a cast.

The contents of angle brackets so far denoted template arguments. With=20
your new syntax, it is something else entirely.

--=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/e0d6379a-c45d-328f-9d29-f0c840a0cf3f%40gmail.com=
..

.

------=_Part_24719_1258950237.1529423978136
Content-Type: multipart/alternative;
 boundary="----=_Part_24720_1500855846.1529423978136"

------=_Part_24720_1500855846.1529423978136
Content-Type: text/plain; charset="UTF-8"

On Tuesday, June 19, 2018 at 11:24:59 AM UTC-4, Hyman Rosen wrote:
>
> On Tue, Jun 19, 2018 at 10:52 AM Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, June 19, 2018 at 10:41:23 AM UTC-4, Hyman Rosen wrote:
>>>
>>> I don't like this.  I think it overlaps too much with non-type
>>> parameters.
>>>
>>
>> Yes, it does overlap with them. But since type parameters are *by far*
>> the most prevalent, let's give them the synatx they deserve.
>>
>
> Type parameters are by far the most prevalent, yet we nevertheless call
> them out as such:
> template <typename SumType, typename Iter>
> SumType accumulate(Iter begin, Iter end, SumType init);
>
> The point of language design isn't to come up with the most compact syntax.
> It's to have a syntax that makes code lucid to its readers.
>

Verbosity should not be ignored. The more verbose a feature is, the less
likely that it will be used. Adding `concept` to such a declaration changes
nothing about it. It doesn't disambiguate anything to the compiler (which
is perfectly capable of telling the difference between a type concept and a
value concept); it exists *solely* for the user.

I'm not saying that "lucidity" is unimportant. But you can't just say
"let's make everything take twice as long to say, even if 99% of the time
it would be obvious what's going on without the extra verbage".

C could have introduced a `function` keyword when declaring functions.
But... why bother? It's not like the compiler needs the extra keyword
there. So why have one? Similarly, it could have had a keyword when
declaring variables. Again, what's the point? The compiler doesn't need it.

Oh yes, such keywords would have disambiguate C++'s Most Vexing Parse, but
that was C++'s fault, not C's fault. And even then, 99% of the time, the
syntax is not ambiguous.

Adding a feature that only matters in 1% of the cases, but has to be used
in 100% of the cases, is just bad syntax.

  So by analogy,
>
> template <concept Sortable S>
> void sort(S &s);
>
> would be the way to go.
>
> And as to your point on lambdas, they definitely should have had a keyword
> introducer,
> (lambda is good!) and trailing return types should have been introduced
> by return, not
> by ->.  Among other things, the reluctance to break old syntax is causing
> new features
> to be expressed as gibberish.
>

Things are gibberish only until they're not. A new language appears to be
gibberish until you get used to its rules and proclivities.

C++ does not need to be readable by non-C++ programmers.

--
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/e3e7f9fa-2b55-4e7f-8af4-08e677fe6572%40isocpp.org.

------=_Part_24720_1500855846.1529423978136
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, June 19, 2018 at 11:24:59 AM UTC-4, Hyman Rose=
n wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div =
class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 19, 2018 at 10:52 AM Nic=
ol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"tQkqoXweBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">jmck...@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">On Tuesday, June 19, 2018 at 10:41:23 AM UTC-4, Hyma=
n Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
 class=3D"gmail_quote"><div>I don&#39;t like this.=C2=A0 I think it overlap=
s too much with non-type parameters.</div></div></div></blockquote><div><br=
></div><div>Yes, it does overlap with them. But since type parameters are <=
i>by far</i> the most prevalent, let&#39;s give them the synatx they deserv=
e.</div></div></blockquote><div><br>Type parameters are by far the most pre=
valent, yet we nevertheless call them out as such:<br><font face=3D"monospa=
ce, monospace">template &lt;typename SumType, typename Iter&gt;<br>SumType =
accumulate(Iter begin, Iter end, SumType init);</font><br><br>The point of =
language design isn&#39;t to come up with the most compact syntax.<br>It&#3=
9;s to have a syntax that makes code lucid to its readers.</div></div></div=
></blockquote><div><br></div><div>Verbosity should not be ignored. The more=
 verbose a feature is, the less likely that it will be used. Adding `concep=
t` to such a declaration changes nothing about it. It doesn&#39;t disambigu=
ate anything to the compiler (which is perfectly capable of telling the dif=
ference between a type concept and a value concept); it exists <i>solely</i=
> for the user.</div><div><br></div><div>I&#39;m not saying that &quot;luci=
dity&quot; is unimportant. But you can&#39;t just say &quot;let&#39;s make =
everything take twice as long to say, even if 99% of the time it would be o=
bvious what&#39;s going on without the extra verbage&quot;.</div><div><br><=
/div><div>C could have introduced a `function` keyword when declaring funct=
ions. But... why bother? It&#39;s not like the compiler needs the extra key=
word there. So why have one? Similarly, it could have had a keyword when de=
claring variables. Again, what&#39;s the point? The compiler doesn&#39;t ne=
ed it.</div><div><br></div><div>Oh yes, such keywords would have disambigua=
te C++&#39;s Most Vexing Parse, but that was C++&#39;s fault, not C&#39;s f=
ault. And even then, 99% of the time, the syntax is not ambiguous.</div><di=
v><br></div><div>Adding a feature that only matters in 1% of the cases, but=
 has to be used in 100% of the cases, is just bad syntax.<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 c=
lass=3D"gmail_quote"><div>=C2=A0 So by analogy,</div><div><br><font face=3D=
"monospace, monospace">template &lt;concept Sortable S&gt;<br>void sort(S &=
amp;s);</font></div><div><font face=3D"monospace, monospace"><br></font>wou=
ld be the way to go.<br><br>And as to your point on lambdas, they definitel=
y should have had a keyword introducer,<br>(<font face=3D"monospace, monosp=
ace">lambda</font> is good!) and trailing return types should have been int=
roduced by <font face=3D"monospace, monospace">return</font>, not<br>by <fo=
nt face=3D"monospace, monospace">-&gt;</font>.=C2=A0 Among other things, th=
e reluctance to break old syntax is causing new features<br>to be expressed=
 as gibberish.<br></div></div></div></blockquote><div><br></div><div>Things=
 are gibberish only until they&#39;re not. A new language appears to be gib=
berish until you get used to its rules and proclivities.</div><div><br></di=
v><div>C++ does not need to be readable by non-C++ programmers.<br></div><b=
r></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/e3e7f9fa-2b55-4e7f-8af4-08e677fe6572%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e3e7f9fa-2b55-4e7f-8af4-08e677fe6572=
%40isocpp.org</a>.<br />

------=_Part_24720_1500855846.1529423978136--

------=_Part_24719_1258950237.1529423978136--

.

On 06/19/18 18:55, Andrey Semashev wrote:
> On 06/19/18 17:41, Hyman Rosen wrote:
>> On Tue, Jun 19, 2018 at 5:33 AM <mihailnajdenov@gmail.com=20
>> <mailto:mihailnajdenov@gmail.com>> wrote:
>>
>> =C2=A0=C2=A0=C2=A0 OK, right now in flight are about FOUR proposals, try=
ing to
>> =C2=A0=C2=A0=C2=A0 "simplify" and "make more clear" concepts usage.
>> =C2=A0=C2=A0=C2=A0 This is madness. It is madness, because NONE of it ma=
ke it more
>> =C2=A0=C2=A0=C2=A0 clear! None.
>> I agree with you, but I think there's one piece of new syntax that is OK=
..
>> To wit:
>>
>> =C2=A0=C2=A0=C2=A0 For Simple cases
>> =C2=A0=C2=A0=C2=A0 template<Sortable S>
>> =C2=A0=C2=A0=C2=A0 void sort(S& s);
>>
>> I don't like this.=C2=A0 I think it overlaps too much with non-type=20
>> parameters.
>=20
> As long as the compiler is able to see what Sortable is, there is no=20
> problem in disambiguating it. A human may not be able to deduce it at=20
> once, but either the naming or the use of the identifier will give a=20
> clue. For example, in your declaration S is used as a type in the=20
> arguments list, so it is clearly not a value and Sortable cannot be an=20
> enum or a typedef of an integral type.
>=20
>> =C2=A0 I would prefer
>>
>> void sort(auto<Sortable>& s);
>=20
> I don't like this as it replaces the existing syntax of template=20
> declaration with a new one.
>=20
>> 1) The angle brackets signal that templates are involved.
>=20
> Yes, but not in the way they should. This is a syntax of template=20
> specialization, not a template declaration, which always starts with the=
=20
> keyword `template`. Well, except for lambdas, but they are sufficiently=
=20
> alien already.
>=20
>> 2) The auto signals that the compiler is deducing something.
>> 3) The keyword followed by a name in angle brackets signal that
>> something is being constrained; it almost has the feeling of a cast.
>=20
> The contents of angle brackets so far denoted template arguments. With=20
> your new syntax, it is something else entirely.

Also, one important feature of the `template` header is that it gives=20
names to the template arguments. With your proposed syntax, the name is=20
not given and one has to resort to decltype hacks. And the hacks don't=20
even help if the return type is declared like this.

--=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/1c65dfd5-68c3-f710-139b-342ea3acb16a%40gmail.com=
..

.

On Tuesday, 19 June 2018 08:59:38 PDT Nicol Bolas wrote:
> C could have introduced a `function` keyword when declaring functions.
> But... why bother? It's not like the compiler needs the extra keyword
> there. So why have one? Similarly, it could have had a keyword when
> declaring variables. Again, what's the point? The compiler doesn't need it.

Uh... it *did* have a keyword for variables. It was "auto". Sure, it was a
legacy of B, which did not have types and only had storage keywords.

It was removed because it provided no extra information to anyone. The only
place you could use it, its meaning was already implied. That's almost like
the "extern" keyword, which in almost all cases where it can be used (in C++),
its meaning is implied. And the place where it can be used where it changes
meaning, you shouldn't use it because it leads to incompatible behaviour
between compilers.

So I'm with you that adding "concept" there is a nuisance. It would be another
"typename", where the compiler knows what you meant, but tells you to change
it anyway. So the only reason to have it would be if some compiler needs the
disambiguation.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/3028730.Gi6nTnzGuy%40tjmaciei-mobl1.

.

------=_Part_24858_1002128820.1529425957398
Content-Type: multipart/alternative;
 boundary="----=_Part_24859_2135629466.1529425957398"

------=_Part_24859_2135629466.1529425957398
Content-Type: text/plain; charset="UTF-8"



On Tuesday, June 19, 2018 at 5:49:49 PM UTC+3, Nicol Bolas wrote:
>
>
>
> On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, mihailn...@gmail.com wrote:
>>
>> OK, right now in flight are about FOUR proposals, trying to "simplify"
>> and "make more clear" concepts usage.
>>
>> This is madness. It is madness, because NONE of it make it more clear!
>> None.
>>
>> By inviting new language constructs one does not make things "more
>> clear", it only adds more things to learn.
>>
>> The worst part is - *we have working solution that is clear. Granted
>> verbose, but clear. *
>>
>> If one makes it Not verbose but Not clear (not self-explanatory, need
>> learning) also one gains nothing!
>>
>
> Clarity is ultimately a measure of time. Variadic templates are not
> "clear" to people who've never seen them. UDLs are not "clear" to people
> who've never seen them. Lambdas are not "clear" to people who've never seen
> them. Structured bindings are not "clear" to people who've never seen them.
> And God knows rvalue references and forwarding references would utterly
> baffle people who've never seen them.
>
> All of these things are clear to us now because we are *used to them*.
> That's the only reason why they are clear. Your hypothetical time traveler
> from the C++98/03 days would be confused by the simplest of modern C++11
> code.
>
> And that's OK.
>

But the problem is *we have* syntax that is clear to old user, even if it
is new!


>
> Saying that a syntax is wrong just because we're not used to it is not
> helpful. It's far more useful to look at things from a cost/benefit
> analysis.
>
> Lambdas are probably the best example, because they don't do *anything*
> that you couldn't do yourself, either with in-situ struct declarations or
> out-of-function declarations. So their benefit is purely convenience.
>
> Lambdas have a *huge* syntactic cost. They have novel introduction
> syntax, re-appropriating something that looks like an array into a
> function/class declaration. They are functions that can be declared without
> parameters, without even `()`. They deduce the return value unless you
> specify otherwise. They allow `auto` in parameter lists. They can capture
> values/expressions in a myriad of ways. And so forth.
>
> All of this represents a syntactic variance relative to regular functions.
> And thus, it is a burden, a cost for entry that people have to learn.
>
> But all of those costs pale into insignificance next to the *gains* from
> the syntax. Lambdas are game-changers for C++. Pre-C++11, people would
> avoid simple algorithms like `transform`, because writing out the
> equivalent code was often easier than providing a functor. That's no longer
> the case.
>

> Now, I'm not saying that any of the terse syntaxes are as valuable as
> lambdas are. But my point is that novel syntax should not be avoided simply
> because it is novel; you *have* to look at the benefits of it.
>



'requires' is the similar of lambdas; in place of the enable_if magic. It
is new syntax, yet clear.




>
> This is the reason why I hate concept introduction syntax. It's not that
> it has novel syntax; it's that the novel syntax doesn't buy much. Yes,
> concept introduction is shorter than the full `requires` clause. But it's
> not shorter *enough* in enough cases to be worth the syntactic burden.
>

I agree 100% obviously.


>
> The nice thing about Herb's syntax is how regular it is. It works the same
> everywhere. It provides the same benefit everywhere. It may be novel
> syntax, but it solves many problems due to its regularity. It allows you to
> concisely fairly obvious things.
>

Sorry, but that syntax is literally taking the hated introduction syntax
and splatting it all over the entire Concepts proposal just to be
"consistent"!
And it is syntax for the sake of syntax because it is not technically
needed - no problem to be solved.

And, as said it has nasty problems, from the fact it is not obvious in *any*
way, to the metal overlap with initialization.

Number{} x;
x = Number{};

And again NO PROBLEM NEEDS SOLVING! None.


>
> Now, you may argue that no terse syntax is worth the syntactic burden. I
> rather disagree: there are too many cases where the function parameters and
> template parameters match each other to say that making that function
> declaration shorter isn't worth the time and effort. Applying concepts to
> variables, even function parameters, makes too much sense to not be worth
> pursuing.
>

Ok, however these are "nice" and nice things can wait, there is no pressing
issue here!
Second, in 10+ years the results ARE WORSE. All of them!
Third the real community is still to have its say. Any additional syntax
should wait for the real feedback and the real requirements.

To be specific they are worse because they try to do things inline instead
of laying them out separately. Its like not having typdef and we are
forced  to always use complex types inline
Consider the decades old example unsinged int. We have typedef for it uint.
Done.

It is exactly the same here. People will *always* want "one thing" as "the
type" and any decorations will be a chore.

Second sin is inviting syntax not for the compiler, but the user. This is
not only not needed - tools (in that case simple coloring) and conventions
cover that perfectly - but creates visual load for information which might
not be immediately needed.
And type/concept information is often exactly that type of information,
that's why auto is so successful.
Code logic is often independent of type and if one wants to focus on it,
the visual noise is just that - noise.
Now, if one wants to focus on the types - ctrl-click and go to definition
and see if it is a class or a concept, study it in isolation. No need to
flood regular core logic with million type nuances and decorations.


Sill - was there ever before a syntax added just for humans and not the
compiler?


--
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/a1ae0248-5af7-40b9-abcf-9f8c9e2c761e%40isocpp.org.

------=_Part_24859_2135629466.1529425957398
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, June 19, 2018 at 5:49:49 PM UTC+3, Nic=
ol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><br><br>On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, <a>mihailn...@gmai=
l.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>OK, right now in flight are about FOUR proposals, trying to &quot;simpli=
fy&quot; and &quot;make more clear&quot; concepts usage.</div><div><br></di=
v><div>This is madness. It is madness, because NONE of it make it more clea=
r! None.=C2=A0</div><div><br></div><div>By inviting new language constructs=
 one does not make things &quot;more clear&quot;, it only adds more things =
to learn.</div><div><br></div><div>The worst part is - <i>we have working s=
olution that is clear. Granted verbose, but clear.=C2=A0</i></div><div><i><=
/i><br></div><div>If one makes it Not verbose but Not clear (not self-expla=
natory, need learning) also one gains nothing!</div></div></blockquote><div=
><br></div><div>Clarity is ultimately a measure of time. Variadic templates=
 are not &quot;clear&quot; to people who&#39;ve never seen them. UDLs are n=
ot &quot;clear&quot; to people who&#39;ve never seen them. Lambdas are not =
&quot;clear&quot; to people who&#39;ve never seen them. Structured bindings=
 are not &quot;clear&quot; to people who&#39;ve never seen them. And God kn=
ows rvalue references and forwarding references would utterly baffle people=
 who&#39;ve never seen them.</div><div><br></div><div>All of these things a=
re clear to us now because we are <i>used to them</i>. That&#39;s the only =
reason why they are clear. Your hypothetical time traveler from the C++98/0=
3 days would be confused by the simplest of modern C++11 code.</div><div><b=
r></div><div>And that&#39;s OK.</div></div></blockquote><div><br></div><div=
>But the problem is <i>we have</i> syntax that is clear to old user, even i=
f it is new!</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><br></div><div>Saying that a syntax is wrong ju=
st because we&#39;re not used to it is not helpful. It&#39;s far more usefu=
l to look at things from a cost/benefit analysis.</div><div><br></div><div>=
Lambdas are probably the best example, because they don&#39;t do <i>anythin=
g</i> that you couldn&#39;t do yourself, either with in-situ struct declara=
tions or out-of-function declarations. So their benefit is purely convenien=
ce.<br></div><div><br></div><div>Lambdas have a <i>huge</i> syntactic cost.=
 They have novel introduction syntax, re-appropriating something that looks=
 like an array into a function/class declaration. They are functions that c=
an be declared without parameters, without even `()`. They deduce the retur=
n value unless you specify otherwise. They allow `auto` in parameter lists.=
 They can capture values/expressions in a myriad of ways. And so forth.</di=
v><div><br></div><div>All of this represents a syntactic variance relative =
to regular functions. And thus, it is a burden, a cost for entry that peopl=
e have to learn.</div><div><br></div><div>But all of those costs pale into =
insignificance next to the <i>gains</i> from the syntax. Lambdas are game-c=
hangers for C++. Pre-C++11, people would avoid simple algorithms like `tran=
sform`, because writing out the equivalent code was often easier than provi=
ding a functor. That&#39;s no longer the case.=C2=A0</div></div></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></=
div><div>Now, I&#39;m not saying that any of the terse syntaxes are as valu=
able as lambdas are. But my point is that novel syntax should not be avoide=
d simply because it is novel; you <i>have</i> to look at the benefits of it=
..</div></div></blockquote><div><br></div><div>=C2=A0</div><div><br></div><d=
iv><span style=3D"display: inline !important; float: none; background-color=
: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot=
;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font-vari=
ant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-ali=
gn: left; text-decoration: none; text-indent: 0px; text-transform: none; -w=
ebkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">&#39=
;requires&#39; is the similar of lambdas; in place of the enable_if magic. =
It is new syntax, yet clear.</span></div><div><br></div><div><br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><br></div><div>This is the reason why I hate concept introduction synt=
ax. It&#39;s not that it has novel syntax; it&#39;s that the novel syntax d=
oesn&#39;t buy much. Yes, concept introduction is shorter than the full `re=
quires` clause. But it&#39;s not shorter <i>enough</i> in enough cases to b=
e worth the syntactic burden.</div></div></blockquote><div><br></div><div>I=
 agree 100% obviously.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>The nice thing ab=
out Herb&#39;s syntax is how regular it is. It works the same everywhere. I=
t provides the same benefit everywhere. It may be novel syntax, but it solv=
es many problems due to its regularity. It allows you to concisely fairly o=
bvious things.</div></div></blockquote><div><br></div><div>Sorry, but that =
syntax is literally taking the hated introduction syntax and splatting it a=
ll over the entire Concepts proposal just to be &quot;consistent&quot;!</di=
v><div>And it is syntax for the sake of syntax because it is not technicall=
y needed - no problem to be solved.=C2=A0</div><div><br></div><div>And, as =
said it has nasty problems, from the fact it is not obvious in <i>any</i> w=
ay, to the metal overlap with initialization.</div><div><br></div><div><fon=
t face=3D"courier new,monospace">Number{} x;</font></div><div><font face=3D=
"courier new,monospace">x =3D Number{};</font></div><div><font face=3D"cour=
ier new,monospace"></font><br></div><div>And again NO PROBLEM NEEDS SOLVING=
! None.=C2=A0</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><br></div><div>Now, you may argue that no terse=
 syntax is worth the syntactic burden. I rather disagree: there are too man=
y cases where the function parameters and template parameters match each ot=
her to say that making that function declaration shorter isn&#39;t worth th=
e time and effort. Applying concepts to variables, even function parameters=
, makes too much sense to not be worth pursuing.<br></div></div></blockquot=
e><div><br></div><div>Ok, however these are &quot;nice&quot; and nice thing=
s can wait, there is no pressing issue here!</div><div>Second, in 10+ years=
 the results ARE WORSE. All of them!=C2=A0</div><div>Third the real communi=
ty is still to have its say. Any additional syntax should wait for the real=
 feedback and the real requirements.=C2=A0</div><div><br></div><div>To be s=
pecific they are worse because they try to do things inline instead of layi=
ng them out separately. Its like not having typdef and we are forced=C2=A0 =
to always use complex types inline<br></div><div>Consider the decades old e=
xample <font face=3D"courier new,monospace">unsinged int</font>. We have ty=
pedef for it <font face=3D"courier new,monospace">uint</font>. Done.=C2=A0<=
/div><div><br></div><div>It is exactly the same here. People will <i>always=
</i> want &quot;one thing&quot; as &quot;the type&quot; and any decorations=
 will be a chore.<br></div><div><br></div><div>Second sin is inviting synta=
x not for the compiler, but the user. This is not only not needed - tools (=
in that case simple coloring) and conventions cover that perfectly - but cr=
eates visual load for information which might not be immediately needed.=C2=
=A0</div><div>And type/concept information is often exactly that type of in=
formation, that&#39;s why auto is so successful.=C2=A0</div><div>Code logic=
 is often independent of type and if one wants to focus on it, the visual n=
oise is just that - noise.</div><div>Now, if one wants to focus on the type=
s - ctrl-click and go to definition and see if it is a class or a concept, =
study it in isolation. No need to flood regular core logic with million typ=
e nuances and decorations.=C2=A0</div><div><br></div><div><br></div><div>Si=
ll - was there ever before a syntax added just for humans and not the compi=
ler?</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&quot; 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/a1ae0248-5af7-40b9-abcf-9f8c9e2c761e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a1ae0248-5af7-40b9-abcf-9f8c9e2c761e=
%40isocpp.org</a>.<br />

------=_Part_24859_2135629466.1529425957398--

------=_Part_24858_1002128820.1529425957398--

.

--000000000000b9f181056f015564
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 19, 2018 at 12:12 PM Thiago Macieira <thiago@macieira.org>
wrote:

> So I'm with you that adding "concept" there is a nuisance. It would be
> another
> "typename", where the compiler knows what you meant, but tells you to
> change
> it anyway. So the only reason to have it would be if some compiler needs
> the
> disambiguation.
>

The reason to have it is to make the code more readable and understandable
to
people. In Ada, statements are terminated to match their beginnings.  One
writes

*if* *condition* *then* *statements* *end if;*
MyLoop: *while* *condition* *loop* *statements* *end loop* MyLoop;

Now, the compiler has no need for the tokens after *end*.  But the people
reading the
code find it useful to see them, so Ada has them.

The notion that one should design languages to minimize characters typed was
ridiculous back in the day when Ada designers had C's bad examples, and
it's still
ridiculous.

--
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/CAHSYqdb8khOxj0kjHDbMupg_qaCO6E4OigXSJyfWggH7Cs6_NA%40mail.gmail.com.

--000000000000b9f181056f015564
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 19=
, 2018 at 12:12 PM Thiago Macieira &lt;<a href=3D"mailto:thiago@macieira.or=
g">thiago@macieira.org</a>&gt; wrote:</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I&#39;m with you that adding &quot;concept&quot; there is a nuisance. It=
 would be another <br>
&quot;typename&quot;, where the compiler knows what you meant, but tells yo=
u to change <br>
it anyway. So the only reason to have it would be if some compiler needs th=
e <br>
disambiguation.<br></blockquote><div><br>The reason to have it is to make t=
he code more readable and understandable to<br>people. In Ada, statements a=
re terminated to match their beginnings.=C2=A0 One writes<br><br><font face=
=3D"monospace, monospace"><b>if</b></font> <i>condition</i> <font face=3D"m=
onospace, monospace"><b>then</b></font> <i>statements</i> <font face=3D"mon=
ospace, monospace"><b>end if;</b></font><br><font face=3D"monospace, monosp=
ace">MyLoop: <b>while</b></font> <i>condition</i> <b><font face=3D"monospac=
e, monospace">loop</font></b> <i>statements</i> <b style=3D"font-family:mon=
ospace,monospace">end loop</b><font face=3D"monospace, monospace"> MyLoop;<=
/font><br><br><font face=3D"arial, helvetica, sans-serif">Now, the compiler=
 has no need for the tokens after </font><font face=3D"monospace, monospace=
"><b>end</b></font><font face=3D"arial, helvetica, sans-serif">.=C2=A0 But =
the people reading the<br>code find it useful to see them, so Ada has them.=
<br><br>The notion that one should design languages to minimize characters =
typed was<br>ridiculous back in the day when Ada designers had C&#39;s bad =
examples, and it&#39;s still<br>ridiculous.</font></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAHSYqdb8khOxj0kjHDbMupg_qaCO6E4OigXS=
JyfWggH7Cs6_NA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdb8khOxj0kj=
HDbMupg_qaCO6E4OigXSJyfWggH7Cs6_NA%40mail.gmail.com</a>.<br />

--000000000000b9f181056f015564--

.

--00000000000010a38e056f015753
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 19, 2018 at 4:59 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, June 19, 2018 at 11:24:59 AM UTC-4, Hyman Rosen wrote:
>>
>> On Tue, Jun 19, 2018 at 10:52 AM Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Tuesday, June 19, 2018 at 10:41:23 AM UTC-4, Hyman Rosen wrote:
>>>>
>>>> I don't like this.  I think it overlaps too much with non-type
>>>> parameters.
>>>>
>>>
>>> Yes, it does overlap with them. But since type parameters are *by far*
>>> the most prevalent, let's give them the synatx they deserve.
>>>
>>
>> Type parameters are by far the most prevalent, yet we nevertheless call
>> them out as such:
>> template <typename SumType, typename Iter>
>> SumType accumulate(Iter begin, Iter end, SumType init);
>>
>> The point of language design isn't to come up with the most compact
>> syntax.
>> It's to have a syntax that makes code lucid to its readers.
>>
>
> Verbosity should not be ignored. The more verbose a feature is, the less
> likely that it will be used. Adding `concept` to such a declaration changes
> nothing about it. It doesn't disambiguate anything to the compiler (which
> is perfectly capable of telling the difference between a type concept and a
> value concept); it exists *solely* for the user.
>
> I'm not saying that "lucidity" is unimportant. But you can't just say
> "let's make everything take twice as long to say, even if 99% of the time
> it would be obvious what's going on without the extra verbage".
>
> C could have introduced a `function` keyword when declaring functions.
> But... why bother? It's not like the compiler needs the extra keyword
> there. So why have one? Similarly, it could have had a keyword when
> declaring variables. Again, what's the point? The compiler doesn't need it.
>
> Oh yes, such keywords would have disambiguate C++'s Most Vexing Parse, but
> that was C++'s fault, not C's fault. And even then, 99% of the time, the
> syntax is not ambiguous.
>
> Adding a feature that only matters in 1% of the cases, but has to be used
> in 100% of the cases, is just bad syntax.
>
>   So by analogy,
>>
>> template <concept Sortable S>
>> void sort(S &s);
>>
>> would be the way to go.
>>
>> And as to your point on lambdas, they definitely should have had a
>> keyword introducer,
>> (lambda is good!) and trailing return types should have been introduced
>> by return, not
>> by ->.  Among other things, the reluctance to break old syntax is
>> causing new features
>> to be expressed as gibberish.
>>
>
> Things are gibberish only until they're not. A new language appears to be
> gibberish until you get used to its rules and proclivities.
>
> C++ does not need to be readable by non-C++ programmers.
>


Of course it does, otherwise nobody will bother to learn it and it'll go
the way of cobol and perl.
It's not like C++ lets people build enterprise-level apps easily as it is,
let's not put another hurdle in front of would-be developers.

--
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/CAFQaeCCpDKziYG9nZgSi80YTcm-JtmiXaSqYdOnzY6r_TDAWZw%40mail.gmail.com.

--00000000000010a38e056f015753
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Jun 19, 2018 at 4:59 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On T=
uesday, June 19, 2018 at 11:24:59 AM UTC-4, Hyman Rosen wrote:<span><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 class=3D"gmail_quote=
"><div dir=3D"ltr">On Tue, Jun 19, 2018 at 10:52 AM Nicol Bolas &lt;<a rel=
=3D"nofollow">jmck...@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">On Tuesday, June 19, 2018 at 10:41:23 AM UTC=
-4, Hyman Rosen wrote:<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 class=3D"gmail_quote"><div>I don&#39;t like this.=C2=A0 I think it=
 overlaps too much with non-type parameters.</div></div></div></blockquote>=
<div><br></div><div>Yes, it does overlap with them. But since type paramete=
rs are <i>by far</i> the most prevalent, let&#39;s give them the synatx the=
y deserve.</div></div></blockquote><div><br>Type parameters are by far the =
most prevalent, yet we nevertheless call them out as such:<br><font face=3D=
"monospace, monospace">template &lt;typename SumType, typename Iter&gt;<br>=
SumType accumulate(Iter begin, Iter end, SumType init);</font><br><br>The p=
oint of language design isn&#39;t to come up with the most compact syntax.<=
br>It&#39;s to have a syntax that makes code lucid to its readers.</div></d=
iv></div></blockquote><div><br></div></span><div>Verbosity should not be ig=
nored. The more verbose a feature is, the less likely that it will be used.=
 Adding `concept` to such a declaration changes nothing about it. It doesn&=
#39;t disambiguate anything to the compiler (which is perfectly capable of =
telling the difference between a type concept and a value concept); it exis=
ts <i>solely</i> for the user.</div><div><br></div><div>I&#39;m not saying =
that &quot;lucidity&quot; is unimportant. But you can&#39;t just say &quot;=
let&#39;s make everything take twice as long to say, even if 99% of the tim=
e it would be obvious what&#39;s going on without the extra verbage&quot;.<=
/div><div><br></div><div>C could have introduced a `function` keyword when =
declaring functions. But... why bother? It&#39;s not like the compiler need=
s the extra keyword there. So why have one? Similarly, it could have had a =
keyword when declaring variables. Again, what&#39;s the point? The compiler=
 doesn&#39;t need it.</div><div><br></div><div>Oh yes, such keywords would =
have disambiguate C++&#39;s Most Vexing Parse, but that was C++&#39;s fault=
, not C&#39;s fault. And even then, 99% of the time, the syntax is not ambi=
guous.</div><div><br></div><div>Adding a feature that only matters in 1% of=
 the cases, but has to be used in 100% of the cases, is just bad syntax.<br=
></div><span><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_quote"><div>=C2=A0 So by analogy,</div><div><=
br><font face=3D"monospace, monospace">template &lt;concept Sortable S&gt;<=
br>void sort(S &amp;s);</font></div><div><font face=3D"monospace, monospace=
"><br></font>would be the way to go.<br><br>And as to your point on lambdas=
, they definitely should have had a keyword introducer,<br>(<font face=3D"m=
onospace, monospace">lambda</font> is good!) and trailing return types shou=
ld have been introduced by <font face=3D"monospace, monospace">return</font=
>, not<br>by <font face=3D"monospace, monospace">-&gt;</font>.=C2=A0 Among =
other things, the reluctance to break old syntax is causing new features<br=
>to be expressed as gibberish.<br></div></div></div></blockquote><div><br><=
/div></span><div>Things are gibberish only until they&#39;re not. A new lan=
guage appears to be gibberish until you get used to its rules and proclivit=
ies.</div><div><br></div><div>C++ does not need to be readable by non-C++ p=
rogrammers.<br></div></div></blockquote><div>=C2=A0</div><div><br></div><di=
v>Of course it does, otherwise nobody will bother to learn it and it&#39;ll=
 go the way of cobol and perl.</div><div>It&#39;s not like C++ lets people =
build enterprise-level apps easily as it is, let&#39;s not put another hurd=
le in front of would-be developers.</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&quot; 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/CAFQaeCCpDKziYG9nZgSi80YTcm-JtmiXaSqY=
dOnzY6r_TDAWZw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCCpDKziYG9n=
ZgSi80YTcm-JtmiXaSqYdOnzY6r_TDAWZw%40mail.gmail.com</a>.<br />

--00000000000010a38e056f015753--

.

--000000000000e293e5056f01654e
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 19, 2018 at 12:32 PM <mihailnajdenov@gmail.com> wrote:

> Sill - was there ever before a syntax added just for humans and not the
> compiler?
>

There certainly was in Ada, as I just posted in another message:

MyLoop: *while* *condition* *loop* *statements* *end loop* MyLoop;

The extra tokens after *end* are there for humans. The compiler would be
fine without them.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ1OnTHivKNh_x%2BhZd6zYOiFxK3yrhVP0oX65rzUDpBFA%40mail.gmail.com.

--000000000000e293e5056f01654e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 19=
, 2018 at 12:32 PM &lt;<a href=3D"mailto:mihailnajdenov@gmail.com">mihailna=
jdenov@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>Sill - was there ever before a syntax added just for humans =
and not the compiler?</div></div></blockquote><div><br>There certainly was =
in Ada, as I just posted in another message:<br><br><font face=3D"monospace=
, monospace">MyLoop: <b>while</b> </font><font face=3D"arial, helvetica, sa=
ns-serif"><i>condition</i></font><font face=3D"monospace, monospace"> <b>lo=
op</b> </font><font face=3D"arial, helvetica, sans-serif"><i>statements</i>=
</font><font face=3D"monospace, monospace"> <b>end loop</b> MyLoop;<br></fo=
nt><br>The extra tokens after <font face=3D"monospace, monospace"><b>end</b=
></font> are there for humans. The compiler would be fine without them.</di=
v></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAHSYqdZ1OnTHivKNh_x%2BhZd6zYOiFxK3yr=
hVP0oX65rzUDpBFA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ1OnTHiv=
KNh_x%2BhZd6zYOiFxK3yrhVP0oX65rzUDpBFA%40mail.gmail.com</a>.<br />

--000000000000e293e5056f01654e--

.

On 06/19/18 19:39, Hyman Rosen wrote:
> On Tue, Jun 19, 2018 at 12:12 PM Thiago Macieira <thiago@macieira.org=20
> <mailto:thiago@macieira.org>> wrote:
>=20
>     So I'm with you that adding "concept" there is a nuisance. It would
>     be another
>     "typename", where the compiler knows what you meant, but tells you
>     to change
>     it anyway. So the only reason to have it would be if some compiler
>     needs the
>     disambiguation.
>=20
>=20
> The reason to have it is to make the code more readable and=20
> understandable to
> people. In Ada, statements are terminated to match their beginnings. =20
> One writes
>=20
> *if* /condition/ *then* /statements/ *end if;*
> MyLoop: *while* /condition/ *loop* /statements/ *end loop* MyLoop;
>=20
> Now, the compiler has no need for the tokens after *end*.=C2=A0 But the=
=20
> people reading the
> code find it useful to see them, so Ada has them.

I think, comments already fill the role for such superfluous tokens=20
quite nicely.

--=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/540cb318-b4fe-fdaa-c440-2aacba18708c%40gmail.com=
..

.

On Tuesday, 19 June 2018 09:39:55 PDT Hyman Rosen wrote:
> The notion that one should design languages to minimize characters typed was
> ridiculous back in the day when Ada designers had C's bad examples, and
> it's still ridiculous.

I don't think the issue is the to save a few characters typed, but to create a
consistent and understandable language, one that can be taught.

I remember when I didn't understand the "typename" rule, as compilers about 10
years ago weren't good at enforcing it. My rule was, "if the compiler
complains while compiling templates, add 'typename'".

But I don't think it's even that, here. The keyword usage would be consistent.

This is a subjective call, a judgement one. The argument is that the "concept"
keyword in that position does not add any value, since it was already
understood by the developer what was meant. I agree with that, since you solve
this with naming conventions: concepts are adjectives (usually ending in
-able), concrete types are nouns.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/2272327.1bto6UkvEM%40tjmaciei-mobl1.

.

--0000000000002a1e83056f018208
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 19, 2018 at 12:50 PM Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> I think, comments already fill the role for such superfluous tokens quite
> nicely.
>

Only if they're required.

--
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/CAHSYqdaSdSkeAJo59O4GpmtAZapEv%3DxdWVEOfEnf2-WkooZaEQ%40mail.gmail.com.

--0000000000002a1e83056f018208
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 19=
, 2018 at 12:50 PM Andrey Semashev &lt;<a href=3D"mailto:andrey.semashev@gm=
ail.com">andrey.semashev@gmail.com</a>&gt; wrote:</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
I think, comments already fill the role for such superfluous tokens quite n=
icely.<br></blockquote><div><br>Only if they&#39;re required.=C2=A0</div></=
div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAHSYqdaSdSkeAJo59O4GpmtAZapEv%3DxdWV=
EOfEnf2-WkooZaEQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaSdSkeAJ=
o59O4GpmtAZapEv%3DxdWVEOfEnf2-WkooZaEQ%40mail.gmail.com</a>.<br />

--0000000000002a1e83056f018208--

.

--0000000000007f888b056f01a3bb
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 19, 2018 at 12:52 PM Thiago Macieira <thiago@macieira.org>
wrote:

> This is a subjective call, a judgement one. The argument is that the
> "concept"
> keyword in that position does not add any value, since it was already
> understood by the developer what was meant. I agree with that, since you
> solve
> this with naming conventions: concepts are adjectives (usually ending in
> -able), concrete types are nouns.
>

This is rather akin to saying that published books should be written in
shorthand.
Human language is full of fillips and redundancies that guide readers
toward more
easily understanding what is being communicated.  Programming languages are
used to control the operations of computers, but they are meant for humans
to read
and write, and should therefore contain the literary features that will
enhance that.

The "added value" is that the eye is drawn to the concept keyword, and the
brain
says, "ah, that is the name of a concept".  It reduces the cognitive load
on the reader.

--
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/CAHSYqdZbuJRFpXZdfmEKk9wPnmGw9W-GVCeS7cuOkZdaMA-Opw%40mail.gmail.com.

--0000000000007f888b056f01a3bb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 19=
, 2018 at 12:52 PM Thiago Macieira &lt;<a href=3D"mailto:thiago@macieira.or=
g">thiago@macieira.org</a>&gt; wrote:</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is a subjective call, a judgement one. The argument is that the &quot;=
concept&quot; <br>
keyword in that position does not add any value, since it was already <br>
understood by the developer what was meant. I agree with that, since you so=
lve <br>
this with naming conventions: concepts are adjectives (usually ending in <b=
r>
-able), concrete types are nouns.<br></blockquote><div><br>This is rather a=
kin to saying that published books should be written in shorthand.<br>Human=
 language is full of fillips and redundancies that guide readers toward mor=
e<br>easily understanding what is being communicated.=C2=A0 Programming lan=
guages are<br>used to control the operations of computers, but they are mea=
nt for humans to read<br>and write, and should therefore contain the litera=
ry features that will enhance that.<br><br>The &quot;added value&quot; is t=
hat the eye is drawn to the <font face=3D"monospace, monospace">concept</fo=
nt> keyword, and the brain<br>says, &quot;ah, that is the name of a concept=
&quot;.=C2=A0 It reduces the cognitive load on the reader.</div></div></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAHSYqdZbuJRFpXZdfmEKk9wPnmGw9W-GVCeS=
7cuOkZdaMA-Opw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZbuJRFpXZd=
fmEKk9wPnmGw9W-GVCeS7cuOkZdaMA-Opw%40mail.gmail.com</a>.<br />

--0000000000007f888b056f01a3bb--

.

On Tuesday, 19 June 2018 10:01:40 PDT Hyman Rosen wrote:
> The "added value" is that the eye is drawn to the concept keyword, and the
> brain
> says, "ah, that is the name of a concept".  It reduces the cognitive load
> on the reader.

I understand what you're saying. I just don't agree it's necessary.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/4838438.igvMGCH07k%40tjmaciei-mobl1.

.

--000000000000f49399056f021ee7
Content-Type: text/plain; charset="UTF-8"

Please don't call folks' proposals "madness". It both minimizes the
difficulties of folks with actual mental illnesses, and is unnecessarily
offensive to folks who have honest differences of opinion.

See also
https://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures#code-of-conduct
..

Jeffrey

On Tue, Jun 19, 2018 at 2:33 AM <mihailnajdenov@gmail.com> wrote:

> OK, right now in flight are about FOUR proposals, trying to "simplify" and
> "make more clear" concepts usage.
>
> This is madness. It is madness, because NONE of it make it more clear!
> None.
>
> By inviting new language constructs one does not make things "more clear",
> it only adds more things to learn.
>
> The worst part is - *we have working solution that is clear. Granted
> verbose, but clear. *
>
> If one makes it Not verbose but Not clear (not self-explanatory, need
> learning) also one gains nothing!
>
>
> Consider
>
> template<Iterator Iter1, Iterator Iter2>
>      requires Comparable_though_iterators<Iter1, Iter2>
> bool equal(Iter1 first, Iter1 last, Iter2)
> {}
>
> This code is *clear to ANYONE who EVER worked with C++*, even to a time
> traveler from 30 years ago!
>
> Comparable_through_iterators{Iter1,Iter2}
> bool equal(Iter1 first, Iter1 last, Iter2)
> {}
>
> This is *NOT clear*!
>
> *First* Comparable_ can be confused with a return type when one starts to
> read.
> *Second* The syntax is COMPLETELY alien to templates - de facto new
> language.
> *Third *there is no obvious connection b/w the function and the clause  -
> it just sits there like a separate declaration
> *Forth *Automatic names introductions is very uncommon and will be
> confusing for sure.
>
> The gain of one-less-line is DWARFED by the HEAP of "new stuff" that does
> NOT grant "new powers"!
>
>
>  --- Let's continue
>
>
> Between
>
> void sort(Sortable& s);
>
> and
>
> template void sort(Sortable& s);
>
> *The second is more confusing! *Why? Because it abuses an already
> established syntax for something *completely* different.
>
> Is the first confusing? Might be. What is the solution?
>
> Solution 1:
>
> If this is your code, and you might be confused - don't use it, use the
> more verbose, but more clear syntax!
>
> Solution 2:
>
> Just ctrl-click on Sortable (hell, just hover over it) and all you doubts
> will be solved!
>
>
> Inventing completely new syntax in the form of  Sortable{} is even worse:
>
> Consider
>
> Number x{};
> [](Number{} x)
> {}
> [x = Number{}]()
> {}
>
> Again, any gains are dwarfed by introducing new syntax to learn and/or new
> ways to read old constructs!
> And the biggest problem is - that syntax right now donates *an action *and
> here it will not, it will be just an indicator!
>
>
>  --- Let's continue further
>
> Another non-issue is "the problem one cannot differentiate b/w constrained
> value and a type concept"
>
> template<Concept T, Value v> void f() {}
>
> Why this is non-issue?
>
> *First* Because templates are inline, usage is visible and Types and
> Value are used RADICALLY differently.
> In real word it will *always* be clear which is which!
>
> *Second* as already mentioned in one of the papers - one can use a naming
> convection.
>
> *Third* the more verbose syntax (the a requires clause) is still
> available!
>
> And BTW lets not forget we have class template arguments now, so the
> template arguments are bound to be a bit overloaded now!
>
> template<Concept T, Value v, Class c> void f() {}
>
> Nothing wrong with that - we can use naming conventions and we have good
> IDEs to help us - no need for syntax noise.
>
>
> *The Solution To All This*
>
>
> For now, include *only* the syntax clear to a time traveler! Do not
> include ANYTHING new to learn!
>
> We are JUST introducing Concepts to the general public - *that alone is
> enough new  material!*
>
> For Simple cases
>
> template<Sortable S>
> void sort(S& s);
>
> For Complex cases
>
> template<Iterator Iter1, Iterator Iter2>
>      requires Comparable_though_iterators<Iter1, Iter2>
> bool equal(Iter1 first, Iter1 last, Iter2)
> {}
>
>       *THATS IT. DONE. *
>
> *No*
> template void sort(Sortable& s);
>
> *No*
> void sort(Sortable{}& s);
>
> *No*
> template<Arithmetic{N}, Arithmetic {} n> void f(N);
>
> *No*
> template<auto Arithmetic N> void f();
>
> *No*
> template<Comparable_through_iterators{Iter1,Iter2}>
> bool equal(Iter1 first, Iter1 last, Iter2)
> {}
>
> *And HELL No*
> Comparable_through_iterators{Iter1,Iter2}
> bool equal(Iter1 first, Iter1 last, Iter2)
> {}
>
> *Why?*
>
> *A. Because of the time traveler!!!*
>
> *B. Let the users have theirs say IN THE REAL WORD.*
>
> *C. We can ALWAYS add "simpler" syntax later, say in 5 years!*
>
>
> *Future Directions*
>
> Why not let arguments be comma separated lists if we care so much about
> typing
>
> template<class In1, In2, Out>
>    requires Mergeable<In1, In2, Out>
> Out merge(In1,In1,In2,In2,Out);
>
> Why not instead of the new syntax for names introducing we simply
>
> requires Mergeable<In1, In2, Out>
> Out merge(In1,In1,In2,In2,Out);
>
>
>
>
>
> --
> 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/19c57a60-e883-4474-b106-7ff2ebc122ee%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/19c57a60-e883-4474-b106-7ff2ebc122ee%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3Df_2eG%3D0H9zFkdOpoJXi8NtdZmqRoCcgvPxknYJvVXHA%40mail.gmail.com.

--000000000000f49399056f021ee7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Please don&#39;t call folks&#39; proposals &quot;madness&q=
uot;. It both minimizes the difficulties of folks with actual mental illnes=
ses, and is unnecessarily offensive to folks who have honest differences of=
 opinion.<div><br></div><div>See also=C2=A0<a href=3D"https://isocpp.org/st=
d/standing-documents/sd-4-wg21-practices-and-procedures#code-of-conduct">ht=
tps://isocpp.org/std/standing-documents/sd-4-wg21-practices-and-procedures#=
code-of-conduct</a>.<br><div><br></div><div>Jeffrey<br><div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 19, 2018 at 2:33 AM &lt;<a hr=
ef=3D"mailto:mihailnajdenov@gmail.com" target=3D"_blank">mihailnajdenov@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div>OK, right now in flight are about FOUR proposal=
s, trying to &quot;simplify&quot; and &quot;make more clear&quot; concepts =
usage.</div><div><br></div><div>This is madness. It is madness, because NON=
E of it make it more clear! None.=C2=A0</div><div><br></div><div>By invitin=
g new language constructs one does not make things &quot;more clear&quot;, =
it only adds more things to learn.</div><div><br></div><div>The worst part =
is - <i>we have working solution that is clear. Granted verbose, but clear.=
=C2=A0</i></div><div><i></i><br></div><div>If one makes it Not verbose but =
Not clear (not self-explanatory, need learning) also one gains nothing!=C2=
=A0</div><div><br></div><div><br></div><div>Consider</div><div><br></div><d=
iv><font face=3D"courier new,monospace">template&lt;Iterator Iter1, Iterato=
r Iter2&gt;=C2=A0</font></div><div><font face=3D"courier new,monospace">=C2=
=A0 =C2=A0=C2=A0 requires Comparable_though_iterators&lt;Iter1, Iter2&gt;</=
font></div><div><font face=3D"courier new,monospace">bool equal(Iter1 first=
, Iter1 last, Iter2)=C2=A0</font></div><div><font face=3D"courier new,monos=
pace">{}=C2=A0</font></div><div><br></div><div>This code is <b>clear to ANY=
ONE who EVER worked with C++</b>, even to a time traveler from 30 years ago=
!</div><div><br></div><div><font face=3D"courier new,monospace">Comparable_=
through_iterators{Iter1,Iter2}=C2=A0</font></div><div><font face=3D"courier=
 new,monospace">bool equal(Iter1 first, Iter1 last, Iter2)=C2=A0</font></di=
v><div><font face=3D"courier new,monospace">{}=C2=A0</font></div><div><br><=
/div><div>This is <b>NOT clear</b>!=C2=A0</div><div><br></div><div><b>First=
</b> <span style=3D"float:none;background-color:transparent;color:rgb(34,34=
,34);font-family:&quot;courier new&quot;,monospace;font-size:13px;font-styl=
e:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-ali=
gn:left;text-decoration:none;text-indent:0px;text-transform:none;white-spac=
e:normal;word-spacing:0px;display:inline">Comparable<font face=3D"&quot;Ari=
al&quot;,&quot;Helvetica&quot;,sans-serif">_</font></span> can be confused =
with a return type when one starts to read.=C2=A0</div><div><b>Second</b> T=
he syntax is COMPLETELY alien to templates - de facto new language.=C2=A0</=
div><div><b>Third </b>there is no obvious connection b/w the function and t=
he clause=C2=A0 - it just sits there like a separate declaration</div><div>=
<b>Forth </b>Automatic names introductions is very uncommon and will be con=
fusing for sure.</div><div><br></div><div>The gain of one-less-line is DWAR=
FED by the HEAP of &quot;new stuff&quot; that does NOT grant &quot;new powe=
rs&quot;!</div><div><br></div><div><br></div><div>=C2=A0--- Let&#39;s conti=
nue</div><div><br></div><div><br></div><div>Between=C2=A0</div><div><br></d=
iv><div><font face=3D"courier new,monospace">void sort(Sortable&amp; s); =
=C2=A0</font><font face=3D"courier new,monospace"><br></font></div><div><fo=
nt face=3D"courier new,monospace"><br></font></div><div><font face=3D"couri=
er new,monospace">and</font></div><div><font face=3D"courier new,monospace"=
><br></font></div><div><font face=3D"courier new,monospace">template void s=
ort(Sortable&amp; s);=C2=A0</font></div><div><font face=3D"courier new,mono=
space"><br></font></div><div><i>The second is more confusing! </i>Why? Beca=
use it abuses an already established syntax for something <i>completely</i>=
 different.=C2=A0</div><div><br></div><div>Is the first confusing? Might be=
.. What is the solution?</div><div><br></div><div>Solution 1:</div><div><br>=
</div><div>If this is your code, and you might be confused - don&#39;t use =
it, use the more verbose, but more clear syntax!</div><div><br></div><div>S=
olution 2:</div><div><br></div><div>Just ctrl-click on Sortable (hell, just=
 hover over it) and all you doubts will be solved!=C2=A0</div><div><br></di=
v><div><br></div><div>Inventing completely new syntax in the form of=C2=A0=
=C2=A0<span style=3D"float:none;background-color:transparent;color:rgb(34,3=
4,34);font-family:&quot;courier new&quot;,monospace;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;display:inline">Sortable{} <font face=3D"arial,s=
ans-serif">is even worse:</font></span></div><div><span style=3D"float:none=
;background-color:transparent;color:rgb(34,34,34);font-family:&quot;courier=
 new&quot;,monospace;font-size:13px;font-style:normal;font-variant:normal;f=
ont-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;t=
ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;disp=
lay:inline"><font face=3D"arial,sans-serif"><br></font></span></div><div><s=
pan style=3D"float:none;background-color:transparent;color:rgb(34,34,34);fo=
nt-family:&quot;courier new&quot;,monospace;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:left=
;text-decoration:none;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px;display:inline"><font face=3D"arial,sans-serif">Consider=
=C2=A0</font></span></div><div><font face=3D"times new roman,serif"><i><b><=
/b><u></u><sub></sub><sup></sup><strike></strike><b></b><u></u><sub></sub><=
sup></sup><strike></strike><font face=3D"arial,sans-serif"></font><br></i><=
/font></div><div><span style=3D"text-align:left;color:rgb(34,34,34);text-tr=
ansform:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-styl=
e:normal;font-variant:normal;font-weight:400;text-decoration:none;word-spac=
ing:0px;white-space:normal;float:none;background-color:transparent;display:=
inline"><font face=3D"courier new,monospace">Number x{};</font></span><b></=
b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><div><font=
 face=3D"courier new,monospace">[](Number{} x)=C2=A0</font></div><div><font=
 face=3D"courier new,monospace">{} </font></div><div><div>[<font face=3D"co=
urier new,monospace" style=3D"border-color:rgb(34,34,34);border-style:none;=
border-width:0px;margin:0px;padding:0px">x =3D Number{}]()</font></div><div=
><font face=3D"courier new,monospace" style=3D"border-color:rgb(34,34,34);b=
order-style:none;border-width:0px;margin:0px;padding:0px">{}=C2=A0</font><b=
r></div></div><div><font face=3D"courier new,monospace"></font><br></div><d=
iv>Again, any gains are dwarfed by introducing new syntax to learn and/or n=
ew ways to read old constructs!=C2=A0</div><div>And the biggest problem is =
- that syntax right now donates <b><i>an action</i> </b>and here it will no=
t, it will be just an indicator!=C2=A0</div><div><i></i><i></i><br></div><d=
iv><br></div><div><span style=3D"float:none;background-color:transparent;co=
lor:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:13px;fon=
t-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;te=
xt-align:left;text-decoration:none;text-indent:0px;text-transform:none;whit=
e-space:normal;word-spacing:0px;display:inline">=C2=A0--- Let&#39;s continu=
e further</span></div><div><b></b><i></i><u></u><sub></sub><sup></sup><stri=
ke></strike><br></div><div>Another non-issue is &quot;the problem one canno=
t differentiate b/w constrained value and a type concept&quot;=C2=A0</div><=
div><br></div><div><font face=3D"courier new,monospace">template&lt;Concept=
 T, Value v&gt; void f() {}</font></div><div><font face=3D"courier new,mono=
space"></font><br></div><div>Why this is non-issue?=C2=A0</div><div><br></d=
iv><div><b>First</b> Because templates are inline, usage is visible and Typ=
es and Value are used RADICALLY differently.</div><div>In real word it will=
 <i>always</i> be clear which is which!=C2=A0</div><div><br></div><div><b>S=
econd</b> as already mentioned in one of the papers - one can use a naming =
convection.</div><div><br></div><div><b>Third</b> the more verbose syntax (=
the a <font face=3D"courier new,monospace">requires</font> clause) is still=
 available!=C2=A0</div><div><b></b><b></b><br></div><div>And BTW lets not f=
orget we have class template arguments now, so the template arguments are b=
ound to be a bit overloaded now!<br></div><div><div><br></div><div><font fa=
ce=3D"courier new,monospace" style=3D"border-color:rgb(34,34,34);border-sty=
le:none;border-width:0px;margin:0px;padding:0px">template&lt;Concept T, Val=
ue v, Class c&gt; void f() {}</font></div><b></b><i></i><u></u><sub></sub><=
sup></sup><strike></strike><br></div><div>Nothing wrong with that - we can =
use naming conventions and we have good IDEs to help us - no need for synta=
x noise. =C2=A0</div><div><br></div><div><br></div><div><b>The Solution To =
All This</b></div><div><b><br></b></div><div><b><br></b></div><div>For now,=
 include <i>only</i> the syntax clear to a time traveler! Do not include AN=
YTHING new to learn!=C2=A0</div><div><br></div><div>We are JUST introducing=
 Concepts to the general public - <i>that alone is enough new=C2=A0 materia=
l!</i><br></div><div><i></i><i></i><br></div><div>For Simple cases</div><di=
v><br></div><div><span style=3D"float:none;background-color:transparent;col=
or:rgb(34,34,34);font-family:&quot;courier new&quot;,monospace;font-size:13=
px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:nor=
mal;text-align:left;text-decoration:none;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px;display:inline">template&lt;Sortable =
S&gt;=C2=A0</span></div><div><span style=3D"float:none;background-color:tra=
nsparent;color:rgb(34,34,34);font-family:&quot;courier new&quot;,monospace;=
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-t=
ransform:none;white-space:normal;word-spacing:0px;display:inline">void sort=
(S&amp; s);=C2=A0</span></div><div><span style=3D"float:none;background-col=
or:transparent;color:rgb(34,34,34);font-family:&quot;courier new&quot;,mono=
space;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;display:inline"><br=
></span></div><div><span style=3D"text-align:left;color:rgb(34,34,34);text-=
transform:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-st=
yle:normal;font-variant:normal;font-weight:400;text-decoration:none;word-sp=
acing:0px;white-space:normal;float:none;background-color:transparent;displa=
y:inline"><font face=3D"arial,sans-serif">For Complex cases</font></span></=
div><div><span style=3D"float:none;background-color:transparent;color:rgb(3=
4,34,34);font-family:&quot;courier new&quot;,monospace;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;display:inline"><font face=3D"arial,sans-seri=
f"></font><br></span></div><div><span style=3D"text-align:left;color:rgb(34=
,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-fami=
ly:&quot;courier new&quot;,monospace;font-size:13px;font-variant:normal;wor=
d-spacing:0px;white-space:normal;float:none;background-color:transparent;di=
splay:inline"><div style=3D"margin:0px;padding:0px;border:0px rgb(34,34,34)=
;text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;le=
tter-spacing:normal;font-size:13px;font-variant:normal;word-spacing:0px;whi=
te-space:normal;background-color:transparent"><span style=3D"margin:0px;pad=
ding:0px;border:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);text-=
transform:none;text-indent:0px;letter-spacing:normal;font-family:&quot;cour=
ier new&quot;,monospace;font-size:13px;font-variant:normal;word-spacing:0px=
;display:inline;white-space:normal;float:none;background-color:transparent"=
><div><font face=3D"courier new,monospace" style=3D"border-color:rgb(34,34,=
34);border-style:none;border-width:0px;margin:0px;padding:0px">template&lt;=
Iterator Iter1, Iterator Iter2&gt;=C2=A0</font></div><div><font face=3D"cou=
rier new,monospace" style=3D"border-color:rgb(34,34,34);border-style:none;b=
order-width:0px;margin:0px;padding:0px">=C2=A0 =C2=A0=C2=A0 requires Compar=
able_though_iterators&lt;Iter1, Iter2&gt;</font></div><div><font face=3D"co=
urier new,monospace" style=3D"border-color:rgb(34,34,34);border-style:none;=
border-width:0px;margin:0px;padding:0px">bool equal(Iter1 first, Iter1 last=
, Iter2)=C2=A0</font></div><div><font face=3D"courier new,monospace" style=
=3D"border-color:rgb(34,34,34);border-style:none;border-width:0px;margin:0p=
x;padding:0px">{}=C2=A0</font></div></span></div><b></b><i></i><u></u><sub>=
</sub><sup></sup><strike></strike><br></span></div><div>=C2=A0 =C2=A0 =C2=
=A0 <b>THATS IT. DONE.=C2=A0</b></div><div><b><br></b></div><div><b>No</b><=
/div><div><span style=3D"float:none;background-color:transparent;color:rgb(=
34,34,34);font-family:&quot;courier new&quot;,monospace;font-size:13px;font=
-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;tex=
t-align:left;text-decoration:none;text-indent:0px;text-transform:none;white=
-space:normal;word-spacing:0px;display:inline">template void sort(Sortable&=
amp; s);=C2=A0</span></div><div><b></b><i></i><u></u><sub></sub><sup></sup>=
<strike></strike><br></div><div><b>No</b></div><div><span style=3D"float:no=
ne;background-color:transparent;color:rgb(34,34,34);font-family:&quot;couri=
er new&quot;,monospace;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;di=
splay:inline">void sort(Sortable{}&amp; s);=C2=A0</span></div><div><span st=
yle=3D"float:none;background-color:transparent;color:rgb(34,34,34);font-fam=
ily:&quot;courier new&quot;,monospace;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;display:inline"><br></span></div><div><span style=3D"text-alig=
n:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spaci=
ng:normal;font-family:&quot;courier new&quot;,monospace;font-size:13px;font=
-variant:normal;word-spacing:0px;white-space:normal;float:none;background-c=
olor:transparent;display:inline"><div><span><div style=3D"background-color:=
transparent;border-color:rgb(34,34,34);border-style:none;border-width:0px;c=
olor:rgb(34,34,34);font-size:13px;font-style:normal;font-variant:normal;fon=
t-weight:400;letter-spacing:normal;margin:0px;padding:0px;text-align:left;t=
ext-decoration:none;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px"><span><font face=3D"arial,sans-serif" style=3D"border-col=
or:rgb(34,34,34);border-style:none;border-width:0px;margin:0px;padding:0px"=
><b style=3D"border-color:rgb(34,34,34);border-style:none;border-width:0px;=
margin:0px;padding:0px">No</b></font><font face=3D"courier new,monospace" s=
tyle=3D"border-color:rgb(34,34,34);border-style:none;border-width:0px;margi=
n:0px;padding:0px">=C2=A0</font></span><br style=3D"border-color:rgb(34,34,=
34);border-style:none;border-width:0px;margin:0px;padding:0px"></div></span=
></div><div><span style=3D"background-color:transparent;border-color:rgb(34=
,34,34);border-style:none;border-width:0px;color:rgb(34,34,34);display:inli=
ne;float:none;font-family:&quot;courier new&quot;,monospace;font-size:13px;=
font-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal=
;margin:0px;padding:0px;text-align:left;text-decoration:none;text-indent:0p=
x;text-transform:none;white-space:normal;word-spacing:0px"><b style=3D"bord=
er-color:rgb(34,34,34);border-style:none;border-width:0px;margin:0px;paddin=
g:0px"></b><i style=3D"border-color:rgb(34,34,34);border-style:none;border-=
width:0px;margin:0px;padding:0px"></i><u style=3D"border-color:rgb(34,34,34=
);border-style:none;border-width:0px;margin:0px;padding:0px"></u><sub style=
=3D"border-color:rgb(34,34,34);border-style:none;border-width:0px;margin:0p=
x;padding:0px"></sub><sup style=3D"border-color:rgb(34,34,34);border-style:=
none;border-width:0px;margin:0px;padding:0px"></sup><strike style=3D"border=
-color:rgb(34,34,34);border-style:none;border-width:0px;margin:0px;padding:=
0px"></strike>template&lt;Arithmetic{N}, Arithmetic {} n&gt; void f(N);</sp=
an><br></div></span></div><div><span style=3D"text-align:left;color:rgb(34,=
34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-size:=
13px;font-style:normal;font-variant:normal;font-weight:400;text-decoration:=
none;word-spacing:0px;white-space:normal;float:none;background-color:transp=
arent;display:inline"><font face=3D"courier new,monospace"></font><b></b><i=
></i><u></u><sub></sub><sup></sup><strike></strike><br></span></div><div><s=
pan style=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-i=
ndent:0px;letter-spacing:normal;font-size:13px;font-variant:normal;word-spa=
cing:0px;white-space:normal;float:none;background-color:transparent;display=
:inline"><div><b><font face=3D"arial,sans-serif">No</font></b></div><div><s=
pan style=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-align:lef=
t;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:no=
rmal;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;t=
ext-decoration:none;word-spacing:0px;display:inline;white-space:normal;floa=
t:none;background-color:transparent"><font face=3D"courier new,monospace">t=
emplate&lt;auto Arithmetic N&gt; void f();</font></span></div></span><div><=
span style=3D"float:none;background-color:transparent;color:rgb(34,34,34);f=
ont-family:&quot;courier new&quot;,monospace;font-size:13px;font-style:norm=
al;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:lef=
t;text-decoration:none;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px;display:inline"><br></span></div></div><div><span style=
=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px=
;letter-spacing:normal;font-size:13px;font-style:normal;font-variant:normal=
;text-decoration:none;word-spacing:0px;white-space:normal;float:none;backgr=
ound-color:transparent;display:inline"><b><font face=3D"arial,sans-serif">N=
o</font></b></span></div><div><div><font face=3D"courier new,monospace" sty=
le=3D"border-color:rgb(34,34,34);border-style:none;border-width:0px;margin:=
0px;padding:0px">template&lt;Comparable_through_iterators{Iter1,Iter2}&gt;<=
/font></div><div><font face=3D"courier new,monospace" style=3D"border-color=
:rgb(34,34,34);border-style:none;border-width:0px;margin:0px;padding:0px">b=
ool equal(Iter1 first, Iter1 last, Iter2)=C2=A0</font></div><div><font face=
=3D"courier new,monospace" style=3D"border-color:rgb(34,34,34);border-style=
:none;border-width:0px;margin:0px;padding:0px">{}=C2=A0</font></div><b></b>=
<i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><div><b>And =
HELL No</b></div><div><div><font face=3D"courier new,monospace" style=3D"bo=
rder-color:rgb(34,34,34);border-style:none;border-width:0px;margin:0px;padd=
ing:0px">Comparable_through_iterators{Iter1,Iter2}=C2=A0</font></div><div><=
font face=3D"courier new,monospace" style=3D"border-color:rgb(34,34,34);bor=
der-style:none;border-width:0px;margin:0px;padding:0px">bool equal(Iter1 fi=
rst, Iter1 last, Iter2)=C2=A0</font></div><div><font face=3D"courier new,mo=
nospace" style=3D"border-color:rgb(34,34,34);border-style:none;border-width=
:0px;margin:0px;padding:0px">{}=C2=A0</font><br></div><b></b><i></i><u></u>=
<sub></sub><sup></sup><strike></strike><br></div><div><b>Why?</b></div><div=
><b></b><i></i><br></div><div><i>A. Because of the time traveler!!!</i></di=
v><div><i><br></i></div><div><i>B. Let the users have theirs say IN THE REA=
L WORD.</i></div><div><i><br></i></div><div><i>C. We can ALWAYS add &quot;s=
impler&quot; syntax later, say in 5 years!</i></div><div><i><br></i></div><=
div><i><br></i></div><div><b>Future Directions</b></div><div><b><br></b></d=
iv><div>Why not let arguments be comma separated lists if we care so much a=
bout typing</div><div><span style=3D"margin:0px;padding:0px;border:0px rgb(=
34,34,34);text-align:left;color:rgb(34,34,34);text-transform:none;text-inde=
nt:0px;letter-spacing:normal;font-size:13px;font-style:normal;font-variant:=
normal;font-weight:400;text-decoration:none;word-spacing:0px;display:inline=
;white-space:normal;float:none;background-color:transparent"><br style=3D"b=
order-color:rgb(34,34,34);border-style:none;border-width:0px;margin:0px;pad=
ding:0px"></span></div><div><div><span style=3D"margin:0px;padding:0px;bord=
er:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);text-transform:non=
e;text-indent:0px;letter-spacing:normal;font-size:13px;font-style:normal;fo=
nt-variant:normal;font-weight:400;text-decoration:none;word-spacing:0px;dis=
play:inline;white-space:normal;float:none;background-color:transparent"><di=
v style=3D"background-color:transparent;border-color:rgb(34,34,34);border-s=
tyle:none;border-width:0px;color:rgb(34,34,34);font-size:13px;font-style:no=
rmal;font-variant:normal;font-weight:400;letter-spacing:normal;margin:0px;p=
adding:0px;text-align:left;text-decoration:none;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px"><span style=3D"margin:0px;pad=
ding:0px;border:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);text-=
transform:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-st=
yle:normal;font-variant:normal;font-weight:400;text-decoration:none;word-sp=
acing:0px;display:inline;white-space:normal;float:none;background-color:tra=
nsparent"><div style=3D"background-color:transparent;border-color:rgb(34,34=
,34);border-style:none;border-width:0px;color:rgb(34,34,34);font-size:13px;=
font-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal=
;margin:0px;padding:0px;text-align:left;text-decoration:none;text-indent:0p=
x;text-transform:none;white-space:normal;word-spacing:0px"><font face=3D"co=
urier new,monospace" style=3D"border-color:rgb(34,34,34);border-style:none;=
border-width:0px;margin:0px;padding:0px">template&lt;class In1, In2, Out&gt=
;=C2=A0</font></div><div style=3D"background-color:transparent;border-color=
:rgb(34,34,34);border-style:none;border-width:0px;color:rgb(34,34,34);font-=
size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spac=
ing:normal;margin:0px;padding:0px;text-align:left;text-decoration:none;text=
-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><font =
face=3D"courier new,monospace" style=3D"border-color:rgb(34,34,34);border-s=
tyle:none;border-width:0px;margin:0px;padding:0px">=C2=A0=C2=A0 requires Me=
rgeable&lt;In1, In2, Out&gt; =C2=A0</font></div><div style=3D"background-co=
lor:transparent;border-color:rgb(34,34,34);border-style:none;border-width:0=
px;color:rgb(34,34,34);font-size:13px;font-style:normal;font-variant:normal=
;font-weight:400;letter-spacing:normal;margin:0px;padding:0px;text-align:le=
ft;text-decoration:none;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px"><font face=3D"courier new,monospace" style=3D"border-=
color:rgb(34,34,34);border-style:none;border-width:0px;margin:0px;padding:0=
px">Out merge(In1,In1,In2,In2,Out);</font></div></span></div></span></div><=
font face=3D"courier new,monospace"></font><br></div><div>Why not instead o=
f the new syntax for names introducing we simply</div><div><br></div><div><=
div><font face=3D"courier new,monospace" style=3D"border-color:rgb(34,34,34=
);border-style:none;border-width:0px;margin:0px;padding:0px">requires Merge=
able&lt;In1, In2, Out&gt; =C2=A0</font></div><div><font face=3D"courier new=
,monospace" style=3D"border-color:rgb(34,34,34);border-style:none;border-wi=
dth:0px;margin:0px;padding:0px">Out merge(In1,In1,In2,In2,Out);</font></div=
><div><font face=3D"courier new,monospace" style=3D"border-color:rgb(34,34,=
34);border-style:none;border-width:0px;margin:0px;padding:0px"><br></font><=
/div><div><br></div></div><div><br></div><div><b></b><i></i><u></u><sub></s=
ub><sup></sup><strike></strike><br></div><div><font face=3D"times new roman=
,serif"></font></div><div><font face=3D"times new roman,serif"><i><br></i><=
/font></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/19c57a60-e883-4474-b106-7ff2ebc122ee%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/19c57a60-e883-=
4474-b106-7ff2ebc122ee%40isocpp.org</a>.<br>
</blockquote></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&quot; 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/CANh-dX%3Df_2eG%3D0H9zFkdOpoJXi8NtdZm=
qRoCcgvPxknYJvVXHA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3Df_2=
eG%3D0H9zFkdOpoJXi8NtdZmqRoCcgvPxknYJvVXHA%40mail.gmail.com</a>.<br />

--000000000000f49399056f021ee7--

.

------=_Part_25533_1118929451.1529429881538
Content-Type: multipart/alternative;
 boundary="----=_Part_25534_965160423.1529429881539"

------=_Part_25534_965160423.1529429881539
Content-Type: text/plain; charset="UTF-8"



On Tuesday, June 19, 2018 at 12:32:37 PM UTC-4, mihailn...@gmail.com wrote:
>
>
>
> On Tuesday, June 19, 2018 at 5:49:49 PM UTC+3, Nicol Bolas wrote:
>>
>>
>>
>> On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> OK, right now in flight are about FOUR proposals, trying to "simplify"
>>> and "make more clear" concepts usage.
>>>
>>> This is madness. It is madness, because NONE of it make it more clear!
>>> None.
>>>
>>> By inviting new language constructs one does not make things "more
>>> clear", it only adds more things to learn.
>>>
>>> The worst part is - *we have working solution that is clear. Granted
>>> verbose, but clear. *
>>>
>>> If one makes it Not verbose but Not clear (not self-explanatory, need
>>> learning) also one gains nothing!
>>>
>>
>> Clarity is ultimately a measure of time. Variadic templates are not
>> "clear" to people who've never seen them. UDLs are not "clear" to people
>> who've never seen them. Lambdas are not "clear" to people who've never seen
>> them. Structured bindings are not "clear" to people who've never seen them.
>> And God knows rvalue references and forwarding references would utterly
>> baffle people who've never seen them.
>>
>> All of these things are clear to us now because we are *used to them*.
>> That's the only reason why they are clear. Your hypothetical time traveler
>> from the C++98/03 days would be confused by the simplest of modern C++11
>> code.
>>
>> And that's OK.
>>
>
> But the problem is *we have* syntax that is clear to old user, even if it
> is new!
>

So what? That doesn't make syntax that isn't clear to old users a priori
bad. Syntax should be judged on its own merits, not on the merits of some
hypothetical user who hasn't kept up with the language in a decade.

Saying that a syntax is wrong just because we're not used to it is not
>> helpful. It's far more useful to look at things from a cost/benefit
>> analysis.
>>
>> Lambdas are probably the best example, because they don't do *anything*
>> that you couldn't do yourself, either with in-situ struct declarations or
>> out-of-function declarations. So their benefit is purely convenience.
>>
>> Lambdas have a *huge* syntactic cost. They have novel introduction
>> syntax, re-appropriating something that looks like an array into a
>> function/class declaration. They are functions that can be declared without
>> parameters, without even `()`. They deduce the return value unless you
>> specify otherwise. They allow `auto` in parameter lists. They can capture
>> values/expressions in a myriad of ways. And so forth.
>>
>> All of this represents a syntactic variance relative to regular
>> functions. And thus, it is a burden, a cost for entry that people have to
>> learn.
>>
>> But all of those costs pale into insignificance next to the *gains* from
>> the syntax. Lambdas are game-changers for C++. Pre-C++11, people would
>> avoid simple algorithms like `transform`, because writing out the
>> equivalent code was often easier than providing a functor. That's no longer
>> the case.
>>
>
>> Now, I'm not saying that any of the terse syntaxes are as valuable as
>> lambdas are. But my point is that novel syntax should not be avoided simply
>> because it is novel; you *have* to look at the benefits of it.
>>
>
> 'requires' is the similar of lambdas; in place of the enable_if magic. It
> is new syntax, yet clear.
>
>
>
>
>>
>> This is the reason why I hate concept introduction syntax. It's not that
>> it has novel syntax; it's that the novel syntax doesn't buy much. Yes,
>> concept introduction is shorter than the full `requires` clause. But it's
>> not shorter *enough* in enough cases to be worth the syntactic burden.
>>
>
> I agree 100% obviously.
>
>
>>
>> The nice thing about Herb's syntax is how regular it is. It works the
>> same everywhere. It provides the same benefit everywhere. It may be novel
>> syntax, but it solves many problems due to its regularity. It allows you to
>> concisely fairly obvious things.
>>
>
> Sorry, but that syntax is literally taking the hated introduction syntax
> and splatting it all over the entire Concepts proposal just to be
> "consistent"!
>

This is why your "I agree 100% obviously" is incorrect. You agree with my
*conclusion*, not my *reasoning*.

I dislike the concept introduction syntax for the reasons I specified: it
does not carry its own weight. The syntax does not provide nearly enough
benefits compared to its cost.

By "splatting it all over the entire Concepts proposal", the syntax gains
additional benefits. For example:

void forward_func(Concept{Typename} &&t)
{
  func(std::forward<Typename>(t));
}

See? No `decltype(t)` gymnastics.

Similarly, I can do this:

void func(Iterator{It} first, It last)
{
}

And that spells out exactly what it means. Sure, I could have used
`template<Iterator It>`, but this is shorter without losing meaning. Yes,
you have to learn what that means, but in a lambda, this is worthwhile:

[](Iterator{It} first, It last) {...}

vs.

[]<Iterator It>(It first, It last) {...}

Now these aren't huge differences. They're not universe-changing,
world-shaking benefits. But they're *significant*, and to me, they allow
this syntax to carry its own weight. Learning this syntax pays for itself
in making concepts more usable.

And it is syntax for the sake of syntax because it is not technically
> needed - no problem to be solved.
>

So are lambdas. As I pointed out, there is no technical reason why you
cannot replace every lambda ever with a user-written type.

And, as said it has nasty problems, from the fact it is not obvious in *any*
> way, to the metal overlap with initialization.
>
> Number{} x;
> x = Number{};
>
> And again NO PROBLEM NEEDS SOLVING! None.
>
>
>>
>> Now, you may argue that no terse syntax is worth the syntactic burden. I
>> rather disagree: there are too many cases where the function parameters and
>> template parameters match each other to say that making that function
>> declaration shorter isn't worth the time and effort. Applying concepts to
>> variables, even function parameters, makes too much sense to not be worth
>> pursuing.
>>
>
> Ok, however these are "nice" and nice things can wait, there is no
> pressing issue here!
>

Concepts are "nice things" too. But I think we can all agree we've waited
too long for them.


> Second, in 10+ years the results ARE WORSE. All of them!
>

.... huh?


> Third the real community is still to have its say. Any additional syntax
> should wait for the real feedback and the real requirements.
>

Every argument you make after this point against terse templates is an
argument you could make against lambdas. But we still have them. Why?

Because the benefits outweigh the costs.

The syntactic costs of terse template syntax is relatively minimal,
whichever syntax it may be.The benefits are still significant enough for
those costs to be meaningful.


> Sill - was there ever before a syntax added just for humans and not the
> compiler?
>

In C++? No; if compilers can figure it out, C and C++ tend to be of the
belief that people can too.

--
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/ee3facb4-a0cd-4bd8-9197-f922787fec75%40isocpp.org.

------=_Part_25534_965160423.1529429881539
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, June 19, 2018 at 12:32:37 PM UTC-4, mi=
hailn...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><br><br>On Tuesday, June 19, 2018 at 5:49:49 PM UTC+3, Nicol Bo=
las wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>=
On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, <a>mihailn...@gmail.com</a> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>OK, rig=
ht now in flight are about FOUR proposals, trying to &quot;simplify&quot; a=
nd &quot;make more clear&quot; concepts usage.</div><div><br></div><div>Thi=
s is madness. It is madness, because NONE of it make it more clear! None.=
=C2=A0</div><div><br></div><div>By inviting new language constructs one doe=
s not make things &quot;more clear&quot;, it only adds more things to learn=
..</div><div><br></div><div>The worst part is - <i>we have working solution =
that is clear. Granted verbose, but clear.=C2=A0</i></div><div><i></i><br><=
/div><div>If one makes it Not verbose but Not clear (not self-explanatory, =
need learning) also one gains nothing!</div></div></blockquote><div><br></d=
iv><div>Clarity is ultimately a measure of time. Variadic templates are not=
 &quot;clear&quot; to people who&#39;ve never seen them. UDLs are not &quot=
;clear&quot; to people who&#39;ve never seen them. Lambdas are not &quot;cl=
ear&quot; to people who&#39;ve never seen them. Structured bindings are not=
 &quot;clear&quot; to people who&#39;ve never seen them. And God knows rval=
ue references and forwarding references would utterly baffle people who&#39=
;ve never seen them.</div><div><br></div><div>All of these things are clear=
 to us now because we are <i>used to them</i>. That&#39;s the only reason w=
hy they are clear. Your hypothetical time traveler from the C++98/03 days w=
ould be confused by the simplest of modern C++11 code.</div><div><br></div>=
<div>And that&#39;s OK.</div></div></blockquote><div><br></div><div>But the=
 problem is <i>we have</i> syntax that is clear to old user, even if it is =
new!</div></div></blockquote><div><br></div><div>So what? That doesn&#39;t =
make syntax that isn&#39;t clear to old users a priori bad. Syntax should b=
e judged on its own merits, not on the merits of some hypothetical user who=
 hasn&#39;t kept up with the language in a decade.<br></div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><b=
lockquote 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>Sayi=
ng that a syntax is wrong just because we&#39;re not used to it is not help=
ful. It&#39;s far more useful to look at things from a cost/benefit analysi=
s.</div><div><br></div><div>Lambdas are probably the best example, because =
they don&#39;t do <i>anything</i> that you couldn&#39;t do yourself, either=
 with in-situ struct declarations or out-of-function declarations. So their=
 benefit is purely convenience.<br></div><div><br></div><div>Lambdas have a=
 <i>huge</i> syntactic cost. They have novel introduction syntax, re-approp=
riating something that looks like an array into a function/class declaratio=
n. They are functions that can be declared without parameters, without even=
 `()`. They deduce the return value unless you specify otherwise. They allo=
w `auto` in parameter lists. They can capture values/expressions in a myria=
d of ways. And so forth.</div><div><br></div><div>All of this represents a =
syntactic variance relative to regular functions. And thus, it is a burden,=
 a cost for entry that people have to learn.</div><div><br></div><div>But a=
ll of those costs pale into insignificance next to the <i>gains</i> from th=
e syntax. Lambdas are game-changers for C++. Pre-C++11, people would avoid =
simple algorithms like `transform`, because writing out the equivalent code=
 was often easier than providing a functor. That&#39;s no longer the case.=
=C2=A0</div></div></blockquote><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><br></div><div>Now, I&#39;m not saying that any of the te=
rse syntaxes are as valuable as lambdas are. But my point is that novel syn=
tax should not be avoided simply because it is novel; you <i>have</i> to lo=
ok at the benefits of it.</div></div></blockquote><div><br></div><div></div=
><div><span style=3D"display:inline!important;float:none;background-color:t=
ransparent;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;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">&#39;=
requires&#39; is the similar of lambdas; in place of the enable_if magic. I=
t is new syntax, yet clear.</span></div><div><br></div><div><br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
br></div><div>This is the reason why I hate concept introduction syntax. It=
&#39;s not that it has novel syntax; it&#39;s that the novel syntax doesn&#=
39;t buy much. Yes, concept introduction is shorter than the full `requires=
` clause. But it&#39;s not shorter <i>enough</i> in enough cases to be wort=
h the syntactic burden.</div></div></blockquote><div><br></div><div>I agree=
 100% obviously.=C2=A0</div><div>=C2=A0</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><br></div><div>The nice thing about Herb&#3=
9;s syntax is how regular it is. It works the same everywhere. It provides =
the same benefit everywhere. It may be novel syntax, but it solves many pro=
blems due to its regularity. It allows you to concisely fairly obvious thin=
gs.</div></div></blockquote><div><br></div><div>Sorry, but that syntax is l=
iterally taking the hated introduction syntax and splatting it all over the=
 entire Concepts proposal just to be &quot;consistent&quot;!</div></div></b=
lockquote><div><br></div><div>This is why your &quot;I agree 100% obviously=
&quot; is incorrect. You agree with my <i>conclusion</i>, not my <i>reasoni=
ng</i>.</div><div><br></div><div>I dislike the concept introduction syntax =
for the reasons I specified: it does not carry its own weight. The syntax d=
oes not provide nearly enough benefits compared to its cost.</div><div><br>=
</div><div>By &quot;splatting it all over the entire Concepts proposal&quot=
;, the syntax gains additional benefits. For example:</div><div><br></div><=
div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1=
87, 187); border-style: solid; border-width: 1px; overflow-wrap: break-word=
;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">void</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> forward_func</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">Concept</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Typename</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">t</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 func</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">forward</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Typename</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">t</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">));</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span></div></code></div><div><br></div><div>See? No `decltype(t)` =
gymnastics.</div><div><br></div><div>Similarly, I can do this:</div><div><b=
r></div><div style=3D"background-color: rgb(250, 250, 250); border-color: r=
gb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: b=
reak-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">=
void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> func<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Iterator</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">It</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> first</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">It</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">last</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span></div></code></div><div><br></div><div>=
</div><div>And that spells out exactly what it means. Sure, I could have us=
ed `template&lt;Iterator It&gt;`, but this is shorter without losing meanin=
g. Yes, you have to learn what that means, but in a lambda, this is worthwh=
ile:</div><div><br></div><div style=3D"background-color: rgb(250, 250, 250)=
; border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px;=
 overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">[](</span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Iterator</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #606;" class=3D"styled-by-prettify">I=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> first</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">It</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">last</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{...}<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>vs<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">[]&lt;</span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">Iterator</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">It</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">It</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> first</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">It</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">last</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{...}</span></div></code></div><div><br>Now th=
ese aren&#39;t huge differences. They&#39;re not universe-changing, world-s=
haking benefits. But they&#39;re <i>significant</i>, and to me, they allow =
this syntax to carry its own weight. Learning this syntax pays for itself i=
n making concepts more usable.</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>And it is syntax for the sake of=
 syntax because it is not technically needed - no problem to be solved.=C2=
=A0</div></div></blockquote><div><br></div><div>So are lambdas. As I pointe=
d out, there is no technical reason why you cannot replace every lambda eve=
r with a user-written type.</div><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div></div><div>And, as said it has nast=
y problems, from the fact it is not obvious in <i>any</i> way, to the metal=
 overlap with initialization.</div><div><br></div><div><font face=3D"courie=
r new,monospace">Number{} x;</font></div><div><font face=3D"courier new,mon=
ospace">x =3D Number{};</font></div><div><font face=3D"courier new,monospac=
e"></font><br></div><div>And again NO PROBLEM NEEDS SOLVING! None.=C2=A0</d=
iv><div>=C2=A0</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=
"><div><br></div><div>Now, you may argue that no terse syntax is worth the =
syntactic burden. I rather disagree: there are too many cases where the fun=
ction parameters and template parameters match each other to say that makin=
g that function declaration shorter isn&#39;t worth the time and effort. Ap=
plying concepts to variables, even function parameters, makes too much sens=
e to not be worth pursuing.<br></div></div></blockquote><div><br></div><div=
>Ok, however these are &quot;nice&quot; and nice things can wait, there is =
no pressing issue here!</div></div></blockquote><div><br></div><div>Concept=
s are &quot;nice things&quot; too. But I think we can all agree we&#39;ve w=
aited too long for them.<br></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div>Second, in 10+ years the results=
 ARE WORSE. All of them!</div></div></blockquote><div><br></div><div>... hu=
h?<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div>Third the real community is still to have its say. Any=
 additional syntax should wait for the real feedback and the real requireme=
nts.</div></div></blockquote><div><br></div><div>Every argument you make af=
ter this point against terse templates is an argument you could make agains=
t lambdas. But we still have them. Why?</div><div><br></div><div>Because th=
e benefits outweigh the costs.</div><div><br></div><div>The syntactic costs=
 of terse template syntax is relatively minimal, whichever syntax it may be=
..The benefits are still significant enough for those costs to be meaningful=
..<br></div><div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div></div><div>Sill - was there ever before a sy=
ntax added just for humans and not the compiler?</div></div></blockquote><d=
iv><br></div><div>In C++? No; if compilers can figure it out, C and C++ ten=
d to be of the belief that people can too.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/ee3facb4-a0cd-4bd8-9197-f922787fec75%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ee3facb4-a0cd-4bd8-9197-f922787fec75=
%40isocpp.org</a>.<br />

------=_Part_25534_965160423.1529429881539--

------=_Part_25533_1118929451.1529429881538--

.

------=_Part_25595_1208544217.1529434097096
Content-Type: multipart/alternative;
 boundary="----=_Part_25596_1393637713.1529434097097"

------=_Part_25596_1393637713.1529434097097
Content-Type: text/plain; charset="UTF-8"



On Tuesday, June 19, 2018 at 8:38:01 PM UTC+3, Nicol Bolas wrote:
>
>
>
> On Tuesday, June 19, 2018 at 12:32:37 PM UTC-4, mihailn...@gmail.com
> wrote:
>>
>>
>>
>> On Tuesday, June 19, 2018 at 5:49:49 PM UTC+3, Nicol Bolas wrote:
>>>
>>>
>>>
>>> On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, mihailn...@gmail.com
>>> wrote:
>>>>
>>>> OK, right now in flight are about FOUR proposals, trying to "simplify"
>>>> and "make more clear" concepts usage.
>>>>
>>>> This is madness. It is madness, because NONE of it make it more clear!
>>>> None.
>>>>
>>>> By inviting new language constructs one does not make things "more
>>>> clear", it only adds more things to learn.
>>>>
>>>> The worst part is - *we have working solution that is clear. Granted
>>>> verbose, but clear. *
>>>>
>>>> If one makes it Not verbose but Not clear (not self-explanatory, need
>>>> learning) also one gains nothing!
>>>>
>>>
>>> Clarity is ultimately a measure of time. Variadic templates are not
>>> "clear" to people who've never seen them. UDLs are not "clear" to people
>>> who've never seen them. Lambdas are not "clear" to people who've never seen
>>> them. Structured bindings are not "clear" to people who've never seen them.
>>> And God knows rvalue references and forwarding references would utterly
>>> baffle people who've never seen them.
>>>
>>> All of these things are clear to us now because we are *used to them*.
>>> That's the only reason why they are clear. Your hypothetical time traveler
>>> from the C++98/03 days would be confused by the simplest of modern C++11
>>> code.
>>>
>>> And that's OK.
>>>
>>
>> But the problem is *we have* syntax that is clear to old user, even if
>> it is new!
>>
>
> So what? That doesn't make syntax that isn't clear to old users a priori
> bad. Syntax should be judged on its own merits, not on the merits of some
> hypothetical user who hasn't kept up with the language in a decade.
>
> Saying that a syntax is wrong just because we're not used to it is not
>>> helpful. It's far more useful to look at things from a cost/benefit
>>> analysis.
>>>
>>> Lambdas are probably the best example, because they don't do *anything*
>>> that you couldn't do yourself, either with in-situ struct declarations or
>>> out-of-function declarations. So their benefit is purely convenience.
>>>
>>> Lambdas have a *huge* syntactic cost. They have novel introduction
>>> syntax, re-appropriating something that looks like an array into a
>>> function/class declaration. They are functions that can be declared without
>>> parameters, without even `()`. They deduce the return value unless you
>>> specify otherwise. They allow `auto` in parameter lists. They can capture
>>> values/expressions in a myriad of ways. And so forth.
>>>
>>> All of this represents a syntactic variance relative to regular
>>> functions. And thus, it is a burden, a cost for entry that people have to
>>> learn.
>>>
>>> But all of those costs pale into insignificance next to the *gains*
>>> from the syntax. Lambdas are game-changers for C++. Pre-C++11, people would
>>> avoid simple algorithms like `transform`, because writing out the
>>> equivalent code was often easier than providing a functor. That's no longer
>>> the case.
>>>
>>
>>> Now, I'm not saying that any of the terse syntaxes are as valuable as
>>> lambdas are. But my point is that novel syntax should not be avoided simply
>>> because it is novel; you *have* to look at the benefits of it.
>>>
>>
>> 'requires' is the similar of lambdas; in place of the enable_if magic. It
>> is new syntax, yet clear.
>>
>>
>>
>>
>>>
>>> This is the reason why I hate concept introduction syntax. It's not that
>>> it has novel syntax; it's that the novel syntax doesn't buy much. Yes,
>>> concept introduction is shorter than the full `requires` clause. But it's
>>> not shorter *enough* in enough cases to be worth the syntactic burden.
>>>
>>
>> I agree 100% obviously.
>>
>>
>>>
>>> The nice thing about Herb's syntax is how regular it is. It works the
>>> same everywhere. It provides the same benefit everywhere. It may be novel
>>> syntax, but it solves many problems due to its regularity. It allows you to
>>> concisely fairly obvious things.
>>>
>>
>> Sorry, but that syntax is literally taking the hated introduction syntax
>> and splatting it all over the entire Concepts proposal just to be
>> "consistent"!
>>
>
> This is why your "I agree 100% obviously" is incorrect. You agree with my
> *conclusion*, not my *reasoning*.
>
> I dislike the concept introduction syntax for the reasons I specified: it
> does not carry its own weight. The syntax does not provide nearly enough
> benefits compared to its cost.
>
> By "splatting it all over the entire Concepts proposal", the syntax gains
> additional benefits. For example:
>
> void forward_func(Concept{Typename} &&t)
> {
>   func(std::forward<Typename>(t));
> }
>
> See? No `decltype(t)` gymnastics.
>
> Similarly, I can do this:
>
> void func(Iterator{It} first, It last)
> {
> }
>
> And that spells out exactly what it means. Sure, I could have used
> `template<Iterator It>`, but this is shorter without losing meaning. Yes,
> you have to learn what that means, but in a lambda, this is worthwhile:
>
> [](Iterator{It} first, It last) {...}
>
> vs.
>
> []<Iterator It>(It first, It last) {...}
>
> Now these aren't huge differences. They're not universe-changing,
> world-shaking benefits. But they're *significant*, and to me, they allow
> this syntax to carry its own weight. Learning this syntax pays for itself
> in making concepts more usable.
>

Are they significant enough to add de facto *brand new syntax*?
A syntax which *could* be used for something else in a decade?
A syntax that does not introduce new features, but only adds second, even
*third* way of doing the same thing?



> And it is syntax for the sake of syntax because it is not technically
>> needed - no problem to be solved.
>>
>
> So are lambdas. As I pointed out, there is no technical reason why you
> cannot replace every lambda ever with a user-written type.
>
> And, as said it has nasty problems, from the fact it is not obvious in
>> *any* way, to the metal overlap with initialization.
>>
>> Number{} x;
>> x = Number{};
>>
>> And again NO PROBLEM NEEDS SOLVING! None.
>>
>>
>>>
>>> Now, you may argue that no terse syntax is worth the syntactic burden. I
>>> rather disagree: there are too many cases where the function parameters and
>>> template parameters match each other to say that making that function
>>> declaration shorter isn't worth the time and effort. Applying concepts to
>>> variables, even function parameters, makes too much sense to not be worth
>>> pursuing.
>>>
>>
>> Ok, however these are "nice" and nice things can wait, there is no
>> pressing issue here!
>>
>
> Concepts are "nice things" too. But I think we can all agree we've waited
> too long for them.
>

>
>> Second, in 10+ years the results ARE WORSE. All of them!
>>
>
> ... huh?
>
>
>> Third the real community is still to have its say. Any additional syntax
>> should wait for the real feedback and the real requirements.
>>
>
> Every argument you make after this point against terse templates is an
> argument you could make against lambdas. But we still have them. Why?
>
> Because the benefits outweigh the costs.
>


Your comparison to lambdas would have been correct only if we had a
concurrent terse lambda proposal being developed *at the same time* as the
regular one.
Even worse - to have the terse lambda blocking normal lambda.

Because we are there with Concepts.

We have two good (as in clear, powerful, understandable, carrying the
legacy forward, (C++) user friendly) ways to use Concepts and we insist of
third way. Almost no matter the cost.
And the results are not good. Not measurably good, given the cost.

As I said I am not against terse, my point is to just play it safe (for now)
:

* - No syntax-for-humans-only.*
* - No new syntactical concepts, which are simply an alternative. *

That's it.

In 5 years - revisit. Just like we revisited lambdas multiple times in
multiple forms.



>
> The syntactic costs of terse template syntax is relatively minimal,
> whichever syntax it may be.The benefits are still significant enough for
> those costs to be meaningful.
>
>
>> Sill - was there ever before a syntax added just for humans and not the
>> compiler?
>>
>
> In C++? No; if compilers can figure it out, C and C++ tend to be of the
> belief that people can too.
>

--
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/5574e3bb-3c4d-4459-a956-3fb77e26d050%40isocpp.org.

------=_Part_25596_1393637713.1529434097097
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, June 19, 2018 at 8:38:01 PM UTC+3, Nic=
ol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><br><br>On Tuesday, June 19, 2018 at 12:32:37 PM UTC-4, <a>mihailn...@gma=
il.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
br><br>On Tuesday, June 19, 2018 at 5:49:49 PM UTC+3, Nicol Bolas wrote:<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"><br><br>On Tuesday, J=
une 19, 2018 at 5:33:54 AM UTC-4, <a>mihailn...@gmail.com</a> wrote:<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>OK, right now in fli=
ght are about FOUR proposals, trying to &quot;simplify&quot; and &quot;make=
 more clear&quot; concepts usage.</div><div><br></div><div>This is madness.=
 It is madness, because NONE of it make it more clear! None.=C2=A0</div><di=
v><br></div><div>By inviting new language constructs one does not make thin=
gs &quot;more clear&quot;, it only adds more things to learn.</div><div><br=
></div><div>The worst part is - <i>we have working solution that is clear. =
Granted verbose, but clear.=C2=A0</i></div><div><i></i><br></div><div>If on=
e makes it Not verbose but Not clear (not self-explanatory, need learning) =
also one gains nothing!</div></div></blockquote><div><br></div><div>Clarity=
 is ultimately a measure of time. Variadic templates are not &quot;clear&qu=
ot; to people who&#39;ve never seen them. UDLs are not &quot;clear&quot; to=
 people who&#39;ve never seen them. Lambdas are not &quot;clear&quot; to pe=
ople who&#39;ve never seen them. Structured bindings are not &quot;clear&qu=
ot; to people who&#39;ve never seen them. And God knows rvalue references a=
nd forwarding references would utterly baffle people who&#39;ve never seen =
them.</div><div><br></div><div>All of these things are clear to us now beca=
use we are <i>used to them</i>. That&#39;s the only reason why they are cle=
ar. Your hypothetical time traveler from the C++98/03 days would be confuse=
d by the simplest of modern C++11 code.</div><div><br></div><div>And that&#=
39;s OK.</div></div></blockquote><div><br></div><div>But the problem is <i>=
we have</i> syntax that is clear to old user, even if it is new!</div></div=
></blockquote><div><br></div><div>So what? That doesn&#39;t make syntax tha=
t isn&#39;t clear to old users a priori bad. Syntax should be judged on its=
 own merits, not on the merits of some hypothetical user who hasn&#39;t kep=
t up with the language in a decade.<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></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></div><div>Saying that a syntax is =
wrong just because we&#39;re not used to it is not helpful. It&#39;s far mo=
re useful to look at things from a cost/benefit analysis.</div><div><br></d=
iv><div>Lambdas are probably the best example, because they don&#39;t do <i=
>anything</i> that you couldn&#39;t do yourself, either with in-situ struct=
 declarations or out-of-function declarations. So their benefit is purely c=
onvenience.<br></div><div><br></div><div>Lambdas have a <i>huge</i> syntact=
ic cost. They have novel introduction syntax, re-appropriating something th=
at looks like an array into a function/class declaration. They are function=
s that can be declared without parameters, without even `()`. They deduce t=
he return value unless you specify otherwise. They allow `auto` in paramete=
r lists. They can capture values/expressions in a myriad of ways. And so fo=
rth.</div><div><br></div><div>All of this represents a syntactic variance r=
elative to regular functions. And thus, it is a burden, a cost for entry th=
at people have to learn.</div><div><br></div><div>But all of those costs pa=
le into insignificance next to the <i>gains</i> from the syntax. Lambdas ar=
e game-changers for C++. Pre-C++11, people would avoid simple algorithms li=
ke `transform`, because writing out the equivalent code was often easier th=
an providing a functor. That&#39;s no longer the case.=C2=A0</div></div></b=
lockquote><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><br=
></div><div>Now, I&#39;m not saying that any of the terse syntaxes are as v=
aluable as lambdas are. But my point is that novel syntax should not be avo=
ided simply because it is novel; you <i>have</i> to look at the benefits of=
 it.</div></div></blockquote><div><br></div><div></div><div><span style=3D"=
display:inline!important;float:none;background-color:transparent;color:rgb(=
34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;fo=
nt-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-s=
pacing:normal;text-align:left;text-decoration:none;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px">&#39;requires&#39; is the =
similar of lambdas; in place of the enable_if magic. It is new syntax, yet =
clear.</span></div><div><br></div><div><br></div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>This is=
 the reason why I hate concept introduction syntax. It&#39;s not that it ha=
s novel syntax; it&#39;s that the novel syntax doesn&#39;t buy much. Yes, c=
oncept introduction is shorter than the full `requires` clause. But it&#39;=
s not shorter <i>enough</i> in enough cases to be worth the syntactic burde=
n.</div></div></blockquote><div><br></div><div>I agree 100% obviously.=C2=
=A0</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><br></div><div>The nice thing about Herb&#39;s syntax is how =
regular it is. It works the same everywhere. It provides the same benefit e=
verywhere. It may be novel syntax, but it solves many problems due to its r=
egularity. It allows you to concisely fairly obvious things.</div></div></b=
lockquote><div><br></div><div>Sorry, but that syntax is literally taking th=
e hated introduction syntax and splatting it all over the entire Concepts p=
roposal just to be &quot;consistent&quot;!</div></div></blockquote><div><br=
></div><div>This is why your &quot;I agree 100% obviously&quot; is incorrec=
t. You agree with my <i>conclusion</i>, not my <i>reasoning</i>.</div><div>=
<br></div><div>I dislike the concept introduction syntax for the reasons I =
specified: it does not carry its own weight. The syntax does not provide ne=
arly enough benefits compared to its cost.</div><div><br></div><div>By &quo=
t;splatting it all over the entire Concepts proposal&quot;, the syntax gain=
s additional benefits. For example:</div><div><br></div><div style=3D"backg=
round-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:sol=
id;border-width:1px"><code><div><span style=3D"color:#008">void</span><span=
 style=3D"color:#000"> forward_func</span><span style=3D"color:#660">(</spa=
n><span style=3D"color:#606">Concept</span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#606">Typename</span><span style=3D"color:#660">}</=
span><span style=3D"color:#000"> </span><span style=3D"color:#660">&amp;&am=
p;</span><span style=3D"color:#000">t</span><span style=3D"color:#660">)</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#000"><br>=C2=A0 func</span><span style=3D"color:#66=
0">(</span><span style=3D"color:#000">std</span><span style=3D"color:#660">=
::</span><span style=3D"color:#000">forward</span><span style=3D"color:#660=
">&lt;</span><span style=3D"color:#606">Typename</span><span style=3D"color=
:#660">&gt;(</span><span style=3D"color:#000">t</span><span style=3D"color:=
#660">)<wbr>);</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#660">}</span><span style=3D"color:#000"><br></span></div></code></div=
><div><br></div><div>See? No `decltype(t)` gymnastics.</div><div><br></div>=
<div>Similarly, I can do this:</div><div><br></div><div style=3D"background=
-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bo=
rder-width:1px"><code><div><span style=3D"color:#008">void</span><span styl=
e=3D"color:#000"> func</span><span style=3D"color:#660">(</span><span style=
=3D"color:#606">Iterator</span><span style=3D"color:#660">{</span><span sty=
le=3D"color:#606">It</span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"> first</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">It</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">last</span><span style=3D"co=
lor:#660">)</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"><br></span><span style=3D"color:=
#660">}</span></div></code></div><div><br></div><div></div><div>And that sp=
ells out exactly what it means. Sure, I could have used `template&lt;Iterat=
or It&gt;`, but this is shorter without losing meaning. Yes, you have to le=
arn what that means, but in a lambda, this is worthwhile:</div><div><br></d=
iv><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187=
,187);border-style:solid;border-width:1px"><code><div><span style=3D"color:=
#660">[](</span><span style=3D"color:#606">Iterator</span><span style=3D"co=
lor:#660">{</span><span style=3D"color:#606">It</span><span style=3D"color:=
#660">}</span><span style=3D"color:#000"> first</span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#606"=
>It</span><span style=3D"color:#000"> </span><span style=3D"color:#008">las=
t</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#660">{...}</span><span style=3D"color:#000"><br><b=
r>vs</span><span style=3D"color:#660">.</span><span style=3D"color:#000"><b=
r><br></span><span style=3D"color:#660">[]&lt;</span><span style=3D"color:#=
606">Iterator</span><span style=3D"color:#000"> </span><span style=3D"color=
:#606">It</span><span style=3D"color:#660">&gt;(</span><span style=3D"color=
:#606">It</span><span style=3D"color:#000"> first</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#60=
6">It</span><span style=3D"color:#000"> </span><span style=3D"color:#008">l=
ast</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> </=
span><span style=3D"color:#660">{...}</span></div></code></div><div><br>Now=
 these aren&#39;t huge differences. They&#39;re not universe-changing, worl=
d-shaking benefits. But they&#39;re <i>significant</i>, and to me, they all=
ow this syntax to carry its own weight. Learning this syntax pays for itsel=
f in making concepts more usable.</div></div></blockquote><div><br></div><d=
iv>Are they significant enough to add de facto <i>brand new syntax</i>?=C2=
=A0</div><div>A syntax which <i>could</i> be used for something else in a d=
ecade?=C2=A0</div><div>A syntax that does not introduce new features, but o=
nly adds second, even <i>third</i> way of doing the same thing?<br></div><d=
iv><br></div><div><b></b><i></i><u></u><sub></sub><sup></sup><strike></stri=
ke><font face=3D"courier new,monospace"></font><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><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>And it is syntax for the sak=
e of syntax because it is not technically needed - no problem to be solved.=
=C2=A0</div></div></blockquote><div><br></div><div>So are lambdas. As I poi=
nted out, there is no technical reason why you cannot replace every lambda =
ever with a user-written type.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div></div><div>And, as said it has nasty =
problems, from the fact it is not obvious in <i>any</i> way, to the metal o=
verlap with initialization.</div><div><br></div><div><font face=3D"courier =
new,monospace">Number{} x;</font></div><div><font face=3D"courier new,monos=
pace">x =3D Number{};</font></div><div><font face=3D"courier new,monospace"=
></font><br></div><div>And again NO PROBLEM NEEDS SOLVING! None.=C2=A0</div=
><div>=C2=A0</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><br></div><div>Now, you may argue that no terse syntax is worth the sy=
ntactic burden. I rather disagree: there are too many cases where the funct=
ion parameters and template parameters match each other to say that making =
that function declaration shorter isn&#39;t worth the time and effort. Appl=
ying concepts to variables, even function parameters, makes too much sense =
to not be worth pursuing.<br></div></div></blockquote><div><br></div><div>O=
k, however these are &quot;nice&quot; and nice things can wait, there is no=
 pressing issue here!</div></div></blockquote><div><br></div><div>Concepts =
are &quot;nice things&quot; too. But I think we can all agree we&#39;ve wai=
ted too long for them.<br></div></div></blockquote><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></div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Second, in 10+ years t=
he results ARE WORSE. All of them!</div></div></blockquote><div><br></div><=
div>... huh?<br></div><div>=C2=A0</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>Third the real community is still to have its say=
.. Any additional syntax should wait for the real feedback and the real requ=
irements.</div></div></blockquote><div><br></div><div>Every argument you ma=
ke after this point against terse templates is an argument you could make a=
gainst lambdas. But we still have them. Why?</div><div><br></div><div>Becau=
se the benefits outweigh the costs.</div></div></blockquote><div><br></div>=
<div><br></div><div>Your comparison to lambdas would have been correct only=
 if we had a concurrent terse lambda proposal being developed <i>at the sam=
e time</i> as the regular one.=C2=A0</div><div>Even worse - to have the ter=
se lambda blocking normal lambda.=C2=A0</div><div><br></div><div>Because we=
 are there with Concepts.=C2=A0</div><div><br></div><div>We have two good (=
as in clear, powerful, understandable, carrying the legacy forward, (C++) u=
ser friendly) ways to use Concepts and we insist of third way. Almost no ma=
tter the cost.=C2=A0</div><div>And the results are not good. Not measurably=
 good, given the cost.</div><div><br></div><div>As I said I am not against =
terse, my point is to just play it safe (for now)<i></i>:</div><div><br></d=
iv><div><b>=C2=A0- No syntax-for-humans-only.</b></div><div><b>=C2=A0- No n=
ew syntactical concepts, which are<i> simply an alternative</i>.=C2=A0</b><=
/div><div><b></b><b></b><br></div><div>That&#39;s it.</div><div><br></div><=
div>In 5 years - revisit. Just like we revisited lambdas multiple times in =
multiple forms.</div><i></i><i></i><div><br></div><div>=C2=A0</div><blockqu=
ote 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>T=
he syntactic costs of terse template syntax is relatively minimal, whicheve=
r syntax it may be.The benefits are still significant enough for those cost=
s to be meaningful.<br></div><div></div><div>=C2=A0</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>Sill - was there ev=
er before a syntax added just for humans and not the compiler?</div></div><=
/blockquote><div><br></div><div>In C++? No; if compilers can figure it out,=
 C and C++ tend to be of the belief that people can too.</div></div></block=
quote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/5574e3bb-3c4d-4459-a956-3fb77e26d050%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5574e3bb-3c4d-4459-a956-3fb77e26d050=
%40isocpp.org</a>.<br />

------=_Part_25596_1393637713.1529434097097--

------=_Part_25595_1208544217.1529434097096--

.

------=_Part_25755_1105823836.1529435734999
Content-Type: multipart/alternative;
 boundary="----=_Part_25756_1447408432.1529435735000"

------=_Part_25756_1447408432.1529435735000
Content-Type: text/plain; charset="UTF-8"

On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, mihailn...@gmail.com wrote:
>
> On Tuesday, June 19, 2018 at 8:38:01 PM UTC+3, Nicol Bolas wrote:
>>
>> On Tuesday, June 19, 2018 at 12:32:37 PM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> On Tuesday, June 19, 2018 at 5:49:49 PM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, mihailn...@gmail.com
>>>> wrote:
>>>>>
>>>>> OK, right now in flight are about FOUR proposals, trying to "simplify"
>>>>> and "make more clear" concepts usage.
>>>>>
>>>>> This is madness. It is madness, because NONE of it make it more clear!
>>>>> None.
>>>>>
>>>>> By inviting new language constructs one does not make things "more
>>>>> clear", it only adds more things to learn.
>>>>>
>>>>> The worst part is - *we have working solution that is clear. Granted
>>>>> verbose, but clear. *
>>>>>
>>>>> If one makes it Not verbose but Not clear (not self-explanatory, need
>>>>> learning) also one gains nothing!
>>>>>
>>>>
>>>> Clarity is ultimately a measure of time. Variadic templates are not
>>>> "clear" to people who've never seen them. UDLs are not "clear" to people
>>>> who've never seen them. Lambdas are not "clear" to people who've never seen
>>>> them. Structured bindings are not "clear" to people who've never seen them.
>>>> And God knows rvalue references and forwarding references would utterly
>>>> baffle people who've never seen them.
>>>>
>>>> All of these things are clear to us now because we are *used to them*.
>>>> That's the only reason why they are clear. Your hypothetical time traveler
>>>> from the C++98/03 days would be confused by the simplest of modern C++11
>>>> code.
>>>>
>>>> And that's OK.
>>>>
>>>
>>> But the problem is *we have* syntax that is clear to old user, even if
>>> it is new!
>>>
>>
>> So what? That doesn't make syntax that isn't clear to old users a priori
>> bad. Syntax should be judged on its own merits, not on the merits of some
>> hypothetical user who hasn't kept up with the language in a decade.
>>
>> Saying that a syntax is wrong just because we're not used to it is not
>>>> helpful. It's far more useful to look at things from a cost/benefit
>>>> analysis.
>>>>
>>>> Lambdas are probably the best example, because they don't do *anything*
>>>> that you couldn't do yourself, either with in-situ struct declarations or
>>>> out-of-function declarations. So their benefit is purely convenience.
>>>>
>>>> Lambdas have a *huge* syntactic cost. They have novel introduction
>>>> syntax, re-appropriating something that looks like an array into a
>>>> function/class declaration. They are functions that can be declared without
>>>> parameters, without even `()`. They deduce the return value unless you
>>>> specify otherwise. They allow `auto` in parameter lists. They can capture
>>>> values/expressions in a myriad of ways. And so forth.
>>>>
>>>> All of this represents a syntactic variance relative to regular
>>>> functions. And thus, it is a burden, a cost for entry that people have to
>>>> learn.
>>>>
>>>> But all of those costs pale into insignificance next to the *gains*
>>>> from the syntax. Lambdas are game-changers for C++. Pre-C++11, people would
>>>> avoid simple algorithms like `transform`, because writing out the
>>>> equivalent code was often easier than providing a functor. That's no longer
>>>> the case.
>>>>
>>>
>>>> Now, I'm not saying that any of the terse syntaxes are as valuable as
>>>> lambdas are. But my point is that novel syntax should not be avoided simply
>>>> because it is novel; you *have* to look at the benefits of it.
>>>>
>>>
>>> 'requires' is the similar of lambdas; in place of the enable_if magic.
>>> It is new syntax, yet clear.
>>>
>>>
>>>
>>>
>>>>
>>>> This is the reason why I hate concept introduction syntax. It's not
>>>> that it has novel syntax; it's that the novel syntax doesn't buy much. Yes,
>>>> concept introduction is shorter than the full `requires` clause. But it's
>>>> not shorter *enough* in enough cases to be worth the syntactic burden.
>>>>
>>>
>>> I agree 100% obviously.
>>>
>>>
>>>>
>>>> The nice thing about Herb's syntax is how regular it is. It works the
>>>> same everywhere. It provides the same benefit everywhere. It may be novel
>>>> syntax, but it solves many problems due to its regularity. It allows you to
>>>> concisely fairly obvious things.
>>>>
>>>
>>> Sorry, but that syntax is literally taking the hated introduction syntax
>>> and splatting it all over the entire Concepts proposal just to be
>>> "consistent"!
>>>
>>
>> This is why your "I agree 100% obviously" is incorrect. You agree with my
>> *conclusion*, not my *reasoning*.
>>
>> I dislike the concept introduction syntax for the reasons I specified: it
>> does not carry its own weight. The syntax does not provide nearly enough
>> benefits compared to its cost.
>>
>> By "splatting it all over the entire Concepts proposal", the syntax gains
>> additional benefits. For example:
>>
>> void forward_func(Concept{Typename} &&t)
>> {
>>   func(std::forward<Typename>(t));
>> }
>>
>> See? No `decltype(t)` gymnastics.
>>
>> Similarly, I can do this:
>>
>> void func(Iterator{It} first, It last)
>> {
>> }
>>
>> And that spells out exactly what it means. Sure, I could have used
>> `template<Iterator It>`, but this is shorter without losing meaning. Yes,
>> you have to learn what that means, but in a lambda, this is worthwhile:
>>
>> [](Iterator{It} first, It last) {...}
>>
>> vs.
>>
>> []<Iterator It>(It first, It last) {...}
>>
>> Now these aren't huge differences. They're not universe-changing,
>> world-shaking benefits. But they're *significant*, and to me, they allow
>> this syntax to carry its own weight. Learning this syntax pays for itself
>> in making concepts more usable.
>>
>
> Are they significant enough to add de facto *brand new syntax*?
>

That's a judgement call, but I would say "yes".

A syntax which *could* be used for something else in a decade?
>

OK, so let's review the two syntaxes in question (because the committee has
essentially boiled them down to just two).

There's Herb's proposal, which is `ConceptName{stuff}`. And there's the
Concepts TS terse syntax but with `template` applied to functions that use
them (except for lambdas which get it without `template`).

What could you use `ConceptName{stuff}` for in the future? Do you have any
ideas at all where such syntax might be useful?

Similarly, what would `template <function definition>` mean in some
hypothetical future?

I understand and appreciate the idea of not burning precious syntax for
trivial things. But we're not talking about prime syntactic real estate
here.

A syntax that does not introduce new features, but only adds second, even
> *third* way of doing the same thing?
>

It doesn't matter how many ways there are of doing something. What matters
is whether those ways are clear and convenient to use. Template headers are
clear but inconvenient.


>> And it is syntax for the sake of syntax because it is not technically
>>> needed - no problem to be solved.
>>>
>>
>> So are lambdas. As I pointed out, there is no technical reason why you
>> cannot replace every lambda ever with a user-written type.
>>
>> And, as said it has nasty problems, from the fact it is not obvious in
>>> *any* way, to the metal overlap with initialization.
>>>
>>> Number{} x;
>>> x = Number{};
>>>
>>> And again NO PROBLEM NEEDS SOLVING! None.
>>>
>>>
>>>>
>>>> Now, you may argue that no terse syntax is worth the syntactic burden.
>>>> I rather disagree: there are too many cases where the function parameters
>>>> and template parameters match each other to say that making that function
>>>> declaration shorter isn't worth the time and effort. Applying concepts to
>>>> variables, even function parameters, makes too much sense to not be worth
>>>> pursuing.
>>>>
>>>
>>> Ok, however these are "nice" and nice things can wait, there is no
>>> pressing issue here!
>>>
>>
>> Concepts are "nice things" too. But I think we can all agree we've waited
>> too long for them.
>>
>
>>
>>> Second, in 10+ years the results ARE WORSE. All of them!
>>>
>>
>> ... huh?
>>
>>
>>> Third the real community is still to have its say. Any additional syntax
>>> should wait for the real feedback and the real requirements.
>>>
>>
>> Every argument you make after this point against terse templates is an
>> argument you could make against lambdas. But we still have them. Why?
>>
>> Because the benefits outweigh the costs.
>>
>
> Your comparison to lambdas would have been correct only if we had a
> concurrent terse lambda proposal being developed *at the same time* as
> the regular one.
>

But *they did*. Go look at some of the old lambda proposals. There were
ideas about dropping the parameter typename identifiers and so forth even
back then. They didn't pan out, but there was discussion about them
concurrently with the broader lambda syntax. And such things would have
been optional rather than mandatory.

Even worse - to have the terse lambda blocking normal lambda. Because we
> are there with Concepts.
>

Since when has terse templates blocked concepts? The Concepts TS wasn't
ready for C++17; questions about terse syntax were just one of the reasons
why <http://honermann.net/blog/?p=3>. And Concepts-sans-terse syntax was
voted into C++20 last year. So we aren't "there" at all.

Not unless one of the 5 national bodies is threatening not to vote for
C++20 *without* some form of terse templates.

--
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/3c5f8766-9ef4-46be-a9c2-7b5f9c7f5ee7%40isocpp.org.

------=_Part_25756_1447408432.1529435735000
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, mihailn...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Tuesday, June 19, 2018 at 8:38:01 PM UTC+3, Nicol Bolas wrote:<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">On Tuesday, June 19, 2018=
 at 12:32:37 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<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">On Tuesday, June 19, 2018 at 5:49:4=
9 PM UTC+3, Nicol Bolas wrote:<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">On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, <a>mihailn...@gm=
ail.com</a> 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"ltr">=
<div>OK, right now in flight are about FOUR proposals, trying to &quot;simp=
lify&quot; and &quot;make more clear&quot; concepts usage.</div><div><br></=
div><div>This is madness. It is madness, because NONE of it make it more cl=
ear! None.=C2=A0</div><div><br></div><div>By inviting new language construc=
ts one does not make things &quot;more clear&quot;, it only adds more thing=
s to learn.</div><div><br></div><div>The worst part is - <i>we have working=
 solution that is clear. Granted verbose, but clear.=C2=A0</i></div><div><i=
></i><br></div><div>If one makes it Not verbose but Not clear (not self-exp=
lanatory, need learning) also one gains nothing!</div></div></blockquote><d=
iv><br></div><div>Clarity is ultimately a measure of time. Variadic templat=
es are not &quot;clear&quot; to people who&#39;ve never seen them. UDLs are=
 not &quot;clear&quot; to people who&#39;ve never seen them. Lambdas are no=
t &quot;clear&quot; to people who&#39;ve never seen them. Structured bindin=
gs are not &quot;clear&quot; to people who&#39;ve never seen them. And God =
knows rvalue references and forwarding references would utterly baffle peop=
le who&#39;ve never seen them.</div><div><br></div><div>All of these things=
 are clear to us now because we are <i>used to them</i>. That&#39;s the onl=
y reason why they are clear. Your hypothetical time traveler from the C++98=
/03 days would be confused by the simplest of modern C++11 code.</div><div>=
<br></div><div>And that&#39;s OK.</div></div></blockquote><div><br></div><d=
iv>But the problem is <i>we have</i> syntax that is clear to old user, even=
 if it is new!</div></div></blockquote><div><br></div><div>So what? That do=
esn&#39;t make syntax that isn&#39;t clear to old users a priori bad. Synta=
x should be judged on its own merits, not on the merits of some hypothetica=
l user who hasn&#39;t kept up with the language in a decade.<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></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div=
>Saying that a syntax is wrong just because we&#39;re not used to it is not=
 helpful. It&#39;s far more useful to look at things from a cost/benefit an=
alysis.</div><div><br></div><div>Lambdas are probably the best example, bec=
ause they don&#39;t do <i>anything</i> that you couldn&#39;t do yourself, e=
ither with in-situ struct declarations or out-of-function declarations. So =
their benefit is purely convenience.<br></div><div><br></div><div>Lambdas h=
ave a <i>huge</i> syntactic cost. They have novel introduction syntax, re-a=
ppropriating something that looks like an array into a function/class decla=
ration. They are functions that can be declared without parameters, without=
 even `()`. They deduce the return value unless you specify otherwise. They=
 allow `auto` in parameter lists. They can capture values/expressions in a =
myriad of ways. And so forth.</div><div><br></div><div>All of this represen=
ts a syntactic variance relative to regular functions. And thus, it is a bu=
rden, a cost for entry that people have to learn.</div><div><br></div><div>=
But all of those costs pale into insignificance next to the <i>gains</i> fr=
om the syntax. Lambdas are game-changers for C++. Pre-C++11, people would a=
void simple algorithms like `transform`, because writing out the equivalent=
 code was often easier than providing a functor. That&#39;s no longer the c=
ase.=C2=A0</div></div></blockquote><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><br></div><div>Now, I&#39;m not saying that any of t=
he terse syntaxes are as valuable as lambdas are. But my point is that nove=
l syntax should not be avoided simply because it is novel; you <i>have</i> =
to look at the benefits of it.</div></div></blockquote><div><br></div><div>=
</div><div><span style=3D"display:inline!important;float:none;background-co=
lor:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Hel=
vetica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:norma=
l;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:non=
e;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">=
&#39;requires&#39; is the similar of lambdas; in place of the enable_if mag=
ic. It is new syntax, yet clear.</span></div><div><br></div><div><br></div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div><br></div><div>This is the reason why I hate concept introduction synta=
x. It&#39;s not that it has novel syntax; it&#39;s that the novel syntax do=
esn&#39;t buy much. Yes, concept introduction is shorter than the full `req=
uires` clause. But it&#39;s not shorter <i>enough</i> in enough cases to be=
 worth the syntactic burden.</div></div></blockquote><div><br></div><div>I =
agree 100% obviously.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><br></div><div>The nice thing about He=
rb&#39;s syntax is how regular it is. It works the same everywhere. It prov=
ides the same benefit everywhere. It may be novel syntax, but it solves man=
y problems due to its regularity. It allows you to concisely fairly obvious=
 things.</div></div></blockquote><div><br></div><div>Sorry, but that syntax=
 is literally taking the hated introduction syntax and splatting it all ove=
r the entire Concepts proposal just to be &quot;consistent&quot;!</div></di=
v></blockquote><div><br></div><div>This is why your &quot;I agree 100% obvi=
ously&quot; is incorrect. You agree with my <i>conclusion</i>, not my <i>re=
asoning</i>.</div><div><br></div><div>I dislike the concept introduction sy=
ntax for the reasons I specified: it does not carry its own weight. The syn=
tax does not provide nearly enough benefits compared to its cost.</div><div=
><br></div><div>By &quot;splatting it all over the entire Concepts proposal=
&quot;, the syntax gains additional benefits. For example:</div><div><br></=
div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px"><code><div><span style=3D"color=
:#008">void</span><span style=3D"color:#000"> forward_func</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#606">Concept</span><span sty=
le=3D"color:#660">{</span><span style=3D"color:#606">Typename</span><span s=
tyle=3D"color:#660">}</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">&amp;&amp;</span><span style=3D"color:#000">t</span><span s=
tyle=3D"color:#660">)</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 func</span>=
<span style=3D"color:#660">(</span><span style=3D"color:#000">std</span><sp=
an style=3D"color:#660">::</span><span style=3D"color:#000">forward</span><=
span style=3D"color:#660">&lt;</span><span style=3D"color:#606">Typename</s=
pan><span style=3D"color:#660">&gt;(</span><span style=3D"color:#000">t</sp=
an><span style=3D"color:#660">)<wbr>);</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br><=
/span></div></code></div><div><br></div><div>See? No `decltype(t)` gymnasti=
cs.</div><div><br></div><div>Similarly, I can do this:</div><div><br></div>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px"><code><div><span style=3D"color:#00=
8">void</span><span style=3D"color:#000"> func</span><span style=3D"color:#=
660">(</span><span style=3D"color:#606">Iterator</span><span style=3D"color=
:#660">{</span><span style=3D"color:#606">It</span><span style=3D"color:#66=
0">}</span><span style=3D"color:#000"> first</span><span style=3D"color:#66=
0">,</span><span style=3D"color:#000"> </span><span style=3D"color:#606">It=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">last</=
span><span style=3D"color:#660">)</span><span style=3D"color:#000"><br></sp=
an><span style=3D"color:#660">{</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#660">}</span></div></code></div><div><br></div><div>=
</div><div>And that spells out exactly what it means. Sure, I could have us=
ed `template&lt;Iterator It&gt;`, but this is shorter without losing meanin=
g. Yes, you have to learn what that means, but in a lambda, this is worthwh=
ile:</div><div><br></div><div style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div=
><span style=3D"color:#660">[](</span><span style=3D"color:#606">Iterator</=
span><span style=3D"color:#660">{</span><span style=3D"color:#606">It</span=
><span style=3D"color:#660">}</span><span style=3D"color:#000"> first</span=
><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#606">It</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#008">last</span><span style=3D"color:#660">)</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">{...}</span><span style=
=3D"color:#000"><br><br>vs</span><span style=3D"color:#660">.</span><span s=
tyle=3D"color:#000"><br><br></span><span style=3D"color:#660">[]&lt;</span>=
<span style=3D"color:#606">Iterator</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#606">It</span><span style=3D"color:#660">&gt;(</spa=
n><span style=3D"color:#606">It</span><span style=3D"color:#000"> first</sp=
an><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#606">It</span><span style=3D"color:#000"> </span><span =
style=3D"color:#008">last</span><span style=3D"color:#660">)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">{...}</span></div></c=
ode></div><div><br>Now these aren&#39;t huge differences. They&#39;re not u=
niverse-changing, world-shaking benefits. But they&#39;re <i>significant</i=
>, and to me, they allow this syntax to carry its own weight. Learning this=
 syntax pays for itself in making concepts more usable.</div></div></blockq=
uote><div><br></div><div>Are they significant enough to add de facto <i>bra=
nd new syntax</i>?</div></div></blockquote><div><br></div><div>That&#39;s a=
 judgement call, but I would say &quot;yes&quot;.<br></div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>A syntax =
which <i>could</i> be used for something else in a decade?</div></div></blo=
ckquote><div><br></div><div>OK, so let&#39;s review the two syntaxes in que=
stion (because the committee has essentially boiled them down to just two).=
</div><div><br></div><div>There&#39;s Herb&#39;s proposal, which is `Concep=
tName{stuff}`. And there&#39;s the Concepts TS terse syntax but with `templ=
ate` applied to functions that use them (except for lambdas which get it wi=
thout `template`).</div><div><br></div><div>What could you use `ConceptName=
{stuff}` for in the future? Do you have any ideas at all where such syntax =
might be useful?</div><div><br></div><div>Similarly, what would `template &=
lt;function definition&gt;` mean in some hypothetical future?</div><div><br=
></div><div>I understand and appreciate the idea of not burning precious sy=
ntax for trivial things. But we&#39;re not talking about prime syntactic re=
al estate here.<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>A syntax that does not introduce new featur=
es, but only adds second, even <i>third</i> way of doing the same thing?<br=
></div></div></blockquote><div><br></div><div>It doesn&#39;t matter how man=
y ways there are of doing something. What matters is whether those ways are=
 clear and convenient to use. Template headers are clear but inconvenient.<=
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 d=
ir=3D"ltr"><div></div><div><b></b><i></i><u></u><sub></sub><sup></sup><stri=
ke></strike><font face=3D"courier new,monospace"></font></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><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>And it is syntax for the sake=
 of syntax because it is not technically needed - no problem to be solved.=
=C2=A0</div></div></blockquote><div><br></div><div>So are lambdas. As I poi=
nted out, there is no technical reason why you cannot replace every lambda =
ever with a user-written type.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div></div><div>And, as said it has nasty =
problems, from the fact it is not obvious in <i>any</i> way, to the metal o=
verlap with initialization.</div><div><br></div><div><font face=3D"courier =
new,monospace">Number{} x;</font></div><div><font face=3D"courier new,monos=
pace">x =3D Number{};</font></div><div><font face=3D"courier new,monospace"=
></font><br></div><div>And again NO PROBLEM NEEDS SOLVING! None.=C2=A0</div=
><div>=C2=A0</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><br></div><div>Now, you may argue that no terse syntax is worth the sy=
ntactic burden. I rather disagree: there are too many cases where the funct=
ion parameters and template parameters match each other to say that making =
that function declaration shorter isn&#39;t worth the time and effort. Appl=
ying concepts to variables, even function parameters, makes too much sense =
to not be worth pursuing.<br></div></div></blockquote><div><br></div><div>O=
k, however these are &quot;nice&quot; and nice things can wait, there is no=
 pressing issue here!</div></div></blockquote><div><br></div><div>Concepts =
are &quot;nice things&quot; too. But I think we can all agree we&#39;ve wai=
ted too long for them.<br></div></div></blockquote><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div></div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div>Second, in 10+ years the re=
sults ARE WORSE. All of them!</div></div></blockquote><div><br></div><div>.=
... huh?<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>Third the real community is still to have its say. A=
ny additional syntax should wait for the real feedback and the real require=
ments.</div></div></blockquote><div><br></div><div>Every argument you make =
after this point against terse templates is an argument you could make agai=
nst lambdas. But we still have them. Why?</div><div><br></div><div>Because =
the benefits outweigh the costs.</div></div></blockquote><div><br></div><di=
v></div><div>Your comparison to lambdas would have been correct only if we =
had a concurrent terse lambda proposal being developed <i>at the same time<=
/i> as the regular one.=C2=A0</div></div></blockquote><div><br></div><div>B=
ut <i>they did</i>. Go look at some of the old lambda proposals. There were=
 ideas about dropping the parameter typename identifiers and so forth even =
back then. They didn&#39;t pan out, but there was discussion about them con=
currently with the broader lambda syntax. And such things would have been o=
ptional rather than mandatory.</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>Even worse - to have the terse l=
ambda blocking normal lambda. Because we are there with Concepts. <br></div=
></div></blockquote><div><br></div><div>Since when has terse templates bloc=
ked concepts? The Concepts TS wasn&#39;t ready for C++17; questions about t=
erse syntax were just <a href=3D"http://honermann.net/blog/?p=3D3">one of t=
he reasons why</a>. And Concepts-sans-terse syntax was voted into C++20 las=
t year. So we aren&#39;t &quot;there&quot; at all.</div><div><br></div><div=
>Not unless one of the 5 national bodies is threatening not to vote for C++=
20 <i>without</i> some form of terse templates.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/3c5f8766-9ef4-46be-a9c2-7b5f9c7f5ee7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c5f8766-9ef4-46be-a9c2-7b5f9c7f5ee7=
%40isocpp.org</a>.<br />

------=_Part_25756_1447408432.1529435735000--

------=_Part_25755_1105823836.1529435734999--

.

------=_Part_26143_1961796449.1529441827150
Content-Type: multipart/alternative;
 boundary="----=_Part_26144_1496892256.1529441827151"

------=_Part_26144_1496892256.1529441827151
Content-Type: text/plain; charset="UTF-8"



On Tuesday, June 19, 2018 at 10:15:35 PM UTC+3, Nicol Bolas wrote:
>
> On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, mihailn...@gmail.com wrote:
>>
>> On Tuesday, June 19, 2018 at 8:38:01 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Tuesday, June 19, 2018 at 12:32:37 PM UTC-4, mihailn...@gmail.com
>>> wrote:
>>>>
>>>> On Tuesday, June 19, 2018 at 5:49:49 PM UTC+3, Nicol Bolas wrote:
>>>>>
>>>>> On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, mihailn...@gmail.com
>>>>> wrote:
>>>>>>
>>>>>> OK, right now in flight are about FOUR proposals, trying to
>>>>>> "simplify" and "make more clear" concepts usage.
>>>>>>
>>>>>> This is madness. It is madness, because NONE of it make it more
>>>>>> clear! None.
>>>>>>
>>>>>> By inviting new language constructs one does not make things "more
>>>>>> clear", it only adds more things to learn.
>>>>>>
>>>>>> The worst part is - *we have working solution that is clear. Granted
>>>>>> verbose, but clear. *
>>>>>>
>>>>>> If one makes it Not verbose but Not clear (not self-explanatory, need
>>>>>> learning) also one gains nothing!
>>>>>>
>>>>>
>>>>> Clarity is ultimately a measure of time. Variadic templates are not
>>>>> "clear" to people who've never seen them. UDLs are not "clear" to people
>>>>> who've never seen them. Lambdas are not "clear" to people who've never seen
>>>>> them. Structured bindings are not "clear" to people who've never seen them.
>>>>> And God knows rvalue references and forwarding references would utterly
>>>>> baffle people who've never seen them.
>>>>>
>>>>> All of these things are clear to us now because we are *used to them*.
>>>>> That's the only reason why they are clear. Your hypothetical time traveler
>>>>> from the C++98/03 days would be confused by the simplest of modern C++11
>>>>> code.
>>>>>
>>>>> And that's OK.
>>>>>
>>>>
>>>> But the problem is *we have* syntax that is clear to old user, even if
>>>> it is new!
>>>>
>>>
>>> So what? That doesn't make syntax that isn't clear to old users a priori
>>> bad. Syntax should be judged on its own merits, not on the merits of some
>>> hypothetical user who hasn't kept up with the language in a decade.
>>>
>>> Saying that a syntax is wrong just because we're not used to it is not
>>>>> helpful. It's far more useful to look at things from a cost/benefit
>>>>> analysis.
>>>>>
>>>>> Lambdas are probably the best example, because they don't do
>>>>> *anything* that you couldn't do yourself, either with in-situ struct
>>>>> declarations or out-of-function declarations. So their benefit is purely
>>>>> convenience.
>>>>>
>>>>> Lambdas have a *huge* syntactic cost. They have novel introduction
>>>>> syntax, re-appropriating something that looks like an array into a
>>>>> function/class declaration. They are functions that can be declared without
>>>>> parameters, without even `()`. They deduce the return value unless you
>>>>> specify otherwise. They allow `auto` in parameter lists. They can capture
>>>>> values/expressions in a myriad of ways. And so forth.
>>>>>
>>>>> All of this represents a syntactic variance relative to regular
>>>>> functions. And thus, it is a burden, a cost for entry that people have to
>>>>> learn.
>>>>>
>>>>> But all of those costs pale into insignificance next to the *gains*
>>>>> from the syntax. Lambdas are game-changers for C++. Pre-C++11, people would
>>>>> avoid simple algorithms like `transform`, because writing out the
>>>>> equivalent code was often easier than providing a functor. That's no longer
>>>>> the case.
>>>>>
>>>>
>>>>> Now, I'm not saying that any of the terse syntaxes are as valuable as
>>>>> lambdas are. But my point is that novel syntax should not be avoided simply
>>>>> because it is novel; you *have* to look at the benefits of it.
>>>>>
>>>>
>>>> 'requires' is the similar of lambdas; in place of the enable_if magic.
>>>> It is new syntax, yet clear.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> This is the reason why I hate concept introduction syntax. It's not
>>>>> that it has novel syntax; it's that the novel syntax doesn't buy much. Yes,
>>>>> concept introduction is shorter than the full `requires` clause. But it's
>>>>> not shorter *enough* in enough cases to be worth the syntactic burden.
>>>>>
>>>>
>>>> I agree 100% obviously.
>>>>
>>>>
>>>>>
>>>>> The nice thing about Herb's syntax is how regular it is. It works the
>>>>> same everywhere. It provides the same benefit everywhere. It may be novel
>>>>> syntax, but it solves many problems due to its regularity. It allows you to
>>>>> concisely fairly obvious things.
>>>>>
>>>>
>>>> Sorry, but that syntax is literally taking the hated introduction
>>>> syntax and splatting it all over the entire Concepts proposal just to be
>>>> "consistent"!
>>>>
>>>
>>> This is why your "I agree 100% obviously" is incorrect. You agree with
>>> my *conclusion*, not my *reasoning*.
>>>
>>> I dislike the concept introduction syntax for the reasons I specified:
>>> it does not carry its own weight. The syntax does not provide nearly enough
>>> benefits compared to its cost.
>>>
>>> By "splatting it all over the entire Concepts proposal", the syntax
>>> gains additional benefits. For example:
>>>
>>> void forward_func(Concept{Typename} &&t)
>>> {
>>>   func(std::forward<Typename>(t));
>>> }
>>>
>>> See? No `decltype(t)` gymnastics.
>>>
>>> Similarly, I can do this:
>>>
>>> void func(Iterator{It} first, It last)
>>> {
>>> }
>>>
>>> And that spells out exactly what it means. Sure, I could have used
>>> `template<Iterator It>`, but this is shorter without losing meaning. Yes,
>>> you have to learn what that means, but in a lambda, this is worthwhile:
>>>
>>> [](Iterator{It} first, It last) {...}
>>>
>>> vs.
>>>
>>> []<Iterator It>(It first, It last) {...}
>>>
>>> Now these aren't huge differences. They're not universe-changing,
>>> world-shaking benefits. But they're *significant*, and to me, they
>>> allow this syntax to carry its own weight. Learning this syntax pays for
>>> itself in making concepts more usable.
>>>
>>
>> Are they significant enough to add de facto *brand new syntax*?
>>
>
> That's a judgement call, but I would say "yes".
>
> A syntax which *could* be used for something else in a decade?
>>
>
> OK, so let's review the two syntaxes in question (because the committee
> has essentially boiled them down to just two).
>
> There's Herb's proposal, which is `ConceptName{stuff}`. And there's the
> Concepts TS terse syntax but with `template` applied to functions that use
> them (except for lambdas which get it without `template`).
>
> What could you use `ConceptName{stuff}` for in the future? Do you have any
> ideas at all where such syntax might be useful?
>


Something{stuff} was already considered for structured bindings.

I don't know what the future holds, but we are clearly chipping away syntax
ground just for an alternative.


>
> Similarly, what would `template <function definition>` mean in some
> hypothetical future?
>
> I understand and appreciate the idea of not burning precious syntax for
> trivial things. But we're not talking about prime syntactic real estate
> here.
>
> A syntax that does not introduce new features, but only adds second, even
>> *third* way of doing the same thing?
>>
>
> It doesn't matter how many ways there are of doing something. What matters
> is whether those ways are clear and convenient to use. Template headers are
> clear but inconvenient.
>
>
>>> And it is syntax for the sake of syntax because it is not technically
>>>> needed - no problem to be solved.
>>>>
>>>
>>> So are lambdas. As I pointed out, there is no technical reason why you
>>> cannot replace every lambda ever with a user-written type.
>>>
>>> And, as said it has nasty problems, from the fact it is not obvious in
>>>> *any* way, to the metal overlap with initialization.
>>>>
>>>> Number{} x;
>>>> x = Number{};
>>>>
>>>> And again NO PROBLEM NEEDS SOLVING! None.
>>>>
>>>>
>>>>>
>>>>> Now, you may argue that no terse syntax is worth the syntactic burden.
>>>>> I rather disagree: there are too many cases where the function parameters
>>>>> and template parameters match each other to say that making that function
>>>>> declaration shorter isn't worth the time and effort. Applying concepts to
>>>>> variables, even function parameters, makes too much sense to not be worth
>>>>> pursuing.
>>>>>
>>>>
>>>> Ok, however these are "nice" and nice things can wait, there is no
>>>> pressing issue here!
>>>>
>>>
>>> Concepts are "nice things" too. But I think we can all agree we've
>>> waited too long for them.
>>>
>>
>>>
>>>> Second, in 10+ years the results ARE WORSE. All of them!
>>>>
>>>
>>> ... huh?
>>>
>>>
>>>> Third the real community is still to have its say. Any additional
>>>> syntax should wait for the real feedback and the real requirements.
>>>>
>>>
>>> Every argument you make after this point against terse templates is an
>>> argument you could make against lambdas. But we still have them. Why?
>>>
>>> Because the benefits outweigh the costs.
>>>
>>
>> Your comparison to lambdas would have been correct only if we had a
>> concurrent terse lambda proposal being developed *at the same time* as
>> the regular one.
>>
>
> But *they did*. Go look at some of the old lambda proposals. There were
> ideas about dropping the parameter typename identifiers and so forth even
> back then. They didn't pan out, but there was discussion about them
> concurrently with the broader lambda syntax. And such things would have
> been optional rather than mandatory.
>
> Even worse - to have the terse lambda blocking normal lambda. Because we
>> are there with Concepts.
>>
>
> Since when has terse templates blocked concepts? The Concepts TS wasn't
> ready for C++17; questions about terse syntax were just one of the
> reasons why
> <http://www.google.com/url?q=http%3A%2F%2Fhonermann.net%2Fblog%2F%3Fp%3D3&sa=D&sntz=1&usg=AFQjCNEIAcV_kxryMk-8pmStWPXQ492S9w>.
> And Concepts-sans-terse syntax was voted into C++20 last year. So we aren't
> "there" at all.
>
> Not unless one of the 5 national bodies is threatening not to vote for
> C++20 *without* some form of terse templates.
>

Funny how we both have commented under that report (not that I remember!).

In any case Concepts-sans-terse is not frozen. And that is what worries me.
On the plus side, it seems the name introducers are *not* in as well so
there is still hope.

--
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/f866bc73-ddd3-43a6-82db-b977c90c09b1%40isocpp.org.

------=_Part_26144_1496892256.1529441827151
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, June 19, 2018 at 10:15:35 PM UTC+3, Ni=
col Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, <a>mihailn...@gmail.com</=
a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesda=
y, June 19, 2018 at 8:38:01 PM UTC+3, Nicol Bolas wrote:<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">On Tuesday, June 19, 2018 at 12:32:=
37 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">On Tuesday, June 19, 2018 at 5:49:49 PM UTC+3,=
 Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, <a>mihailn...@gmail.com</a>=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>OK, ri=
ght now in flight are about FOUR proposals, trying to &quot;simplify&quot; =
and &quot;make more clear&quot; concepts usage.</div><div><br></div><div>Th=
is is madness. It is madness, because NONE of it make it more clear! None.=
=C2=A0</div><div><br></div><div>By inviting new language constructs one doe=
s not make things &quot;more clear&quot;, it only adds more things to learn=
..</div><div><br></div><div>The worst part is - <i>we have working solution =
that is clear. Granted verbose, but clear.=C2=A0</i></div><div><i></i><br><=
/div><div>If one makes it Not verbose but Not clear (not self-explanatory, =
need learning) also one gains nothing!</div></div></blockquote><div><br></d=
iv><div>Clarity is ultimately a measure of time. Variadic templates are not=
 &quot;clear&quot; to people who&#39;ve never seen them. UDLs are not &quot=
;clear&quot; to people who&#39;ve never seen them. Lambdas are not &quot;cl=
ear&quot; to people who&#39;ve never seen them. Structured bindings are not=
 &quot;clear&quot; to people who&#39;ve never seen them. And God knows rval=
ue references and forwarding references would utterly baffle people who&#39=
;ve never seen them.</div><div><br></div><div>All of these things are clear=
 to us now because we are <i>used to them</i>. That&#39;s the only reason w=
hy they are clear. Your hypothetical time traveler from the C++98/03 days w=
ould be confused by the simplest of modern C++11 code.</div><div><br></div>=
<div>And that&#39;s OK.</div></div></blockquote><div><br></div><div>But the=
 problem is <i>we have</i> syntax that is clear to old user, even if it is =
new!</div></div></blockquote><div><br></div><div>So what? That doesn&#39;t =
make syntax that isn&#39;t clear to old users a priori bad. Syntax should b=
e judged on its own merits, not on the merits of some hypothetical user who=
 hasn&#39;t kept up with the language in a decade.<br></div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></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></div><div>Saying th=
at a syntax is wrong just because we&#39;re not used to it is not helpful. =
It&#39;s far more useful to look at things from a cost/benefit analysis.</d=
iv><div><br></div><div>Lambdas are probably the best example, because they =
don&#39;t do <i>anything</i> that you couldn&#39;t do yourself, either with=
 in-situ struct declarations or out-of-function declarations. So their bene=
fit is purely convenience.<br></div><div><br></div><div>Lambdas have a <i>h=
uge</i> syntactic cost. They have novel introduction syntax, re-appropriati=
ng something that looks like an array into a function/class declaration. Th=
ey are functions that can be declared without parameters, without even `()`=
.. They deduce the return value unless you specify otherwise. They allow `au=
to` in parameter lists. They can capture values/expressions in a myriad of =
ways. And so forth.</div><div><br></div><div>All of this represents a synta=
ctic variance relative to regular functions. And thus, it is a burden, a co=
st for entry that people have to learn.</div><div><br></div><div>But all of=
 those costs pale into insignificance next to the <i>gains</i> from the syn=
tax. Lambdas are game-changers for C++. Pre-C++11, people would avoid simpl=
e algorithms like `transform`, because writing out the equivalent code was =
often easier than providing a functor. That&#39;s no longer the case.=C2=A0=
</div></div></blockquote><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><br></div><div>Now, I&#39;m not saying that any of the terse =
syntaxes are as valuable as lambdas are. But my point is that novel syntax =
should not be avoided simply because it is novel; you <i>have</i> to look a=
t the benefits of it.</div></div></blockquote><div><br></div><div></div><di=
v><span style=3D"display:inline!important;float:none;background-color:trans=
parent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&qu=
ot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-we=
ight:400;letter-spacing:normal;text-align:left;text-decoration:none;text-in=
dent:0px;text-transform:none;white-space:normal;word-spacing:0px">&#39;requ=
ires&#39; is the similar of lambdas; in place of the enable_if magic. It is=
 new syntax, yet clear.</span></div><div><br></div><div><br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>=
</div><div>This is the reason why I hate concept introduction syntax. It&#3=
9;s not that it has novel syntax; it&#39;s that the novel syntax doesn&#39;=
t buy much. Yes, concept introduction is shorter than the full `requires` c=
lause. But it&#39;s not shorter <i>enough</i> in enough cases to be worth t=
he syntactic burden.</div></div></blockquote><div><br></div><div>I agree 10=
0% obviously.=C2=A0</div><div>=C2=A0</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><br></div><div>The nice thing about Herb&#39;s=
 syntax is how regular it is. It works the same everywhere. It provides the=
 same benefit everywhere. It may be novel syntax, but it solves many proble=
ms due to its regularity. It allows you to concisely fairly obvious things.=
</div></div></blockquote><div><br></div><div>Sorry, but that syntax is lite=
rally taking the hated introduction syntax and splatting it all over the en=
tire Concepts proposal just to be &quot;consistent&quot;!</div></div></bloc=
kquote><div><br></div><div>This is why your &quot;I agree 100% obviously&qu=
ot; is incorrect. You agree with my <i>conclusion</i>, not my <i>reasoning<=
/i>.</div><div><br></div><div>I dislike the concept introduction syntax for=
 the reasons I specified: it does not carry its own weight. The syntax does=
 not provide nearly enough benefits compared to its cost.</div><div><br></d=
iv><div>By &quot;splatting it all over the entire Concepts proposal&quot;, =
the syntax gains additional benefits. For example:</div><div><br></div><div=
 style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);b=
order-style:solid;border-width:1px"><code><div><span style=3D"color:#008">v=
oid</span><span style=3D"color:#000"> forward_func</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#606">Concept</span><span style=3D"co=
lor:#660">{</span><span style=3D"color:#606">Typename</span><span style=3D"=
color:#660">}</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">&amp;&amp;</span><span style=3D"color:#000">t</span><span style=3D"c=
olor:#660">)</span><span style=3D"color:#000"><br></span><span style=3D"col=
or:#660">{</span><span style=3D"color:#000"><br>=C2=A0 func</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">forward</span><span sty=
le=3D"color:#660">&lt;</span><span style=3D"color:#606">Typename</span><spa=
n style=3D"color:#660">&gt;(</span><span style=3D"color:#000">t</span><span=
 style=3D"color:#660">)<wbr>);</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#660">}</span><span style=3D"color:#000"><br></span></=
div></code></div><div><br></div><div>See? No `decltype(t)` gymnastics.</div=
><div><br></div><div>Similarly, I can do this:</div><div><br></div><div sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px"><code><div><span style=3D"color:#008">void<=
/span><span style=3D"color:#000"> func</span><span style=3D"color:#660">(</=
span><span style=3D"color:#606">Iterator</span><span style=3D"color:#660">{=
</span><span style=3D"color:#606">It</span><span style=3D"color:#660">}</sp=
an><span style=3D"color:#000"> first</span><span style=3D"color:#660">,</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#606">It</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">last</span><sp=
an style=3D"color:#660">)</span><span style=3D"color:#000"><br></span><span=
 style=3D"color:#660">{</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#660">}</span></div></code></div><div><br></div><div></div><d=
iv>And that spells out exactly what it means. Sure, I could have used `temp=
late&lt;Iterator It&gt;`, but this is shorter without losing meaning. Yes, =
you have to learn what that means, but in a lambda, this is worthwhile:</di=
v><div><br></div><div style=3D"background-color:rgb(250,250,250);border-col=
or:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span s=
tyle=3D"color:#660">[](</span><span style=3D"color:#606">Iterator</span><sp=
an style=3D"color:#660">{</span><span style=3D"color:#606">It</span><span s=
tyle=3D"color:#660">}</span><span style=3D"color:#000"> first</span><span s=
tyle=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">It</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">last</span><span style=3D"color:#660">)</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">{...}</span><span style=3D"col=
or:#000"><br><br>vs</span><span style=3D"color:#660">.</span><span style=3D=
"color:#000"><br><br></span><span style=3D"color:#660">[]&lt;</span><span s=
tyle=3D"color:#606">Iterator</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#606">It</span><span style=3D"color:#660">&gt;(</span><span=
 style=3D"color:#606">It</span><span style=3D"color:#000"> first</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#606">It</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">last</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{...}</span></div></code=
></div><div><br>Now these aren&#39;t huge differences. They&#39;re not univ=
erse-changing, world-shaking benefits. But they&#39;re <i>significant</i>, =
and to me, they allow this syntax to carry its own weight. Learning this sy=
ntax pays for itself in making concepts more usable.</div></div></blockquot=
e><div><br></div><div>Are they significant enough to add de facto <i>brand =
new syntax</i>?</div></div></blockquote><div><br></div><div>That&#39;s a ju=
dgement call, but I would say &quot;yes&quot;.<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>A syntax which <i=
>could</i> be used for something else in a decade?</div></div></blockquote>=
<div><br></div><div>OK, so let&#39;s review the two syntaxes in question (b=
ecause the committee has essentially boiled them down to just two).</div><d=
iv><br></div><div>There&#39;s Herb&#39;s proposal, which is `ConceptName{st=
uff}`. And there&#39;s the Concepts TS terse syntax but with `template` app=
lied to functions that use them (except for lambdas which get it without `t=
emplate`).</div><div><br></div><div>What could you use `ConceptName{stuff}`=
 for in the future? Do you have any ideas at all where such syntax might be=
 useful?</div></div></blockquote><div><br></div><div><br></div><div>Somethi=
ng{stuff} was already considered for structured bindings.=C2=A0</div><div><=
br></div><div>I don&#39;t know what the future holds, but we are clearly ch=
ipping away syntax ground just for an alternative.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div>=
<div>Similarly, what would `template &lt;function definition&gt;` mean in s=
ome hypothetical future?</div><div><br></div><div>I understand and apprecia=
te the idea of not burning precious syntax for trivial things. But we&#39;r=
e not talking about prime syntactic real estate here.<br></div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>A syntax t=
hat does not introduce new features, but only adds second, even <i>third</i=
> way of doing the same thing?<br></div></div></blockquote><div><br></div><=
div>It doesn&#39;t matter how many ways there are of doing something. What =
matters is whether those ways are clear and convenient to use. Template hea=
ders are clear but inconvenient.<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><b></b><i></i><u></=
u><sub></sub><sup></sup><strike></strike><font face=3D"courier new,monospac=
e"></font></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><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>=
And it is syntax for the sake of syntax because it is not technically neede=
d - no problem to be solved.=C2=A0</div></div></blockquote><div><br></div><=
div>So are lambdas. As I pointed out, there is no technical reason why you =
cannot replace every lambda ever with a user-written type.</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><di=
v>And, as said it has nasty problems, from the fact it is not obvious in <i=
>any</i> way, to the metal overlap with initialization.</div><div><br></div=
><div><font face=3D"courier new,monospace">Number{} x;</font></div><div><fo=
nt face=3D"courier new,monospace">x =3D Number{};</font></div><div><font fa=
ce=3D"courier new,monospace"></font><br></div><div>And again NO PROBLEM NEE=
DS SOLVING! None.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><br></div><div>Now, you may argue that no =
terse syntax is worth the syntactic burden. I rather disagree: there are to=
o many cases where the function parameters and template parameters match ea=
ch other to say that making that function declaration shorter isn&#39;t wor=
th the time and effort. Applying concepts to variables, even function param=
eters, makes too much sense to not be worth pursuing.<br></div></div></bloc=
kquote><div><br></div><div>Ok, however these are &quot;nice&quot; and nice =
things can wait, there is no pressing issue here!</div></div></blockquote><=
div><br></div><div>Concepts are &quot;nice things&quot; too. But I think we=
 can all agree we&#39;ve waited too long for them.<br></div></div></blockqu=
ote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>Second, in 10+ years the results ARE WORSE. All of them!</div></div></bloc=
kquote><div><br></div><div>... huh?<br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>Third the real community i=
s still to have its say. Any additional syntax should wait for the real fee=
dback and the real requirements.</div></div></blockquote><div><br></div><di=
v>Every argument you make after this point against terse templates is an ar=
gument you could make against lambdas. But we still have them. Why?</div><d=
iv><br></div><div>Because the benefits outweigh the costs.</div></div></blo=
ckquote><div><br></div><div></div><div>Your comparison to lambdas would hav=
e been correct only if we had a concurrent terse lambda proposal being deve=
loped <i>at the same time</i> as the regular one.=C2=A0</div></div></blockq=
uote><div><br></div><div>But <i>they did</i>. Go look at some of the old la=
mbda proposals. There were ideas about dropping the parameter typename iden=
tifiers and so forth even back then. They didn&#39;t pan out, but there was=
 discussion about them concurrently with the broader lambda syntax. And suc=
h things would have been optional rather than mandatory.</div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Even worse =
- to have the terse lambda blocking normal lambda. Because we are there wit=
h Concepts. <br></div></div></blockquote><div><br></div><div>Since when has=
 terse templates blocked concepts? The Concepts TS wasn&#39;t ready for C++=
17; questions about terse syntax were just <a onmousedown=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fhonermann.net%2Fblog%2F%3Fp%=
3D3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEIAcV_kxryMk-8pmStWPXQ492S9w&#3=
9;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3=
dhttp%3A%2F%2Fhonermann.net%2Fblog%2F%3Fp%3D3\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNEIAcV_kxryMk-8pmStWPXQ492S9w&#39;;return true;" href=3D"http://w=
ww.google.com/url?q=3Dhttp%3A%2F%2Fhonermann.net%2Fblog%2F%3Fp%3D3&amp;sa=
=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNEIAcV_kxryMk-8pmStWPXQ492S9w" target=3D"_=
blank" rel=3D"nofollow">one of the reasons why</a>. And Concepts-sans-terse=
 syntax was voted into C++20 last year. So we aren&#39;t &quot;there&quot; =
at all.</div><div><br></div><div>Not unless one of the 5 national bodies is=
 threatening not to vote for C++20 <i>without</i> some form of terse templa=
tes.<br></div></div></blockquote><div><br></div><div>Funny how we both have=
 commented under that report (not that I remember!).=C2=A0</div><div><br></=
div><div>In any case Concepts<span style=3D"display: inline !important; flo=
at: none; background-color: transparent; color: rgb(34, 34, 34); font-famil=
y: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; fon=
t-style: normal; font-variant: normal; font-weight: 400; letter-spacing: no=
rmal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;">-sans-terse</span> is not frozen. And that is what wo=
rries me.=C2=A0</div><div>On the plus side, it seems the name introducers a=
re <i>not</i> in as well so there is still hope.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/f866bc73-ddd3-43a6-82db-b977c90c09b1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f866bc73-ddd3-43a6-82db-b977c90c09b1=
%40isocpp.org</a>.<br />

------=_Part_26144_1496892256.1529441827151--

------=_Part_26143_1961796449.1529441827150--

.

--00000000000049881d056f05e496
Content-Type: text/plain; charset="UTF-8"

The Concept{} syntax could be used for archetypes.

G

On Tue, Jun 19, 2018, 21:57 <mihailnajdenov@gmail.com> wrote:

>
>
> On Tuesday, June 19, 2018 at 10:15:35 PM UTC+3, Nicol Bolas wrote:
>>
>> On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> On Tuesday, June 19, 2018 at 8:38:01 PM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Tuesday, June 19, 2018 at 12:32:37 PM UTC-4, mihailn...@gmail.com
>>>> wrote:
>>>>>
>>>>> On Tuesday, June 19, 2018 at 5:49:49 PM UTC+3, Nicol Bolas wrote:
>>>>>>
>>>>>> On Tuesday, June 19, 2018 at 5:33:54 AM UTC-4, mihailn...@gmail.com
>>>>>> wrote:
>>>>>>>
>>>>>>> OK, right now in flight are about FOUR proposals, trying to
>>>>>>> "simplify" and "make more clear" concepts usage.
>>>>>>>
>>>>>>> This is madness. It is madness, because NONE of it make it more
>>>>>>> clear! None.
>>>>>>>
>>>>>>> By inviting new language constructs one does not make things "more
>>>>>>> clear", it only adds more things to learn.
>>>>>>>
>>>>>>> The worst part is - *we have working solution that is clear.
>>>>>>> Granted verbose, but clear. *
>>>>>>>
>>>>>>> If one makes it Not verbose but Not clear (not self-explanatory,
>>>>>>> need learning) also one gains nothing!
>>>>>>>
>>>>>>
>>>>>> Clarity is ultimately a measure of time. Variadic templates are not
>>>>>> "clear" to people who've never seen them. UDLs are not "clear" to people
>>>>>> who've never seen them. Lambdas are not "clear" to people who've never seen
>>>>>> them. Structured bindings are not "clear" to people who've never seen them.
>>>>>> And God knows rvalue references and forwarding references would utterly
>>>>>> baffle people who've never seen them.
>>>>>>
>>>>>> All of these things are clear to us now because we are *used to them*.
>>>>>> That's the only reason why they are clear. Your hypothetical time traveler
>>>>>> from the C++98/03 days would be confused by the simplest of modern C++11
>>>>>> code.
>>>>>>
>>>>>> And that's OK.
>>>>>>
>>>>>
>>>>> But the problem is *we have* syntax that is clear to old user, even
>>>>> if it is new!
>>>>>
>>>>
>>>> So what? That doesn't make syntax that isn't clear to old users a
>>>> priori bad. Syntax should be judged on its own merits, not on the merits of
>>>> some hypothetical user who hasn't kept up with the language in a decade.
>>>>
>>>> Saying that a syntax is wrong just because we're not used to it is not
>>>>>> helpful. It's far more useful to look at things from a cost/benefit
>>>>>> analysis.
>>>>>>
>>>>>> Lambdas are probably the best example, because they don't do
>>>>>> *anything* that you couldn't do yourself, either with in-situ struct
>>>>>> declarations or out-of-function declarations. So their benefit is purely
>>>>>> convenience.
>>>>>>
>>>>>> Lambdas have a *huge* syntactic cost. They have novel introduction
>>>>>> syntax, re-appropriating something that looks like an array into a
>>>>>> function/class declaration. They are functions that can be declared without
>>>>>> parameters, without even `()`. They deduce the return value unless you
>>>>>> specify otherwise. They allow `auto` in parameter lists. They can capture
>>>>>> values/expressions in a myriad of ways. And so forth.
>>>>>>
>>>>>> All of this represents a syntactic variance relative to regular
>>>>>> functions. And thus, it is a burden, a cost for entry that people have to
>>>>>> learn.
>>>>>>
>>>>>> But all of those costs pale into insignificance next to the *gains*
>>>>>> from the syntax. Lambdas are game-changers for C++. Pre-C++11, people would
>>>>>> avoid simple algorithms like `transform`, because writing out the
>>>>>> equivalent code was often easier than providing a functor. That's no longer
>>>>>> the case.
>>>>>>
>>>>>
>>>>>> Now, I'm not saying that any of the terse syntaxes are as valuable as
>>>>>> lambdas are. But my point is that novel syntax should not be avoided simply
>>>>>> because it is novel; you *have* to look at the benefits of it.
>>>>>>
>>>>>
>>>>> 'requires' is the similar of lambdas; in place of the enable_if magic.
>>>>> It is new syntax, yet clear.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> This is the reason why I hate concept introduction syntax. It's not
>>>>>> that it has novel syntax; it's that the novel syntax doesn't buy much. Yes,
>>>>>> concept introduction is shorter than the full `requires` clause. But it's
>>>>>> not shorter *enough* in enough cases to be worth the syntactic
>>>>>> burden.
>>>>>>
>>>>>
>>>>> I agree 100% obviously.
>>>>>
>>>>>
>>>>>>
>>>>>> The nice thing about Herb's syntax is how regular it is. It works the
>>>>>> same everywhere. It provides the same benefit everywhere. It may be novel
>>>>>> syntax, but it solves many problems due to its regularity. It allows you to
>>>>>> concisely fairly obvious things.
>>>>>>
>>>>>
>>>>> Sorry, but that syntax is literally taking the hated introduction
>>>>> syntax and splatting it all over the entire Concepts proposal just to be
>>>>> "consistent"!
>>>>>
>>>>
>>>> This is why your "I agree 100% obviously" is incorrect. You agree with
>>>> my *conclusion*, not my *reasoning*.
>>>>
>>>> I dislike the concept introduction syntax for the reasons I specified:
>>>> it does not carry its own weight. The syntax does not provide nearly enough
>>>> benefits compared to its cost.
>>>>
>>>> By "splatting it all over the entire Concepts proposal", the syntax
>>>> gains additional benefits. For example:
>>>>
>>>> void forward_func(Concept{Typename} &&t)
>>>> {
>>>>   func(std::forward<Typename>(t));
>>>> }
>>>>
>>>> See? No `decltype(t)` gymnastics.
>>>>
>>>> Similarly, I can do this:
>>>>
>>>> void func(Iterator{It} first, It last)
>>>> {
>>>> }
>>>>
>>>> And that spells out exactly what it means. Sure, I could have used
>>>> `template<Iterator It>`, but this is shorter without losing meaning. Yes,
>>>> you have to learn what that means, but in a lambda, this is worthwhile:
>>>>
>>>> [](Iterator{It} first, It last) {...}
>>>>
>>>> vs.
>>>>
>>>> []<Iterator It>(It first, It last) {...}
>>>>
>>>> Now these aren't huge differences. They're not universe-changing,
>>>> world-shaking benefits. But they're *significant*, and to me, they
>>>> allow this syntax to carry its own weight. Learning this syntax pays for
>>>> itself in making concepts more usable.
>>>>
>>>
>>> Are they significant enough to add de facto *brand new syntax*?
>>>
>>
>> That's a judgement call, but I would say "yes".
>>
>> A syntax which *could* be used for something else in a decade?
>>>
>>
>> OK, so let's review the two syntaxes in question (because the committee
>> has essentially boiled them down to just two).
>>
>> There's Herb's proposal, which is `ConceptName{stuff}`. And there's the
>> Concepts TS terse syntax but with `template` applied to functions that use
>> them (except for lambdas which get it without `template`).
>>
>> What could you use `ConceptName{stuff}` for in the future? Do you have
>> any ideas at all where such syntax might be useful?
>>
>
>
> Something{stuff} was already considered for structured bindings.
>
> I don't know what the future holds, but we are clearly chipping away
> syntax ground just for an alternative.
>
>
>>
>> Similarly, what would `template <function definition>` mean in some
>> hypothetical future?
>>
>> I understand and appreciate the idea of not burning precious syntax for
>> trivial things. But we're not talking about prime syntactic real estate
>> here.
>>
>> A syntax that does not introduce new features, but only adds second, even
>>> *third* way of doing the same thing?
>>>
>>
>> It doesn't matter how many ways there are of doing something. What
>> matters is whether those ways are clear and convenient to use. Template
>> headers are clear but inconvenient.
>>
>>
>>>> And it is syntax for the sake of syntax because it is not technically
>>>>> needed - no problem to be solved.
>>>>>
>>>>
>>>> So are lambdas. As I pointed out, there is no technical reason why you
>>>> cannot replace every lambda ever with a user-written type.
>>>>
>>>> And, as said it has nasty problems, from the fact it is not obvious in
>>>>> *any* way, to the metal overlap with initialization.
>>>>>
>>>>> Number{} x;
>>>>> x = Number{};
>>>>>
>>>>> And again NO PROBLEM NEEDS SOLVING! None.
>>>>>
>>>>>
>>>>>>
>>>>>> Now, you may argue that no terse syntax is worth the syntactic
>>>>>> burden. I rather disagree: there are too many cases where the function
>>>>>> parameters and template parameters match each other to say that making that
>>>>>> function declaration shorter isn't worth the time and effort. Applying
>>>>>> concepts to variables, even function parameters, makes too much sense to
>>>>>> not be worth pursuing.
>>>>>>
>>>>>
>>>>> Ok, however these are "nice" and nice things can wait, there is no
>>>>> pressing issue here!
>>>>>
>>>>
>>>> Concepts are "nice things" too. But I think we can all agree we've
>>>> waited too long for them.
>>>>
>>>
>>>>
>>>>> Second, in 10+ years the results ARE WORSE. All of them!
>>>>>
>>>>
>>>> ... huh?
>>>>
>>>>
>>>>> Third the real community is still to have its say. Any additional
>>>>> syntax should wait for the real feedback and the real requirements.
>>>>>
>>>>
>>>> Every argument you make after this point against terse templates is an
>>>> argument you could make against lambdas. But we still have them. Why?
>>>>
>>>> Because the benefits outweigh the costs.
>>>>
>>>
>>> Your comparison to lambdas would have been correct only if we had a
>>> concurrent terse lambda proposal being developed *at the same time* as
>>> the regular one.
>>>
>>
>> But *they did*. Go look at some of the old lambda proposals. There were
>> ideas about dropping the parameter typename identifiers and so forth even
>> back then. They didn't pan out, but there was discussion about them
>> concurrently with the broader lambda syntax. And such things would have
>> been optional rather than mandatory.
>>
>> Even worse - to have the terse lambda blocking normal lambda. Because we
>>> are there with Concepts.
>>>
>>
>> Since when has terse templates blocked concepts? The Concepts TS wasn't
>> ready for C++17; questions about terse syntax were just one of the
>> reasons why
>> <http://www.google.com/url?q=http%3A%2F%2Fhonermann.net%2Fblog%2F%3Fp%3D3&sa=D&sntz=1&usg=AFQjCNEIAcV_kxryMk-8pmStWPXQ492S9w>.
>> And Concepts-sans-terse syntax was voted into C++20 last year. So we aren't
>> "there" at all.
>>
>> Not unless one of the 5 national bodies is threatening not to vote for
>> C++20 *without* some form of terse templates.
>>
>
> Funny how we both have commented under that report (not that I remember!).
>
> In any case Concepts-sans-terse is not frozen. And that is what worries
> me.
> On the plus side, it seems the name introducers are *not* in as well so
> there is still hope.
>
> --
> 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/f866bc73-ddd3-43a6-82db-b977c90c09b1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f866bc73-ddd3-43a6-82db-b977c90c09b1%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkX%2BXuUaEKOEChU9dhu%2BZThbiAwq683tLZn5Z7qmuLQBfQ%40mail.gmail.com.

--00000000000049881d056f05e496
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">The Concept{} syntax could be used for archetypes.<div di=
r=3D"auto"><br></div><div dir=3D"auto">G</div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr">On Tue, Jun 19, 2018, 21:57  &lt;<a href=3D"mailto=
:mihailnajdenov@gmail.com">mihailnajdenov@gmail.com</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Tuesday, June 1=
9, 2018 at 10:15:35 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4=
, <a rel=3D"noreferrer">mihailn...@gmail.com</a> wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">On Tuesday, June 19, 2018 at 8:38:01 P=
M UTC+3, Nicol Bolas wrote:<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">On Tuesday, June 19, 2018 at 12:32:37 PM UTC-4, <a rel=3D"noreferr=
er">mihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">On Tuesday, June 19, 2018 at 5:49:49 PM UTC+3, Nicol Bola=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday=
, June 19, 2018 at 5:33:54 AM UTC-4, <a rel=3D"noreferrer">mihailn...@gmail=
..com</a> wrote:<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>OK, right now in flight are about FOUR proposals, trying to &quot;simplif=
y&quot; and &quot;make more clear&quot; concepts usage.</div><div><br></div=
><div>This is madness. It is madness, because NONE of it make it more clear=
! None.=C2=A0</div><div><br></div><div>By inviting new language constructs =
one does not make things &quot;more clear&quot;, it only adds more things t=
o learn.</div><div><br></div><div>The worst part is - <i>we have working so=
lution that is clear. Granted verbose, but clear.=C2=A0</i></div><div><i></=
i><br></div><div>If one makes it Not verbose but Not clear (not self-explan=
atory, need learning) also one gains nothing!</div></div></blockquote><div>=
<br></div><div>Clarity is ultimately a measure of time. Variadic templates =
are not &quot;clear&quot; to people who&#39;ve never seen them. UDLs are no=
t &quot;clear&quot; to people who&#39;ve never seen them. Lambdas are not &=
quot;clear&quot; to people who&#39;ve never seen them. Structured bindings =
are not &quot;clear&quot; to people who&#39;ve never seen them. And God kno=
ws rvalue references and forwarding references would utterly baffle people =
who&#39;ve never seen them.</div><div><br></div><div>All of these things ar=
e clear to us now because we are <i>used to them</i>. That&#39;s the only r=
eason why they are clear. Your hypothetical time traveler from the C++98/03=
 days would be confused by the simplest of modern C++11 code.</div><div><br=
></div><div>And that&#39;s OK.</div></div></blockquote><div><br></div><div>=
But the problem is <i>we have</i> syntax that is clear to old user, even if=
 it is new!</div></div></blockquote><div><br></div><div>So what? That doesn=
&#39;t make syntax that isn&#39;t clear to old users a priori bad. Syntax s=
hould be judged on its own merits, not on the merits of some hypothetical u=
ser who hasn&#39;t kept up with the language in a decade.<br></div><div><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Sa=
ying that a syntax is wrong just because we&#39;re not used to it is not he=
lpful. It&#39;s far more useful to look at things from a cost/benefit analy=
sis.</div><div><br></div><div>Lambdas are probably the best example, becaus=
e they don&#39;t do <i>anything</i> that you couldn&#39;t do yourself, eith=
er with in-situ struct declarations or out-of-function declarations. So the=
ir benefit is purely convenience.<br></div><div><br></div><div>Lambdas have=
 a <i>huge</i> syntactic cost. They have novel introduction syntax, re-appr=
opriating something that looks like an array into a function/class declarat=
ion. They are functions that can be declared without parameters, without ev=
en `()`. They deduce the return value unless you specify otherwise. They al=
low `auto` in parameter lists. They can capture values/expressions in a myr=
iad of ways. And so forth.</div><div><br></div><div>All of this represents =
a syntactic variance relative to regular functions. And thus, it is a burde=
n, a cost for entry that people have to learn.</div><div><br></div><div>But=
 all of those costs pale into insignificance next to the <i>gains</i> from =
the syntax. Lambdas are game-changers for C++. Pre-C++11, people would avoi=
d simple algorithms like `transform`, because writing out the equivalent co=
de was often easier than providing a functor. That&#39;s no longer the case=
..=C2=A0</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><br></div><div>Now, I&#39;m not saying that any of the t=
erse syntaxes are as valuable as lambdas are. But my point is that novel sy=
ntax should not be avoided simply because it is novel; you <i>have</i> to l=
ook at the benefits of it.</div></div></blockquote><div><br></div><div></di=
v><div><span style=3D"display:inline!important;float:none;background-color:=
transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helveti=
ca&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;fo=
nt-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">&#39=
;requires&#39; is the similar of lambdas; in place of the enable_if magic. =
It is new syntax, yet clear.</span></div><div><br></div><div><br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<br></div><div>This is the reason why I hate concept introduction syntax. I=
t&#39;s not that it has novel syntax; it&#39;s that the novel syntax doesn&=
#39;t buy much. Yes, concept introduction is shorter than the full `require=
s` clause. But it&#39;s not shorter <i>enough</i> in enough cases to be wor=
th the syntactic burden.</div></div></blockquote><div><br></div><div>I agre=
e 100% obviously.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><br></div><div>The nice thing about Herb&#=
39;s syntax is how regular it is. It works the same everywhere. It provides=
 the same benefit everywhere. It may be novel syntax, but it solves many pr=
oblems due to its regularity. It allows you to concisely fairly obvious thi=
ngs.</div></div></blockquote><div><br></div><div>Sorry, but that syntax is =
literally taking the hated introduction syntax and splatting it all over th=
e entire Concepts proposal just to be &quot;consistent&quot;!</div></div></=
blockquote><div><br></div><div>This is why your &quot;I agree 100% obviousl=
y&quot; is incorrect. You agree with my <i>conclusion</i>, not my <i>reason=
ing</i>.</div><div><br></div><div>I dislike the concept introduction syntax=
 for the reasons I specified: it does not carry its own weight. The syntax =
does not provide nearly enough benefits compared to its cost.</div><div><br=
></div><div>By &quot;splatting it all over the entire Concepts proposal&quo=
t;, the syntax gains additional benefits. For example:</div><div><br></div>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px"><code><div><span style=3D"color:#00=
8">void</span><span style=3D"color:#000"> forward_func</span><span style=3D=
"color:#660">(</span><span style=3D"color:#606">Concept</span><span style=
=3D"color:#660">{</span><span style=3D"color:#606">Typename</span><span sty=
le=3D"color:#660">}</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">&amp;&amp;</span><span style=3D"color:#000">t</span><span styl=
e=3D"color:#660">)</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 func</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span=
 style=3D"color:#660">::</span><span style=3D"color:#000">forward</span><sp=
an style=3D"color:#660">&lt;</span><span style=3D"color:#606">Typename</spa=
n><span style=3D"color:#660">&gt;(</span><span style=3D"color:#000">t</span=
><span style=3D"color:#660">));</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></span><=
/div></code></div><div><br></div><div>See? No `decltype(t)` gymnastics.</di=
v><div><br></div><div>Similarly, I can do this:</div><div><br></div><div st=
yle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bord=
er-style:solid;border-width:1px"><code><div><span style=3D"color:#008">void=
</span><span style=3D"color:#000"> func</span><span style=3D"color:#660">(<=
/span><span style=3D"color:#606">Iterator</span><span style=3D"color:#660">=
{</span><span style=3D"color:#606">It</span><span style=3D"color:#660">}</s=
pan><span style=3D"color:#000"> first</span><span style=3D"color:#660">,</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#606">It</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#008">last</span><s=
pan style=3D"color:#660">)</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">{</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#660">}</span></div></code></div><div><br></div><div></div><=
div>And that spells out exactly what it means. Sure, I could have used `tem=
plate&lt;Iterator It&gt;`, but this is shorter without losing meaning. Yes,=
 you have to learn what that means, but in a lambda, this is worthwhile:</d=
iv><div><br></div><div style=3D"background-color:rgb(250,250,250);border-co=
lor:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span =
style=3D"color:#660">[](</span><span style=3D"color:#606">Iterator</span><s=
pan style=3D"color:#660">{</span><span style=3D"color:#606">It</span><span =
style=3D"color:#660">}</span><span style=3D"color:#000"> first</span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">It</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">last</span><span style=3D"color:#660">)</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">{...}</span><span style=3D"col=
or:#000"><br><br>vs</span><span style=3D"color:#660">.</span><span style=3D=
"color:#000"><br><br></span><span style=3D"color:#660">[]&lt;</span><span s=
tyle=3D"color:#606">Iterator</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#606">It</span><span style=3D"color:#660">&gt;(</span><span=
 style=3D"color:#606">It</span><span style=3D"color:#000"> first</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#606">It</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">last</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{...}</span></div></code=
></div><div><br>Now these aren&#39;t huge differences. They&#39;re not univ=
erse-changing, world-shaking benefits. But they&#39;re <i>significant</i>, =
and to me, they allow this syntax to carry its own weight. Learning this sy=
ntax pays for itself in making concepts more usable.</div></div></blockquot=
e><div><br></div><div>Are they significant enough to add de facto <i>brand =
new syntax</i>?</div></div></blockquote><div><br></div><div>That&#39;s a ju=
dgement call, but I would say &quot;yes&quot;.<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>A syntax which <i=
>could</i> be used for something else in a decade?</div></div></blockquote>=
<div><br></div><div>OK, so let&#39;s review the two syntaxes in question (b=
ecause the committee has essentially boiled them down to just two).</div><d=
iv><br></div><div>There&#39;s Herb&#39;s proposal, which is `ConceptName{st=
uff}`. And there&#39;s the Concepts TS terse syntax but with `template` app=
lied to functions that use them (except for lambdas which get it without `t=
emplate`).</div><div><br></div><div>What could you use `ConceptName{stuff}`=
 for in the future? Do you have any ideas at all where such syntax might be=
 useful?</div></div></blockquote><div><br></div><div><br></div><div>Somethi=
ng{stuff} was already considered for structured bindings.=C2=A0</div><div><=
br></div><div>I don&#39;t know what the future holds, but we are clearly ch=
ipping away syntax ground just for an alternative.</div><div>=C2=A0</div><b=
lockquote 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>=
Similarly, what would `template &lt;function definition&gt;` mean in some h=
ypothetical future?</div><div><br></div><div>I understand and appreciate th=
e idea of not burning precious syntax for trivial things. But we&#39;re not=
 talking about prime syntactic real estate here.<br></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>A syntax that d=
oes not introduce new features, but only adds second, even <i>third</i> way=
 of doing the same thing?<br></div></div></blockquote><div><br></div><div>I=
t doesn&#39;t matter how many ways there are of doing something. What matte=
rs is whether those ways are clear and convenient to use. Template headers =
are clear but inconvenient.<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></div><div><b></b><i></i><u></u><sub=
></sub><sup></sup><strike></strike><font face=3D"courier new,monospace"></f=
ont></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><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>And it=
 is syntax for the sake of syntax because it is not technically needed - no=
 problem to be solved.=C2=A0</div></div></blockquote><div><br></div><div>So=
 are lambdas. As I pointed out, there is no technical reason why you cannot=
 replace every lambda ever with a user-written type.</div><div><br></div><b=
lockquote 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>And,=
 as said it has nasty problems, from the fact it is not obvious in <i>any</=
i> way, to the metal overlap with initialization.</div><div><br></div><div>=
<font face=3D"courier new,monospace">Number{} x;</font></div><div><font fac=
e=3D"courier new,monospace">x =3D Number{};</font></div><div><font face=3D"=
courier new,monospace"></font><br></div><div>And again NO PROBLEM NEEDS SOL=
VING! None.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div><br></div><div>Now, you may argue that no terse =
syntax is worth the syntactic burden. I rather disagree: there are too many=
 cases where the function parameters and template parameters match each oth=
er to say that making that function declaration shorter isn&#39;t worth the=
 time and effort. Applying concepts to variables, even function parameters,=
 makes too much sense to not be worth pursuing.<br></div></div></blockquote=
><div><br></div><div>Ok, however these are &quot;nice&quot; and nice things=
 can wait, there is no pressing issue here!</div></div></blockquote><div><b=
r></div><div>Concepts are &quot;nice things&quot; too. But I think we can a=
ll agree we&#39;ve waited too long for them.<br></div></div></blockquote><b=
lockquote 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>=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>Seco=
nd, in 10+ years the results ARE WORSE. All of them!</div></div></blockquot=
e><div><br></div><div>... huh?<br></div><div>=C2=A0</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>Third the real community is st=
ill to have its say. Any additional syntax should wait for the real feedbac=
k and the real requirements.</div></div></blockquote><div><br></div><div>Ev=
ery argument you make after this point against terse templates is an argume=
nt you could make against lambdas. But we still have them. Why?</div><div><=
br></div><div>Because the benefits outweigh the costs.</div></div></blockqu=
ote><div><br></div><div></div><div>Your comparison to lambdas would have be=
en correct only if we had a concurrent terse lambda proposal being develope=
d <i>at the same time</i> as the regular one.=C2=A0</div></div></blockquote=
><div><br></div><div>But <i>they did</i>. Go look at some of the old lambda=
 proposals. There were ideas about dropping the parameter typename identifi=
ers and so forth even back then. They didn&#39;t pan out, but there was dis=
cussion about them concurrently with the broader lambda syntax. And such th=
ings would have been optional rather than mandatory.</div><div><br></div><b=
lockquote 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>Even worse - to=
 have the terse lambda blocking normal lambda. Because we are there with Co=
ncepts. <br></div></div></blockquote><div><br></div><div>Since when has ter=
se templates blocked concepts? The Concepts TS wasn&#39;t ready for C++17; =
questions about terse syntax were just <a href=3D"http://www.google.com/url=
?q=3Dhttp%3A%2F%2Fhonermann.net%2Fblog%2F%3Fp%3D3&amp;sa=3DD&amp;sntz=3D1&a=
mp;usg=3DAFQjCNEIAcV_kxryMk-8pmStWPXQ492S9w" rel=3D"nofollow noreferrer" ta=
rget=3D"_blank">one of the reasons why</a>. And Concepts-sans-terse syntax =
was voted into C++20 last year. So we aren&#39;t &quot;there&quot; at all.<=
/div><div><br></div><div>Not unless one of the 5 national bodies is threate=
ning not to vote for C++20 <i>without</i> some form of terse templates.<br>=
</div></div></blockquote><div><br></div><div>Funny how we both have comment=
ed under that report (not that I remember!).=C2=A0</div><div><br></div><div=
>In any case Concepts<span style=3D"display:inline!important;float:none;bac=
kground-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;=
,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-var=
iant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-deco=
ration:none;text-indent:0px;text-transform:none;white-space:normal;word-spa=
cing:0px">-sans-terse</span> is not frozen. And that is what worries me.=C2=
=A0</div><div>On the plus side, it seems the name introducers are <i>not</i=
> in as well so there is still hope.</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" rel=3D"noreferrer">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" rel=3D"noreferrer">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/f866bc73-ddd3-43a6-82db-b977c90c09b1%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/f866bc73-ddd3-43a6-82db-b977c90c09b1%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAANG%3DkX%2BXuUaEKOEChU9dhu%2BZThbiA=
wq683tLZn5Z7qmuLQBfQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkX%=
2BXuUaEKOEChU9dhu%2BZThbiAwq683tLZn5Z7qmuLQBfQ%40mail.gmail.com</a>.<br />

--00000000000049881d056f05e496--

.

------=_Part_26982_1880676731.1529447575324
Content-Type: multipart/alternative;
 boundary="----=_Part_26983_1914026642.1529447575324"

------=_Part_26983_1914026642.1529447575324
Content-Type: text/plain; charset="UTF-8"

On Tuesday, June 19, 2018 at 4:57:07 PM UTC-4, mihailn...@gmail.com wrote:
>
> On Tuesday, June 19, 2018 at 10:15:35 PM UTC+3, Nicol Bolas wrote:
>>
>> On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> Are they significant enough to add de facto *brand new syntax*?
>>>
>>
>> That's a judgement call, but I would say "yes".
>>
>> A syntax which *could* be used for something else in a decade?
>>>
>>
>> OK, so let's review the two syntaxes in question (because the committee
>> has essentially boiled them down to just two).
>>
>> There's Herb's proposal, which is `ConceptName{stuff}`. And there's the
>> Concepts TS terse syntax but with `template` applied to functions that use
>> them (except for lambdas which get it without `template`).
>>
>> What could you use `ConceptName{stuff}` for in the future? Do you have
>> any ideas at all where such syntax might be useful?
>>
>
>
> Something{stuff} was already considered for structured bindings.
>

> I don't know what the future holds, but we are clearly chipping away
> syntax ground just for an alternative.
>

So your hypothetical is a syntax that was considered and rejected on
grounds having nothing to do with concepts. So if concepts had used it, it
would still have been rejected, just with one more reason to do so.

I'm having a problem seeing the potential in this syntax.

Again, I recognize the importance of not spending syntax just because it's
there. Generally. But we're not talking about "generally"; we're talking
about a specific piece of syntax. If there is some potential competition
for this syntax that could be more useful, that'd be one thing. But if
there is no such competition, and we can solve a bunch of (relatively
minor) problems using this syntax, then I say take it.

Unused syntax helps nobody.

In any case Concepts-sans-terse is not frozen. And that is what worries me.
>

Are you also worried that contracts aren't frozen either? Or that ranges
isn't frozen? Or `operator<=>` isn't frozen yet?

They're not frozen because C++20 is not frozen. That's how standards are
developed. Concepts is decoupled from terse syntax; one is in, and the
other is out.

There is no way the committee could give you more than they've already
given you. Take the win and move on.

--
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/57272b82-fbc7-490a-b332-73a2deaedac5%40isocpp.org.

------=_Part_26983_1914026642.1529447575324
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, June 19, 2018 at 4:57:07 PM UTC-4, mihailn...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Tuesday, June 19, 2018 at 10:15:35 PM UTC+3, Nicol Bolas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, June 19, 201=
8 at 2:48:17 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<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>Are they significan=
t enough to add de facto <i>brand new syntax</i>?</div></div></blockquote><=
div><br></div><div>That&#39;s a judgement call, but I would say &quot;yes&q=
uot;.<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>A syntax which <i>could</i> be used for something else in =
a decade?</div></div></blockquote><div><br></div><div>OK, so let&#39;s revi=
ew the two syntaxes in question (because the committee has essentially boil=
ed them down to just two).</div><div><br></div><div>There&#39;s Herb&#39;s =
proposal, which is `ConceptName{stuff}`. And there&#39;s the Concepts TS te=
rse syntax but with `template` applied to functions that use them (except f=
or lambdas which get it without `template`).</div><div><br></div><div>What =
could you use `ConceptName{stuff}` for in the future? Do you have any ideas=
 at all where such syntax might be useful?</div></div></blockquote><div><br=
></div><div><br></div><div>Something{stuff} was already considered for stru=
ctured bindings.</div></div></blockquote><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"><div><br></div><div>I don&#39;t know what the f=
uture holds, but we are clearly chipping away syntax ground just for an alt=
ernative.</div></div></blockquote><div><br></div><div><div>So your hypothet=
ical is a syntax that was considered and rejected on grounds having nothing=
 to do with concepts.
So if concepts had used it, it would still have been rejected, just with
 one more reason to do so.</div><div><br></div>I&#39;m having a problem see=
ing the potential in this syntax.</div><div><br></div><div>Again, I recogni=
ze the importance of not spending syntax just because it&#39;s there. Gener=
ally. But we&#39;re not talking about &quot;generally&quot;; we&#39;re talk=
ing about a specific piece of syntax. If there is some potential competitio=
n for this syntax that could be more useful, that&#39;d be one thing. But i=
f there is no such competition, and we can solve a bunch of (relatively min=
or) problems using this syntax, then I say take it.</div><div><br></div><di=
v>Unused syntax helps nobody.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>In any case Concepts<s=
pan style=3D"display:inline!important;float:none;background-color:transpare=
nt;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,=
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;white-space:normal;word-spacing:0px">-sans-terse</=
span> is not frozen. And that is what worries me.</div></div></blockquote><=
div><br></div><div>Are you also worried that contracts aren&#39;t frozen ei=
ther? Or that ranges isn&#39;t frozen? Or `operator&lt;=3D&gt;` isn&#39;t f=
rozen yet?</div><div><br></div><div>They&#39;re not frozen because C++20 is=
 not frozen. That&#39;s how standards are developed. Concepts is decoupled =
from terse syntax; one is in, and the other is out.</div><div><br></div><di=
v>There is no way the committee could give you more than they&#39;ve alread=
y given you. Take the win and move on.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/57272b82-fbc7-490a-b332-73a2deaedac5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/57272b82-fbc7-490a-b332-73a2deaedac5=
%40isocpp.org</a>.<br />

------=_Part_26983_1914026642.1529447575324--

------=_Part_26982_1880676731.1529447575324--

.

------=_Part_27979_336757823.1529477216350
Content-Type: multipart/alternative;
 boundary="----=_Part_27980_1820846940.1529477216350"

------=_Part_27980_1820846940.1529477216350
Content-Type: text/plain; charset="UTF-8"



On Wednesday, June 20, 2018 at 1:32:55 AM UTC+3, Nicol Bolas wrote:
>
> On Tuesday, June 19, 2018 at 4:57:07 PM UTC-4, mihailn...@gmail.com wrote:
>>
>> On Tuesday, June 19, 2018 at 10:15:35 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, mihailn...@gmail.com
>>> wrote:
>>>>
>>>> Are they significant enough to add de facto *brand new syntax*?
>>>>
>>>
>>> That's a judgement call, but I would say "yes".
>>>
>>> A syntax which *could* be used for something else in a decade?
>>>>
>>>
>>> OK, so let's review the two syntaxes in question (because the committee
>>> has essentially boiled them down to just two).
>>>
>>> There's Herb's proposal, which is `ConceptName{stuff}`. And there's the
>>> Concepts TS terse syntax but with `template` applied to functions that use
>>> them (except for lambdas which get it without `template`).
>>>
>>> What could you use `ConceptName{stuff}` for in the future? Do you have
>>> any ideas at all where such syntax might be useful?
>>>
>>
>>
>> Something{stuff} was already considered for structured bindings.
>>
>
>> I don't know what the future holds, but we are clearly chipping away
>> syntax ground just for an alternative.
>>
>
> So your hypothetical is a syntax that was considered and rejected on
> grounds having nothing to do with concepts. So if concepts had used it, it
> would still have been rejected, just with one more reason to do so.
>
> I'm having a problem seeing the potential in this syntax.
>
> Again, I recognize the importance of not spending syntax just because it's
> there. Generally. But we're not talking about "generally"; we're talking
> about a specific piece of syntax. If there is some potential competition
> for this syntax that could be more useful, that'd be one thing. But if
> there is no such competition, and we can solve a bunch of (relatively
> minor) problems using this syntax, then I say take it.
>


You see problems solved, but I see none. That's where we differ.

But lets say we solved a minor problem. And we pay the price of new syntax.
Looks like 1:1 for now.

However, the downsides with in-place are greater then this tradeoff alone.

The biggest downside is that it opens the door for *a dialect* of template
code - it is so all encompassing that it start to create alternative
templates language.

How long until someone request this

func(class{Container}& c);


And what will be the one to teach?

template<Concept {C}>
void f(C);
or
void f(Concept{C});

Which one? Is the first one legacy now?


And how can we explain we have three syntaxes to a student *and only* *one *of
them *is not *a natural evolution?
Because we don't have this problem with the standard notations - they are
ALL evolutionarily!


Lets talk about local scope

Do we *really* need *or want *this, or was that "a nice side effect"

Number{N2} sum = x+y;

Do we really want two (completely different) declarations in one line?!?
(Putting aside the fact in local scope the syntax looks like construction
and/or inline class definition)

Honestly, the issues with in-place are far and beyond "we paid a bit of
syntax and got some minor problems solved".



>
> Unused syntax helps nobody.
>
> In any case Concepts-sans-terse is not frozen. And that is what worries
>> me.
>>
>
> Are you also worried that contracts aren't frozen either? Or that ranges
> isn't frozen? Or `operator<=>` isn't frozen yet?
>
> They're not frozen because C++20 is not frozen. That's how standards are
> developed. Concepts is decoupled from terse syntax; one is in, and the
> other is out.
>

I *wish* that was the case, but "the other" is not 'out' - it is still
actively pursued. Hence this topic.

My wish is to have this discussion after C++ 23 instead.


>
> There is no way the committee could give you more than they've already
> given you. Take the win and move on.
>

--
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/02c84409-d59c-480c-b33f-ced5cdd4fff2%40isocpp.org.

------=_Part_27980_1820846940.1529477216350
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, June 20, 2018 at 1:32:55 AM UTC+3, N=
icol Bolas 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">On Tuesday, June 19, 2018 at 4:57:07 PM UTC-4, <a>mihailn...@gmail.com<=
/a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesd=
ay, June 19, 2018 at 10:15:35 PM UTC+3, Nicol Bolas wrote:<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">On Tuesday, June 19, 2018 at 2:48:1=
7 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div></div><div>Are they significant enough to =
add de facto <i>brand new syntax</i>?</div></div></blockquote><div><br></di=
v><div>That&#39;s a judgement call, but I would say &quot;yes&quot;.<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>A syntax which <i>could</i> be used for something else in a decade?</d=
iv></div></blockquote><div><br></div><div>OK, so let&#39;s review the two s=
yntaxes in question (because the committee has essentially boiled them down=
 to just two).</div><div><br></div><div>There&#39;s Herb&#39;s proposal, wh=
ich is `ConceptName{stuff}`. And there&#39;s the Concepts TS terse syntax b=
ut with `template` applied to functions that use them (except for lambdas w=
hich get it without `template`).</div><div><br></div><div>What could you us=
e `ConceptName{stuff}` for in the future? Do you have any ideas at all wher=
e such syntax might be useful?</div></div></blockquote><div><br></div><div>=
<br></div><div>Something{stuff} was already considered for structured bindi=
ngs.</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><br></div><div>I don&#39;t know what the future holds, but =
we are clearly chipping away syntax ground just for an alternative.</div></=
div></blockquote><div><br></div><div><div>So your hypothetical is a syntax =
that was considered and rejected on grounds having nothing to do with conce=
pts.
So if concepts had used it, it would still have been rejected, just with
 one more reason to do so.</div><div><br></div>I&#39;m having a problem see=
ing the potential in this syntax.</div><div><br></div><div>Again, I recogni=
ze the importance of not spending syntax just because it&#39;s there. Gener=
ally. But we&#39;re not talking about &quot;generally&quot;; we&#39;re talk=
ing about a specific piece of syntax. If there is some potential competitio=
n for this syntax that could be more useful, that&#39;d be one thing. But i=
f there is no such competition, and we can solve a bunch of (relatively min=
or) problems using this syntax, then I say take it.</div></div></blockquote=
><div>=C2=A0</div><div><br></div><div>You see problems solved, but I see no=
ne. That&#39;s where we differ.=C2=A0</div><div><br></div><div>But lets say=
 we solved a minor problem. And we pay the price of new syntax. Looks like =
1:1 for now.=C2=A0</div><div><br></div><div>However, the downsides with in-=
place are greater then this tradeoff alone.=C2=A0</div><div><br></div><div>=
The biggest downside is that it opens the door for <i>a dialect</i> of temp=
late code - it is so all encompassing that it start to create alternative t=
emplates language.=C2=A0</div><div><br></div><div>How long until someone re=
quest this=C2=A0</div><div><font face=3D"courier new,monospace"></font><br>=
</div><div><font face=3D"courier new,monospace">func(class{Container}&amp; =
c);</font></div><div><font face=3D"courier new,monospace"><br></font></div>=
<div><font face=3D"courier new,monospace"><br></font></div><div>And what wi=
ll be the one to teach?</div><div><br></div><div><font face=3D"courier new,=
monospace">template&lt;Concept {C}&gt;=C2=A0</font></div><div><font face=3D=
"courier new,monospace">void f(C);</font></div><div><font face=3D"arial,san=
s-serif">or</font></div><div><span style=3D"text-align: left; color: rgb(34=
, 34, 34); text-transform: none; text-indent: 0px; letter-spacing: normal; =
font-size: 13px; font-style: normal; font-variant: normal; font-weight: 400=
; text-decoration: none; word-spacing: 0px; display: inline !important; whi=
te-space: normal; orphans: 2; float: none; -webkit-text-stroke-width: 0px; =
background-color: transparent;"><font face=3D"courier new,monospace">void f=
(<span style=3D"text-align: left; color: rgb(34, 34, 34); text-transform: n=
one; text-indent: 0px; letter-spacing: normal; font-size: 13px; font-style:=
 normal; font-variant: normal; font-weight: 400; text-decoration: none; wor=
d-spacing: 0px; display: inline !important; white-space: normal; orphans: 2=
; float: none; -webkit-text-stroke-width: 0px; background-color: transparen=
t;">Concept{C}</span>);</font></span></div><div><br></div><div>Which one? I=
s the first one legacy now?=C2=A0</div><div><br></div><div><font face=3D"ar=
ial,sans-serif"><br></font></div><div><font face=3D"arial,sans-serif">And h=
ow can we explain we have three syntaxes to a student <i>and only</i> <i>on=
e </i>of them <i>is not </i>a natural evolution?=C2=A0</font></div><div><fo=
nt face=3D"arial,sans-serif">Because we don&#39;t have this problem with th=
e standard notations - they are ALL evolutionarily!</font></div><div><br></=
div><div><br></div><div>Lets talk about local scope</div><div><br></div><di=
v>Do we <i>really</i> need <i>or want </i>this, or=C2=A0<span style=3D"disp=
lay: inline !important; float: none; background-color: transparent; color: =
rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-=
serif; font-size: 13px; font-style: normal; font-variant: normal; font-weig=
ht: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decorat=
ion: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-widt=
h: 0px; white-space: normal; word-spacing: 0px;">was that &quot;a nice side=
 effect&quot;</span></div><div><b></b><i></i><u></u><sub></sub><sup></sup><=
strike></strike><br></div><div><font face=3D"courier new,monospace">Number{=
N2} sum =3D x+y;</font><br></div><div><br></div><div>Do we really want two =
(completely different) declarations in one line?!? (Putting aside the fact =
in local scope the syntax looks like construction and/or inline class defin=
ition)</div><div><br></div><div>Honestly, the issues with in-place are far =
and beyond &quot;we paid a bit of syntax and got some minor problems solved=
&quot;. =C2=A0</div><div><br></div><div>=C2=A0</div><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><br></div><div>Unused syntax he=
lps nobody.</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"><di=
v dir=3D"ltr"><div></div><div>In any case Concepts<span style=3D"display:in=
line!important;float:none;background-color:transparent;color:rgb(34,34,34);=
font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13=
px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:nor=
mal;text-align:left;text-decoration:none;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px">-sans-terse</span> is not frozen. An=
d that is what worries me.</div></div></blockquote><div><br></div><div>Are =
you also worried that contracts aren&#39;t frozen either? Or that ranges is=
n&#39;t frozen? Or `operator&lt;=3D&gt;` isn&#39;t frozen yet?</div><div><b=
r></div><div>They&#39;re not frozen because C++20 is not frozen. That&#39;s=
 how standards are developed. Concepts is decoupled from terse syntax; one =
is in, and the other is out.</div></div></blockquote><div><br></div><div>I =
*wish* that was the case, but &quot;the other&quot; is not &#39;out&#39; - =
it is still actively pursued. Hence this topic.</div><div><br></div><div>My=
 wish is to have this discussion after C++ 23 instead. =C2=A0</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=
><br></div><div>There is no way the committee could give you more than they=
&#39;ve already given you. Take the win and move on.</div></div></blockquot=
e></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/02c84409-d59c-480c-b33f-ced5cdd4fff2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/02c84409-d59c-480c-b33f-ced5cdd4fff2=
%40isocpp.org</a>.<br />

------=_Part_27980_1820846940.1529477216350--

------=_Part_27979_336757823.1529477216350--

.

------=_Part_30654_819060810.1529513098671
Content-Type: multipart/alternative;
 boundary="----=_Part_30655_1199753039.1529513098672"

------=_Part_30655_1199753039.1529513098672
Content-Type: text/plain; charset="UTF-8"

On Wednesday, June 20, 2018 at 2:46:56 AM UTC-4, mihailn...@gmail.com wrote:
>
> On Wednesday, June 20, 2018 at 1:32:55 AM UTC+3, Nicol Bolas wrote:
>>
>> On Tuesday, June 19, 2018 at 4:57:07 PM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> On Tuesday, June 19, 2018 at 10:15:35 PM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, mihailn...@gmail.com
>>>> wrote:
>>>>>
>>>>> In any case Concepts-sans-terse is not frozen. And that is what
>>>>> worries me.
>>>>>
>>>>
>>>> Are you also worried that contracts aren't frozen either? Or that
>>>> ranges isn't frozen? Or `operator<=>` isn't frozen yet?
>>>>
>>>> They're not frozen because C++20 is not frozen. That's how standards
>>>> are developed. Concepts is decoupled from terse syntax; one is in, and the
>>>> other is out.
>>>>
>>>
> I *wish* that was the case, but "the other" is not 'out' - it is still
> actively pursued. Hence this topic.
>
> My wish is to have this discussion after C++ 23 instead.
>

Your earlier statement suggested that you were concerned that terse syntax
was interferring with the rest of concepts being shipped: "Even worse - to
have the terse lambda blocking normal lambda. Because we are there with
Concepts."

But now, you're saying that you're not concerned with when the rest of
concepts is shipped. You're merely concerned that terse syntax *exists at
all*. That people are working on trying to get a feature into the standard
that you don't want.

Let me put it a different way. Do you *really* want to have to write this
to have a conceptualized lambda:

[]<Concept C1, Concept C2>(C1 &c1, const C2 &c2) {...}

Rather than

[](Concept &c1, const Concept &c2) {...}

Or

[](Concept{} &c1, const Concept{} &c2) {...}

Why is the first one better than the second or third? What is all of that
verbiage providing?

--
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/906c89da-61de-41ae-bf38-c2cf8ade77b9%40isocpp.org.

------=_Part_30655_1199753039.1529513098672
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 20, 2018 at 2:46:56 AM UTC-4, mihailn..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Wednesday, June 20, 2018 at 1:32:55 AM UTC+3, Nicol Bolas wrote:<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">On Tuesday, June 19, =
2018 at 4:57:07 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<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">On Tuesday, June 19, 2018 at 10:1=
5:35 PM UTC+3, Nicol Bolas wrote:<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">On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, <a>mihailn...=
@gmail.com</a> wrote:<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"lt=
r"><div>In any case Concepts<span style=3D"display:inline!important;float:n=
one;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Aria=
l&quot;,&quot;Helvetica&quot;,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">-sans-terse</span> is not frozen. And that is what worries=
 me.</div></div></blockquote><div><br></div><div>Are you also worried that =
contracts aren&#39;t frozen either? Or that ranges isn&#39;t frozen? Or `op=
erator&lt;=3D&gt;` isn&#39;t frozen yet?</div><div><br></div><div>They&#39;=
re not frozen because C++20 is not frozen. That&#39;s how standards are dev=
eloped. Concepts is decoupled from terse syntax; one is in, and the other i=
s out.</div></div></blockquote></div></blockquote></div></blockquote></div>=
</blockquote><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><br></div><div>I *wish* that was the case, but &quot;the other&quot; i=
s not &#39;out&#39; - it is still actively pursued. Hence this topic.</div>=
<div><br></div><div>My wish is to have this discussion after C++ 23 instead=
..<br></div></div></blockquote><div><br></div><div>Your earlier statement su=
ggested that you were concerned that terse syntax was interferring with the=
 rest of concepts being shipped: &quot;Even worse - to have the terse lambd=
a blocking normal lambda. Because we are there with Concepts.&quot;</div><d=
iv><br></div><div>But now, you&#39;re saying that you&#39;re not concerned =
with when the rest of concepts is shipped. You&#39;re merely concerned that=
 terse syntax <i>exists at all</i>. That people are working on trying to ge=
t a feature into the standard that you don&#39;t want.</div><div><br></div>=
<div>Let me put it a different way. Do you <i>really</i> want to have to wr=
ite this to have a conceptualized lambda:</div><div><br></div><div style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"=
prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">[]&lt;</span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">Concept</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> C1</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Concept</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> C2</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">C1 </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c1<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> C2 </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">c2</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{...}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br></span><span style=3D"color: #606;" class=3D"styled-by-prettify">R=
ather</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> than=
<br><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]=
(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Concept</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">c1</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Concept</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c2</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{...}</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">Or</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">[](</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Concept</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{}</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c1</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Concept</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">c2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{...}</span></div></cod=
e></div><div><br></div><div>Why is the first one better than the second or =
third? What is all of that verbiage providing?<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/906c89da-61de-41ae-bf38-c2cf8ade77b9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/906c89da-61de-41ae-bf38-c2cf8ade77b9=
%40isocpp.org</a>.<br />

------=_Part_30655_1199753039.1529513098672--

------=_Part_30654_819060810.1529513098671--

.

--0000000000008e2080056f164156
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 20, 2018 at 12:45 PM Nicol Bolas <jmckesson@gmail.com> wrote:

> Let me put it a different way. Do you *really* want to have to write this
> to have a conceptualized lambda:
>
> []<Concept C1, Concept C2>(C1 &c1, const C2 &c2) {...}
> Rather than
> [](Concept &c1, const Concept &c2) {...}
> Or
> [](Concept{} &c1, const Concept{} &c2) {...}
>
> Why is the first one better than the second or third? What is all of that
> verbiage providing?
>

I still want

[](auto<Concept>& c1, const auto<Concept>& c2) { ... }

One thing the extra verbiage here provides is a hint that deduction is
happening
independently for each parameter.  It's not intuitive that in

[](Concept& c1, const Concept& c2) { ... }

the two parameter types can be unrelated, except that they both satisfy
Concept.
(At least I assume that's the case?)

--
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/CAHSYqdaac8%3D3tz0tCmiojFK8md00GUh%3DELq3w%2BuF0JCOL3AQWg%40mail.gmail.com.

--0000000000008e2080056f164156
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jun 20=
, 2018 at 12:45 PM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">j=
mckesson@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div>Let me put it a different way. Do you <i>really</i> want t=
o have to write this to have a conceptualized lambda:</div><div><br></div><=
div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187=
);border-style:solid;border-width:1px" class=3D"m_-345726463106334511pretty=
print"><code class=3D"m_-345726463106334511prettyprint"><div class=3D"m_-34=
5726463106334511subprettyprint"><span style=3D"color:#660" class=3D"m_-3457=
26463106334511styled-by-prettify">[]&lt;</span><span style=3D"color:#606" c=
lass=3D"m_-345726463106334511styled-by-prettify">Concept</span><span style=
=3D"color:#000" class=3D"m_-345726463106334511styled-by-prettify"> C1</span=
><span style=3D"color:#660" class=3D"m_-345726463106334511styled-by-prettif=
y">,</span><span style=3D"color:#000" class=3D"m_-345726463106334511styled-=
by-prettify"> </span><span style=3D"color:#606" class=3D"m_-345726463106334=
511styled-by-prettify">Concept</span><span style=3D"color:#000" class=3D"m_=
-345726463106334511styled-by-prettify"> C2</span><span style=3D"color:#660"=
 class=3D"m_-345726463106334511styled-by-prettify">&gt;(</span><span style=
=3D"color:#000" class=3D"m_-345726463106334511styled-by-prettify">C1 </span=
><span style=3D"color:#660" class=3D"m_-345726463106334511styled-by-prettif=
y">&amp;</span><span style=3D"color:#000" class=3D"m_-345726463106334511sty=
led-by-prettify">c1</span><span style=3D"color:#660" class=3D"m_-3457264631=
06334511styled-by-prettify">,</span><span style=3D"color:#000" class=3D"m_-=
345726463106334511styled-by-prettify"> </span><span style=3D"color:#008" cl=
ass=3D"m_-345726463106334511styled-by-prettify">const</span><span style=3D"=
color:#000" class=3D"m_-345726463106334511styled-by-prettify"> C2 </span><s=
pan style=3D"color:#660" class=3D"m_-345726463106334511styled-by-prettify">=
&amp;</span><span style=3D"color:#000" class=3D"m_-345726463106334511styled=
-by-prettify">c2</span><span style=3D"color:#660" class=3D"m_-3457264631063=
34511styled-by-prettify">)</span><span style=3D"color:#000" class=3D"m_-345=
726463106334511styled-by-prettify"> </span><span style=3D"color:#660" class=
=3D"m_-345726463106334511styled-by-prettify">{...}</span><span style=3D"col=
or:#000" class=3D"m_-345726463106334511styled-by-prettify"><br></span><span=
 style=3D"color:#606" class=3D"m_-345726463106334511styled-by-prettify">Rat=
her</span><span style=3D"color:#000" class=3D"m_-345726463106334511styled-b=
y-prettify"> than<br></span><span style=3D"color:#660" class=3D"m_-34572646=
3106334511styled-by-prettify">[](</span><span style=3D"color:#606" class=3D=
"m_-345726463106334511styled-by-prettify">Concept</span><span style=3D"colo=
r:#000" class=3D"m_-345726463106334511styled-by-prettify"> </span><span sty=
le=3D"color:#660" class=3D"m_-345726463106334511styled-by-prettify">&amp;</=
span><span style=3D"color:#000" class=3D"m_-345726463106334511styled-by-pre=
ttify">c1</span><span style=3D"color:#660" class=3D"m_-345726463106334511st=
yled-by-prettify">,</span><span style=3D"color:#000" class=3D"m_-3457264631=
06334511styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_-=
345726463106334511styled-by-prettify">const</span><span style=3D"color:#000=
" class=3D"m_-345726463106334511styled-by-prettify"> </span><span style=3D"=
color:#606" class=3D"m_-345726463106334511styled-by-prettify">Concept</span=
><span style=3D"color:#000" class=3D"m_-345726463106334511styled-by-prettif=
y"> </span><span style=3D"color:#660" class=3D"m_-345726463106334511styled-=
by-prettify">&amp;</span><span style=3D"color:#000" class=3D"m_-34572646310=
6334511styled-by-prettify">c2</span><span style=3D"color:#660" class=3D"m_-=
345726463106334511styled-by-prettify">)</span><span style=3D"color:#000" cl=
ass=3D"m_-345726463106334511styled-by-prettify"> </span><span style=3D"colo=
r:#660" class=3D"m_-345726463106334511styled-by-prettify">{...}</span><span=
 style=3D"color:#000" class=3D"m_-345726463106334511styled-by-prettify"><br=
></span><span style=3D"color:#606" class=3D"m_-345726463106334511styled-by-=
prettify">Or</span><span style=3D"color:#000" class=3D"m_-34572646310633451=
1styled-by-prettify"><br></span><span style=3D"color:#660" class=3D"m_-3457=
26463106334511styled-by-prettify">[](</span><span style=3D"color:#606" clas=
s=3D"m_-345726463106334511styled-by-prettify">Concept</span><span style=3D"=
color:#660" class=3D"m_-345726463106334511styled-by-prettify">{}</span><spa=
n style=3D"color:#000" class=3D"m_-345726463106334511styled-by-prettify"> <=
/span><span style=3D"color:#660" class=3D"m_-345726463106334511styled-by-pr=
ettify">&amp;</span><span style=3D"color:#000" class=3D"m_-3457264631063345=
11styled-by-prettify">c1</span><span style=3D"color:#660" class=3D"m_-34572=
6463106334511styled-by-prettify">,</span><span style=3D"color:#000" class=
=3D"m_-345726463106334511styled-by-prettify"> </span><span style=3D"color:#=
008" class=3D"m_-345726463106334511styled-by-prettify">const</span><span st=
yle=3D"color:#000" class=3D"m_-345726463106334511styled-by-prettify"> </spa=
n><span style=3D"color:#606" class=3D"m_-345726463106334511styled-by-pretti=
fy">Concept</span><span style=3D"color:#660" class=3D"m_-345726463106334511=
styled-by-prettify">{}</span><span style=3D"color:#000" class=3D"m_-3457264=
63106334511styled-by-prettify"> </span><span style=3D"color:#660" class=3D"=
m_-345726463106334511styled-by-prettify">&amp;</span><span style=3D"color:#=
000" class=3D"m_-345726463106334511styled-by-prettify">c2</span><span style=
=3D"color:#660" class=3D"m_-345726463106334511styled-by-prettify">)</span><=
span style=3D"color:#000" class=3D"m_-345726463106334511styled-by-prettify"=
> </span><span style=3D"color:#660" class=3D"m_-345726463106334511styled-by=
-prettify">{...}</span></div></code></div><div><br></div><div>Why is the fi=
rst one better than the second or third? What is all of that verbiage provi=
ding?</div></div></blockquote><div><br>I still want<br><br><font face=3D"mo=
nospace, monospace">[](auto&lt;Concept&gt;&amp; c1, const auto&lt;Concept&g=
t;&amp; c2) { ... }<br></font><br>One thing the extra verbiage here provide=
s is a hint that deduction is happening<br>independently for each parameter=
..=C2=A0 It&#39;s not intuitive that in<br><br><font face=3D"monospace, mono=
space">[](Concept&amp; c1, const Concept&amp; c2) { ... }</font><br><br>the=
 two parameter types can be unrelated, except that they both satisfy <font =
face=3D"monospace, monospace">Concept</font>.<br>(At least I assume that&#3=
9;s the case?)</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAHSYqdaac8%3D3tz0tCmiojFK8md00GUh%3D=
ELq3w%2BuF0JCOL3AQWg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaac8=
%3D3tz0tCmiojFK8md00GUh%3DELq3w%2BuF0JCOL3AQWg%40mail.gmail.com</a>.<br />

--0000000000008e2080056f164156--

.

On 06/20/18 19:44, Nicol Bolas wrote:
>
> Let me put it a different way. Do you /really/ want to have to write
> this to have a conceptualized lambda:
>
> |
> []<ConceptC1,ConceptC2>(C1 &c1,constC2 &c2){...}
>
> Ratherthan
>
> [](Concept&c1,constConcept&c2){...}
>
> Or
>
> [](Concept{}&c1,constConcept{}&c2){...}
> |

I, actually, would prefer the first syntax.

> Why is the first one better than the second or third? What is all of
> that verbiage providing?

It provides somewhat consistent syntax, which is already a significant
enough advantage for me. It also provides names for the argument types,
which may be useful.

--
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/c4552393-aabb-ebb7-42af-c40decd7da4c%40gmail.com.

.

------=_Part_364_1173499950.1529520887574
Content-Type: multipart/alternative;
 boundary="----=_Part_365_1428120430.1529520887574"

------=_Part_365_1428120430.1529520887574
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Wednesday, June 20, 2018 at 7:44:58 PM UTC+3, Nicol Bolas wrote:
>
> On Wednesday, June 20, 2018 at 2:46:56 AM UTC-4, mihailn...@gmail.com=20
> wrote:
>>
>> On Wednesday, June 20, 2018 at 1:32:55 AM UTC+3, Nicol Bolas wrote:
>>>
>>> On Tuesday, June 19, 2018 at 4:57:07 PM UTC-4, mihailn...@gmail.com=20
>>> wrote:
>>>>
>>>> On Tuesday, June 19, 2018 at 10:15:35 PM UTC+3, Nicol Bolas wrote:
>>>>>
>>>>> On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, mihailn...@gmail.com=
=20
>>>>> wrote:
>>>>>>
>>>>>> In any case Concepts-sans-terse is not frozen. And that is what=20
>>>>>> worries me.
>>>>>>
>>>>>
>>>>> Are you also worried that contracts aren't frozen either? Or that=20
>>>>> ranges isn't frozen? Or `operator<=3D>` isn't frozen yet?
>>>>>
>>>>> They're not frozen because C++20 is not frozen. That's how standards=
=20
>>>>> are developed. Concepts is decoupled from terse syntax; one is in, an=
d the=20
>>>>> other is out.
>>>>>
>>>>
>> I *wish* that was the case, but "the other" is not 'out' - it is still=
=20
>> actively pursued. Hence this topic.
>>
>> My wish is to have this discussion after C++ 23 instead.
>>
>
> Your earlier statement suggested that you were concerned that terse synta=
x=20
> was interferring with the rest of concepts being shipped: "Even worse - t=
o=20
> have the terse lambda blocking normal lambda. Because we are there with=
=20
> Concepts."
>
> But now, you're saying that you're not concerned with when the rest of=20
> concepts is shipped. You're merely concerned that terse syntax *exists at=
=20
> all*. That people are working on trying to get a feature into the=20
> standard that you don't want.=20
>

I am not concerned when the rest will ship if ever, I even think it is=20
better to postpone (so Concepts are not slowed... or worse) and get some=20
real feedback.=20

But, yes I am VERY, VERY concerned about in-place making it into the=20
language. As I said - this is (the base of) a dialect on templates in=20
general.=20
I also question 2-in-1 declarations that come with it.
=20

>
> Let me put it a different way. Do you *really* want to have to write this=
=20
> to have a conceptualized lambda:
>
> []<Concept C1, Concept C2>(C1 &c1, const C2 &c2) {...}
>
> Rather than
>
> [](Concept &c1, const Concept &c2) {...}
>
> Or
>
> [](Concept{} &c1, const Concept{} &c2) {...}
>
> Why is the first one better than the second or third? What is all of that=
=20
> verbiage providing?
>

I personally have no problem with either 1 or 2.=20

And BTW the last example should be [](Concept{C1} &c1, const Concept{C2}=20
&c2) {=E2=80=A6} to match the first, otherwise the {} will surely be option=
al (as=20
the proposal anticipates)

This is new language - new syntax *and* new idioms - 2-in-1 instructions.=
=20
(again, putting aside the mental overlap with object creation)

All this *right after* we doubled down on the 30 years old name introducing=
=20
syntax - <Type Name> - with lambdas as well!=20


And I ask again - what is the problem of having comma separated template=20
arguments <Concept C1, C2> ?

And if we want the required statement to be able to also introduce, why=20
does it need brand new syntax?=20

instead of=20
Mergeable{In1, In2, Out}=20
Out merge(In1,In1,In2,In2,Out);

just=20
requires Mergeable<In1, In2, Out>=20
Out merge(In1,In1,In2,In2,Out);

No new syntax AND it is clear we are starting a template.
Is there a parsing problem with that? Was something like that considered?=
=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/becbeb5f-cd4f-40df-998c-10f849a6a3fe%40isocpp.or=
g.

------=_Part_365_1428120430.1529520887574
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, June 20, 2018 at 7:44:58 PM UTC+3, N=
icol Bolas 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">On Wednesday, June 20, 2018 at 2:46:56 AM UTC-4, <a>mihailn...@gmail.co=
m</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wed=
nesday, June 20, 2018 at 1:32:55 AM UTC+3, Nicol Bolas wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, June 19, 2018 at 4:5=
7:07 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">On Tuesday, June 19, 2018 at 10:15:35 PM UTC=
+3, Nicol Bolas wrote:<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">On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, <a>mihailn...@gmail.com<=
/a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>In =
any case Concepts<span style=3D"display:inline!important;float:none;backgro=
und-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&qu=
ot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant=
:normal;font-weight:400;letter-spacing:normal;text-align:left;text-decorati=
on:none;text-indent:0px;text-transform:none;white-space:normal;word-spacing=
:0px">-sans-terse</span> is not frozen. And that is what worries me.</div><=
/div></blockquote><div><br></div><div>Are you also worried that contracts a=
ren&#39;t frozen either? Or that ranges isn&#39;t frozen? Or `operator&lt;=
=3D&gt;` isn&#39;t frozen yet?</div><div><br></div><div>They&#39;re not fro=
zen because C++20 is not frozen. That&#39;s how standards are developed. Co=
ncepts is decoupled from terse syntax; one is in, and the other is out.</di=
v></div></blockquote></div></blockquote></div></blockquote></div></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>=
<div>I *wish* that was the case, but &quot;the other&quot; is not &#39;out&=
#39; - it is still actively pursued. Hence this topic.</div><div><br></div>=
<div>My wish is to have this discussion after C++ 23 instead.<br></div></di=
v></blockquote><div><br></div><div>Your earlier statement suggested that yo=
u were concerned that terse syntax was interferring with the rest of concep=
ts being shipped: &quot;Even worse - to have the terse lambda blocking norm=
al lambda. Because we are there with Concepts.&quot;</div><div><br></div><d=
iv>But now, you&#39;re saying that you&#39;re not concerned with when the r=
est of concepts is shipped. You&#39;re merely concerned that terse syntax <=
i>exists at all</i>. That people are working on trying to get a feature int=
o the standard that you don&#39;t want.=C2=A0</div></div></blockquote><div>=
<br></div><div>I am not concerned when the rest will ship if ever, I even t=
hink it is better to postpone (so Concepts are not slowed... or worse) and =
get some real feedback.=C2=A0</div><div><br></div><div>But, yes I am VERY, =
VERY concerned about in-place making it into the language. As I said - this=
 is (the base of) a dialect on templates in general.=C2=A0</div><div>I also=
 question 2-in-1 declarations that come with it.</div><div>=C2=A0</div><blo=
ckquote 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><d=
iv>Let me put it a different way. Do you <i>really</i> want to have to writ=
e this to have a conceptualized lambda:</div><div><br></div><div style=3D"b=
ackground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style=
:solid;border-width:1px"><code><div><span style=3D"color:#660">[]&lt;</span=
><span style=3D"color:#606">Concept</span><span style=3D"color:#000"> C1</s=
pan><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><=
span style=3D"color:#606">Concept</span><span style=3D"color:#000"> C2</spa=
n><span style=3D"color:#660">&gt;(</span><span style=3D"color:#000">C1 </sp=
an><span style=3D"color:#660">&amp;</span><span style=3D"color:#000">c1</sp=
an><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#008">const</span><span style=3D"color:#000"> C2 </span>=
<span style=3D"color:#660">&amp;</span><span style=3D"color:#000">c2</span>=
<span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#660">{...}</span><span style=3D"color:#000"><br><br></span=
><span style=3D"color:#606">Rather</span><span style=3D"color:#000"> than<b=
r><br></span><span style=3D"color:#660">[](</span><span style=3D"color:#606=
">Concept</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">&amp;</span><span style=3D"color:#000">c1</span><span style=3D"color:#66=
0">,</span><span style=3D"color:#000"> </span><span style=3D"color:#008">co=
nst</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Con=
cept</span><span style=3D"color:#000"> </span><span style=3D"color:#660">&a=
mp;</span><span style=3D"color:#000">c2</span><span style=3D"color:#660">)<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">{...}</=
span><span style=3D"color:#000"><br><br></span><span style=3D"color:#606">O=
r</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#660=
">[](</span><span style=3D"color:#606">Concept</span><span style=3D"color:#=
660">{}</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>&amp;</span><span style=3D"color:#000">c1</span><span style=3D"color:#660"=
>,</span><span style=3D"color:#000"> </span><span style=3D"color:#008">cons=
t</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Conce=
pt</span><span style=3D"color:#660">{}</span><span style=3D"color:#000"> </=
span><span style=3D"color:#660">&amp;</span><span style=3D"color:#000">c2</=
span><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">{...}</span></div></code></div><div><br></div><d=
iv>Why is the first one better than the second or third? What is all of tha=
t verbiage providing?<br></div></div></blockquote><div><br></div><div>I per=
sonally have no problem with either 1 or 2.=C2=A0</div><div><br></div><div>=
And BTW the last example should be=C2=A0<font face=3D"courier new,monospace=
">[](Concept{C1} &amp;c1, const Concept{C2} &amp;c2) {=E2=80=A6} </font><fo=
nt face=3D"arial,sans-serif">to match the first, otherwise the {} will sure=
ly be optional (as the proposal anticipates)</font></div><div><font face=3D=
"courier new,monospace"><font face=3D"arial,sans-serif"></font><br></font><=
/div><div><font face=3D"arial,sans-serif">This is new language - new syntax=
 <i>and</i> new idioms - 2-in-1 instructions. (again, putting aside the men=
tal overlap with object creation)</font></div><div><font face=3D"arial,sans=
-serif"><br></font></div><div><font face=3D"arial,sans-serif">All this <i>r=
ight after</i> we doubled down on the 30 years old name introducing syntax =
- &lt;Type Name&gt; - with lambdas as well!=C2=A0</font></div><div><font fa=
ce=3D"arial,sans-serif"><br></font></div><div><font face=3D"arial,sans-seri=
f"><br></font></div><div><font face=3D"arial,sans-serif">And I ask again - =
what is the problem of having comma separated template arguments</font><fon=
t face=3D"courier new,monospace"> &lt;Concept C1, C2&gt; ?</font></div><div=
><font face=3D"courier new,monospace"><br></font></div><div><font face=3D"a=
rial,sans-serif">And if we want the required statement to be able to also i=
ntroduce, why does it need brand new syntax?=C2=A0</font></div><div><font f=
ace=3D"arial,sans-serif"><br></font></div><div>instead of=C2=A0<br></div><d=
iv><font face=3D"courier new,monospace">Mergeable{In1, In2, Out}=C2=A0</fon=
t></div><div><font face=3D"courier new,monospace">Out merge(In1,In1,In2,In2=
,Out);</font></div><div><font face=3D"courier new,monospace"><br></font></d=
iv><div><font face=3D"arial,sans-serif">just</font><font face=3D"courier ne=
w,monospace">=C2=A0</font></div><div><font face=3D"courier new,monospace"><=
div style=3D"background-color: transparent; border-bottom-color: rgb(34, 34=
, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-ou=
tset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-ima=
ge-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(3=
4, 34, 34); border-right-style: none; border-right-width: 0px; border-top-c=
olor: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color=
: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helveti=
ca&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant:=
 normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; marg=
in-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-botto=
m: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align=
: left; text-decoration: none; text-indent: 0px; text-transform: none; -web=
kit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><font =
face=3D"courier new,monospace" style=3D"border-bottom-color: rgb(34, 34, 34=
); border-bottom-style: none; border-bottom-width: 0px; border-image-outset=
: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image-s=
ource: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); bor=
der-left-style: none; border-left-width: 0px; border-right-color: rgb(34, 3=
4, 34); border-right-style: none; border-right-width: 0px; border-top-color=
: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; margin-bo=
ttom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bo=
ttom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">requir=
es Mergeable&lt;In1, In2, Out&gt;=C2=A0</font></div><div style=3D"backgroun=
d-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-s=
tyle: none; border-bottom-width: 0px; border-image-outset: 0; border-image-=
repeat: stretch; border-image-slice: 100%; border-image-source: none; borde=
r-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: no=
ne; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-rig=
ht-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34);=
 border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); fon=
t-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-seri=
f; font-size: 13px; font-style: normal; font-variant: normal; font-weight: =
400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-r=
ight: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: =
0px; padding-right: 0px; padding-top: 0px; text-align: left; text-decoratio=
n: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width:=
 0px; white-space: normal; word-spacing: 0px;"><font face=3D"courier new,mo=
nospace" style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style=
: none; border-bottom-width: 0px; border-image-outset: 0; border-image-repe=
at: stretch; border-image-slice: 100%; border-image-source: none; border-im=
age-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-s=
tyle: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bor=
der-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-left=
: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-lef=
t: 0px; padding-right: 0px; padding-top: 0px;">Out merge(In1,In1,In2,In2,Ou=
t);</font></div><div><b></b><i></i><u></u><sub></sub><sup></sup><strike></s=
trike><br></div></font><div><font face=3D"arial,sans-serif">No new syntax A=
ND it is clear we are starting a template.</font></div><div><font face=3D"a=
rial,sans-serif">Is there a parsing problem with that? Was something like t=
hat considered?=C2=A0</font></div><div><br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/becbeb5f-cd4f-40df-998c-10f849a6a3fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/becbeb5f-cd4f-40df-998c-10f849a6a3fe=
%40isocpp.org</a>.<br />

------=_Part_365_1428120430.1529520887574--

------=_Part_364_1173499950.1529520887574--

.

--000000000000a1ea7a056f17ff6a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I have an issue with reserving Concept{} because that means "create an
archetype of Concept, substituting no archetype free variables" to me.

Archetypes will be important at some point, or at least I hope so - they
are really important for completion and body-checking, and when you have
that, why not be able to use them in unevaluated contexts?

G

On Wed, Jun 20, 2018 at 7:54 PM, <mihailnajdenov@gmail.com> wrote:

>
>
> On Wednesday, June 20, 2018 at 7:44:58 PM UTC+3, Nicol Bolas wrote:
>>
>> On Wednesday, June 20, 2018 at 2:46:56 AM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> On Wednesday, June 20, 2018 at 1:32:55 AM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Tuesday, June 19, 2018 at 4:57:07 PM UTC-4, mihailn...@gmail.com
>>>> wrote:
>>>>>
>>>>> On Tuesday, June 19, 2018 at 10:15:35 PM UTC+3, Nicol Bolas wrote:
>>>>>>
>>>>>> On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4, mihailn...@gmail.com
>>>>>> wrote:
>>>>>>>
>>>>>>> In any case Concepts-sans-terse is not frozen. And that is what
>>>>>>> worries me.
>>>>>>>
>>>>>>
>>>>>> Are you also worried that contracts aren't frozen either? Or that
>>>>>> ranges isn't frozen? Or `operator<=3D>` isn't frozen yet?
>>>>>>
>>>>>> They're not frozen because C++20 is not frozen. That's how standards
>>>>>> are developed. Concepts is decoupled from terse syntax; one is in, a=
nd the
>>>>>> other is out.
>>>>>>
>>>>>
>>> I *wish* that was the case, but "the other" is not 'out' - it is still
>>> actively pursued. Hence this topic.
>>>
>>> My wish is to have this discussion after C++ 23 instead.
>>>
>>
>> Your earlier statement suggested that you were concerned that terse
>> syntax was interferring with the rest of concepts being shipped: "Even
>> worse - to have the terse lambda blocking normal lambda. Because we are
>> there with Concepts."
>>
>> But now, you're saying that you're not concerned with when the rest of
>> concepts is shipped. You're merely concerned that terse syntax *exists
>> at all*. That people are working on trying to get a feature into the
>> standard that you don't want.
>>
>
> I am not concerned when the rest will ship if ever, I even think it is
> better to postpone (so Concepts are not slowed... or worse) and get some
> real feedback.
>
> But, yes I am VERY, VERY concerned about in-place making it into the
> language. As I said - this is (the base of) a dialect on templates in
> general.
> I also question 2-in-1 declarations that come with it.
>
>
>>
>> Let me put it a different way. Do you *really* want to have to write
>> this to have a conceptualized lambda:
>>
>> []<Concept C1, Concept C2>(C1 &c1, const C2 &c2) {...}
>>
>> Rather than
>>
>> [](Concept &c1, const Concept &c2) {...}
>>
>> Or
>>
>> [](Concept{} &c1, const Concept{} &c2) {...}
>>
>> Why is the first one better than the second or third? What is all of tha=
t
>> verbiage providing?
>>
>
> I personally have no problem with either 1 or 2.
>
> And BTW the last example should be [](Concept{C1} &c1, const Concept{C2}
> &c2) {=E2=80=A6} to match the first, otherwise the {} will surely be opti=
onal (as
> the proposal anticipates)
>
> This is new language - new syntax *and* new idioms - 2-in-1 instructions.
> (again, putting aside the mental overlap with object creation)
>
> All this *right after* we doubled down on the 30 years old name
> introducing syntax - <Type Name> - with lambdas as well!
>
>
> And I ask again - what is the problem of having comma separated template
> arguments <Concept C1, C2> ?
>
> And if we want the required statement to be able to also introduce, why
> does it need brand new syntax?
>
> instead of
> Mergeable{In1, In2, Out}
> Out merge(In1,In1,In2,In2,Out);
>
> just
> requires Mergeable<In1, In2, Out>
> Out merge(In1,In1,In2,In2,Out);
>
> No new syntax AND it is clear we are starting a template.
> Is there a parsing problem with that? Was something like that considered?
>
> --
> 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/becbeb5f-cd4f-40df-
> 998c-10f849a6a3fe%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/becbeb5f-cd=
4f-40df-998c-10f849a6a3fe%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/CAANG%3DkVjYC90M6YB-VDHWQrSGPsunhXnbLwjYJ3uqQQhM=
_b-bQ%40mail.gmail.com.

--000000000000a1ea7a056f17ff6a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have an issue with reserving Concept{} because that mean=
s &quot;create an archetype of Concept, substituting no archetype free vari=
ables&quot; to me.<div><br></div><div>Archetypes will be important at some =
point, or at least I hope so - they are really important for completion and=
 body-checking, and when you have that, why not be able to use them in unev=
aluated contexts?</div><div><br></div><div>G</div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Wed, Jun 20, 2018 at 7:54 PM,  <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:mihailnajdenov@gmail.com" target=3D"_=
blank">mihailnajdenov@gmail.com</a>&gt;</span> wrote:<br><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"><span class=3D""><br><br>On Wednesday, June =
20, 2018 at 7:44:58 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">On Wednesday, June 20, 2018 at 2:46:56 AM UTC=
-4, <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">On Wednesday, June 20, 2018 at 1:32:55 AM UTC+3, Nicol =
Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tue=
sday, June 19, 2018 at 4:57:07 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, June 1=
9, 2018 at 10:15:35 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">On Tuesday, June 19, 2018 at 2:48:17 PM UTC-4=
, <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>In any case Concepts<span style=3D"display:inline!im=
portant;float:none;background-color:transparent;color:rgb(34,34,34);font-fa=
mily:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font=
-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;tex=
t-align:left;text-decoration:none;text-indent:0px;text-transform:none;white=
-space:normal;word-spacing:0px">-sans-terse</span> is not frozen. And that =
is what worries me.</div></div></blockquote><div><br></div><div>Are you als=
o worried that contracts aren&#39;t frozen either? Or that ranges isn&#39;t=
 frozen? Or `operator&lt;=3D&gt;` isn&#39;t frozen yet?</div><div><br></div=
><div>They&#39;re not frozen because C++20 is not frozen. That&#39;s how st=
andards are developed. Concepts is decoupled from terse syntax; one is in, =
and the other is out.</div></div></blockquote></div></blockquote></div></bl=
ockquote></div></blockquote><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div><br></div><div>I *wish* that was the case, but &quot;the oth=
er&quot; is not &#39;out&#39; - it is still actively pursued. Hence this to=
pic.</div><div><br></div><div>My wish is to have this discussion after C++ =
23 instead.<br></div></div></blockquote><div><br></div><div>Your earlier st=
atement suggested that you were concerned that terse syntax was interferrin=
g with the rest of concepts being shipped: &quot;Even worse - to have the t=
erse lambda blocking normal lambda. Because we are there with Concepts.&quo=
t;</div><div><br></div><div>But now, you&#39;re saying that you&#39;re not =
concerned with when the rest of concepts is shipped. You&#39;re merely conc=
erned that terse syntax <i>exists at all</i>. That people are working on tr=
ying to get a feature into the standard that you don&#39;t want.=C2=A0</div=
></div></blockquote><div><br></div></span><div>I am not concerned when the =
rest will ship if ever, I even think it is better to postpone (so Concepts =
are not slowed... or worse) and get some real feedback.=C2=A0</div><div><br=
></div><div>But, yes I am VERY, VERY concerned about in-place making it int=
o the language. As I said - this is (the base of) a dialect on templates in=
 general.=C2=A0</div><div>I also question 2-in-1 declarations that come wit=
h it.</div><span class=3D""><div>=C2=A0</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><br></div><div>Let me put it a different wa=
y. Do you <i>really</i> want to have to write this to have a conceptualized=
 lambda:</div><div><br></div><div style=3D"background-color:rgb(250,250,250=
);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code>=
<div><span style=3D"color:#660">[]&lt;</span><span style=3D"color:#606">Con=
cept</span><span style=3D"color:#000"> C1</span><span style=3D"color:#660">=
,</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Conce=
pt</span><span style=3D"color:#000"> C2</span><span style=3D"color:#660">&g=
t;(</span><span style=3D"color:#000">C1 </span><span style=3D"color:#660">&=
amp;</span><span style=3D"color:#000">c1</span><span style=3D"color:#660">,=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">const<=
/span><span style=3D"color:#000"> C2 </span><span style=3D"color:#660">&amp=
;</span><span style=3D"color:#000">c2</span><span style=3D"color:#660">)</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">{...}</sp=
an><span style=3D"color:#000"><br><br></span><span style=3D"color:#606">Rat=
her</span><span style=3D"color:#000"> than<br><br></span><span style=3D"col=
or:#660">[](</span><span style=3D"color:#606">Concept</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">&amp;</span><span style=3D"c=
olor:#000">c1</span><span style=3D"color:#660">,</span><span style=3D"color=
:#000"> </span><span style=3D"color:#008">const</span><span style=3D"color:=
#000"> </span><span style=3D"color:#606">Concept</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">&amp;</span><span style=3D"color:=
#000">c2</span><span style=3D"color:#660">)</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">{...}</span><span style=3D"color:#000"=
><br><br></span><span style=3D"color:#606">Or</span><span style=3D"color:#0=
00"><br><br></span><span style=3D"color:#660">[](</span><span style=3D"colo=
r:#606">Concept</span><span style=3D"color:#660">{}</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">&amp;</span><span style=3D"col=
or:#000">c1</span><span style=3D"color:#660">,</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">const</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#606">Concept</span><span style=3D"color:#=
660">{}</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>&amp;</span><span style=3D"color:#000">c2</span><span style=3D"color:#660"=
>)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{...=
}</span></div></code></div><div><br></div><div>Why is the first one better =
than the second or third? What is all of that verbiage providing?<br></div>=
</div></blockquote><div><br></div></span><div>I personally have no problem =
with either 1 or 2.=C2=A0</div><div><br></div><div>And BTW the last example=
 should be=C2=A0<font face=3D"courier new,monospace">[](Concept{C1} &amp;c1=
, const Concept{C2} &amp;c2) {=E2=80=A6} </font><font face=3D"arial,sans-se=
rif">to match the first, otherwise the {} will surely be optional (as the p=
roposal anticipates)</font></div><div><font face=3D"courier new,monospace">=
<font face=3D"arial,sans-serif"></font><br></font></div><div><font face=3D"=
arial,sans-serif">This is new language - new syntax <i>and</i> new idioms -=
 2-in-1 instructions. (again, putting aside the mental overlap with object =
creation)</font></div><div><font face=3D"arial,sans-serif"><br></font></div=
><div><font face=3D"arial,sans-serif">All this <i>right after</i> we double=
d down on the 30 years old name introducing syntax - &lt;Type Name&gt; - wi=
th lambdas as well!=C2=A0</font></div><div><font face=3D"arial,sans-serif">=
<br></font></div><div><font face=3D"arial,sans-serif"><br></font></div><div=
><font face=3D"arial,sans-serif">And I ask again - what is the problem of h=
aving comma separated template arguments</font><font face=3D"courier new,mo=
nospace"> &lt;Concept C1, C2&gt; ?</font></div><div><font face=3D"courier n=
ew,monospace"><br></font></div><div><font face=3D"arial,sans-serif">And if =
we want the required statement to be able to also introduce, why does it ne=
ed brand new syntax?=C2=A0</font></div><div><font face=3D"arial,sans-serif"=
><br></font></div><div>instead of=C2=A0<br></div><span class=3D""><div><fon=
t face=3D"courier new,monospace">Mergeable{In1, In2, Out}=C2=A0</font></div=
><div><font face=3D"courier new,monospace">Out merge(In1,In1,In2,In2,Out);<=
/font></div><div><font face=3D"courier new,monospace"><br></font></div></sp=
an><div><font face=3D"arial,sans-serif">just</font><font face=3D"courier ne=
w,monospace">=C2=A0</font></div><div><span class=3D""><font face=3D"courier=
 new,monospace"><div><font face=3D"courier new,monospace" style=3D"border-b=
ottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;=
border-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0p=
x;border-right-color:rgb(34,34,34);border-right-style:none;border-right-wid=
th:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-widt=
h:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;pad=
ding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px">require=
s Mergeable&lt;In1, In2, Out&gt;=C2=A0</font></div><div><font face=3D"couri=
er new,monospace" style=3D"border-bottom-color:rgb(34,34,34);border-bottom-=
style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-l=
eft-style:none;border-left-width:0px;border-right-color:rgb(34,34,34);borde=
r-right-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);bo=
rder-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;=
margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding=
-right:0px;padding-top:0px">Out merge(In1,In1,In2,In2,Out);</font></div><di=
v><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div></f=
ont></span><div><font face=3D"arial,sans-serif">No new syntax AND it is cle=
ar we are starting a template.</font></div><div><font face=3D"arial,sans-se=
rif">Is there a parsing problem with that? Was something like that consider=
ed?=C2=A0</font></div><div><br></div></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/becbeb5f-cd4f-40df-998c-10f849a6a3fe%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/becb=
eb5f-cd4f-40df-<wbr>998c-10f849a6a3fe%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAANG%3DkVjYC90M6YB-VDHWQrSGPsunhXnbL=
wjYJ3uqQQhM_b-bQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkVjYC90=
M6YB-VDHWQrSGPsunhXnbLwjYJ3uqQQhM_b-bQ%40mail.gmail.com</a>.<br />

--000000000000a1ea7a056f17ff6a--

.

------=_Part_495_1684961580.1529524275181
Content-Type: multipart/alternative;
 boundary="----=_Part_496_292523007.1529524275181"

------=_Part_496_292523007.1529524275181
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wednesday, June 20, 2018 at 3:42:29 PM UTC-4, Ga=C5=A1per A=C5=BEman wro=
te:
>
> I have an issue with reserving Concept{} because that means "create an=20
> archetype of Concept, substituting no archetype free variables" to me.
>

OK, but what is an "archetype of Concept", and why would most C++=20
programmers think that this syntax means that?

Archetypes will be important at some point, or at least I hope so - they=20
> are really important for completion and body-checking, and when you have=
=20
> that, why not be able to use them in unevaluated contexts?
>

Because certain members of the committee have made it abundantly clear that=
=20
"Concepts" in C++ will never go beyond their current constraints. There=20
will be no "completion and body-checking" in C++. Ever.

--=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/2a47070a-1488-41d6-9a36-2860723aaa07%40isocpp.or=
g.

------=_Part_496_292523007.1529524275181
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 20, 2018 at 3:42:29 PM UTC-4, Ga=C5=A1p=
er A=C5=BEman wrote:<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">I have an issue with reserving Concept{} because that means &quot;=
create an archetype of Concept, substituting no archetype free variables&qu=
ot; to me.</div></blockquote><div><br></div><div>OK, but what is an &quot;a=
rchetype of Concept&quot;, and why would most C++ programmers think that th=
is syntax means that?<br></div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div></div><div>Archetypes will be importa=
nt at some point, or at least I hope so - they are really important for com=
pletion and body-checking, and when you have that, why not be able to use t=
hem in unevaluated contexts?</div></div></blockquote><div><br></div><div>Be=
cause certain members of the committee have made it abundantly clear that &=
quot;Concepts&quot; in C++ will never go beyond their current constraints. =
There will be no &quot;completion and body-checking&quot; in C++. Ever.<br>=
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/2a47070a-1488-41d6-9a36-2860723aaa07%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2a47070a-1488-41d6-9a36-2860723aaa07=
%40isocpp.org</a>.<br />

------=_Part_496_292523007.1529524275181--

------=_Part_495_1684961580.1529524275181--

.

--0000000000002ff239056f184f80
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 20, 2018 at 8:51 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, June 20, 2018 at 3:42:29 PM UTC-4, Ga=C5=A1per A=C5=BEman w=
rote:
>>
>> I have an issue with reserving Concept{} because that means "create an
>> archetype of Concept, substituting no archetype free variables" to me.
>>
>
> OK, but what is an "archetype of Concept", and why would most C++
> programmers think that this syntax means that?
>

An archetype of a concept is a fictional concrete type that satisfies the
syntactic constraints. Under certain conditions it can be generated from
the concept specification, thus enabling completion. Body checking might be
warning only, but that doesn't mean it isn't useful.


>
> Archetypes will be important at some point, or at least I hope so - they
>> are really important for completion and body-checking, and when you have
>> that, why not be able to use them in unevaluated contexts?
>>
>
> Because certain members of the committee have made it abundantly clear
> that "Concepts" in C++ will never go beyond their current constraints.
> There will be no "completion and body-checking" in C++. Ever.
>

People's opinions change, especially in the face of evidence. Even if the
past proposals weren't acceptable, why does that prohibit it in the future?
If we can make it work in a way that's "right" for C++, why kill it now,
before we've had the chance to do that?

The reason that syntax means Archetype to me is because Type{} is an
instantiation, which means Concept{} is an instantiation - and an
instantiation of a concept is a type-ish thing.

--=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/CAANG%3DkWZdjrde2%3DU2gCHQu4X_8fDz9eej5_OUBF_NFY=
2KtUa8Q%40mail.gmail.com.

--0000000000002ff239056f184f80
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Jun 20, 2018 at 8:51 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span c=
lass=3D"">On Wednesday, June 20, 2018 at 3:42:29 PM UTC-4, Ga=C5=A1per A=C5=
=BEman wrote:<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">I hav=
e an issue with reserving Concept{} because that means &quot;create an arch=
etype of Concept, substituting no archetype free variables&quot; to me.</di=
v></blockquote><div><br></div></span><div>OK, but what is an &quot;archetyp=
e of Concept&quot;, and why would most C++ programmers think that this synt=
ax means that?<br></div></div></blockquote><div><br></div><div>An archetype=
 of a concept is a fictional concrete type that satisfies the syntactic con=
straints. Under certain conditions it can be generated from the concept spe=
cification, thus enabling completion. Body checking might be warning only, =
but that doesn&#39;t mean it isn&#39;t useful.</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 dir=3D"ltr"><div></div><span class=3D""><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></d=
iv><div>Archetypes will be important at some point, or at least I hope so -=
 they are really important for completion and body-checking, and when you h=
ave that, why not be able to use them in unevaluated contexts?</div></div><=
/blockquote><div><br></div></span><div>Because certain members of the commi=
ttee have made it abundantly clear that &quot;Concepts&quot; in C++ will ne=
ver go beyond their current constraints. There will be no &quot;completion =
and body-checking&quot; in C++. Ever.<br></div></div></blockquote><div><br>=
</div><div>People&#39;s opinions change, especially in the face of evidence=
.. Even if the past proposals weren&#39;t acceptable, why does that prohibit=
 it in the future? If we can make it work in a way that&#39;s &quot;right&q=
uot; for C++, why kill it now, before we&#39;ve had the chance to do that?<=
/div><div><br></div><div>The reason that syntax means Archetype to me is be=
cause Type{} is an instantiation, which means Concept{} is an instantiation=
 - and an instantiation of a concept is a type-ish thing.</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&quot; 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/CAANG%3DkWZdjrde2%3DU2gCHQu4X_8fDz9ee=
j5_OUBF_NFY2KtUa8Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWZdj=
rde2%3DU2gCHQu4X_8fDz9eej5_OUBF_NFY2KtUa8Q%40mail.gmail.com</a>.<br />

--0000000000002ff239056f184f80--

.

------=_Part_596_94246029.1529525106682
Content-Type: multipart/alternative;
 boundary="----=_Part_597_382062202.1529525106682"

------=_Part_597_382062202.1529525106682
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wednesday, June 20, 2018 at 2:54:47 PM UTC-4, mihailn...@gmail.com wrote=
:
>
> On Wednesday, June 20, 2018 at 7:44:58 PM UTC+3, Nicol Bolas wrote:
>>
>> On Wednesday, June 20, 2018 at 2:46:56 AM UTC-4, mihailn...@gmail.com=20
>> wrote:
>>>
>>> I *wish* that was the case, but "the other" is not 'out' - it is still=
=20
>>> actively pursued. Hence this topic.
>>>
>>> My wish is to have this discussion after C++ 23 instead.
>>>
>>
>> Your earlier statement suggested that you were concerned that terse=20
>> syntax was interferring with the rest of concepts being shipped: "Even=
=20
>> worse - to have the terse lambda blocking normal lambda. Because we are=
=20
>> there with Concepts."
>>
>> But now, you're saying that you're not concerned with when the rest of=
=20
>> concepts is shipped. You're merely concerned that terse syntax *exists=
=20
>> at all*. That people are working on trying to get a feature into the=20
>> standard that you don't want.=20
>>
>
> I am not concerned when the rest will ship if ever,
>

When I said "rest", I meant the "non-terse template" part.

I even think it is better to postpone (so Concepts are not slowed... or=20
> worse) and get some real feedback.
>

But we *have* "real feedback". It's not like terse syntax manifested=20
ex-nihilo sometime in 2017. It's out there in the Concepts TS, which is=20
being used by real people.

Let me put it a different way. Do you *really* want to have to write this=
=20
>> to have a conceptualized lambda:
>>
>> []<Concept C1, Concept C2>(C1 &c1, const C2 &c2) {...}
>>
>> Rather than
>>
>> [](Concept &c1, const Concept &c2) {...}
>>
>> Or
>>
>> [](Concept{} &c1, const Concept{} &c2) {...}
>>
>> Why is the first one better than the second or third? What is all of tha=
t=20
>> verbiage providing?
>>
>
> I personally have no problem with either 1 or 2.
>

Then why does the title of this thread call Bjarne's proposal "madness"? If=
=20
you wanted to rail against Herb's proposal, then you should have focused on=
=20
that specifically.

And BTW the last example should be [](Concept{C1} &c1, const Concept{C2}=20
> &c2) {=E2=80=A6} to match the first, otherwise the {} will surely be opti=
onal (as=20
> the proposal anticipates)
>

Anticipation isn't the same thing as "gonna happen". Because once you make=
=20
those curly braces optional, you lose the ability to easily tell whether a=
=20
function is a template or not. Which was the primary problem being resolved=
..

This is new language - new syntax *and* new idioms - 2-in-1 instructions.=
=20
> (again, putting aside the mental overlap with object creation)
>
> All this *right after* we doubled down on the 30 years old name=20
> introducing syntax - <Type Name> - with lambdas as well!=20
>
>
> And I ask again - what is the problem of having comma separated template=
=20
> arguments <Concept C1, C2> ?
>

Because it doesn't make things shorter. Not by nearly as much. We're=20
talking about creating syntax that lets you see what's going on without so=
=20
much text. Dropping a single word like that isn't helping.
=20

> And if we want the required statement to be able to also introduce, why=
=20
> does it need brand new syntax?=20
>

Wait: I thought the reason you hated Herb's syntax was because it is a=20
novel syntax. How is using `requires` to preemptively create a template any=
=20
less novel?

instead of=20
> Mergeable{In1, In2, Out}=20
> Out merge(In1,In1,In2,In2,Out);
>
> just=20
> requires Mergeable<In1, In2, Out>=20
> Out merge(In1,In1,In2,In2,Out);
>
> No new syntax AND it is clear we are starting a template.
>

But nobody's suggesting that. Well OK, Bjarne is probably still hoping=20
concept introduction syntax will make it in, but Herb's proposal doesn't do=
=20
that. It does this:

Mergeable{Out, In1, In2} merge(In1, In1, In2, In2, Out);

That is, you define `Mergeable` such that it *is* the output type. So it's=
=20
not some special syntax that begins a template function declaration. It=20
behaves no differently than any other use of a concept for a function's=20
output parameter, while simultaneously naming some of its template=20
parameters for use as function parameter types.

>

--=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/3e64b8ef-f04a-424f-a10b-2d8177cc88c5%40isocpp.or=
g.

------=_Part_597_382062202.1529525106682
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 20, 2018 at 2:54:47 PM UTC-4, mihailn..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Wednesday, June 20, 2018 at 7:44:58 PM UTC+3, Nicol Bolas wrote:<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">On Wednesday, June 20=
, 2018 at 2:46:56 AM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>I *wish* that w=
as the case, but &quot;the other&quot; is not &#39;out&#39; - it is still a=
ctively pursued. Hence this topic.</div><div><br></div><div>My wish is to h=
ave this discussion after C++ 23 instead.<br></div></div></blockquote><div>=
<br></div><div>Your earlier statement suggested that you were concerned tha=
t terse syntax was interferring with the rest of concepts being shipped: &q=
uot;Even worse - to have the terse lambda blocking normal lambda. Because w=
e are there with Concepts.&quot;</div><div><br></div><div>But now, you&#39;=
re saying that you&#39;re not concerned with when the rest of concepts is s=
hipped. You&#39;re merely concerned that terse syntax <i>exists at all</i>.=
 That people are working on trying to get a feature into the standard that =
you don&#39;t want.=C2=A0</div></div></blockquote><div><br></div><div>I am =
not concerned when the rest will ship if ever,</div></div></blockquote><div=
><br></div><div>When I said &quot;rest&quot;, I meant the &quot;non-terse t=
emplate&quot; part.<br></div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div> I even think it is better to postpone =
(so Concepts are not slowed... or worse) and get some real feedback.</div><=
/div></blockquote><div><br></div><div>But we <i>have</i> &quot;real feedbac=
k&quot;. It&#39;s not like terse syntax manifested ex-nihilo sometime in 20=
17. It&#39;s out there in the Concepts TS, which is being used by real peop=
le.<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div></div><div></div><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"><div></div><div>Let me put it a different way. Do you <i=
>really</i> want to have to write this to have a conceptualized lambda:</di=
v><div><br></div><div style=3D"background-color:rgb(250,250,250);border-col=
or:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span s=
tyle=3D"color:#660">[]&lt;</span><span style=3D"color:#606">Concept</span><=
span style=3D"color:#000"> C1</span><span style=3D"color:#660">,</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#606">Concept</span><sp=
an style=3D"color:#000"> C2</span><span style=3D"color:#660">&gt;(</span><s=
pan style=3D"color:#000">C1 </span><span style=3D"color:#660">&amp;</span><=
span style=3D"color:#000">c1</span><span style=3D"color:#660">,</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#008">const</span><span =
style=3D"color:#000"> C2 </span><span style=3D"color:#660">&amp;</span><spa=
n style=3D"color:#000">c2</span><span style=3D"color:#660">)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">{...}</span><span sty=
le=3D"color:#000"><br><br></span><span style=3D"color:#606">Rather</span><s=
pan style=3D"color:#000"> than<br><br></span><span style=3D"color:#660">[](=
</span><span style=3D"color:#606">Concept</span><span style=3D"color:#000">=
 </span><span style=3D"color:#660">&amp;</span><span style=3D"color:#000">c=
1</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">const</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#606">Concept</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#660">&amp;</span><span style=3D"color:#000">c2</sp=
an><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">{...}</span><span style=3D"color:#000"><br><br></s=
pan><span style=3D"color:#606">Or</span><span style=3D"color:#000"><br><br>=
</span><span style=3D"color:#660">[](</span><span style=3D"color:#606">Conc=
ept</span><span style=3D"color:#660">{}</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">&amp;</span><span style=3D"color:#000">c1<=
/span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">const</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#606">Concept</span><span style=3D"color:#660">{}</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660">&amp;</span=
><span style=3D"color:#000">c2</span><span style=3D"color:#660">)</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">{...}</span></di=
v></code></div><div><br></div><div>Why is the first one better than the sec=
ond or third? What is all of that verbiage providing?<br></div></div></bloc=
kquote><div><br></div><div>I personally have no problem with either 1 or 2.=
</div></div></blockquote><div><br></div><div>Then why does the title of thi=
s thread call Bjarne&#39;s proposal &quot;madness&quot;? If you wanted to r=
ail against Herb&#39;s proposal, then you should have focused on that speci=
fically.<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></div><div>And BTW the last example should be=C2=
=A0<font face=3D"courier new,monospace">[](Concept{C1} &amp;c1, const Conce=
pt{C2} &amp;c2) {=E2=80=A6} </font><font face=3D"arial,sans-serif">to match=
 the first, otherwise the {} will surely be optional (as the proposal antic=
ipates)</font></div></div></blockquote><div><br></div><div>Anticipation isn=
&#39;t the same thing as &quot;gonna happen&quot;. Because once you make th=
ose curly braces optional, you lose the ability to easily tell whether a fu=
nction is a template or not. Which was the primary problem being resolved.<=
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 d=
ir=3D"ltr"><div><font face=3D"courier new,monospace"><font face=3D"arial,sa=
ns-serif"></font></font></div><div><font face=3D"arial,sans-serif">This is =
new language - new syntax <i>and</i> new idioms - 2-in-1 instructions. (aga=
in, putting aside the mental overlap with object creation)</font></div><div=
><font face=3D"arial,sans-serif"><br></font></div><div><font face=3D"arial,=
sans-serif">All this <i>right after</i> we doubled down on the 30 years old=
 name introducing syntax - &lt;Type Name&gt; - with lambdas as well!=C2=A0<=
/font></div><div><font face=3D"arial,sans-serif"><br></font></div><div><fon=
t face=3D"arial,sans-serif"><br></font></div><div><font face=3D"arial,sans-=
serif">And I ask again - what is the problem of having comma separated temp=
late arguments</font><font face=3D"courier new,monospace"> &lt;Concept C1, =
C2&gt; ?</font></div></div></blockquote><div><br></div><div>Because it does=
n&#39;t make things shorter. Not by nearly as much. We&#39;re talking about=
 creating syntax that lets you see what&#39;s going on without so much text=
.. Dropping a single word like that isn&#39;t helping.<br></div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><fo=
nt face=3D"courier new,monospace"></font></div><div><font face=3D"arial,san=
s-serif">And if we want the required statement to be able to also introduce=
, why does it need brand new syntax?=C2=A0</font></div></div></blockquote><=
div><br></div><div>Wait: I thought the reason you hated Herb&#39;s syntax w=
as because it is a novel syntax. How is using `requires` to preemptively cr=
eate a template any less novel?</div><div><br></div><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><font face=3D"arial,sans-serif"=
></font></div><div>instead of=C2=A0<br></div><div><font face=3D"courier new=
,monospace">Mergeable{In1, In2, Out}=C2=A0</font></div><div><font face=3D"c=
ourier new,monospace">Out merge(In1,In1,In2,In2,Out);</font></div><div><fon=
t face=3D"courier new,monospace"><br></font></div><div><font face=3D"arial,=
sans-serif">just</font><font face=3D"courier new,monospace">=C2=A0</font></=
div><div><font face=3D"courier new,monospace"><div><font style=3D"border-bo=
ttom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;b=
order-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-widt=
h:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width=
:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padd=
ing-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=3D"=
courier new,monospace">requires Mergeable&lt;In1, In2, Out&gt;=C2=A0</font>=
</div><div><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-s=
tyle:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-le=
ft-style:none;border-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);bor=
der-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;m=
argin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-=
right:0px;padding-top:0px" face=3D"courier new,monospace">Out merge(In1,In1=
,In2,In2,Out);</font></div><div><b></b><i></i><u></u><sub></sub><sup></sup>=
<strike></strike><br></div></font><div><font face=3D"arial,sans-serif">No n=
ew syntax AND it is clear we are starting a template.</font></div></div></d=
iv></blockquote><div><br></div><div>But nobody&#39;s suggesting that. Well =
OK, Bjarne is probably still hoping concept introduction syntax will make i=
t in, but Herb&#39;s proposal doesn&#39;t do that. It does this:</div><div>=
<br></div><div><div style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-=
wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Mergeable</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Out=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">In1</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">In2</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> merge</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">In1</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">In1</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">In2</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">I=
n2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">Out</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span></div></code></div><br><=
/div><div></div><div>That is, you define `Mergeable` such that it <i>is</i>=
 the output type. So it&#39;s not some special syntax that begins a templat=
e function declaration. It behaves no differently than any other use of a c=
oncept for a function&#39;s output parameter, while simultaneously naming s=
ome of its template parameters for use as function parameter types.<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><=
/div></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&quot; 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/3e64b8ef-f04a-424f-a10b-2d8177cc88c5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3e64b8ef-f04a-424f-a10b-2d8177cc88c5=
%40isocpp.org</a>.<br />

------=_Part_597_382062202.1529525106682--

------=_Part_596_94246029.1529525106682--

.

------=_Part_822_1739262052.1529527461275
Content-Type: multipart/alternative;
 boundary="----=_Part_823_1612994148.1529527461276"

------=_Part_823_1612994148.1529527461276
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wednesday, June 20, 2018 at 4:04:44 PM UTC-4, Ga=C5=A1per A=C5=BEman wro=
te:
>
> On Wed, Jun 20, 2018 at 8:51 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Wednesday, June 20, 2018 at 3:42:29 PM UTC-4, Ga=C5=A1per A=C5=BEman =
wrote:
>>>
>>> I have an issue with reserving Concept{} because that means "create an=
=20
>>> archetype of Concept, substituting no archetype free variables" to me.
>>>
>>
>> OK, but what is an "archetype of Concept", and why would most C++=20
>> programmers think that this syntax means that?
>>
>
> An archetype of a concept is a fictional concrete type that satisfies the=
=20
> syntactic constraints. Under certain conditions it can be generated from=
=20
> the concept specification, thus enabling completion.
>

If it's a "fictional" type, why do I want to name it? And if it's a type=20
that gets generated, then I probably want to have something that looks like=
=20
a regular type declaration `class Name : Concept`.

Otherwise we're in concept map territory. And *nobody* wants to be there.

Body checking might be warning only, but that doesn't mean it isn't useful.
> =20
>
>>
>> Archetypes will be important at some point, or at least I hope so - they=
=20
>>> are really important for completion and body-checking, and when you hav=
e=20
>>> that, why not be able to use them in unevaluated contexts?
>>>
>>
>> Because certain members of the committee have made it abundantly clear=
=20
>> that "Concepts" in C++ will never go beyond their current constraints.=
=20
>> There will be no "completion and body-checking" in C++. Ever.
>>
>
> People's opinions change, especially in the face of evidence. Even if the=
=20
> past proposals weren't acceptable, why does that prohibit it in the futur=
e?=20
> If we can make it work in a way that's "right" for C++, why kill it now,=
=20
> before we've had the chance to do that?
>

The moment concepts land in the standard, definition checking will be dead.=
=20
Why? Because right now, a `concept` is just a constexpr expression based on=
=20
template parameters. It doesn't have to use a `requires` clause; it's just=
=20
a boolean value.

One of the big problems with getting definition checking is dealing with=20
the fact that a concept is not merely a set of expressions that have to be=
=20
followed (which a compiler can match expressions against), but just=20
whatever constexpr stuff you stick in the variable. You can call arbitrary=
=20
constexpr functions that do arbitrary things, and that's OK.

If your concepts are all defined that way, you can't have definition=20
checking. At least, not without saying that you have to define your=20
concepts using a specific syntax in order to get definition checking. In=20
which case, you create a dichotomy between "real concepts" and "fake=20
concepts". And if some library uses a bunch of "fake concepts", how can you=
=20
have definition checking? Can you call their code that's not using real=20
concepts with your types that follow the same "conceptual" concepts that=20
are implemented in a non-"fake" way?

No, it just turns into a big bunch of mess. We lost the fight for=20
definition checking the minute concepts was allowed into the standard=20
without *proven* definition checking abilities. Best to let it go and move=
=20
on.

The reason that syntax means Archetype to me is because Type{} is an=20
> instantiation,
>

It's not. A concept is a template; an instantiation of a template uses `<>`=
..

which means Concept{} is an instantiation - and an instantiation of a=20
> concept is a type-ish thing.
>

--=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/08cd7791-715d-42ba-b863-1d8829e9ec1e%40isocpp.or=
g.

------=_Part_823_1612994148.1529527461276
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 20, 2018 at 4:04:44 PM UTC-4, Ga=C5=A1p=
er A=C5=BEman wrote:<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><div class=3D"gmail_quote">On Wed, Jun 20, 2018 at 8:51 PM, N=
icol Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"xd0SVFZYAgAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Wednesday, June 20, 20=
18 at 3:42:29 PM UTC-4, Ga=C5=A1per A=C5=BEman wrote:<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">I have an issue with reserving Concept{}=
 because that means &quot;create an archetype of Concept, substituting no a=
rchetype free variables&quot; to me.</div></blockquote><div><br></div></spa=
n><div>OK, but what is an &quot;archetype of Concept&quot;, and why would m=
ost C++ programmers think that this syntax means that?<br></div></div></blo=
ckquote><div><br></div><div>An archetype of a concept is a fictional concre=
te type that satisfies the syntactic constraints. Under certain conditions =
it can be generated from the concept specification, thus enabling completio=
n.</div></div></div></div></blockquote><div><br></div><div>If it&#39;s a &q=
uot;fictional&quot; type, why do I want to name it? And if it&#39;s a type =
that gets generated, then I probably want to have something that looks like=
 a regular type declaration `class Name : Concept`.<br></div><div><br></div=
><div>Otherwise we&#39;re in concept map territory. And <i>nobody</i> wants=
 to be there.<br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Body checking=
 might be warning only, but that doesn&#39;t mean it isn&#39;t useful.</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></di=
v><span><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>Archetypes will be important at some point, or at leas=
t I hope so - they are really important for completion and body-checking, a=
nd when you have that, why not be able to use them in unevaluated contexts?=
</div></div></blockquote><div><br></div></span><div>Because certain members=
 of the committee have made it abundantly clear that &quot;Concepts&quot; i=
n C++ will never go beyond their current constraints. There will be no &quo=
t;completion and body-checking&quot; in C++. Ever.<br></div></div></blockqu=
ote><div><br></div><div>People&#39;s opinions change, especially in the fac=
e of evidence. Even if the past proposals weren&#39;t acceptable, why does =
that prohibit it in the future? If we can make it work in a way that&#39;s =
&quot;right&quot; for C++, why kill it now, before we&#39;ve had the chance=
 to do that?</div></div></div></div></blockquote><div><br></div><div>The mo=
ment concepts land in the standard, definition checking will be dead. Why? =
Because right now, a `concept` is just a constexpr expression based on temp=
late parameters. It doesn&#39;t have to use a `requires` clause; it&#39;s j=
ust a boolean value.</div><div><br></div><div>One of the big problems with =
getting definition checking is dealing with the fact that a concept is not =
merely a set of expressions that have to be followed (which a compiler can =
match expressions against), but just whatever constexpr stuff you stick in =
the variable. You can call arbitrary constexpr functions that do arbitrary =
things, and that&#39;s OK.</div><div><br></div><div>If your concepts are al=
l defined that way, you can&#39;t have definition checking. At least, not w=
ithout saying that you have to define your concepts using a specific syntax=
 in order to get definition checking. In which case, you create a dichotomy=
 between &quot;real concepts&quot; and &quot;fake concepts&quot;. And if so=
me library uses a bunch of &quot;fake concepts&quot;, how can you have defi=
nition checking? Can you call their code that&#39;s not using real concepts=
 with your types that follow the same &quot;conceptual&quot; concepts that =
are implemented in a non-&quot;fake&quot; way?</div><div><br></div><div>No,=
 it just turns into a big bunch of mess. We lost the fight for definition c=
hecking the minute concepts was allowed into the standard without <i>proven=
</i> definition checking abilities. Best to let it go and move on.<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"lt=
r"><div><div class=3D"gmail_quote"><div></div><div>The reason that syntax m=
eans Archetype to me is because Type{} is an instantiation,</div></div></di=
v></div></blockquote><div><br></div><div>It&#39;s not. A concept is a templ=
ate; an instantiation of a template uses `&lt;&gt;`.<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div>which means Concept{} is an instantiation - and a=
n instantiation of a concept is a type-ish thing.</div></div></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&quot; 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/08cd7791-715d-42ba-b863-1d8829e9ec1e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/08cd7791-715d-42ba-b863-1d8829e9ec1e=
%40isocpp.org</a>.<br />

------=_Part_823_1612994148.1529527461276--

------=_Part_822_1739262052.1529527461275--

.

------=_Part_1029_174534743.1529531515506
Content-Type: multipart/alternative;
 boundary="----=_Part_1030_1991354448.1529531515507"

------=_Part_1030_1991354448.1529531515507
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Wednesday, June 20, 2018 at 11:05:06 PM UTC+3, Nicol Bolas wrote:
>
> On Wednesday, June 20, 2018 at 2:54:47 PM UTC-4, mihailn...@gmail.com=20
> wrote:
>>
>> On Wednesday, June 20, 2018 at 7:44:58 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Wednesday, June 20, 2018 at 2:46:56 AM UTC-4, mihailn...@gmail.com=
=20
>>> wrote:
>>>>
>>>> I *wish* that was the case, but "the other" is not 'out' - it is still=
=20
>>>> actively pursued. Hence this topic.
>>>>
>>>> My wish is to have this discussion after C++ 23 instead.
>>>>
>>>
>>> Your earlier statement suggested that you were concerned that terse=20
>>> syntax was interferring with the rest of concepts being shipped: "Even=
=20
>>> worse - to have the terse lambda blocking normal lambda. Because we are=
=20
>>> there with Concepts."
>>>
>>> But now, you're saying that you're not concerned with when the rest of=
=20
>>> concepts is shipped. You're merely concerned that terse syntax *exists=
=20
>>> at all*. That people are working on trying to get a feature into the=20
>>> standard that you don't want.=20
>>>
>>
>> I am not concerned when the rest will ship if ever,
>>
>
> When I said "rest", I meant the "non-terse template" part.
>
> I even think it is better to postpone (so Concepts are not slowed... or=
=20
>> worse) and get some real feedback.
>>
>
> But we *have* "real feedback". It's not like terse syntax manifested=20
> ex-nihilo sometime in 2017. It's out there in the Concepts TS, which is=
=20
> being used by real people.
>


Well, that's debatable, considering even the STL does not use these yet.=20
Why should anyone use them in production en masse when they are not ready?=
=20
The real use begins with 20.
=20

=20

>
> Let me put it a different way. Do you *really* want to have to write this=
=20
>>> to have a conceptualized lambda:
>>>
>>> []<Concept C1, Concept C2>(C1 &c1, const C2 &c2) {...}
>>>
>>> Rather than
>>>
>>> [](Concept &c1, const Concept &c2) {...}
>>>
>>> Or
>>>
>>> [](Concept{} &c1, const Concept{} &c2) {...}
>>>
>>> Why is the first one better than the second or third? What is all of=20
>>> that verbiage providing?
>>>
>>
>> I personally have no problem with either 1 or 2.
>>
>
> Then why does the title of this thread call Bjarne's proposal "madness"?=
=20
> If you wanted to rail against Herb's proposal, then you should have focus=
ed=20
> on that specifically.
>


First and foremost I apologies for overly emotional use of words.=20
Second the topic is not about any specific proposal. How the title implies=
=20
Bjarne's? It does not.
Third I have massive respect to both of them and in particular Herb, as he=
=20
is one of the best speakers and his Zero-overhead exceptions is the single=
=20
most exiting new proposal for me personally.
In general I am pro Bjarne terse, except for introducers.

What I call madness (and again, I regret) is the fact we have 100% working=
=20
solution (yes, not 99%, but 100%) that the vast majority will feel at home=
=20
with, that is still being "improved" and no improvement is undeniably=20
better.
=20


> And BTW the last example should be [](Concept{C1} &c1, const Concept{C2}=
=20
>> &c2) {=E2=80=A6} to match the first, otherwise the {} will surely be opt=
ional=20
>> (as the proposal anticipates)
>>
>
> Anticipation isn't the same thing as "gonna happen". Because once you mak=
e=20
> those curly braces optional, you lose the ability to easily tell whether =
a=20
> function is a template or not. Which was the primary problem being resolv=
ed.
>

Only goes to show one of the problems with the proposal - even the author=
=20
thinks "it might" not be needed (and it is not).=20
=20

>
> This is new language - new syntax *and* new idioms - 2-in-1 instructions.=
=20
>> (again, putting aside the mental overlap with object creation)
>>
>> All this *right after* we doubled down on the 30 years old name=20
>> introducing syntax - <Type Name> - with lambdas as well!=20
>>
>>
>> And I ask again - what is the problem of having comma separated template=
=20
>> arguments <Concept C1, C2> ?
>>
>
> Because it doesn't make things shorter. Not by nearly as much. We're=20
> talking about creating syntax that lets you see what's going on without s=
o=20
> much text. Dropping a single word like that isn't helping.=20
>
=20
>
>> And if we want the required statement to be able to also introduce, why=
=20
>> does it need brand new syntax?=20
>>
>
> Wait: I thought the reason you hated Herb's syntax was because it is a=20
> novel syntax. How is using `requires` to preemptively create a template a=
ny=20
> less novel?
>


It is not novel because it just omits something that the compiler can=20
deduce.=20
It does not introduce any new syntax and even the time traveler will=20
understand it after he has first seen the full syntax just one time.

template<typename In1, typename In2, typename Out> //< deduce me
requires Mergeable<In1, In2, Out>=20
Out merge(In1,In1,In2,In2,Out);=20
=20
In any case I am not proposing anything, just asking!



> instead of=20
>> Mergeable{In1, In2, Out}=20
>> Out merge(In1,In1,In2,In2,Out);
>>
>> just=20
>> requires Mergeable<In1, In2, Out>=20
>> Out merge(In1,In1,In2,In2,Out);
>>
>> No new syntax AND it is clear we are starting a template.
>>
>
> But nobody's suggesting that. Well OK, Bjarne is probably still hoping=20
> concept introduction syntax will make it in, but Herb's proposal doesn't =
do=20
> that. It does this:
>
=20
Currently it is suggested as

template<Mergeable{In1, In2, Out}>
Out merge(In1,In1,In2,In2,Out);
=20
By both of them.


> Mergeable{Out, In1, In2} merge(In1, In1, In2, In2, Out);
>
> That is, you define `Mergeable` such that it *is* the output type. So=20
> it's not some special syntax that begins a template function declaration.=
=20
> It behaves no differently than any other use of a concept for a function'=
s=20
> output parameter, while simultaneously naming some of its template=20
> parameters for use as function parameter types.
>


And it will *surely* clash with any anonymous structures return syntax,=20
some of which are already proposed.
After all, it *already* looks like some class that it is returned. That is=
=20
the problem with doing too much with too few words.

In any case=20

Output_it copy(Input_it, Input_it, Output_it);=20

is miles better (clear) then

Output_it{O} copy(Input_it{I}, I, O); =20

Although it is longer.=20

Same for the classical syntax

template<Output_it O, Input_it I>=20
O copy(I, I, O); =20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c7ba9022-3ab6-47b0-bfc2-62218e643d48%40isocpp.or=
g.

------=_Part_1030_1991354448.1529531515507
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, June 20, 2018 at 11:05:06 PM UTC+3, =
Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Wednesday, June 20, 2018 at 2:54:47 PM UTC-4, <a>mihailn...@gmail.c=
om</a> wrote:<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">On We=
dnesday, June 20, 2018 at 7:44:58 PM UTC+3, Nicol Bolas wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, June 20, 2018 at =
2:46:56 AM UTC-4, <a>mihailn...@gmail.com</a> wrote:<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></div><div>I *wish* that was the cas=
e, but &quot;the other&quot; is not &#39;out&#39; - it is still actively pu=
rsued. Hence this topic.</div><div><br></div><div>My wish is to have this d=
iscussion after C++ 23 instead.<br></div></div></blockquote><div><br></div>=
<div>Your earlier statement suggested that you were concerned that terse sy=
ntax was interferring with the rest of concepts being shipped: &quot;Even w=
orse - to have the terse lambda blocking normal lambda. Because we are ther=
e with Concepts.&quot;</div><div><br></div><div>But now, you&#39;re saying =
that you&#39;re not concerned with when the rest of concepts is shipped. Yo=
u&#39;re merely concerned that terse syntax <i>exists at all</i>. That peop=
le are working on trying to get a feature into the standard that you don&#3=
9;t want.=C2=A0</div></div></blockquote><div><br></div><div>I am not concer=
ned when the rest will ship if ever,</div></div></blockquote><div><br></div=
><div>When I said &quot;rest&quot;, I meant the &quot;non-terse template&qu=
ot; part.<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> I even think it is better to postpone (so Concepts =
are not slowed... or worse) and get some real feedback.</div></div></blockq=
uote><div><br></div><div>But we <i>have</i> &quot;real feedback&quot;. It&#=
39;s not like terse syntax manifested ex-nihilo sometime in 2017. It&#39;s =
out there in the Concepts TS, which is being used by real people.<br></div>=
</div></blockquote><div><br></div><div><br></div><div>Well, that&#39;s deba=
table, considering even the STL does not use these yet. Why should anyone u=
se them in production en masse when they are not ready? The real use begins=
 with 20.<br>=C2=A0</div><div><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div></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></div><div></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Le=
t me put it a different way. Do you <i>really</i> want to have to write thi=
s to have a conceptualized lambda:</div><div><br></div><div style=3D"backgr=
ound-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:soli=
d;border-width:1px"><code><div><span style=3D"color:#660">[]&lt;</span><spa=
n style=3D"color:#606">Concept</span><span style=3D"color:#000"> C1</span><=
span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span =
style=3D"color:#606">Concept</span><span style=3D"color:#000"> C2</span><sp=
an style=3D"color:#660">&gt;(</span><span style=3D"color:#000">C1 </span><s=
pan style=3D"color:#660">&amp;</span><span style=3D"color:#000">c1</span><s=
pan style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#008">const</span><span style=3D"color:#000"> C2 </span><span=
 style=3D"color:#660">&amp;</span><span style=3D"color:#000">c2</span><span=
 style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">{...}</span><span style=3D"color:#000"><br><br></span><spa=
n style=3D"color:#606">Rather</span><span style=3D"color:#000"> than<br><br=
></span><span style=3D"color:#660">[](</span><span style=3D"color:#606">Con=
cept</span><span style=3D"color:#000"> </span><span style=3D"color:#660">&a=
mp;</span><span style=3D"color:#000">c1</span><span style=3D"color:#660">,<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#008">const</=
span><span style=3D"color:#000"> </span><span style=3D"color:#606">Concept<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">&amp;</=
span><span style=3D"color:#000">c2</span><span style=3D"color:#660">)</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">{...}</span>=
<span style=3D"color:#000"><br><br></span><span style=3D"color:#606">Or</sp=
an><span style=3D"color:#000"><br><br></span><span style=3D"color:#660">[](=
</span><span style=3D"color:#606">Concept</span><span style=3D"color:#660">=
{}</span><span style=3D"color:#000"> </span><span style=3D"color:#660">&amp=
;</span><span style=3D"color:#000">c1</span><span style=3D"color:#660">,</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">const</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#606">Concept</s=
pan><span style=3D"color:#660">{}</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">&amp;</span><span style=3D"color:#000">c2</span>=
<span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#660">{...}</span></div></code></div><div><br></div><div>Wh=
y is the first one better than the second or third? What is all of that ver=
biage providing?<br></div></div></blockquote><div><br></div><div>I personal=
ly have no problem with either 1 or 2.</div></div></blockquote><div><br></d=
iv><div>Then why does the title of this thread call Bjarne&#39;s proposal &=
quot;madness&quot;? If you wanted to rail against Herb&#39;s proposal, then=
 you should have focused on that specifically.<br></div></div></blockquote>=
<div><br></div><div><br></div><div>First and foremost I apologies for overl=
y emotional use of words.=C2=A0</div><div>Second the topic is not about any=
 specific proposal. How the title implies Bjarne&#39;s? It does not.<br></d=
iv><div>Third I have massive respect to both of them and in particular Herb=
, as he is one of the best speakers and his Zero-overhead exceptions is the=
 single most exiting new proposal for me personally.</div><div>In general I=
 am pro Bjarne terse, except for introducers.</div><div><br></div><div>What=
 I call madness (and again, I regret) is the fact we have 100% working solu=
tion (yes, not 99%, but 100%) that the vast majority will feel at home with=
, that is still being &quot;improved&quot; and no improvement is undeniably=
 better.</div><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div></div><div><br></div><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></div><div>And BTW the last e=
xample should be=C2=A0<font face=3D"courier new,monospace">[](Concept{C1} &=
amp;c1, const Concept{C2} &amp;c2) {=E2=80=A6} </font><font face=3D"arial,s=
ans-serif">to match the first, otherwise the {} will surely be optional (as=
 the proposal anticipates)</font></div></div></blockquote><div><br></div><d=
iv>Anticipation isn&#39;t the same thing as &quot;gonna happen&quot;. Becau=
se once you make those curly braces optional, you lose the ability to easil=
y tell whether a function is a template or not. Which was the primary probl=
em being resolved.<br></div></div></blockquote><div><br></div><div>Only goe=
s to show one of the problems with the proposal - even the author thinks &q=
uot;it might&quot; not be needed (and it is not).=C2=A0</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><font face=3D"courier new,monospace"><font face=3D"arial,sans-serif"></f=
ont></font></div><div><font face=3D"arial,sans-serif">This is new language =
- new syntax <i>and</i> new idioms - 2-in-1 instructions. (again, putting a=
side the mental overlap with object creation)</font></div><div><font face=
=3D"arial,sans-serif"><br></font></div><div><font face=3D"arial,sans-serif"=
>All this <i>right after</i> we doubled down on the 30 years old name intro=
ducing syntax - &lt;Type Name&gt; - with lambdas as well!=C2=A0</font></div=
><div><font face=3D"arial,sans-serif"><br></font></div><div><font face=3D"a=
rial,sans-serif"><br></font></div><div><font face=3D"arial,sans-serif">And =
I ask again - what is the problem of having comma separated template argume=
nts</font><font face=3D"courier new,monospace"> &lt;Concept C1, C2&gt; ?</f=
ont></div></div></blockquote><div><br></div><div>Because it doesn&#39;t mak=
e things shorter. Not by nearly as much. We&#39;re talking about creating s=
yntax that lets you see what&#39;s going on without so much text. Dropping =
a single word like that isn&#39;t helping.=C2=A0</div></div></blockquote><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<font face=3D"courier new,monospace"></font></div><div><font face=3D"arial,=
sans-serif">And if we want the required statement to be able to also introd=
uce, why does it need brand new syntax?=C2=A0</font></div></div></blockquot=
e><div><br></div><div>Wait: I thought the reason you hated Herb&#39;s synta=
x was because it is a novel syntax. How is using `requires` to preemptively=
 create a template any less novel?</div></div></blockquote><div><br></div><=
div><br></div><div>It is not novel because it just omits something that the=
 compiler can deduce.=C2=A0</div><div>It does not introduce any new syntax =
and even the time traveler will understand it after he has first seen the f=
ull syntax just one time.</div><div><br></div><div><font face=3D"courier ne=
w,monospace">template&lt;typename In1, typename In2, typename Out&gt; //&lt=
; deduce me<br>requires Mergeable&lt;In1, In2, Out&gt; <br>Out merge(In1,In=
1,In2,In2,Out); </font><br></div><div>=C2=A0</div><div>In any case I am not=
 proposing anything, just asking!</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><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><font face=3D"ari=
al,sans-serif"></font></div><div>instead of=C2=A0<br></div><div><font face=
=3D"courier new,monospace">Mergeable{In1, In2, Out}=C2=A0</font></div><div>=
<font face=3D"courier new,monospace">Out merge(In1,In1,In2,In2,Out);</font>=
</div><div><font face=3D"courier new,monospace"><br></font></div><div><font=
 face=3D"arial,sans-serif">just</font><font face=3D"courier new,monospace">=
=C2=A0</font></div><div><font face=3D"courier new,monospace"><div><font fac=
e=3D"courier new,monospace" style=3D"border-bottom-color:rgb(34,34,34);bord=
er-bottom-style:none;border-bottom-width:0px;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-color:rgb(34=
,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;margin=
-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0=
px;padding-right:0px;padding-top:0px">requires Mergeable&lt;In1, In2, Out&g=
t;=C2=A0</font></div><div><font face=3D"courier new,monospace" style=3D"bor=
der-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width=
:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-wid=
th:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-righ=
t-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top=
-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0p=
x;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px">Ou=
t merge(In1,In1,In2,In2,Out);</font></div><div><b></b><i></i><u></u><sub></=
sub><sup></sup><strike></strike><br></div></font><div><font face=3D"arial,s=
ans-serif">No new syntax AND it is clear we are starting a template.</font>=
</div></div></div></blockquote><div><br></div><div>But nobody&#39;s suggest=
ing that. Well OK, Bjarne is probably still hoping concept introduction syn=
tax will make it in, but Herb&#39;s proposal doesn&#39;t do that. It does t=
his:</div></div></blockquote><div>=C2=A0</div><div>Currently it is suggeste=
d as</div><div><br></div><div><div style=3D"background-color: transparent; =
border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bot=
tom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; borde=
r-image-slice: 100%; border-image-source: none; border-image-width: 1; bord=
er-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-color: rgb(34, 34, 34); border-top-style: non=
e; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Ar=
ial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; fo=
nt-style: normal; font-variant: normal; font-weight: 400; letter-spacing: n=
ormal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top:=
 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0p=
x; padding-top: 0px; text-align: left; text-decoration: none; text-indent: =
0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: nor=
mal; word-spacing: 0px;"><font face=3D"courier new,monospace" style=3D"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; margin-bottom: 0px; margin-left: 0px; margin-right: 0=
px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right:=
 0px; padding-top: 0px;">template&lt;Mergeable{In1, In2, Out}&gt;</font></d=
iv><div style=3D"background-color: transparent; border-bottom-color: rgb(34=
, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-imag=
e-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: 0px; border-right-color: r=
gb(34, 34, 34); border-right-style: none; border-right-width: 0px; border-t=
op-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; c=
olor: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Hel=
vetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-vari=
ant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; =
margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-b=
ottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-a=
lign: left; text-decoration: none; text-indent: 0px; text-transform: none; =
-webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><f=
ont face=3D"courier new,monospace" style=3D"border-bottom-color: rgb(34, 34=
, 34); border-bottom-style: none; border-bottom-width: 0px; border-image-ou=
tset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-ima=
ge-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(3=
4, 34, 34); border-right-style: none; border-right-width: 0px; border-top-c=
olor: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; margi=
n-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; paddin=
g-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">Ou=
t merge(In1,In1,In2,In2,Out);</font></div>=C2=A0</div><div>By both of them.=
</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"ltr"><div><br></div><div><div style=3D"background-color:rgb(250,250,250=
);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code>=
<div><span style=3D"color:#606">Mergeable</span><span style=3D"color:#660">=
{</span><span style=3D"color:#606">Out</span><span style=3D"color:#660">,</=
span><span style=3D"color:#000"> </span><span style=3D"color:#606">In1</spa=
n><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#606">In2</span><span style=3D"color:#660">}</span><span =
style=3D"color:#000"> merge</span><span style=3D"color:#660">(</span><span =
style=3D"color:#606">In1</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#606">In1</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#606">In2</span><span style=3D"color:#660">,</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#606">In2</span><span style=3D"color:#=
660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#606">=
Out</span><span style=3D"color:#660">);</span></div></code></div><br></div>=
<div></div><div>That is, you define `Mergeable` such that it <i>is</i> the =
output type. So it&#39;s not some special syntax that begins a template fun=
ction declaration. It behaves no differently than any other use of a concep=
t for a function&#39;s output parameter, while simultaneously naming some o=
f its template parameters for use as function parameter types.<br></div></d=
iv></blockquote><div><br></div><div><br></div><div>And it will <i>surely</i=
> clash with any anonymous structures return syntax, some of which are alre=
ady proposed.</div><div>After all, it <i>already</i> looks like some class =
that it is returned. That is the problem with doing too much with too few w=
ords.<br></div><div><br></div><div>In any case=C2=A0</div><div><br></div><d=
iv><font face=3D"courier new,monospace">Output_it copy(Input_it, Input_it, =
Output_it);=C2=A0</font></div><div><font face=3D"courier new,monospace"><br=
></font></div><div>is miles better (clear) then</div><div><br></div><div><f=
ont face=3D"courier new,monospace">Output_it{O} copy(Input_it{I}, I, O); =
=C2=A0</font></div><div><font face=3D"courier new,monospace"><br></font></d=
iv><div>Although it is longer.=C2=A0</div><div><br></div><div>Same for the =
classical syntax</div><div><br></div><div><font face=3D"courier new,monospa=
ce">template&lt;<span style=3D"text-align: left; color: rgb(34, 34, 34); te=
xt-transform: none; text-indent: 0px; letter-spacing: normal; font-size: 13=
px; font-style: normal; font-variant: normal; font-weight: 400; text-decora=
tion: none; word-spacing: 0px; display: inline !important; white-space: nor=
mal; orphans: 2; float: none; -webkit-text-stroke-width: 0px; background-co=
lor: transparent;">Output_it O, <span style=3D"text-align: left; color: rgb=
(34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing: norma=
l; font-size: 13px; font-style: normal; font-variant: normal; font-weight: =
400; text-decoration: none; word-spacing: 0px; display: inline !important; =
white-space: normal; orphans: 2; float: none; -webkit-text-stroke-width: 0p=
x; background-color: transparent;">Input_it I</span></span>&gt;=C2=A0</font=
></div><div><font face=3D"courier new,monospace">O=C2=A0<span style=3D"text=
-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0p=
x; letter-spacing: normal; font-size: 13px; font-style: normal; font-varian=
t: normal; font-weight: 400; text-decoration: none; word-spacing: 0px; disp=
lay: inline !important; white-space: normal; orphans: 2; float: none; -webk=
it-text-stroke-width: 0px; background-color: transparent;">copy(I, I, O);=
=C2=A0=C2=A0</span></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&quot; 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/c7ba9022-3ab6-47b0-bfc2-62218e643d48%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c7ba9022-3ab6-47b0-bfc2-62218e643d48=
%40isocpp.org</a>.<br />

------=_Part_1030_1991354448.1529531515507--

------=_Part_1029_174534743.1529531515506--

.

------=_Part_1205_831085415.1529532008175
Content-Type: multipart/alternative;
 boundary="----=_Part_1206_1790368374.1529532008175"

------=_Part_1206_1790368374.1529532008175
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Is it really true that a concept can call any constexpr function? If so,=20
how can it be used to disambiguate function overloading? Isn't a big part=
=20
of concepts to be able to overload on, say, whether a container has a find=
=20
method? If so, the compiler will have to check "inside" the constexpr=20
expression to see which one is _more specialized_. For me this point has=20
always been the problematic part of "new" concepts, the tension between=20
being able to discern which of two true return values comes from a _more=20
specialized_ constexpr expression, or whether this can't be deduced and the=
=20
call is to be deemed ambiguous. Setting up clear rules for this seems=20
daunting (much more so than for the old concepts pre-2011).

Thoughts?


Den onsdag 20 juni 2018 kl. 22:44:21 UTC+2 skrev Nicol Bolas:
>
> On Wednesday, June 20, 2018 at 4:04:44 PM UTC-4, Ga=C5=A1per A=C5=BEman w=
rote:
>>
>> On Wed, Jun 20, 2018 at 8:51 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Wednesday, June 20, 2018 at 3:42:29 PM UTC-4, Ga=C5=A1per A=C5=BEman=
 wrote:
>>>>
>>>> I have an issue with reserving Concept{} because that means "create an=
=20
>>>> archetype of Concept, substituting no archetype free variables" to me.
>>>>
>>>
>>> OK, but what is an "archetype of Concept", and why would most C++=20
>>> programmers think that this syntax means that?
>>>
>>
>> An archetype of a concept is a fictional concrete type that satisfies th=
e=20
>> syntactic constraints. Under certain conditions it can be generated from=
=20
>> the concept specification, thus enabling completion.
>>
>
> If it's a "fictional" type, why do I want to name it? And if it's a type=
=20
> that gets generated, then I probably want to have something that looks li=
ke=20
> a regular type declaration `class Name : Concept`.
>
> Otherwise we're in concept map territory. And *nobody* wants to be there.
>
> Body checking might be warning only, but that doesn't mean it isn't usefu=
l.
>> =20
>>
>>>
>>> Archetypes will be important at some point, or at least I hope so - the=
y=20
>>>> are really important for completion and body-checking, and when you ha=
ve=20
>>>> that, why not be able to use them in unevaluated contexts?
>>>>
>>>
>>> Because certain members of the committee have made it abundantly clear=
=20
>>> that "Concepts" in C++ will never go beyond their current constraints.=
=20
>>> There will be no "completion and body-checking" in C++. Ever.
>>>
>>
>> People's opinions change, especially in the face of evidence. Even if th=
e=20
>> past proposals weren't acceptable, why does that prohibit it in the futu=
re?=20
>> If we can make it work in a way that's "right" for C++, why kill it now,=
=20
>> before we've had the chance to do that?
>>
>
> The moment concepts land in the standard, definition checking will be=20
> dead. Why? Because right now, a `concept` is just a constexpr expression=
=20
> based on template parameters. It doesn't have to use a `requires` clause;=
=20
> it's just a boolean value.
>
> One of the big problems with getting definition checking is dealing with=
=20
> the fact that a concept is not merely a set of expressions that have to b=
e=20
> followed (which a compiler can match expressions against), but just=20
> whatever constexpr stuff you stick in the variable. You can call arbitrar=
y=20
> constexpr functions that do arbitrary things, and that's OK.
>
> If your concepts are all defined that way, you can't have definition=20
> checking. At least, not without saying that you have to define your=20
> concepts using a specific syntax in order to get definition checking. In=
=20
> which case, you create a dichotomy between "real concepts" and "fake=20
> concepts". And if some library uses a bunch of "fake concepts", how can y=
ou=20
> have definition checking? Can you call their code that's not using real=
=20
> concepts with your types that follow the same "conceptual" concepts that=
=20
> are implemented in a non-"fake" way?
>
> No, it just turns into a big bunch of mess. We lost the fight for=20
> definition checking the minute concepts was allowed into the standard=20
> without *proven* definition checking abilities. Best to let it go and=20
> move on.
>
> The reason that syntax means Archetype to me is because Type{} is an=20
>> instantiation,
>>
>
> It's not. A concept is a template; an instantiation of a template uses=20
> `<>`.
>
> which means Concept{} is an instantiation - and an instantiation of a=20
>> concept is a type-ish thing.
>>
>

--=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/a1b8a8a0-4b72-4179-9c0a-ad44fd659450%40isocpp.or=
g.

------=_Part_1206_1790368374.1529532008175
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is it really true that a concept can call any constexpr fu=
nction? If so, how can it be used to disambiguate function overloading? Isn=
&#39;t a big part of concepts to be able to overload on, say, whether a con=
tainer has a find method? If so, the compiler will have to check &quot;insi=
de&quot; the constexpr expression to see which one is _more specialized_. F=
or me this point has always been the problematic part of &quot;new&quot; co=
ncepts, the tension between being able to discern which of two true return =
values comes from a _more specialized_ constexpr expression, or whether thi=
s can&#39;t be deduced and the call is to be deemed ambiguous. Setting up c=
lear rules for this seems daunting (much more so than for the old concepts =
pre-2011).<div><br></div><div>Thoughts?</div><div><br><br>Den onsdag 20 jun=
i 2018 kl. 22:44:21 UTC+2 skrev Nicol Bolas:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">On Wednesday, June 20, 2018 at 4:04:44 PM UT=
C-4, Ga=C5=A1per A=C5=BEman wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Jun 20, 2018 at 8=
:51 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><span>On Wednesday, June 20, 2018 at 3:42:29 PM UTC-4, Ga=C5=A1per A=C5=
=BEman wrote:<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">I hav=
e an issue with reserving Concept{} because that means &quot;create an arch=
etype of Concept, substituting no archetype free variables&quot; to me.</di=
v></blockquote><div><br></div></span><div>OK, but what is an &quot;archetyp=
e of Concept&quot;, and why would most C++ programmers think that this synt=
ax means that?<br></div></div></blockquote><div><br></div><div>An archetype=
 of a concept is a fictional concrete type that satisfies the syntactic con=
straints. Under certain conditions it can be generated from the concept spe=
cification, thus enabling completion.</div></div></div></div></blockquote><=
div><br></div><div>If it&#39;s a &quot;fictional&quot; type, why do I want =
to name it? And if it&#39;s a type that gets generated, then I probably wan=
t to have something that looks like a regular type declaration `class Name =
: Concept`.<br></div><div><br></div><div>Otherwise we&#39;re in concept map=
 territory. And <i>nobody</i> wants to be there.<br></div><div><br></div><b=
lockquote 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 class=3D"g=
mail_quote"><div>Body checking might be warning only, but that doesn&#39;t =
mean it isn&#39;t useful.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div></div><span><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></div><div>Archetypes will be impor=
tant at some point, or at least I hope so - they are really important for c=
ompletion and body-checking, and when you have that, why not be able to use=
 them in unevaluated contexts?</div></div></blockquote><div><br></div></spa=
n><div>Because certain members of the committee have made it abundantly cle=
ar that &quot;Concepts&quot; in C++ will never go beyond their current cons=
traints. There will be no &quot;completion and body-checking&quot; in C++. =
Ever.<br></div></div></blockquote><div><br></div><div>People&#39;s opinions=
 change, especially in the face of evidence. Even if the past proposals wer=
en&#39;t acceptable, why does that prohibit it in the future? If we can mak=
e it work in a way that&#39;s &quot;right&quot; for C++, why kill it now, b=
efore we&#39;ve had the chance to do that?</div></div></div></div></blockqu=
ote><div><br></div><div>The moment concepts land in the standard, definitio=
n checking will be dead. Why? Because right now, a `concept` is just a cons=
texpr expression based on template parameters. It doesn&#39;t have to use a=
 `requires` clause; it&#39;s just a boolean value.</div><div><br></div><div=
>One of the big problems with getting definition checking is dealing with t=
he fact that a concept is not merely a set of expressions that have to be f=
ollowed (which a compiler can match expressions against), but just whatever=
 constexpr stuff you stick in the variable. You can call arbitrary constexp=
r functions that do arbitrary things, and that&#39;s OK.</div><div><br></di=
v><div>If your concepts are all defined that way, you can&#39;t have defini=
tion checking. At least, not without saying that you have to define your co=
ncepts using a specific syntax in order to get definition checking. In whic=
h case, you create a dichotomy between &quot;real concepts&quot; and &quot;=
fake concepts&quot;. And if some library uses a bunch of &quot;fake concept=
s&quot;, how can you have definition checking? Can you call their code that=
&#39;s not using real concepts with your types that follow the same &quot;c=
onceptual&quot; concepts that are implemented in a non-&quot;fake&quot; way=
?</div><div><br></div><div>No, it just turns into a big bunch of mess. We l=
ost the fight for definition checking the minute concepts was allowed into =
the standard without <i>proven</i> definition checking abilities. Best to l=
et it go and move on.<br></div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div=
>The reason that syntax means Archetype to me is because Type{} is an insta=
ntiation,</div></div></div></div></blockquote><div><br></div><div>It&#39;s =
not. A concept is a template; an instantiation of a template uses `&lt;&gt;=
`.<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><div class=3D"gmail_quote"><div>which means Concept{} is an i=
nstantiation - and an instantiation of a concept is a type-ish thing.</div>=
</div></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&quot; 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/a1b8a8a0-4b72-4179-9c0a-ad44fd659450%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a1b8a8a0-4b72-4179-9c0a-ad44fd659450=
%40isocpp.org</a>.<br />

------=_Part_1206_1790368374.1529532008175--

------=_Part_1205_831085415.1529532008175--

.

------=_Part_1968_2126933012.1529543835247
Content-Type: multipart/alternative;
 boundary="----=_Part_1969_1379145745.1529543835248"

------=_Part_1969_1379145745.1529543835248
Content-Type: text/plain; charset="UTF-8"

I'm not an expert but in my point of view, in order to don't adding too
much verbosity or new syntax elements under the "time-traveler" approach, I
think C++ has already constructs enough to implement concepts without
changing template syntax too much. As a C++ user since at least 10 years
ago, something like this will be good enough for me without confusing the
alleged time-traveler:

   template<class T> // `T` refers to the type being checked.
   concept my_concept
   {
         // Anything that can be declared inside classes.

         static bool requires() { // `requires` it's a keyword but only as
a concept function member.
             // expressions that must compile with usual C++ syntax.
             // No need for `return statements`. If a call to `requires()`
compiles, it returns true.
         } // Of course, any future syntactic sugar can still be applied
over this base syntax which for now adds nothing new but the keyword
`concept`.
   };

   template<class T>
   void f(my_concept<T> const& a) { do_whatever_with_a(); }

Here, when calling `f` with anytype, the compiler must first call
`a.requires();`, and, if it compiles, then the concept is satisfied. The
syntax is the same as has been always be. If there's further improvements
or simplifications in template or concept syntax, it is applied all the
same to functions, classes and concepts. The problem with concepts having
its own syntax is that it must be treated or re-thinked separatedly for any
change on the language.

The adventage of defining concepts as some kind of metaclasses, is that you
can declare attributes, static functions, using-declarations and anything
that helps you to write your requires expressions in a more readable way,
or do anything that can be currently done with classes, like writting
partial specializations, inheritance of concepts or defining local
(auxiliary) concepts. Any future change to the core language, can be
applied and being used in metaclasses as well. So, syntactic concerns about
concepts can be left to future discussions, and the language could add
concepts "right know". The only concerns are semantical, not syntactical.

When the time-traveler reads `my_concept` he will initially think
`my_concept` is a class that must be defined somewhere, with no further
misunderstandings because there's no extra syntax; and then he founds
`concept`. The time-traveler just *google*s it and will easily understand
what is going on.

In case you need a manual check of a constraint, you can just do: `if
constexpr (concept_a<T>::requires()) bla_bla_bla();`.

About future improvements, another thing that worries me is about the extra
compilation step to check concepts. For example, standard library
components will be implemented in such a way that will satisfy for sure
certain concepts. Having to check the same contrainsts over and over again
with types that we already know will satisfy them is a waste. This can be
also applied to user-defined types that have been fully tested.

So maybe any mechanism to declare that a class satisfies a concept would be
a good think. To don't adding new syntaxes for that, let's just keep using
the functional notation, with a colon to identify it as a keyword
(emacs-lisp style):

    struct A
    {
         bool :satisfies(destructible<T> const&) { return true; } //
constexpr is mandatory, and then, implicit.
         bool :satisfies(iterable<T> const&) { return false; } // SFINAE
purposes with fast compilation times for known contexts?
    };

If you instantiate a function using an object of type `A`, and the function
requires it is `destructible`, you promises that `A` already satisfies it
and then the `requires` check of the function parameter can be skipped to
improve compilation times. If you lied, you will get the usual compiler
errors in the instantiation steps.

Of course, if a `satisfability` assertion rest on dependent types, you can
use `if constexpr` constructs to computate the result (or just use `if`;
`constexpr` is implicit inside `:satisfies`).

If later you want to reduce typing when declaring constraints (like the
already know `requires` clauses in function signatures), the language
should just use syntactic sugar over the standard approach (a `concept`
class is automatically created with the usual members described above; like
it's already done with `lambda` expressions).

Each time I read about future purposal on concepts and templates, usually
the discussions are mixed: in one hand, we have the problem of template
verbosity, and on the other hand, how to add concepts to the language, and
the discussions tries to solve both problems at once.

I think that way of expressing concepts allow more separation of concerns.
You add concepts capabilities to the language using the already existing
syntax with just a couple of keywords. Then, you can apply any liked
syntactic sugar on template declarations in an independent way (which will
affect the expressibility of concepts as well), and later, based on the
agreed template simplifications, then any specific syntactic sugar for
concepts.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6349a7db-6d98-45ff-a022-3ab98078d011%40isocpp.org.

------=_Part_1969_1379145745.1529543835248
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-family: arial, sans-serif; font-size: =
small;">I&#39;m not an expert but in my point of view, in order to don&#39;=
t adding too much verbosity or new syntax elements under the &quot;time-tra=
veler&quot; approach, I think C++ has already constructs enough to implemen=
t concepts without changing template syntax too much. As a C++ user since a=
t least 10 years ago, something like this will be good enough for me withou=
t confusing the alleged time-traveler:</span><div><span style=3D"font-famil=
y: arial, sans-serif; font-size: small;"><br></span></div><div><span style=
=3D"font-family: arial, sans-serif; font-size: small;">=C2=A0 =C2=A0templat=
e&lt;class T&gt; // `T` refers to the type being checked.</span></div><div>=
<span style=3D"font-family: arial, sans-serif; font-size: small;">=C2=A0 =
=C2=A0concept my_concept</span></div><div><span style=3D"font-family: arial=
, sans-serif; font-size: small;">=C2=A0 =C2=A0{</span></div><div><span styl=
e=3D"font-family: arial, sans-serif; font-size: small;">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0// Anything that can be declared inside classes.</span></d=
iv><div><br></div><div><span style=3D"font-family: arial, sans-serif; font-=
size: small;">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0static bool requires() { //=
 `requires` it&#39;s a keyword but only as a concept function member.</span=
></div><div><span style=3D"font-family: arial, sans-serif; font-size: small=
;">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// expressions that must=
 compile with usual C++ syntax.</span></div><div><span style=3D"font-family=
: arial, sans-serif; font-size: small;">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0// No need for `return statements`. If a call to `requires()` =
compiles, it returns true.</span></div><div><span style=3D"font-family: ari=
al, sans-serif; font-size: small;">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} // O=
f course, any future syntactic sugar can still be applied over this base sy=
ntax which for now adds nothing new but the keyword `concept`.</span></div>=
<div><span style=3D"font-family: arial, sans-serif; font-size: small;">=C2=
=A0 =C2=A0};</span></div><div><span style=3D"font-family: arial, sans-serif=
; font-size: small;"><br></span></div><div><span style=3D"font-family: aria=
l, sans-serif; font-size: small;">=C2=A0 =C2=A0template&lt;class T&gt;</spa=
n></div><div><span style=3D"font-family: arial, sans-serif; font-size: smal=
l;">=C2=A0 =C2=A0void f(my_concept&lt;T&gt; const&amp; a) { do_whatever_wit=
h_a(); }</span></div><div><span style=3D"font-family: arial, sans-serif; fo=
nt-size: small;"><br></span></div><div><font face=3D"arial, sans-serif" siz=
e=3D"2">Here, when calling `f` with anytype, the compiler must first call `=
a.requires();`, and, if it compiles, then the concept is satisfied. The syn=
tax is the same as has been always be. If there&#39;s further improvements =
or simplifications in template or concept syntax, it is applied all the sam=
e to functions, classes and concepts. The problem with concepts having its =
own syntax is that it must be treated or re-thinked separatedly for any cha=
nge on the language.<br><br>The adventage of defining concepts as some kind=
 of metaclasses, is that you can declare attributes, static functions, usin=
g-declarations and anything that helps you to write your requires expressio=
ns in a more readable way, or do anything that can be currently done with c=
lasses, like writting partial specializations, inheritance of concepts or d=
efining local (auxiliary) concepts. Any future change to the core language,=
 can be applied and being used in metaclasses as well. So, syntactic concer=
ns about concepts can be left to future discussions, and the language could=
 add concepts &quot;right know&quot;. The only concerns are semantical, not=
 syntactical.</font></div><div><font face=3D"arial, sans-serif" size=3D"2">=
<br></font></div><div><font face=3D"arial, sans-serif" size=3D"2">When the =
time-traveler reads `my_concept` he will initially think `my_concept` is a =
class that must be defined somewhere, with no further misunderstandings bec=
ause there&#39;s no extra syntax; and then he founds `concept`. The time-tr=
aveler just <i>google</i>s it and will easily understand what is going on.<=
/font></div><div><br></div><div><font face=3D"arial, sans-serif" size=3D"2"=
>In case you need a manual check of a constraint, you can just do: `if cons=
texpr (concept_a&lt;T&gt;::requires()) bla_bla_bla();`.</font></div><div><f=
ont face=3D"arial, sans-serif" size=3D"2"><br></font></div><div><font face=
=3D"arial, sans-serif" size=3D"2">About future improvements, a</font><span =
style=3D"font-family: arial, sans-serif; font-size: small;">nother thing th=
at worries me is about the extra compilation step to check concepts. For ex=
ample, standard library components will be implemented in such a way that w=
ill satisfy for sure certain concepts. Having to check the same contrainsts=
 over and over again with types that we already know will satisfy them is a=
 waste. This can be also applied to user-defined types that have been fully=
 tested.<br><br>So maybe any mechanism to declare that a class satisfies a =
concept would be a good think. To don&#39;t adding new syntaxes for that, l=
et&#39;s just keep using the functional notation, with a colon to identify =
it as a keyword (emacs-lisp style):</span></div><div><font face=3D"arial, s=
ans-serif" size=3D"2"><br>=C2=A0 =C2=A0 struct A</font></div><div><font fac=
e=3D"arial, sans-serif" size=3D"2">=C2=A0 =C2=A0 {</font></div><div><font f=
ace=3D"arial, sans-serif" size=3D"2">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bool=
 :satisfies(destructible&lt;T&gt; const&amp;) { return true; } // constexpr=
 is mandatory, and then, implicit.</font></div><div><font face=3D"arial, sa=
ns-serif" size=3D"2">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bool :satisfies(iter=
able&lt;T&gt; const&amp;) { return false; } // SFINAE purposes with fast co=
mpilation times for known contexts?</font></div><div><font face=3D"arial, s=
ans-serif" size=3D"2">=C2=A0 =C2=A0 };</font></div><div><font face=3D"arial=
, sans-serif" size=3D"2"><br></font></div><div><font face=3D"arial, sans-se=
rif" size=3D"2">If you instantiate a function using an object of type `A`, =
and the function requires it is `destructible`, you promises that `A` alrea=
dy satisfies it and then the `requires` check of the function parameter can=
 be skipped to improve compilation times. If you lied, you will get the usu=
al compiler errors in the instantiation steps.<br><br>Of course, if a `sati=
sfability` assertion rest on dependent types, you can use `if constexpr` co=
nstructs to computate the result (or just use `if`; `constexpr` is implicit=
 inside `:satisfies`).</font></div><div><font face=3D"arial, sans-serif" si=
ze=3D"2"><br></font></div><div><font face=3D"arial, sans-serif" size=3D"2">=
If later you want to reduce typing when declaring constraints (like the alr=
eady know `requires` clauses in function signatures), the language should j=
ust use syntactic sugar over the standard approach (a `concept` class is au=
tomatically created with the usual members described above; like it&#39;s a=
lready done with `lambda` expressions).</font></div><div><font face=3D"aria=
l, sans-serif" size=3D"2"><br></font></div><div><font face=3D"arial, sans-s=
erif" size=3D"2">Each time I read about future purposal on concepts and tem=
plates, usually the discussions are mixed: in one hand, we have the problem=
 of template verbosity, and on the other hand, how to add concepts to the l=
anguage, and the discussions tries to solve both problems at once.</font></=
div><div><font face=3D"arial, sans-serif" size=3D"2"><br></font></div><div>=
<font face=3D"arial, sans-serif" size=3D"2">I think that way of expressing =
concepts allow more separation of concerns. You add concepts capabilities t=
o the language using the already existing syntax with just a couple of keyw=
ords. Then, you can apply any liked syntactic sugar on template declaration=
s in an independent way (which will affect the expressibility of concepts a=
s well), and later, based on the agreed template simplifications, then any =
specific syntactic sugar for concepts.</font></div><div><font face=3D"arial=
, sans-serif" size=3D"2"><br></font></div><div><font face=3D"arial, sans-se=
rif" size=3D"2"><br></font></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/6349a7db-6d98-45ff-a022-3ab98078d011%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6349a7db-6d98-45ff-a022-3ab98078d011=
%40isocpp.org</a>.<br />

------=_Part_1969_1379145745.1529543835248--

------=_Part_1968_2126933012.1529543835247--

.

------=_Part_3349_1006364972.1529569469014
Content-Type: multipart/alternative;
 boundary="----=_Part_3350_548322050.1529569469015"

------=_Part_3350_548322050.1529569469015
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The way to see if a concept is "more specialized" than another is to check=
=20
if the first is a conjunction using the second.

template <class T> constexpr bool foo();
template <class T> constexpr bool bar();=20

template <class T> concept Foo =3D foo<T>();
template <class T> concept FooBar =3D Foo<T> && bar<T>();

Here FooBar is necessarily more specialized than Foo: There is no way that=
=20
a type can satisfy FooBar, without satisfying Foo.
In theory, it could also work in the opposite way with disjunction, but I=
=20
don't remember if that's a thing.


Le jeudi 21 juin 2018 00:00:08 UTC+2, Bengt Gustafsson a =C3=A9crit :
>
> Is it really true that a concept can call any constexpr function? If so,=
=20
> how can it be used to disambiguate function overloading? Isn't a big part=
=20
> of concepts to be able to overload on, say, whether a container has a fin=
d=20
> method? If so, the compiler will have to check "inside" the constexpr=20
> expression to see which one is _more specialized_. For me this point has=
=20
> always been the problematic part of "new" concepts, the tension between=
=20
> being able to discern which of two true return values comes from a _more=
=20
> specialized_ constexpr expression, or whether this can't be deduced and t=
he=20
> call is to be deemed ambiguous. Setting up clear rules for this seems=20
> daunting (much more so than for the old concepts pre-2011).
>
> Thoughts?
>
>
> Den onsdag 20 juni 2018 kl. 22:44:21 UTC+2 skrev Nicol Bolas:
>>
>> On Wednesday, June 20, 2018 at 4:04:44 PM UTC-4, Ga=C5=A1per A=C5=BEman =
wrote:
>>>
>>> On Wed, Jun 20, 2018 at 8:51 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Wednesday, June 20, 2018 at 3:42:29 PM UTC-4, Ga=C5=A1per A=C5=BEma=
n wrote:
>>>>>
>>>>> I have an issue with reserving Concept{} because that means "create a=
n=20
>>>>> archetype of Concept, substituting no archetype free variables" to me=
..
>>>>>
>>>>
>>>> OK, but what is an "archetype of Concept", and why would most C++=20
>>>> programmers think that this syntax means that?
>>>>
>>>
>>> An archetype of a concept is a fictional concrete type that satisfies=
=20
>>> the syntactic constraints. Under certain conditions it can be generated=
=20
>>> from the concept specification, thus enabling completion.
>>>
>>
>> If it's a "fictional" type, why do I want to name it? And if it's a type=
=20
>> that gets generated, then I probably want to have something that looks l=
ike=20
>> a regular type declaration `class Name : Concept`.
>>
>> Otherwise we're in concept map territory. And *nobody* wants to be there=
..
>>
>> Body checking might be warning only, but that doesn't mean it isn't=20
>>> useful.
>>> =20
>>>
>>>>
>>>> Archetypes will be important at some point, or at least I hope so -=20
>>>>> they are really important for completion and body-checking, and when =
you=20
>>>>> have that, why not be able to use them in unevaluated contexts?
>>>>>
>>>>
>>>> Because certain members of the committee have made it abundantly clear=
=20
>>>> that "Concepts" in C++ will never go beyond their current constraints.=
=20
>>>> There will be no "completion and body-checking" in C++. Ever.
>>>>
>>>
>>> People's opinions change, especially in the face of evidence. Even if=
=20
>>> the past proposals weren't acceptable, why does that prohibit it in the=
=20
>>> future? If we can make it work in a way that's "right" for C++, why kil=
l it=20
>>> now, before we've had the chance to do that?
>>>
>>
>> The moment concepts land in the standard, definition checking will be=20
>> dead. Why? Because right now, a `concept` is just a constexpr expression=
=20
>> based on template parameters. It doesn't have to use a `requires` clause=
;=20
>> it's just a boolean value.
>>
>> One of the big problems with getting definition checking is dealing with=
=20
>> the fact that a concept is not merely a set of expressions that have to =
be=20
>> followed (which a compiler can match expressions against), but just=20
>> whatever constexpr stuff you stick in the variable. You can call arbitra=
ry=20
>> constexpr functions that do arbitrary things, and that's OK.
>>
>> If your concepts are all defined that way, you can't have definition=20
>> checking. At least, not without saying that you have to define your=20
>> concepts using a specific syntax in order to get definition checking. In=
=20
>> which case, you create a dichotomy between "real concepts" and "fake=20
>> concepts". And if some library uses a bunch of "fake concepts", how can =
you=20
>> have definition checking? Can you call their code that's not using real=
=20
>> concepts with your types that follow the same "conceptual" concepts that=
=20
>> are implemented in a non-"fake" way?
>>
>> No, it just turns into a big bunch of mess. We lost the fight for=20
>> definition checking the minute concepts was allowed into the standard=20
>> without *proven* definition checking abilities. Best to let it go and=20
>> move on.
>>
>> The reason that syntax means Archetype to me is because Type{} is an=20
>>> instantiation,
>>>
>>
>> It's not. A concept is a template; an instantiation of a template uses=
=20
>> `<>`.
>>
>> which means Concept{} is an instantiation - and an instantiation of a=20
>>> concept is a type-ish thing.
>>>
>>

--=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/8662ee7c-f9ec-431e-9cb4-7e373270e39f%40isocpp.or=
g.

------=_Part_3350_548322050.1529569469015
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The way to see if a concept is &quot;more specialized&quot=
; than another is to check if the first is a conjunction using the second.<=
br><br><div style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: br=
eak-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">t=
emplate</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">templa=
te</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> bar</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br=
><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">templ=
ate</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">concept</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Foo</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;();</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">concept=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">FooBar</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Foo</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bar</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;();</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>=
Here FooBar is necessarily more specialized than Foo: There is no way that =
a type can satisfy FooBar, without satisfying Foo.<br>In theory, it could a=
lso work in the opposite way with disjunction, but I don&#39;t remember if =
that&#39;s a thing.<br><br><br>Le jeudi 21 juin 2018 00:00:08 UTC+2, Bengt =
Gustafsson a =C3=A9crit=C2=A0:<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">Is it really true that a concept can call any constexpr fu=
nction? If so, how can it be used to disambiguate function overloading? Isn=
&#39;t a big part of concepts to be able to overload on, say, whether a con=
tainer has a find method? If so, the compiler will have to check &quot;insi=
de&quot; the constexpr expression to see which one is _more specialized_. F=
or me this point has always been the problematic part of &quot;new&quot; co=
ncepts, the tension between being able to discern which of two true return =
values comes from a _more specialized_ constexpr expression, or whether thi=
s can&#39;t be deduced and the call is to be deemed ambiguous. Setting up c=
lear rules for this seems daunting (much more so than for the old concepts =
pre-2011).<div><br></div><div>Thoughts?</div><div><br><br>Den onsdag 20 jun=
i 2018 kl. 22:44:21 UTC+2 skrev Nicol Bolas:<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">On Wednesday, June 20, 2018 at 4:04:44 PM UTC-4, =
Ga=C5=A1per A=C5=BEman wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Jun 20, 2018 at 8:51 PM,=
 Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><spa=
n>On Wednesday, June 20, 2018 at 3:42:29 PM UTC-4, Ga=C5=A1per A=C5=BEman w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I have an iss=
ue with reserving Concept{} because that means &quot;create an archetype of=
 Concept, substituting no archetype free variables&quot; to me.</div></bloc=
kquote><div><br></div></span><div>OK, but what is an &quot;archetype of Con=
cept&quot;, and why would most C++ programmers think that this syntax means=
 that?<br></div></div></blockquote><div><br></div><div>An archetype of a co=
ncept is a fictional concrete type that satisfies the syntactic constraints=
.. Under certain conditions it can be generated from the concept specificati=
on, thus enabling completion.</div></div></div></div></blockquote><div><br>=
</div><div>If it&#39;s a &quot;fictional&quot; type, why do I want to name =
it? And if it&#39;s a type that gets generated, then I probably want to hav=
e something that looks like a regular type declaration `class Name : Concep=
t`.<br></div><div><br></div><div>Otherwise we&#39;re in concept map territo=
ry. And <i>nobody</i> wants to be there.<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 class=3D"gmail_quo=
te"><div>Body checking might be warning only, but that doesn&#39;t mean it =
isn&#39;t useful.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div></div><span><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></div><div>Archetypes will be important at =
some point, or at least I hope so - they are really important for completio=
n and body-checking, and when you have that, why not be able to use them in=
 unevaluated contexts?</div></div></blockquote><div><br></div></span><div>B=
ecause certain members of the committee have made it abundantly clear that =
&quot;Concepts&quot; in C++ will never go beyond their current constraints.=
 There will be no &quot;completion and body-checking&quot; in C++. Ever.<br=
></div></div></blockquote><div><br></div><div>People&#39;s opinions change,=
 especially in the face of evidence. Even if the past proposals weren&#39;t=
 acceptable, why does that prohibit it in the future? If we can make it wor=
k in a way that&#39;s &quot;right&quot; for C++, why kill it now, before we=
&#39;ve had the chance to do that?</div></div></div></div></blockquote><div=
><br></div><div>The moment concepts land in the standard, definition checki=
ng will be dead. Why? Because right now, a `concept` is just a constexpr ex=
pression based on template parameters. It doesn&#39;t have to use a `requir=
es` clause; it&#39;s just a boolean value.</div><div><br></div><div>One of =
the big problems with getting definition checking is dealing with the fact =
that a concept is not merely a set of expressions that have to be followed =
(which a compiler can match expressions against), but just whatever constex=
pr stuff you stick in the variable. You can call arbitrary constexpr functi=
ons that do arbitrary things, and that&#39;s OK.</div><div><br></div><div>I=
f your concepts are all defined that way, you can&#39;t have definition che=
cking. At least, not without saying that you have to define your concepts u=
sing a specific syntax in order to get definition checking. In which case, =
you create a dichotomy between &quot;real concepts&quot; and &quot;fake con=
cepts&quot;. And if some library uses a bunch of &quot;fake concepts&quot;,=
 how can you have definition checking? Can you call their code that&#39;s n=
ot using real concepts with your types that follow the same &quot;conceptua=
l&quot; concepts that are implemented in a non-&quot;fake&quot; way?</div><=
div><br></div><div>No, it just turns into a big bunch of mess. We lost the =
fight for definition checking the minute concepts was allowed into the stan=
dard without <i>proven</i> definition checking abilities. Best to let it go=
 and move on.<br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>The rea=
son that syntax means Archetype to me is because Type{} is an instantiation=
,</div></div></div></div></blockquote><div><br></div><div>It&#39;s not. A c=
oncept is a template; an instantiation of a template uses `&lt;&gt;`.<br></=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote"><div>which means Concept{} is an instantia=
tion - and an instantiation of a concept is a type-ish thing.</div></div></=
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&quot; 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/8662ee7c-f9ec-431e-9cb4-7e373270e39f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8662ee7c-f9ec-431e-9cb4-7e373270e39f=
%40isocpp.org</a>.<br />

------=_Part_3350_548322050.1529569469015--

------=_Part_3349_1006364972.1529569469014--

.

------=_Part_5237_2029459147.1529592938620
Content-Type: multipart/alternative;
 boundary="----=_Part_5238_1012015289.1529592938620"

------=_Part_5238_1012015289.1529592938620
Content-Type: text/plain; charset="UTF-8"

Ok, I was reading some old papers on the then-called Concepts Light and
then it hit me.

*Terse syntax have nothing to do with Concepts*! And It never had. It was *a
feature creep* from the beginning, an additional goal, the goal to have
generic code expressed naturally.

This goal however has nothing to do with Concepts as the goal for Concepts
is to have constrained types and nothing more.

The goal of generic code expressed naturally is unrelated - you might want
*un*constrained types expressed naturally.

But, before concepts we didn't have "natural" templates! We didn't have func(auto)
or some  func(class{}) for 30 years

This is were ALL the problems stem from - the fact we try to "evolve"
natural syntax, but there is no base to evolve from!

As a result we create jump, a discontinuation, which either leads to the so
called "natural" syntax looking more alien then templates themselves (incl.
introducing new constructs).
or
We got confused "is auto func(Searchabe&)"  a template. It is normal to be
confused - there is no continuous evolution. We/some resist the
discontinuation.

On the other hand Concepts, as an integral part of the template system *do*
fit - it *is* a smooth evolution in both syntax and meaning.


And it goes the other direction - because natural has nothing to do with
Concepts, the syntax MUST work with unconstrained as well. We MUST have
func(auto) or  func(class{T});


With all that out of the way, I intended to write a proposal to not include
any terse syntax for 20. Now I don't have a shadow of doubt this is The
Right Thing (for now). Luckily (not that it s luck!) the current working
paper does not includes any of it.

To iterate, I am not against natural, but
it MUST be tackled as separate problem,
it MUST be decupled from Concepts (physically and mentally)
it MUST be tackled AFTER Concepts and
it MUST handle unconstrained as well.

--
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/5083fdc0-5316-4b70-bb80-c0bc4c756232%40isocpp.org.

------=_Part_5238_1012015289.1529592938620
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Ok, I was reading some old papers on the then-called =
Concepts Light and then it hit me. =C2=A0</div><div><br></div><div><i>Terse=
 syntax have nothing to do with Concepts</i>! And It never had. It was <i>a=
 feature creep</i> from the beginning, an additional goal, the goal to have=
 generic code expressed naturally.</div><div><br></div><div>This goal howev=
er has nothing to do with Concepts as the goal for Concepts is to have cons=
trained types and nothing more.=C2=A0</div><div><br></div><div>The goal of =
<span style=3D"display: inline !important; float: none; background-color: t=
ransparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;He=
lvetica&quot;,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;">generic=
 code expressed naturally is unrelated - you might want <i>un</i>constraine=
d types=C2=A0<span style=3D"display: inline !important; float: none; backgr=
ound-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&q=
uot;,&quot;Helvetica&quot;,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; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: =
0px;">expressed naturally.=C2=A0</span></span></div><div><span style=3D"dis=
play: inline !important; float: none; background-color: transparent; color:=
 rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif; font-size: 13px; font-style: normal; font-variant: normal; font-wei=
ght: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decora=
tion: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-wid=
th: 0px; white-space: normal; word-spacing: 0px;"><span style=3D"display: i=
nline !important; float: none; background-color: transparent; color: rgb(34=
, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;=
 font-size: 13px; font-style: normal; font-variant: normal; font-weight: 40=
0; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: n=
one; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px=
; white-space: normal; word-spacing: 0px;"><br></span></span></div><div>But=
, before concepts we didn&#39;t have &quot;natural&quot; templates! We didn=
&#39;t have <font face=3D"courier new,monospace">func(auto) <font face=3D"a=
rial,sans-serif">or some=C2=A0 </font>func(class{}) <span style=3D"display:=
 inline !important; float: none; background-color: transparent; color: rgb(=
34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-seri=
f; 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; -webkit-text-stroke-width: 0=
px; white-space: normal; word-spacing: 0px;">for 30 years</span></font></di=
v><div><br></div><div>This is were ALL the problems stem from - the fact we=
 try to &quot;evolve&quot; natural syntax, but there is no base to evolve f=
rom!</div><div><br></div><div>As a result we create jump, a discontinuation=
, which either leads to the so called &quot;natural&quot; syntax looking mo=
re alien then templates themselves (incl. introducing new constructs).<br><=
/div><div>or<br></div><div>We got confused &quot;is <font face=3D"courier n=
ew,monospace">auto func(Searchabe&amp;)</font>&quot;=C2=A0 a template. It i=
s normal to be confused - there is no continuous evolution. We/some resist =
the discontinuation.=C2=A0</div><div><span style=3D"background-color: trans=
parent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bo=
rder-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretc=
h; border-image-slice: 100%; border-image-source: none; border-image-width:=
 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-lef=
t-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-top-st=
yle: none; border-top-width: 0px; color: rgb(34, 34, 34); display: inline; =
float: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp=
;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: norma=
l; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-lef=
t: 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; -webkit-te=
xt-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><br style=3D=
"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bo=
ttom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; bord=
er-image-slice: 100%; border-image-source: none; border-image-width: 1; bor=
der-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; borde=
r-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: no=
ne; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-rig=
ht: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-r=
ight: 0px; padding-top: 0px;"></span></div><div><div style=3D"background-co=
lor: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style=
: none; border-bottom-width: 0px; border-image-outset: 0; border-image-repe=
at: stretch; border-image-slice: 100%; border-image-source: none; border-im=
age-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-s=
tyle: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bor=
der-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-fa=
mily: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; f=
ont-size: 13px; font-style: normal; font-variant: normal; font-weight: 400;=
 letter-spacing: normal; margin-bottom: 0px; margin-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: n=
one; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px=
; white-space: normal; word-spacing: 0px;"><span style=3D"background-color:=
 transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: no=
ne; border-bottom-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; bord=
er-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-=
top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); display: in=
line; float: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helveti=
ca&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant:=
 normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; marg=
in-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-botto=
m: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align=
: left; text-decoration: none; text-indent: 0px; text-transform: none; -web=
kit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">On the=
 other hand Concepts, as an integral part of the template system <i style=
=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border=
-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; b=
order-image-slice: 100%; border-image-source: none; border-image-width: 1; =
border-left-color: rgb(34, 34, 34); border-left-style: none; border-left-wi=
dth: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; bo=
rder-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style:=
 none; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-=
right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; paddin=
g-right: 0px; padding-top: 0px;">do</i> fit - it <i style=3D"border-bottom-=
color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-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: 0px; border-r=
ight-color: rgb(34, 34, 34); border-right-style: none; border-right-width: =
0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-=
width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin=
-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padd=
ing-top: 0px;">is</i> a smooth evolution in both syntax and meaning.</span>=
</div><div style=3D"background-color: transparent; border-bottom-color: rgb=
(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-i=
mage-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bor=
der-image-source: none; border-image-width: 1; border-left-color: rgb(34, 3=
4, 34); border-left-style: none; border-left-width: 0px; border-right-color=
: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; borde=
r-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px=
; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;=
Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0p=
x; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddin=
g-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; tex=
t-align: left; text-decoration: none; text-indent: 0px; text-transform: non=
e; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"=
><br></div></div><div><br>And it goes the other direction <i></i>- because =
natural has nothing to do with Concepts, the syntax MUST work with un<span =
style=3D"display: inline !important; float: none; background-color: transpa=
rent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetic=
a&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: norm=
al; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left;=
 text-decoration: none; text-indent: 0px; text-transform: none; -webkit-tex=
t-stroke-width: 0px; white-space: normal; word-spacing: 0px;">constrained a=
s well. We MUST have func(auto) or=C2=A0 func(class{T});</span></div><div><=
span style=3D"display: inline !important; float: none; background-color: tr=
ansparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Hel=
vetica&quot;,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; -webki=
t-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><br></sp=
an></div><div><span style=3D"display: inline !important; float: none; backg=
round-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&=
quot;,&quot;Helvetica&quot;,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-transfor=
m: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing:=
 0px;"><br></span></div><div><span style=3D"display: inline !important; flo=
at: none; background-color: transparent; color: rgb(34, 34, 34); font-famil=
y: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; fon=
t-style: normal; font-variant: normal; font-weight: 400; letter-spacing: no=
rmal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px=
; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal=
; word-spacing: 0px;">With all that out of the way, I intended to write a p=
roposal to not include any terse syntax for 20. Now I don&#39;t have a shad=
ow of doubt this is The Right Thing (for now). Luckily (not that it s luck!=
) the current working paper does not includes any of it.</span></div><div><=
span style=3D"display: inline !important; float: none; background-color: tr=
ansparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Hel=
vetica&quot;,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; -webki=
t-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><br></sp=
an></div><div><span style=3D"display: inline !important; float: none; backg=
round-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&=
quot;,&quot;Helvetica&quot;,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-transfor=
m: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing:=
 0px;">To iterate, I am not against natural, but=C2=A0</span></div><div><sp=
an style=3D"display: inline !important; float: none; background-color: tran=
sparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helve=
tica&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: n=
ormal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: le=
ft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-=
text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">it MUST be=
 tackled as separate problem,=C2=A0</span></div><div><span style=3D"display=
: inline !important; float: none; background-color: transparent; color: rgb=
(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-ser=
if; 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; -webkit-text-stroke-width: =
0px; white-space: normal; word-spacing: 0px;">it MUST be decupled from Conc=
epts (physically and mentally)=C2=A0</span></div><div><span style=3D"displa=
y: inline !important; float: none; background-color: transparent; color: rg=
b(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-se=
rif; font-size: 13px; font-style: normal; font-variant: normal; font-weight=
: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoratio=
n: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width:=
 0px; white-space: normal; word-spacing: 0px;">it MUST be <span style=3D"di=
splay: inline !important; float: none; background-color: transparent; color=
: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,san=
s-serif; font-size: 13px; font-style: normal; font-variant: normal; font-we=
ight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decor=
ation: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-wi=
dth: 0px; white-space: normal; word-spacing: 0px;">tackled </span>AFTER Con=
cepts and=C2=A0</span></div><div><span style=3D"display: inline !important;=
 float: none; background-color: transparent; color: rgb(34, 34, 34); font-f=
amily: &quot;Arial&quot;,&quot;Helvetica&quot;,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; -webkit-text-stroke-width: 0px; white-space: no=
rmal; word-spacing: 0px;">it MUST handle unconstrained as well.=C2=A0</span=
></div><div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br=
></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/5083fdc0-5316-4b70-bb80-c0bc4c756232%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5083fdc0-5316-4b70-bb80-c0bc4c756232=
%40isocpp.org</a>.<br />

------=_Part_5238_1012015289.1529592938620--

------=_Part_5237_2029459147.1529592938620--

.

------=_Part_5297_769677475.1529595608066
Content-Type: multipart/alternative;
 boundary="----=_Part_5298_174530277.1529595608066"

------=_Part_5298_174530277.1529595608066
Content-Type: text/plain; charset="UTF-8"

On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, mihailn...@gmail.com wrote:
>
> Ok, I was reading some old papers on the then-called Concepts Light and
> then it hit me.
>
> *Terse syntax have nothing to do with Concepts*! And It never had. It was *a
> feature creep* from the beginning, an additional goal, the goal to have
> generic code expressed naturally.
>
> This goal however has nothing to do with Concepts as the goal for Concepts
> is to have constrained types and nothing more.
>

That's one way to express it. Another way to express the goal of the
Concepts-lite proposal is to improve the ability of users to constrain
templates. That involves two pieces: how to define constraints and how to
*apply* them. "Natural syntax" is about application, and therefore falls
under its purview.

The goal of generic code expressed naturally is unrelated - you might want
> *un*constrained types expressed naturally.
>

You almost never want truly unconstrained types. Seriously, show me a
template that genuinely imposes *no constraints* on its argument. It
happens, but not very often. `any`'s constructor requires that `T` is
CopyConstructible. Even `emplace` requires that the sequence of parameters
can be forwarded to `allocator::construct`.

We use unconstrained types mainly because constraining them requires lots
of effort. The goal of concepts is to minimize that effort. The *fruits* of
that goal is the ability to express those constraints "naturally".

So to say that constraints and "natural syntax" are unrelated is
misleading. The existence of constraints makes "natural syntax" useful,
readable, and digestible. And "natural syntax" makes constraint application
more useable, readable, and digestible.

The two are closely associated.

Unconstrained "natural syntax" is just porting lambda's use of `auto`
parameters to regular functions. And doing only that is just not worth the
effort, not in a world where constraints exist as a feature.

But, before concepts we didn't have "natural" templates! We didn't have func(auto)
> or some  func(class{}) for 30 years
>

[](auto foo) {...}

This is were ALL the problems stem from - the fact we try to "evolve"
> natural syntax, but there is no base to evolve from!
>
> As a result we create jump, a discontinuation, which either leads to the
> so called "natural" syntax looking more alien then templates themselves
> (incl. introducing new constructs).
> or
> We got confused "is auto func(Searchabe&)"  a template. It is normal to
> be confused - there is no continuous evolution. We/some resist the
> discontinuation.
>
> On the other hand Concepts, as an integral part of the template system
> *do* fit - it *is* a smooth evolution in both syntax and meaning.
>
>
> And it goes the other direction - because natural has nothing to do with
> Concepts, the syntax MUST work with unconstrained as well. We MUST have
> func(auto) or  func(class{T});
>

Why? I mean sure, it'd be nice, but we can get unconstrained behavior with
`template<typename T> concept all = true;`. I'm not formally against the
use of `auto`, but that's primarily because lambdas set the precedent.
Personally, if there were no generic lambdas, then I would say that `auto`
is the wrong keyword because it doesn't work like `auto` normally does in
deduction.

If we could switch to a named "unconstrained" constraint rather than
`auto`, I think that would be better.

Also, `class` implies a constraint: that the type is a class. That's why I
prefer `typename` in templates over `class`, even though they technically
mean the same thing.

With all that out of the way, I intended to write a proposal to not include
> any terse syntax for 20. Now I don't have a shadow of doubt this is The
> Right Thing (for now). Luckily (not that it s luck!) the current working
> paper does not includes any of it.
>

And luckily, most of the committee seems to disagree, since they're moving
forward with these proposals. I highly doubt you're going to convince them
that the very idea of terse syntax is not related to concepts, or that they
should abandon the idea.

To iterate, I am not against natural, but
> it MUST be tackled as separate problem,
>

It already is a separate problem. Suggesting that people keep doing the
thing they're already doing isn't useful.

it MUST be decupled from Concepts (physically and mentally)
>

See above.

it MUST be tackled AFTER Concepts and
>

We already are "AFTER Concepts".

it MUST handle unconstrained as well.
>

Ignoring the fact that you can have a `template<typename T> concept all =
true;` to get "unconstrained", Bjarne's syntax already does. Nobody is
ignoring "unconstrained" cases.

--
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/dc85fa84-b3b3-40ae-a1ed-c4872b04a816%40isocpp.org.

------=_Part_5298_174530277.1529595608066
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, mihailn..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>Ok, I was reading some old papers on the then-called Concepts Lig=
ht and then it hit me. =C2=A0</div><div><br></div><div><i>Terse syntax have=
 nothing to do with Concepts</i>! And It never had. It was <i>a feature cre=
ep</i> from the beginning, an additional goal, the goal to have generic cod=
e expressed naturally.</div><div><br></div><div>This goal however has nothi=
ng to do with Concepts as the goal for Concepts is to have constrained type=
s and nothing more.</div></div></blockquote><div><br></div><div>That&#39;s =
one way to express it. Another way to express the goal of the Concepts-lite=
 proposal is to improve the ability of users to constrain templates. That i=
nvolves two pieces: how to define constraints and how to <i>apply</i> them.=
 &quot;Natural syntax&quot; is about application, and therefore falls under=
 its purview.<br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div></div><div>The goal of <span style=3D"display=
:inline!important;float:none;background-color:transparent;color:rgb(34,34,3=
4);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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;white-space:normal;word-spacing:0px">generic code expressed naturally =
is unrelated - you might want <i>un</i>constrained types=C2=A0<span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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">expressed naturally.</=
span></span></div></div></blockquote><div><br></div>You almost never want t=
ruly unconstrained types. Seriously, show me a template that genuinely impo=
ses <i>no constraints</i> on its argument. It happens, but not very often. =
`any`&#39;s constructor requires that `T` is CopyConstructible. Even `empla=
ce` requires that the sequence of parameters can be forwarded to `allocator=
::construct`.<div><br></div><div>We use unconstrained types mainly because =
constraining them requires lots of effort. The goal of concepts is to minim=
ize that effort. The <i>fruits</i> of that goal is the ability to express t=
hose constraints &quot;naturally&quot;.<br></div><div><br></div><div>So to =
say that constraints and &quot;natural syntax&quot; are unrelated is mislea=
ding. The existence of constraints makes &quot;natural syntax&quot; useful,=
 readable, and digestible. And &quot;natural syntax&quot; makes constraint =
application more useable, readable, and digestible.</div><div><br></div><di=
v>The two are closely associated.<br></div><div><br></div><div>Unconstraine=
d &quot;natural syntax&quot; is just porting lambda&#39;s use of `auto` par=
ameters to regular functions. And doing only that is just not worth the eff=
ort, not in a world where constraints exist as a feature.<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><=
span style=3D"display:inline!important;float:none;background-color:transpar=
ent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;=
,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-weigh=
t:400;letter-spacing:normal;text-align:left;text-decoration:none;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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"></span></span></div><d=
iv>But, before concepts we didn&#39;t have &quot;natural&quot; templates! W=
e didn&#39;t have <font face=3D"courier new,monospace">func(auto) <font fac=
e=3D"arial,sans-serif">or some=C2=A0 </font>func(class{}) <span style=3D"di=
splay:inline!important;float:none;background-color:transparent;color:rgb(34=
,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font=
-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spa=
cing:normal;text-align:left;text-decoration:none;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px">for 30 years</span></font></=
div></div></blockquote><div><br></div><div>[](auto foo) {...}<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"><d=
iv></div><div>This is were ALL the problems stem from - the fact we try to =
&quot;evolve&quot; natural syntax, but there is no base to evolve from!</di=
v><div><br></div><div>As a result we create jump, a discontinuation, which =
either leads to the so called &quot;natural&quot; syntax looking more alien=
 then templates themselves (incl. introducing new constructs).<br></div><di=
v>or<br></div><div>We got confused &quot;is <font face=3D"courier new,monos=
pace">auto func(Searchabe&amp;)</font>&quot;=C2=A0 a template. It is normal=
 to be confused - there is no continuous evolution. We/some resist the disc=
ontinuation.=C2=A0</div><div><span><br style=3D"border-bottom-color:rgb(34,=
34,34);border-bottom-style:none;border-bottom-width:0px;border-left-color:r=
gb(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;border-top-c=
olor:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom=
:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;pad=
ding-left:0px;padding-right:0px;padding-top:0px"></span></div><div><div><sp=
an>On the other hand Concepts, as an integral part of the template system <=
i style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;borde=
r-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;b=
order-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:no=
ne;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:n=
one;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px=
;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;paddi=
ng-top:0px">do</i> fit - it <i style=3D"border-bottom-color:rgb(34,34,34);b=
order-bottom-style:none;border-bottom-width:0px;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-color:rgb=
(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;mar=
gin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-lef=
t:0px;padding-right:0px;padding-top:0px">is</i> a smooth evolution in both =
syntax and meaning.</span></div><div><br></div></div><div><br>And it goes t=
he other direction <i></i>- because natural has nothing to do with Concepts=
, the syntax MUST work with un<span style=3D"display:inline!important;float=
:none;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Ar=
ial&quot;,&quot;Helvetica&quot;,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;white-space:normal=
;word-spacing:0px">constrained as well. We MUST have func(auto) or=C2=A0 fu=
nc(class{T});</span></div></div></blockquote><div><br></div><div>Why? I mea=
n sure, it&#39;d be nice, but we can get unconstrained behavior with `templ=
ate&lt;typename T&gt; concept all =3D true;`. I&#39;m not formally against =
the use of `auto`, but that&#39;s primarily because lambdas set the precede=
nt. Personally, if there were no generic lambdas, then I would say that `au=
to` is the wrong keyword because it doesn&#39;t work like `auto` normally d=
oes in deduction.</div><div><br></div><div>If we could switch to a named &q=
uot;unconstrained&quot; constraint rather than `auto`, I think that would b=
e better.</div><div><br></div><div>Also, `class` implies a constraint: that=
 the type is a class. That&#39;s why I prefer `typename` in templates over =
`class`, even though they technically mean the same thing.<br></div><div><b=
r></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>=
<span style=3D"display:inline!important;float:none;background-color:transpa=
rent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot=
;,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"></span></di=
v><div><span style=3D"display:inline!important;float:none;background-color:=
transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helveti=
ca&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;fo=
nt-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">With=
 all that out of the way, I intended to write a proposal to not include any=
 terse syntax for 20. Now I don&#39;t have a shadow of doubt this is The Ri=
ght Thing (for now). Luckily (not that it s luck!) the current working pape=
r does not includes any of it.</span></div></div></blockquote><div><br></di=
v><div>And luckily, most of the committee seems to disagree, since they&#39=
;re moving forward with these proposals. I highly doubt you&#39;re going to=
 convince them that the very idea of terse syntax is not related to concept=
s, or that they should abandon the idea.<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><span style=3D"dis=
play:inline!important;float:none;background-color:transparent;color:rgb(34,=
34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-=
size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spac=
ing:normal;text-align:left;text-decoration:none;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px"></span></div><div><span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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">To iterate, I am not a=
gainst natural, but=C2=A0</span></div><div><span style=3D"display:inline!im=
portant;float:none;background-color:transparent;color:rgb(34,34,34);font-fa=
mily:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font=
-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;tex=
t-align:left;text-decoration:none;text-indent:0px;text-transform:none;white=
-space:normal;word-spacing:0px">it MUST be tackled as separate problem,=C2=
=A0</span></div></div></blockquote><div><br></div><div>It already is a sepa=
rate problem. Suggesting that people keep doing the thing they&#39;re alrea=
dy doing isn&#39;t useful.<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><span style=3D"display:inline!im=
portant;float:none;background-color:transparent;color:rgb(34,34,34);font-fa=
mily:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font=
-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;tex=
t-align:left;text-decoration:none;text-indent:0px;text-transform:none;white=
-space:normal;word-spacing:0px">it MUST be decupled from Concepts (physical=
ly and mentally)=C2=A0</span></div></div></blockquote><div><br></div><div>S=
ee above.<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><span style=3D"display:inline!important;float:n=
one;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Aria=
l&quot;,&quot;Helvetica&quot;,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">it MUST be <span style=3D"display:inline!important;float:n=
one;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Aria=
l&quot;,&quot;Helvetica&quot;,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">tackled </span>AFTER Concepts and=C2=A0</span></div></div>=
</blockquote><div><br></div><div>We already are &quot;AFTER Concepts&quot;.=
<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><span style=3D"display:inline!important;float:none;backgro=
und-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&qu=
ot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant=
:normal;font-weight:400;letter-spacing:normal;text-align:left;text-decorati=
on:none;text-indent:0px;text-transform:none;white-space:normal;word-spacing=
:0px">it MUST handle unconstrained as well.</span></div></div></blockquote>=
<div><br></div><div>Ignoring the fact that you can have a `template&lt;type=
name T&gt; concept all =3D true;` to get &quot;unconstrained&quot;, Bjarne&=
#39;s syntax already does. Nobody is ignoring &quot;unconstrained&quot; cas=
es.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/dc85fa84-b3b3-40ae-a1ed-c4872b04a816%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dc85fa84-b3b3-40ae-a1ed-c4872b04a816=
%40isocpp.org</a>.<br />

------=_Part_5298_174530277.1529595608066--

------=_Part_5297_769677475.1529595608066--

.

------=_Part_5653_953656392.1529595979373
Content-Type: multipart/alternative;
 boundary="----=_Part_5654_1967548802.1529595979374"

------=_Part_5654_1967548802.1529595979374
Content-Type: text/plain; charset="UTF-8"



On Thursday, June 21, 2018 at 11:40:08 AM UTC-4, Nicol Bolas wrote:
>
> On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, mihailn...@gmail.com
> wrote:
>>
>> Ok, I was reading some old papers on the then-called Concepts Light and
>> then it hit me.
>>
>> *Terse syntax have nothing to do with Concepts*! And It never had. It
>> was *a feature creep* from the beginning, an additional goal, the goal
>> to have generic code expressed naturally.
>>
>> This goal however has nothing to do with Concepts as the goal for
>> Concepts is to have constrained types and nothing more.
>>
>
> That's one way to express it. Another way to express the goal of the
> Concepts-lite proposal is to improve the ability of users to constrain
> templates. That involves two pieces: how to define constraints and how to
> *apply* them. "Natural syntax" is about application, and therefore falls
> under its purview.
>

This is a point I wanted to elaborate on further.

Concepts-lite did not have to allow this:

template<Concept T> ...;

It could have required you to use an explicit requires clause:

template<typename T> requires Concept<T> ...;

That would have been the bare minimum feature: requires clauses applying
concepts.

But the proposal didn't stop there; it allowed you to apply a concept to a
template parameter directly. It even implicitly instantiates that concept
without needing <>. Back when function concepts were allowed/required, it
even implicitly *called the function*.

Those are all usability enhancements: they make applying a concept to a
template easier and more digestible.

Natural syntax is merely another form of usability enhancement. If the
replacing of `typename` with a type concept is reasonable for
Concepts-lite, then so too is the consideration of other usability
enhancements. Even ones that remove `template` boilerplate.

--
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/4f30ad78-83c6-4a0a-95c0-836c4289df76%40isocpp.org.

------=_Part_5654_1967548802.1529595979374
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, June 21, 2018 at 11:40:08 AM UTC-4, N=
icol Bolas 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">On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, <a>mihailn...@gmail.co=
m</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>O=
k, I was reading some old papers on the then-called Concepts Light and then=
 it hit me. =C2=A0</div><div><br></div><div><i>Terse syntax have nothing to=
 do with Concepts</i>! And It never had. It was <i>a feature creep</i> from=
 the beginning, an additional goal, the goal to have generic code expressed=
 naturally.</div><div><br></div><div>This goal however has nothing to do wi=
th Concepts as the goal for Concepts is to have constrained types and nothi=
ng more.</div></div></blockquote><div><br></div><div>That&#39;s one way to =
express it. Another way to express the goal of the Concepts-lite proposal i=
s to improve the ability of users to constrain templates. That involves two=
 pieces: how to define constraints and how to <i>apply</i> them. &quot;Natu=
ral syntax&quot; is about application, and therefore falls under its purvie=
w.<br></div></div></blockquote><div><br></div><div>This is a point I wanted=
 to elaborate on further.</div><div><br></div><div>Concepts-lite did not ha=
ve to allow this:</div><div><br></div><div><div style=3D"background-color: =
rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; =
border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #=
008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Concept</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>...;</span></div></code></div><br></div><div>It could have required you to=
 use an explicit requires clause:</div><div><br></div><div><div style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pre=
ttyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">template</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> requires </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Concept</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...;</=
span></div></code></div><br></div><div>That would have been the bare minimu=
m feature: requires clauses applying concepts.</div><div><br></div><div>But=
 the proposal didn&#39;t stop there; it allowed you to apply a concept to a=
 template parameter directly. It even implicitly instantiates that concept =
without needing &lt;&gt;. Back when function concepts were allowed/required=
, it even implicitly <i>called the function</i>.</div><div><br></div><div>T=
hose are all usability enhancements: they make applying a concept to a temp=
late easier and more digestible.<br></div><div><br></div><div>Natural synta=
x is merely another form of usability enhancement. If the replacing of `typ=
ename` with a type concept is reasonable for Concepts-lite, then so too is =
the consideration of other usability enhancements. Even ones that remove `t=
emplate` boilerplate.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/4f30ad78-83c6-4a0a-95c0-836c4289df76%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f30ad78-83c6-4a0a-95c0-836c4289df76=
%40isocpp.org</a>.<br />

------=_Part_5654_1967548802.1529595979374--

------=_Part_5653_953656392.1529595979373--

.

------=_Part_5781_44607890.1529599023501
Content-Type: multipart/alternative;
 boundary="----=_Part_5782_1150237030.1529599023501"

------=_Part_5782_1150237030.1529599023501
Content-Type: text/plain; charset="UTF-8"



On Thursday, June 21, 2018 at 6:46:19 PM UTC+3, Nicol Bolas wrote:
>
>
>
> On Thursday, June 21, 2018 at 11:40:08 AM UTC-4, Nicol Bolas wrote:
>>
>> On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> Ok, I was reading some old papers on the then-called Concepts Light and
>>> then it hit me.
>>>
>>> *Terse syntax have nothing to do with Concepts*! And It never had. It
>>> was *a feature creep* from the beginning, an additional goal, the goal
>>> to have generic code expressed naturally.
>>>
>>> This goal however has nothing to do with Concepts as the goal for
>>> Concepts is to have constrained types and nothing more.
>>>
>>
>> That's one way to express it. Another way to express the goal of the
>> Concepts-lite proposal is to improve the ability of users to constrain
>> templates. That involves two pieces: how to define constraints and how to
>> *apply* them. "Natural syntax" is about application, and therefore falls
>> under its purview.
>>
>
> This is a point I wanted to elaborate on further.
>
> Concepts-lite did not have to allow this:
>
> template<Concept T> ...;
>
> It could have required you to use an explicit requires clause:
>
> template<typename T> requires Concept<T> ...;
>
> That would have been the bare minimum feature: requires clauses applying
> concepts.
>
> But the proposal didn't stop there; it allowed you to apply a concept to a
> template parameter directly. It even implicitly instantiates that concept
> without needing <>. Back when function concepts were allowed/required, it
> even implicitly *called the function*.
>

This does not introduce natural syntax. It builds on templates machinery. I
am not against shortcuts. Natural is much more then that however.


>
> Those are all usability enhancements: they make applying a concept to a
> template easier and more digestible.
>
> Natural syntax is merely another form of usability enhancement. If the
> replacing of `typename` with a type concept is reasonable for
> Concepts-lite, then so too is the consideration of other usability
> enhancements. Even ones that remove `template` boilerplate.
>

It is *obviously* not that simple as "merely another form". If it was, then
there would have been no issues.
But exactly because we cross a boundary outside templates, outside what we
used for 30 years, we can't agree how to proceed and the opinions vary
greatly - from minimalistic to new templates syntax.

It is better to see and accepts there is boundary, then to pretend there is
some sort of "natural evolution" that happens to "suddenly" not be so
natural for many people.

<Will answer the previous post separately.>

--
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/1d1782a7-7056-4d46-b4d6-adee63a04382%40isocpp.org.

------=_Part_5782_1150237030.1529599023501
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, June 21, 2018 at 6:46:19 PM UTC+3, Ni=
col Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><br><br>On Thursday, June 21, 2018 at 11:40:08 AM UTC-4, Nicol Bolas wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, Ju=
ne 21, 2018 at 10:55:38 AM UTC-4, <a>mihailn...@gmail.com</a> wrote:<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>Ok, I was reading so=
me old papers on the then-called Concepts Light and then it hit me. =C2=A0<=
/div><div><br></div><div><i>Terse syntax have nothing to do with Concepts</=
i>! And It never had. It was <i>a feature creep</i> from the beginning, an =
additional goal, the goal to have generic code expressed naturally.</div><d=
iv><br></div><div>This goal however has nothing to do with Concepts as the =
goal for Concepts is to have constrained types and nothing more.</div></div=
></blockquote><div><br></div><div>That&#39;s one way to express it. Another=
 way to express the goal of the Concepts-lite proposal is to improve the ab=
ility of users to constrain templates. That involves two pieces: how to def=
ine constraints and how to <i>apply</i> them. &quot;Natural syntax&quot; is=
 about application, and therefore falls under its purview.<br></div></div><=
/blockquote><div><br></div><div>This is a point I wanted to elaborate on fu=
rther.</div><div><br></div><div>Concepts-lite did not have to allow this:</=
div><div><br></div><div><div style=3D"background-color:rgb(250,250,250);bor=
der-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div>=
<span style=3D"color:#008">template</span><span style=3D"color:#660">&lt;</=
span><span style=3D"color:#606">Concept</span><span style=3D"color:#000"> T=
</span><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> </=
span><span style=3D"color:#660">...;</span></div></code></div><br></div><di=
v>It could have required you to use an explicit requires clause:</div><div>=
<br></div><div><div style=3D"background-color:rgb(250,250,250);border-color=
:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span sty=
le=3D"color:#008">template</span><span style=3D"color:#660">&lt;</span><spa=
n style=3D"color:#008">typename</span><span style=3D"color:#000"> T</span><=
span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> requires <=
/span><span style=3D"color:#606">Concept</span><span style=3D"color:#660">&=
lt;</span><span style=3D"color:#000">T</span><span style=3D"color:#660">&gt=
;</span><span style=3D"color:#000"> </span><span style=3D"color:#660">...;<=
/span></div></code></div><br></div><div>That would have been the bare minim=
um feature: requires clauses applying concepts.</div><div><br></div><div>Bu=
t the proposal didn&#39;t stop there; it allowed you to apply a concept to =
a template parameter directly. It even implicitly instantiates that concept=
 without needing &lt;&gt;. Back when function concepts were allowed/require=
d, it even implicitly <i>called the function</i>.</div></div></blockquote><=
div><br></div><div>This does not introduce natural syntax. It builds on tem=
plates machinery. I am not against shortcuts. Natural is much more then tha=
t however.</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><br></div><div>Those are all usability enhancement=
s: they make applying a concept to a template easier and more digestible.<b=
r></div><div><br></div><div>Natural syntax is merely another form of usabil=
ity enhancement. If the replacing of `typename` with a type concept is reas=
onable for Concepts-lite, then so too is the consideration of other usabili=
ty enhancements. Even ones that remove `template` boilerplate.<br></div></d=
iv></blockquote><div><br></div><div>It is <i>obviously</i> not that simple =
as &quot;<span style=3D"display: inline !important; float: none; background=
-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;=
,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; fon=
t-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; te=
xt-align: left; text-decoration: none; text-indent: 0px; text-transform: no=
ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;=
">merely another form</span>&quot;. If it was, then there would have been n=
o issues.=C2=A0</div><div>But exactly because we cross a boundary outside t=
emplates, outside what we used for 30 years, we can&#39;t agree how to proc=
eed and the opinions vary greatly - from minimalistic to new templates synt=
ax.=C2=A0</div><div><br></div><div>It is better to see and accepts there is=
 boundary, then to pretend there is some sort of &quot;natural evolution&qu=
ot; that happens to &quot;suddenly&quot; not be so natural for many people.=
 =C2=A0<br></div><div><br></div><div>&lt;Will answer the previous post sepa=
rately.&gt;</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&quot; 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/1d1782a7-7056-4d46-b4d6-adee63a04382%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1d1782a7-7056-4d46-b4d6-adee63a04382=
%40isocpp.org</a>.<br />

------=_Part_5782_1150237030.1529599023501--

------=_Part_5781_44607890.1529599023501--

.

------=_Part_6270_728883862.1529603897927
Content-Type: multipart/alternative;
 boundary="----=_Part_6271_175961662.1529603897928"

------=_Part_6271_175961662.1529603897928
Content-Type: text/plain; charset="UTF-8"



On Thursday, June 21, 2018 at 6:40:08 PM UTC+3, Nicol Bolas wrote:
>
> On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, mihailn...@gmail.com
> wrote:
>>
>> Ok, I was reading some old papers on the then-called Concepts Light and
>> then it hit me.
>>
>> *Terse syntax have nothing to do with Concepts*! And It never had. It
>> was *a feature creep* from the beginning, an additional goal, the goal
>> to have generic code expressed naturally.
>>
>> This goal however has nothing to do with Concepts as the goal for
>> Concepts is to have constrained types and nothing more.
>>
>
> That's one way to express it. Another way to express the goal of the
> Concepts-lite proposal is to improve the ability of users to constrain
> templates. That involves two pieces: how to define constraints and how to
> *apply* them. "Natural syntax" is about application, and therefore falls
> under its purview.
>

Hold on, what are the two pieces. Define and Apply. "to improve the ability
of users to constrain templates", where I assume natural syntax fall in is *a
third *goal.

Because Define and Apply is already served by Concepts *without* natural
syntax. Natural syntax is "an improvement", something additional.




>
> The goal of generic code expressed naturally is unrelated - you might
>> want *un*constrained types expressed naturally.
>>
>
> You almost never want truly unconstrained types. Seriously, show me a
> template that genuinely imposes *no constraints* on its argument. It
> happens, but not very often. `any`'s constructor requires that `T` is
> CopyConstructible. Even `emplace` requires that the sequence of parameters
> can be forwarded to `allocator::construct`.
>
> We use unconstrained types mainly because constraining them requires lots
> of effort. The goal of concepts is to minimize that effort. The *fruits*
> of that goal is the ability to express those constraints "naturally".
>

Prototyping, teaching, consistency. Unconstrained are hare to stay as a
baseline.


>
> So to say that constraints and "natural syntax" are unrelated is
> misleading. The existence of constraints makes "natural syntax" useful,
> readable, and digestible. And "natural syntax" makes constraint application
> more useable, readable, and digestible.
>

First, there is no such thing as "natural syntax" as we cant agree what it
looks like.
Second, the benefits of Concepts alone are so massive that anyone will
gladly use them as they are now.
No one, ever, will boycott them because the lack of some magical syntax.
Why? Because they use the same old syntax one is using for ages!

Natural syntax is not related to Concepts directly, it is related to
Temples and generic programming.
The desire to have natural syntax will not disappear if Concepts are not
used and, with few expectations, it is not greater if Concepts are used.


>
> The two are closely associated.
>
> Unconstrained "natural syntax" is just porting lambda's use of `auto`
> parameters to regular functions. And doing only that is just not worth the
> effort, not in a world where constraints exist as a feature.
>
> But, before concepts we didn't have "natural" templates! We didn't have func(auto)
>> or some  func(class{}) for 30 years
>>
>
> [](auto foo) {...}
>
> This is were ALL the problems stem from - the fact we try to "evolve"
>> natural syntax, but there is no base to evolve from!
>>
>> As a result we create jump, a discontinuation, which either leads to the
>> so called "natural" syntax looking more alien then templates themselves
>> (incl. introducing new constructs).
>> or
>> We got confused "is auto func(Searchabe&)"  a template. It is normal to
>> be confused - there is no continuous evolution. We/some resist the
>> discontinuation.
>>
>> On the other hand Concepts, as an integral part of the template system
>> *do* fit - it *is* a smooth evolution in both syntax and meaning.
>>
>>
>> And it goes the other direction - because natural has nothing to do with
>> Concepts, the syntax MUST work with unconstrained as well. We MUST have
>> func(auto) or  func(class{T});
>>
>
> Why? I mean sure, it'd be nice, but we can get unconstrained behavior with
> `template<typename T> concept all = true;`. I'm not formally against the
> use of `auto`, but that's primarily because lambdas set the precedent.
> Personally, if there were no generic lambdas, then I would say that `auto`
> is the wrong keyword because it doesn't work like `auto` normally does in
> deduction.
>
> If we could switch to a named "unconstrained" constraint rather than
> `auto`, I think that would be better.
>
> Also, `class` implies a constraint: that the type is a class. That's why I
> prefer `typename` in templates over `class`, even though they technically
> mean the same thing.
>
> With all that out of the way, I intended to write a proposal to not
>> include any terse syntax for 20. Now I don't have a shadow of doubt this is
>> The Right Thing (for now). Luckily (not that it s luck!) the current
>> working paper does not includes any of it.
>>
>
> And luckily, most of the committee seems to disagree, since they're moving
> forward with these proposals. I highly doubt you're going to convince them
> that the very idea of terse syntax is not related to concepts, or that they
> should abandon the idea.
>


They agree, there is a clear boundary. They can't agree on syntax and the
differences are not minor, but major, diametrical.
Natural syntax is only partially related to Concepts, and is bigger then we
think - it does not flow naturally (that much was proven), it must be
invented, it is a different topic.
I am not for abandoned, but for it to be separate topic, not against
current Concepts WP and on later date so the 99% can give feedback.



>
> To iterate, I am not against natural, but
>> it MUST be tackled as separate problem,
>>
>
> It already is a separate problem. Suggesting that people keep doing the
> thing they're already doing isn't useful.
>
> it MUST be decupled from Concepts (physically and mentally)
>>
>
> See above.
>
>
Then why are natural syntax proposals against Concepts WP?
Why it is officially listed as "issues with Concepts".



> it MUST be tackled AFTER Concepts and
>>
>
> We already are "AFTER Concepts".
>

Are we?
Concepts are not only not released, they are still worked on. And by worked
on I mean real issues like the Constraining Concepts Overload Sets proposal


>
> it MUST handle unconstrained as well.
>>
>
> Ignoring the fact that you can have a `template<typename T> concept all =
> true;` to get "unconstrained", Bjarne's syntax already does. Nobody is
> ignoring "unconstrained" cases.
>

We are playing with words - is 'unconstrained' no concept or concepts which
accept everything. That's an interesting question.
Should unconstrained be expressed in terms of Concepts? Should we deprecate
class/typename or auto as arg?
Fact of the matter is we often completely ignore the unconstrained case.



--
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/0402365a-ffe5-4c5c-9eff-aa4953490657%40isocpp.org.

------=_Part_6271_175961662.1529603897928
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, June 21, 2018 at 6:40:08 PM UTC+3, Ni=
col Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, <a>mihailn...@gmail.com=
</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Ok=
, I was reading some old papers on the then-called Concepts Light and then =
it hit me. =C2=A0</div><div><br></div><div><i>Terse syntax have nothing to =
do with Concepts</i>! And It never had. It was <i>a feature creep</i> from =
the beginning, an additional goal, the goal to have generic code expressed =
naturally.</div><div><br></div><div>This goal however has nothing to do wit=
h Concepts as the goal for Concepts is to have constrained types and nothin=
g more.</div></div></blockquote><div><br></div><div>That&#39;s one way to e=
xpress it. Another way to express the goal of the Concepts-lite proposal is=
 to improve the ability of users to constrain templates. That involves two =
pieces: how to define constraints and how to <i>apply</i> them. &quot;Natur=
al syntax&quot; is about application, and therefore falls under its purview=
..<br></div></div></blockquote><div>=C2=A0</div><div>Hold on, what are the t=
wo pieces. Define and Apply. &quot;<span style=3D"display: inline !importan=
t; float: none; background-color: transparent; color: rgb(34, 34, 34); font=
-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13p=
x; font-style: normal; font-variant: normal; font-weight: 400; letter-spaci=
ng: normal; orphans: 2; text-align: left; text-decoration: none; text-inden=
t: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: =
normal; word-spacing: 0px;">to improve the ability of users to constrain te=
mplates&quot;, where I assume natural syntax fall in is <i>a third </i>goal=
..</span></div><div><span style=3D"display: inline !important; float: none; =
background-color: transparent; color: rgb(34, 34, 34); font-family: &quot;A=
rial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: n=
ormal; font-variant: normal; font-weight: 400; letter-spacing: normal; orph=
ans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-tra=
nsform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spa=
cing: 0px;"><br></span></div><div><span style=3D"display: inline !important=
; float: none; background-color: transparent; color: rgb(34, 34, 34); font-=
family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px=
; font-style: normal; font-variant: normal; font-weight: 400; letter-spacin=
g: normal; orphans: 2; text-align: left; text-decoration: none; text-indent=
: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: n=
ormal; word-spacing: 0px;">Because Define and Apply is already served by Co=
ncepts <i>without</i> natural syntax. Natural syntax is &quot;an improvemen=
t&quot;, something additional.=C2=A0</span></div><div><span style=3D"displa=
y: inline !important; float: none; background-color: transparent; color: rg=
b(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-se=
rif; font-size: 13px; font-style: normal; font-variant: normal; font-weight=
: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoratio=
n: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width:=
 0px; white-space: normal; word-spacing: 0px;"><br></span></div><div><span =
style=3D"display: inline !important; float: none; background-color: transpa=
rent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetic=
a&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: norm=
al; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left;=
 text-decoration: none; text-indent: 0px; text-transform: none; -webkit-tex=
t-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><br></span></=
div><div>=C2=A0</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"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>The goal of <span style=3D"display:inline=
!important;float:none;background-color:transparent;color:rgb(34,34,34);font=
-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;f=
ont-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;=
text-align:left;text-decoration:none;text-indent:0px;text-transform:none;wh=
ite-space:normal;word-spacing:0px">generic code expressed naturally is unre=
lated - you might want <i>un</i>constrained types=C2=A0<span style=3D"displ=
ay:inline!important;float:none;background-color:transparent;color:rgb(34,34=
,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-si=
ze:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacin=
g:normal;text-align:left;text-decoration:none;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px">expressed naturally.</span></sp=
an></div></div></blockquote><div><br></div>You almost never want truly unco=
nstrained types. Seriously, show me a template that genuinely imposes <i>no=
 constraints</i> on its argument. It happens, but not very often. `any`&#39=
;s constructor requires that `T` is CopyConstructible. Even `emplace` requi=
res that the sequence of parameters can be forwarded to `allocator::constru=
ct`.<div><br></div><div>We use unconstrained types mainly because constrain=
ing them requires lots of effort. The goal of concepts is to minimize that =
effort. The <i>fruits</i> of that goal is the ability to express those cons=
traints &quot;naturally&quot;.<br></div></div></blockquote><div><br></div><=
div>Prototyping, teaching, consistency. Unconstrained are hare to stay as a=
 baseline. =C2=A0</div><div>=C2=A0</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></div><div><br></div><div>So to say that co=
nstraints and &quot;natural syntax&quot; are unrelated is misleading. The e=
xistence of constraints makes &quot;natural syntax&quot; useful, readable, =
and digestible. And &quot;natural syntax&quot; makes constraint application=
 more useable, readable, and digestible.</div></div></blockquote><div><br><=
/div><div>First, there is no such thing as &quot;natural syntax&quot; as we=
 cant agree what it looks like.=C2=A0</div><div>Second, the benefits of Con=
cepts alone are so massive that anyone will gladly use them as they are now=
..=C2=A0</div><div>No one, ever, will boycott them because the lack of some =
magical syntax. Why? Because they use the same old syntax one is using for =
ages!=C2=A0</div><div><br></div><div>Natural syntax is not related to Conce=
pts directly, it is related to Temples and generic programming.=C2=A0</div>=
<div>The desire to have natural syntax will not disappear if Concepts are n=
ot used and, with few expectations, it is not greater if Concepts are used.=
 =C2=A0</div><div>=C2=A0</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><br></div><div>The two are closely associated.<br></d=
iv><div><br></div><div>Unconstrained &quot;natural syntax&quot; is just por=
ting lambda&#39;s use of `auto` parameters to regular functions. And doing =
only that is just not worth the effort, not in a world where constraints ex=
ist as a feature.<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><span style=3D"display:inline!important;float:=
none;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Ari=
al&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;=
font-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;t=
ext-decoration:none;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px"><span style=3D"display:inline!important;float:none;backgr=
ound-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&q=
uot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-varian=
t:normal;font-weight:400;letter-spacing:normal;text-align:left;text-decorat=
ion:none;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px"></span></span></div><div>But, before concepts we didn&#39;t have &qu=
ot;natural&quot; templates! We didn&#39;t have <font face=3D"courier new,mo=
nospace">func(auto) <font face=3D"arial,sans-serif">or some=C2=A0 </font>fu=
nc(class{}) <span style=3D"display:inline!important;float:none;background-c=
olor:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;He=
lvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:norm=
al;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:no=
ne;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"=
>for 30 years</span></font></div></div></blockquote><div><br></div><div>[](=
auto foo) {...}<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-left:=
1ex"><div dir=3D"ltr"><div></div><div>This is were ALL the problems stem fr=
om - the fact we try to &quot;evolve&quot; natural syntax, but there is no =
base to evolve from!</div><div><br></div><div>As a result we create jump, a=
 discontinuation, which either leads to the so called &quot;natural&quot; s=
yntax looking more alien then templates themselves (incl. introducing new c=
onstructs).<br></div><div>or<br></div><div>We got confused &quot;is <font f=
ace=3D"courier new,monospace">auto func(Searchabe&amp;)</font>&quot;=C2=A0 =
a template. It is normal to be confused - there is no continuous evolution.=
 We/some resist the discontinuation.=C2=A0</div><div><span><br style=3D"bor=
der-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width=
:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-wid=
th:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-righ=
t-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top=
-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0p=
x;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px"></=
span></div><div><div><span>On the other hand Concepts, as an integral part =
of the template system <i style=3D"border-bottom-color:rgb(34,34,34);border=
-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);=
border-left-style:none;border-left-width:0px;border-right-color:rgb(34,34,3=
4);border-right-style:none;border-right-width:0px;border-top-color:rgb(34,3=
4,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;margin-l=
eft:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px=
;padding-right:0px;padding-top:0px">do</i> fit - it <i style=3D"border-bott=
om-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;bor=
der-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;b=
order-right-color:rgb(34,34,34);border-right-style:none;border-right-width:=
0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0=
px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;paddin=
g-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px">is</i> a s=
mooth evolution in both syntax and meaning.</span></div><div><br></div></di=
v><div><br>And it goes the other direction <i></i>- because natural has not=
hing to do with Concepts, the syntax MUST work with un<span style=3D"displa=
y:inline!important;float:none;background-color:transparent;color:rgb(34,34,=
34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-siz=
e: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">constrained as well. We MUST hav=
e func(auto) or=C2=A0 func(class{T});</span></div></div></blockquote><div><=
br></div><div>Why? I mean sure, it&#39;d be nice, but we can get unconstrai=
ned behavior with `template&lt;typename T&gt; concept all =3D true;`. I&#39=
;m not formally against the use of `auto`, but that&#39;s primarily because=
 lambdas set the precedent. Personally, if there were no generic lambdas, t=
hen I would say that `auto` is the wrong keyword because it doesn&#39;t wor=
k like `auto` normally does in deduction.</div><div><br></div><div>If we co=
uld switch to a named &quot;unconstrained&quot; constraint rather than `aut=
o`, I think that would be better.</div><div><br></div><div>Also, `class` im=
plies a constraint: that the type is a class. That&#39;s why I prefer `type=
name` in templates over `class`, even though they technically mean the same=
 thing.<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"><di=
v dir=3D"ltr"><div><span style=3D"display:inline!important;float:none;backg=
round-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&=
quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-varia=
nt:normal;font-weight:400;letter-spacing:normal;text-align:left;text-decora=
tion:none;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px"></span></div><div><span style=3D"display:inline!important;float:non=
e;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&=
quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;fon=
t-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;text=
-decoration:none;text-indent:0px;text-transform:none;white-space:normal;wor=
d-spacing:0px">With all that out of the way, I intended to write a proposal=
 to not include any terse syntax for 20. Now I don&#39;t have a shadow of d=
oubt this is The Right Thing (for now). Luckily (not that it s luck!) the c=
urrent working paper does not includes any of it.</span></div></div></block=
quote><div><br></div><div>And luckily, most of the committee seems to disag=
ree, since they&#39;re moving forward with these proposals. I highly doubt =
you&#39;re going to convince them that the very idea of terse syntax is not=
 related to concepts, or that they should abandon the idea.<br></div></div>=
</blockquote><div><br></div><div><br></div><div>They agree, there is a clea=
r boundary. They can&#39;t agree on syntax and the differences are not mino=
r, but major, diametrical.=C2=A0</div><div>Natural syntax is only partially=
 related to Concepts, and is bigger then we think - it does not flow natura=
lly (that much was proven), it must be invented, it is a different topic.=
=C2=A0</div><div>I am not for abandoned, but for it to be separate topic, n=
ot against current Concepts WP and on later date so the 99% can give feedba=
ck.=C2=A0</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div></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><span style=3D"display:inlin=
e!important;float:none;background-color:transparent;color:rgb(34,34,34);fon=
t-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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"></span></div><div><span style=3D"displa=
y:inline!important;float:none;background-color:transparent;color:rgb(34,34,=
34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-siz=
e: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">To iterate, I am not against nat=
ural, but=C2=A0</span></div><div><span style=3D"display:inline!important;fl=
oat:none;background-color:transparent;color:rgb(34,34,34);font-family:&quot=
;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:nor=
mal;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:le=
ft;text-decoration:none;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px">it MUST be tackled as separate problem,=C2=A0</span><=
/div></div></blockquote><div><br></div><div>It already is a separate proble=
m. Suggesting that people keep doing the thing they&#39;re already doing is=
n&#39;t useful.<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-left:=
1ex"><div dir=3D"ltr"><div><span style=3D"display:inline!important;float:no=
ne;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial=
&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;fo=
nt-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;tex=
t-decoration:none;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px">it MUST be decupled from Concepts (physically and mentally)=
=C2=A0</span></div></div></blockquote><div><br></div><div>See above.<br></d=
iv><div><br></div></div></blockquote><div><br></div><div>Then why are natur=
al syntax proposals against Concepts WP?=C2=A0</div><div>Why it is official=
ly listed as &quot;issues with Concepts&quot;.</div><div><br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span =
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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;white-space:normal;word-spacing:0px">it MUST be <span =
style=3D"display:inline!important;float:none;background-color:transparent;c=
olor:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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;white-space:normal;word-spacing:0px">tackled </span>AF=
TER Concepts and=C2=A0</span></div></div></blockquote><div><br></div><div>W=
e already are &quot;AFTER Concepts&quot;.<br></div></div></blockquote><div>=
<br></div><div>Are we?=C2=A0</div><div><span style=3D"display: inline !impo=
rtant; float: none; background-color: transparent; color: rgb(34, 34, 34); =
font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,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;">Concepts are not only not released, they ar=
e still worked on. And by worked on I mean real issues like the Constrainin=
g Concepts Overload Sets proposal</span></div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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">it MUST handle unconst=
rained as well.</span></div></div></blockquote><div><br></div><div>Ignoring=
 the fact that you can have a `template&lt;typename T&gt; concept all =3D t=
rue;` to get &quot;unconstrained&quot;, Bjarne&#39;s syntax already does. N=
obody is ignoring &quot;unconstrained&quot; cases.<br></div></div></blockqu=
ote><div>=C2=A0</div><div>We are playing with words - is &#39;<span style=
=3D"display: inline !important; float: none; background-color: transparent;=
 color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quo=
t;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; f=
ont-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text=
-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-str=
oke-width: 0px; white-space: normal; word-spacing: 0px;">unconstrained&#39;=
 no concept or concepts which accept everything. That&#39;s an interesting =
question.=C2=A0</span></div><div><span style=3D"display: inline !important;=
 float: none; background-color: transparent; color: rgb(34, 34, 34); font-f=
amily: &quot;Arial&quot;,&quot;Helvetica&quot;,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; -webkit-text-stroke-width: 0px; white-space: no=
rmal; word-spacing: 0px;">Should=C2=A0<span style=3D"background-color: tran=
sparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; b=
order-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stret=
ch; border-image-slice: 100%; border-image-source: none; border-image-width=
: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-le=
ft-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: non=
e; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-s=
tyle: none; border-top-width: 0px; color: rgb(34, 34, 34); display: inline;=
 float: none; font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&am=
p;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: norm=
al; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-le=
ft: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0p=
x; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: lef=
t; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-t=
ext-stroke-width: 0px; white-space: normal; word-spacing: 0px;">unconstrain=
ed be expressed in terms of Concepts?</span> Should we deprecate class/type=
name or auto as arg?=C2=A0</span></div><div><span style=3D"display: inline =
!important; float: none; background-color: transparent; color: rgb(34, 34, =
34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-=
size: 13px; font-style: normal; font-variant: normal; font-weight: 400; let=
ter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; t=
ext-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whit=
e-space: normal; word-spacing: 0px;">Fact of the matter is we often complet=
ely ignore the=C2=A0<span style=3D"display: inline !important; float: none;=
 background-color: transparent; color: rgb(34, 34, 34); font-family: &quot;=
Arial&quot;,&quot;Helvetica&quot;,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;">unconstrained case.</span></span></div><div><span style=3D"dis=
play: inline !important; float: none; background-color: transparent; color:=
 rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif; font-size: 13px; font-style: normal; font-variant: normal; font-wei=
ght: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decora=
tion: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-wid=
th: 0px; white-space: normal; word-spacing: 0px;"></span><b></b><i></i><u><=
/u><sub></sub><sup></sup><strike></strike><br></div><div><br></div><div><b>=
</b><i></i><u></u><sub></sub><sup></sup><strike></strike><b></b><i></i><u><=
/u><sub></sub><sup></sup><strike></strike><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/0402365a-ffe5-4c5c-9eff-aa4953490657%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0402365a-ffe5-4c5c-9eff-aa4953490657=
%40isocpp.org</a>.<br />

------=_Part_6271_175961662.1529603897928--

------=_Part_6270_728883862.1529603897927--

.

------=_Part_6914_825387123.1529611517419
Content-Type: multipart/alternative;
 boundary="----=_Part_6915_594802672.1529611517419"

------=_Part_6915_594802672.1529611517419
Content-Type: text/plain; charset="UTF-8"

On Thursday, June 21, 2018 at 12:37:03 PM UTC-4, mihailn...@gmail.com wrote:
>
> On Thursday, June 21, 2018 at 6:46:19 PM UTC+3, Nicol Bolas wrote:
>>
>> On Thursday, June 21, 2018 at 11:40:08 AM UTC-4, Nicol Bolas wrote:
>>>
>>> On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, mihailn...@gmail.com
>>> wrote:
>>>>
>>>> Ok, I was reading some old papers on the then-called Concepts Light and
>>>> then it hit me.
>>>>
>>>> *Terse syntax have nothing to do with Concepts*! And It never had. It
>>>> was *a feature creep* from the beginning, an additional goal, the goal
>>>> to have generic code expressed naturally.
>>>>
>>>> This goal however has nothing to do with Concepts as the goal for
>>>> Concepts is to have constrained types and nothing more.
>>>>
>>>
>>> That's one way to express it. Another way to express the goal of the
>>> Concepts-lite proposal is to improve the ability of users to constrain
>>> templates. That involves two pieces: how to define constraints and how to
>>> *apply* them. "Natural syntax" is about application, and therefore
>>> falls under its purview.
>>>
>>
>> This is a point I wanted to elaborate on further.
>>
>> Concepts-lite did not have to allow this:
>>
>> template<Concept T> ...;
>>
>> It could have required you to use an explicit requires clause:
>>
>> template<typename T> requires Concept<T> ...;
>>
>> That would have been the bare minimum feature: requires clauses applying
>> concepts.
>>
>> But the proposal didn't stop there; it allowed you to apply a concept to
>> a template parameter directly. It even implicitly instantiates that concept
>> without needing <>. Back when function concepts were allowed/required, it
>> even implicitly *called the function*.
>>
>
> This does not introduce natural syntax. It builds on templates machinery.
> I am not against shortcuts. Natural is much more then that however.
>
>
>>
>> Those are all usability enhancements: they make applying a concept to a
>> template easier and more digestible.
>>
>> Natural syntax is merely another form of usability enhancement. If the
>> replacing of `typename` with a type concept is reasonable for
>> Concepts-lite, then so too is the consideration of other usability
>> enhancements. Even ones that remove `template` boilerplate.
>>
>
> It is *obviously* not that simple as "merely another form". If it was,
> then there would have been no issues. But exactly because we cross a
> boundary outside templates, outside what we used for 30 years, we can't
> agree how to proceed and the opinions vary greatly - from minimalistic to
> new templates syntax.
>

Let me see if I've got this right. Terse syntax is not "merely another
form" of usability enhancements. Why? Because if it trust were just that,
there wouldn't be arguments about what form it should take.

By that reasoning, `template<Concept T>` is not "merely another form"
either. Why? Because we have people *in this very thread* who have argued
that it ought to be `template<auto<Concept> T>`. There have been *actual
proposals* for `template<Concept typename T>` (thankfully, they were
expurgated). So there are arguments about what this form should take.

And therefore, *by your reasoning*, it is not "merely another form" of
"Apply". So which is it? Will you accept that we should also ditch
`template<Concept T>`? Or can we agree that disagreement alone does not
represent some kind of "boundary outside template"?

It is better to see and accepts there is boundary, then to pretend there is
> some sort of "natural evolution" that happens to "suddenly" not be so
> natural for many people.
>

Nobody is "suddenly" anything. People have had concerns about Bjarne's
"natural syntax" since its inception.

On Thursday, June 21, 2018 at 1:58:18 PM UTC-4, mihailn...@gmail.com wrote:

> On Thursday, June 21, 2018 at 6:40:08 PM UTC+3, Nicol Bolas wrote:
>>
>> On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> Ok, I was reading some old papers on the then-called Concepts Light and
>>> then it hit me.
>>>
>>> *Terse syntax have nothing to do with Concepts*! And It never had. It
>>> was *a feature creep* from the beginning, an additional goal, the goal
>>> to have generic code expressed naturally.
>>>
>>> This goal however has nothing to do with Concepts as the goal for
>>> Concepts is to have constrained types and nothing more.
>>>
>>
>> That's one way to express it. Another way to express the goal of the
>> Concepts-lite proposal is to improve the ability of users to constrain
>> templates. That involves two pieces: how to define constraints and how to
>> *apply* them. "Natural syntax" is about application, and therefore falls
>> under its purview.
>>
>
> Hold on, what are the two pieces. Define and Apply. "to improve the
> ability of users to constrain templates", where I assume natural syntax
> fall in is *a third *goal.
>

You misunderstood my meaning. "To improve the ability of users to constrain
templates" is why concepts exists at all. It is the very goal of concepts.

"Define and Apply" are the *means* to achieve that goal; they are not the
goal itself. My point is that "natural syntax" is within that goal;
therefore, it is a perfectly reasonable thing for the Concepts proposal to
include. It is not out-of-bounds, it is not scope creep or anything of the
sort.

The goal of generic code expressed naturally is unrelated - you might want
>>> *un*constrained types expressed naturally.
>>>
>>
>> You almost never want truly unconstrained types. Seriously, show me a
>> template that genuinely imposes *no constraints* on its argument. It
>> happens, but not very often. `any`'s constructor requires that `T` is
>> CopyConstructible. Even `emplace` requires that the sequence of parameters
>> can be forwarded to `allocator::construct`.
>>
>> We use unconstrained types mainly because constraining them requires lots
>> of effort. The goal of concepts is to minimize that effort. The *fruits*
>> of that goal is the ability to express those constraints "naturally".
>>
>
> Prototyping, teaching, consistency. Unconstrained are hare to stay as a
> baseline.
>

Where I come from, you start by creating an interface. In class
hierarchies, that means a base class with pure virtual functions. With
static polymorphism, that now means creating a concept.

Any good teacher should start teaching static polymorphism with concepts.
New users should be taught that unconstrained templates exist but *should
be avoided*. And any decent prototype will have a prototype interface too,
expressed as a concept.

Now sure, you're still going to need `<typename T>`, but this will be for
cases where `T` needs to be constrained by a `requires` clause. Truly
unconstrained template parameters ought to go the way of the Dodo.

So to say that constraints and "natural syntax" are unrelated is
>> misleading. The existence of constraints makes "natural syntax" useful,
>> readable, and digestible. And "natural syntax" makes constraint application
>> more useable, readable, and digestible.
>>
>
> First, there is no such thing as "natural syntax" as we cant agree what it
> looks like.
>

Yes there is. The term "natural syntax" comes directly from Bjarne
Stroustrup and *specifically* refers to the Concepts TS proposal's terse
syntax. Indeed, you were the first one to bring the term up, precisely
because the early Concepts TS proposals referred to that syntax as "natural
syntax".

What is being debated by the committee is what terse syntax will look like:
Bjarne's "natural syntax" or Herb's alternative form.

And even then, there is clear agreement on the basic principle behind terse
templates: you replace a parameter typename and/or output value with a
concept name; this causes the parameter/output value to be deduced via a
constrained template/return value deduction. So the general look of the
concept is well understood. The differences, while significant, are not
that huge.

Second, the benefits of Concepts alone are so massive that anyone will
> gladly use them as they are now.
> No one, ever, will boycott them because the lack of some magical syntax.
> Why? Because they use the same old syntax one is using for ages!
>

Who are you arguing with? *Nobody* claimed that people would avoid concepts
because of a lack of "natural syntax". Just because people will use a
feature anyway does not mean we can't make it more readable and easier to
use.

Producing the bare minimum when you can do *more* and *better* than that
doesn't make sense.

Natural syntax is not related to Concepts directly, it is related to
> Temples and generic programming.
> The desire to have natural syntax will not disappear if Concepts are not
> used and, with few expectations, it is not greater if Concepts are used.
>
>
>> With all that out of the way, I intended to write a proposal to not
>>> include any terse syntax for 20. Now I don't have a shadow of doubt this is
>>> The Right Thing (for now). Luckily (not that it s luck!) the current
>>> working paper does not includes any of it.
>>>
>>
>> And luckily, most of the committee seems to disagree, since they're
>> moving forward with these proposals. I highly doubt you're going to
>> convince them that the very idea of terse syntax is not related to
>> concepts, or that they should abandon the idea.
>>
>
> They agree, there is a clear boundary.
>

No, they agree that terse syntax needs more discussion and has issues to be
worked out compared to the rest of concepts.

They did not agree that terse syntax is unrelated to concepts, or that
terse syntax should be abandoned or delayed.

They can't agree on syntax and the differences are not minor, but major,
> diametrical.
>

"Can't" is a far cry from "haven't". The latter is true; the former has yet
to be determined.


> Natural syntax is only partially related to Concepts, and is bigger then
> we think - it does not flow naturally (that much was proven), it must be
> invented, it is a different topic.
> I am not for abandoned, but for it to be separate topic, not against
> current Concepts WP and on later date so the 99% can give feedback.
>

Who is this 99% who are incapable of giving feedback on Concepts TS, but
will be capable of giving feedback in a few years? Indeed, the entire terse
syntax discussion *is feedback* on the "natural syntax" in Concepts TS.

Why is that feedback insufficient? Why do you treat terse syntax as though
it's some novel thing that nobody has ever heard of before? It's been over *four
years* since the concepts-lite effort started.

To iterate, I am not against natural, but
>>> it MUST be tackled as separate problem,
>>>
>>
>> It already is a separate problem. Suggesting that people keep doing the
>> thing they're already doing isn't useful.
>>
>> it MUST be decupled from Concepts (physically and mentally)
>>>
>>
>> See above.
>>
>>
> Then why are natural syntax proposals against Concepts WP?
>

I don't know what you mean by "Concepts WP". The terse syntax proposals are
EWG proposals, not proposals against the Concepts TS.

Why it is officially listed as "issues with Concepts".
>

Because terse templates come from the Concepts TS. Therefore, adjustments
to issues relating to the Concepts TS are issues with concepts.

it MUST be tackled AFTER Concepts and
>>>
>>
>> We already are "AFTER Concepts".
>>
>
> Are we?
> Concepts are not only not released, they are still worked on. And by
> worked on I mean real issues like the Constraining Concepts Overload Sets
> proposal
>

We are as "AFTER Concepts" as it is reasonable to get. Unless you are
suggesting that there will be design changes to concepts that will impact
terse syntax, there is no problem moving forward with both terse syntax
discussions *and* tweaks to the concepts feature.

Again, I don't know what it is that you're so concerned about here. What
are you afraid will happen if the committee continues to debate these
proposals (besides your technical issues with Herb's proposal)? Why do you
feel it is *necessary* to shut down all discussion in this area?

--
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/2e4a8cfd-d460-43d4-b2de-864cd48e71ea%40isocpp.org.

------=_Part_6915_594802672.1529611517419
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On Thursday, June 21, 2018 at 12:37:03 PM UTC-4, miha=
iln...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">On Thursday, June 21, 2018 at 6:46:19 PM UTC+3, Nicol Bolas wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, June=
 21, 2018 at 11:40:08 AM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">On Thursday, June 21, 2018 at 10:55:38 AM U=
TC-4, <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div>Ok, I was reading some old papers on the then-ca=
lled Concepts Light and then it hit me. =C2=A0</div><div><br></div><div><i>=
Terse syntax have nothing to do with Concepts</i>! And It never had. It was=
 <i>a feature creep</i> from the beginning, an additional goal, the goal to=
 have generic code expressed naturally.</div><div><br></div><div>This goal =
however has nothing to do with Concepts as the goal for Concepts is to have=
 constrained types and nothing more.</div></div></blockquote><div><br></div=
><div>That&#39;s
 one way to express it. Another way to express the goal of the=20
Concepts-lite proposal is to improve the ability of users to constrain=20
templates. That involves two pieces: how to define constraints and how=20
to <i>apply</i> them. &quot;Natural syntax&quot; is about application, and =
therefore falls under its purview.<br></div></div></blockquote><div><br></d=
iv><div>This is a point I wanted to elaborate on further.</div><div><br></d=
iv><div>Concepts-lite did not have to allow this:</div><div><br></div><div>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px"><code><div><span style=3D"color:#00=
8">template</span><span style=3D"color:#660">&lt;</span><span style=3D"colo=
r:#606">Concept</span><span style=3D"color:#000"> T</span><span style=3D"co=
lor:#660">&gt;</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">...;</span></div></code></div><br></div><div>It could have required=
 you to use an explicit requires clause:</div><div><br></div><div><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px"><code><div><span style=3D"color:#008">templa=
te</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">t=
ypename</span><span style=3D"color:#000"> T</span><span style=3D"color:#660=
">&gt;</span><span style=3D"color:#000"> requires </span><span style=3D"col=
or:#606">Concept</span><span style=3D"color:#660">&lt;</span><span style=3D=
"color:#000">T</span><span style=3D"color:#660">&gt;</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">...;</span></div></code></div=
><br></div><div>That would have been the bare minimum feature: requires cla=
uses applying concepts.</div><div><br></div><div>But
 the proposal didn&#39;t stop there; it allowed you to apply a concept to a=
=20
template parameter directly. It even implicitly instantiates that=20
concept without needing &lt;&gt;. Back when function concepts were=20
allowed/required, it even implicitly <i>called the function</i>.</div></div=
></blockquote><div><br></div><div>This
 does not introduce natural syntax. It builds on templates machinery. I=20
am not against shortcuts. Natural is much more then that however.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<br></div><div>Those are all usability enhancements: they make applying a c=
oncept to a template easier and more digestible.<br></div><div><br></div><d=
iv>Natural
 syntax is merely another form of usability enhancement. If the=20
replacing of `typename` with a type concept is reasonable for=20
Concepts-lite, then so too is the consideration of other usability=20
enhancements. Even ones that remove `template` boilerplate.<br></div></div>=
</blockquote><div><br></div><div>It is <i>obviously</i> not that simple as =
&quot;<span style=3D"display:inline!important;float:none;background-color:t=
ransparent;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;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">merel=
y another form</span>&quot;. If it was, then there would have been no issue=
s. But
 exactly because we cross a boundary outside templates, outside what we=20
used for 30 years, we can&#39;t agree how to proceed and the opinions vary=
=20
greatly - from minimalistic to new templates syntax.</div></div></blockquot=
e><div><br></div><div>Let me see if I&#39;ve got this right. Terse syntax i=
s not &quot;merely another form&quot; of usability enhancements. Why? Becau=
se if it trust were just that, there wouldn&#39;t be arguments about what f=
orm it should take.<br></div><div><br></div><div>By that reasoning, `templa=
te&lt;Concept T&gt;` is not &quot;merely another form&quot; either. Why? Be=
cause we have people <i>in this very thread</i> who have argued that it oug=
ht to be `template&lt;auto&lt;Concept&gt; T&gt;`. There have been <i>actual=
 proposals</i> for `template&lt;Concept typename T&gt;` (thankfully, they w=
ere expurgated). So there are arguments about what this form should take.</=
div><div><br></div><div>And therefore, <i>by your reasoning</i>, it is not =
&quot;merely another form&quot; of &quot;Apply&quot;. So which is it? Will =
you accept that we should also ditch `template&lt;Concept T&gt;`? Or can we=
 agree that disagreement alone does not represent some kind of &quot;bounda=
ry outside template&quot;?</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div></div></div></blockquote><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>It
 is better to see and accepts there is boundary, then to pretend there=20
is some sort of &quot;natural evolution&quot; that happens to &quot;suddenl=
y&quot; not be so
 natural for many people.</div></div></blockquote><div><br></div><div>Nobod=
y is &quot;suddenly&quot; anything. People have had concerns about Bjarne&#=
39;s &quot;natural syntax&quot; since its inception.</div></div><div><br></=
div><div>On Thursday, June 21, 2018 at 1:58:18 PM UTC-4, mihailn...@gmail.c=
om wrote:</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=
">On Thursday, June 21, 2018 at 6:40:08 PM UTC+3, Nicol Bolas wrote:<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">On Thursday, June 21, 201=
8 at 10:55:38 AM UTC-4, <a>mihailn...@gmail.com</a> wrote:<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>Ok, I was reading some old pap=
ers on the then-called Concepts Light and then it hit me. =C2=A0</div><div>=
<br></div><div><i>Terse syntax have nothing to do with Concepts</i>! And It=
 never had. It was <i>a feature creep</i> from the beginning, an additional=
 goal, the goal to have generic code expressed naturally.</div><div><br></d=
iv><div>This goal however has nothing to do with Concepts as the goal for C=
oncepts is to have constrained types and nothing more.</div></div></blockqu=
ote><div><br></div><div>That&#39;s one way to express it. Another way to ex=
press the goal of the Concepts-lite proposal is to improve the ability of u=
sers to constrain templates. That involves two pieces: how to define constr=
aints and how to <i>apply</i> them. &quot;Natural syntax&quot; is about app=
lication, and therefore falls under its purview.<br></div></div></blockquot=
e><div><br></div><div>Hold on, what are the two pieces. Define and Apply. &=
quot;<span style=3D"display:inline!important;float:none;background-color:tr=
ansparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica=
&quot;,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;white-space:normal;word-spacing:0px">to imp=
rove the ability of users to constrain templates&quot;, where I assume natu=
ral syntax fall in is <i>a third </i>goal.</span></div></div></blockquote><=
div><br></div><div>You misunderstood my meaning. &quot;To improve the abili=
ty of users to constrain templates&quot; is why concepts exists at all. It =
is the very goal of concepts.</div><div><br></div><div>&quot;Define and App=
ly&quot; are the <i>means</i> to achieve that goal; they are not the goal i=
tself. My point is that &quot;natural syntax&quot; is within that goal; the=
refore, it is a perfectly reasonable thing for the Concepts proposal to inc=
lude. It is not out-of-bounds, it is not scope creep or anything of the sor=
t.<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;"><di=
v dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div></div><div></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></div><div>The goal of <span style=3D"display:inline!impo=
rtant;float:none;background-color:transparent;color:rgb(34,34,34);font-fami=
ly:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-s=
tyle:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-=
align:left;text-decoration:none;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px">generic code expressed naturally is unrelated=
 - you might want <i>un</i>constrained types=C2=A0<span style=3D"display:in=
line!important;float:none;background-color:transparent;color:rgb(34,34,34);=
font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13=
px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:nor=
mal;text-align:left;text-decoration:none;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px">expressed naturally.</span></span></=
div></div></blockquote><div><br></div>You almost never want truly unconstra=
ined types. Seriously, show me a template that genuinely imposes <i>no cons=
traints</i> on its argument. It happens, but not very often. `any`&#39;s co=
nstructor requires that `T` is CopyConstructible. Even `emplace` requires t=
hat the sequence of parameters can be forwarded to `allocator::construct`.<=
div><br></div><div>We use unconstrained types mainly because constraining t=
hem requires lots of effort. The goal of concepts is to minimize that effor=
t. The <i>fruits</i> of that goal is the ability to express those constrain=
ts &quot;naturally&quot;.<br></div></div></blockquote><div><br></div><div>P=
rototyping, teaching, consistency. Unconstrained are hare to stay as a base=
line.<br></div></div></blockquote><div><br></div><div>Where I come from, yo=
u start by creating an interface. In class hierarchies, that means a base c=
lass with pure virtual functions. With static polymorphism, that now means =
creating a concept.</div><div><br></div><div>Any good teacher should start =
teaching static polymorphism with concepts. New users should be taught that=
 unconstrained templates exist but <i>should be avoided</i>. And any decent=
 prototype will have a prototype interface too, expressed as a concept.</di=
v><div><br></div><div>Now sure, you&#39;re still going to need `&lt;typenam=
e T&gt;`, but this will be for cases where `T` needs to be constrained by a=
 `requires` clause. Truly unconstrained template parameters ought to go the=
 way of the Dodo.<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></div><div></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div></div><div></div><div>So to say that =
constraints and &quot;natural syntax&quot; are unrelated is misleading. The=
 existence of constraints makes &quot;natural syntax&quot; useful, readable=
, and digestible. And &quot;natural syntax&quot; makes constraint applicati=
on more useable, readable, and digestible.</div></div></blockquote><div><br=
></div><div>First, there is no such thing as &quot;natural syntax&quot; as =
we cant agree what it looks like.</div></div></blockquote><div><br></div><d=
iv>Yes there is. The term &quot;natural syntax&quot; comes directly from Bj=
arne Stroustrup and <i>specifically</i> refers to the Concepts TS proposal&=
#39;s terse syntax. Indeed, you were the first one to bring the term up, pr=
ecisely because the early Concepts TS proposals referred to that syntax as =
&quot;natural syntax&quot;.<br></div><div><br></div><div>What is being deba=
ted by the committee is what terse syntax will look like: Bjarne&#39;s &quo=
t;natural syntax&quot; or Herb&#39;s alternative form.</div><div><br></div>=
<div>And even then, there is clear agreement on the basic principle behind =
terse templates: you replace a parameter typename and/or output value with =
a concept name; this causes the parameter/output value to be deduced via a =
constrained template/return value deduction. So the general look of the con=
cept is well understood. The differences, while significant, are not that h=
uge.<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div>Second, the benefits of Concepts alone are so massive =
that anyone will gladly use them as they are now.=C2=A0</div><div>No one, e=
ver, will boycott them because the lack of some magical syntax. Why? Becaus=
e they use the same old syntax one is using for ages!</div></div></blockquo=
te><div><br></div><div>Who are you arguing with? <i>Nobody</i> claimed that=
 people would avoid concepts because of a lack of &quot;natural syntax&quot=
;. Just because people will use a feature anyway does not mean we can&#39;t=
 make it more readable and easier to use.</div><div><br></div><div>Producin=
g the bare minimum when you can do <i>more</i> and <i>better</i> than that =
doesn&#39;t make sense.<br></div><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Natural syntax is not re=
lated to Concepts directly, it is related to Temples and generic programmin=
g.=C2=A0</div><div>The desire to have natural syntax will not disappear if =
Concepts are not used and, with few expectations, it is not greater if Conc=
epts are used.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div></div><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><span style=3D"display:inline!important;float:none;b=
ackground-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quo=
t;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-v=
ariant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-de=
coration:none;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px"></span></div><div><span style=3D"display:inline!important;float=
:none;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Ar=
ial&quot;,&quot;Helvetica&quot;,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;white-space:normal=
;word-spacing:0px">With all that out of the way, I intended to write a prop=
osal to not include any terse syntax for 20. Now I don&#39;t have a shadow =
of doubt this is The Right Thing (for now). Luckily (not that it s luck!) t=
he current working paper does not includes any of it.</span></div></div></b=
lockquote><div><br></div><div>And luckily, most of the committee seems to d=
isagree, since they&#39;re moving forward with these proposals. I highly do=
ubt you&#39;re going to convince them that the very idea of terse syntax is=
 not related to concepts, or that they should abandon the idea.<br></div></=
div></blockquote><div><br></div><div></div><div>They agree, there is a clea=
r boundary.</div></div></blockquote><div><br></div><div>No, they agree that=
 terse syntax needs more discussion and has issues to be worked out compare=
d to the rest of concepts.</div><div><br></div><div>They did not agree that=
 terse syntax is unrelated to concepts, or that terse syntax should be aban=
doned or delayed.<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>They can&#39;t agree on syntax and the di=
fferences are not minor, but major, diametrical.</div></div></blockquote><d=
iv><br></div><div>&quot;Can&#39;t&quot; is a far cry from &quot;haven&#39;t=
&quot;. The latter is true; the former has yet to be determined.<br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div>Natural syntax is only partially related to Concepts, and is bigger=
 then we think - it does not flow naturally (that much was proven), it must=
 be invented, it is a different topic.=C2=A0</div><div>I am not for abandon=
ed, but for it to be separate topic, not against current Concepts WP and on=
 later date so the 99% can give feedback.</div></div></blockquote><div><br>=
</div><div>Who is this 99% who are incapable of giving feedback on Concepts=
 TS, but will be capable of giving feedback in a few years? Indeed, the ent=
ire terse syntax discussion <i>is feedback</i> on the &quot;natural syntax&=
quot; in Concepts TS.</div><div><br></div><div>Why is that feedback insuffi=
cient? Why do you treat terse syntax as though it&#39;s some novel thing th=
at nobody has ever heard of before? It&#39;s been over <i>four years</i> si=
nce the concepts-lite effort started.<br></div><div></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></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></div><div></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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"></span></div><div><spa=
n style=3D"display:inline!important;float:none;background-color:transparent=
;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sa=
ns-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:4=
00;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0=
px;text-transform:none;white-space:normal;word-spacing:0px">To iterate, I a=
m not against natural, but=C2=A0</span></div><div><span style=3D"display:in=
line!important;float:none;background-color:transparent;color:rgb(34,34,34);=
font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13=
px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:nor=
mal;text-align:left;text-decoration:none;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px">it MUST be tackled as separate probl=
em,=C2=A0</span></div></div></blockquote><div><br></div><div>It already is =
a separate problem. Suggesting that people keep doing the thing they&#39;re=
 already doing isn&#39;t useful.<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><span style=3D"display:inline!=
important;float:none;background-color:transparent;color:rgb(34,34,34);font-=
family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;fo=
nt-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;t=
ext-align:left;text-decoration:none;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px">it MUST be decupled from Concepts (physic=
ally and mentally)=C2=A0</span></div></div></blockquote><div><br></div><div=
>See above.<br></div><div><br></div></div></blockquote><div><br></div><div>=
Then why are natural syntax proposals against Concepts WP?</div></div></blo=
ckquote><div><br></div><div>I don&#39;t know what you mean by &quot;Concept=
s WP&quot;. The terse syntax proposals are EWG proposals, not proposals aga=
inst the Concepts TS.<br></div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div>Why it is officially listed as &quot;=
issues with Concepts&quot;.</div></div></blockquote><div><br></div><div>Bec=
ause terse templates come from the Concepts TS. Therefore, adjustments to i=
ssues relating to the Concepts TS are issues with concepts.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></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><span style=3D"di=
splay:inline!important;float:none;background-color:transparent;color:rgb(34=
,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font=
-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spa=
cing:normal;text-align:left;text-decoration:none;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px">it MUST be <span style=3D"di=
splay:inline!important;float:none;background-color:transparent;color:rgb(34=
,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font=
-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spa=
cing:normal;text-align:left;text-decoration:none;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px">tackled </span>AFTER Concept=
s and=C2=A0</span></div></div></blockquote><div><br></div><div>We already a=
re &quot;AFTER Concepts&quot;.<br></div></div></blockquote><div><br></div><=
div>Are we?</div><div><span style=3D"display:inline!important;float:none;ba=
ckground-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot=
;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-va=
riant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-dec=
oration:none;text-indent:0px;text-transform:none;white-space:normal;word-sp=
acing:0px">Concepts are not only not released, they are still worked on. An=
d by worked on I mean real issues like the Constraining Concepts Overload S=
ets proposal</span></div></div></blockquote><div><br></div><div>We are as &=
quot;AFTER Concepts&quot; as it is reasonable to get. Unless you are sugges=
ting that there will be design changes to concepts that will impact terse s=
yntax, there is no problem moving forward with both terse syntax discussion=
s <i>and</i> tweaks to the concepts feature.</div><div><br></div><div>Again=
, I don&#39;t know what it is that you&#39;re so concerned about here. What=
 are you afraid will happen if the committee continues to debate these prop=
osals (besides your technical issues with Herb&#39;s proposal)? Why do you =
feel it is <i>necessary</i> to shut down all discussion in this area?<br></=
div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/2e4a8cfd-d460-43d4-b2de-864cd48e71ea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2e4a8cfd-d460-43d4-b2de-864cd48e71ea=
%40isocpp.org</a>.<br />

------=_Part_6915_594802672.1529611517419--

------=_Part_6914_825387123.1529611517419--

.

------=_Part_10080_1438988149.1529651609568
Content-Type: multipart/alternative;
 boundary="----=_Part_10081_66847082.1529651609569"

------=_Part_10081_66847082.1529651609569
Content-Type: text/plain; charset="UTF-8"



On Thursday, June 21, 2018 at 11:05:17 PM UTC+3, Nicol Bolas wrote:
>
> On Thursday, June 21, 2018 at 12:37:03 PM UTC-4, mihailn...@gmail.com
> wrote:
>>
>> On Thursday, June 21, 2018 at 6:46:19 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Thursday, June 21, 2018 at 11:40:08 AM UTC-4, Nicol Bolas wrote:
>>>>
>>>> On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, mihailn...@gmail.com
>>>> wrote:
>>>>>
>>>>> Ok, I was reading some old papers on the then-called Concepts Light
>>>>> and then it hit me.
>>>>>
>>>>> *Terse syntax have nothing to do with Concepts*! And It never had. It
>>>>> was *a feature creep* from the beginning, an additional goal, the
>>>>> goal to have generic code expressed naturally.
>>>>>
>>>>> This goal however has nothing to do with Concepts as the goal for
>>>>> Concepts is to have constrained types and nothing more.
>>>>>
>>>>
>>>> That's one way to express it. Another way to express the goal of the
>>>> Concepts-lite proposal is to improve the ability of users to constrain
>>>> templates. That involves two pieces: how to define constraints and how to
>>>> *apply* them. "Natural syntax" is about application, and therefore
>>>> falls under its purview.
>>>>
>>>
>>> This is a point I wanted to elaborate on further.
>>>
>>> Concepts-lite did not have to allow this:
>>>
>>> template<Concept T> ...;
>>>
>>> It could have required you to use an explicit requires clause:
>>>
>>> template<typename T> requires Concept<T> ...;
>>>
>>> That would have been the bare minimum feature: requires clauses applying
>>> concepts.
>>>
>>> But the proposal didn't stop there; it allowed you to apply a concept to
>>> a template parameter directly. It even implicitly instantiates that concept
>>> without needing <>. Back when function concepts were allowed/required, it
>>> even implicitly *called the function*.
>>>
>>
>> This does not introduce natural syntax. It builds on templates machinery.
>> I am not against shortcuts. Natural is much more then that however.
>>
>>
>>>
>>> Those are all usability enhancements: they make applying a concept to a
>>> template easier and more digestible.
>>>
>>> Natural syntax is merely another form of usability enhancement. If the
>>> replacing of `typename` with a type concept is reasonable for
>>> Concepts-lite, then so too is the consideration of other usability
>>> enhancements. Even ones that remove `template` boilerplate.
>>>
>>
>> It is *obviously* not that simple as "merely another form". If it was,
>> then there would have been no issues. But exactly because we cross a
>> boundary outside templates, outside what we used for 30 years, we can't
>> agree how to proceed and the opinions vary greatly - from minimalistic to
>> new templates syntax.
>>
>
> Let me see if I've got this right. Terse syntax is not "merely another
> form" of usability enhancements. Why? Because if it trust were just that,
> there wouldn't be arguments about what form it should take.
>
> By that reasoning, `template<Concept T>` is not "merely another form"
> either. Why? Because we have people *in this very thread* who have argued
> that it ought to be `template<auto<Concept> T>`. There have been *actual
> proposals* for `template<Concept typename T>` (thankfully, they were
> expurgated). So there are arguments about what this form should take.
>
> And therefore, *by your reasoning*, it is not "merely another form" of
> "Apply". So which is it? Will you accept that we should also ditch
> `template<Concept T>`? Or can we agree that disagreement alone does not
> represent some kind of "boundary outside template"?
>

The boundary is obvious - addition (requires) and improvement (<Concept T>)
to the current generic programing on one side, with (very) minor
disagreement
VS new way of defining generic functions, where the disagreements is
massive.


>
> It is better to see and accepts there is boundary, then to pretend there
>> is some sort of "natural evolution" that happens to "suddenly" not be so
>> natural for many people.
>>
>
> Nobody is "suddenly" anything. People have had concerns about Bjarne's
> "natural syntax" since its inception.
>
> On Thursday, June 21, 2018 at 1:58:18 PM UTC-4, mihailn...@gmail.com
> wrote:
>
>> On Thursday, June 21, 2018 at 6:40:08 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, mihailn...@gmail.com
>>> wrote:
>>>>
>>>> Ok, I was reading some old papers on the then-called Concepts Light and
>>>> then it hit me.
>>>>
>>>> *Terse syntax have nothing to do with Concepts*! And It never had. It
>>>> was *a feature creep* from the beginning, an additional goal, the goal
>>>> to have generic code expressed naturally.
>>>>
>>>> This goal however has nothing to do with Concepts as the goal for
>>>> Concepts is to have constrained types and nothing more.
>>>>
>>>
>>> That's one way to express it. Another way to express the goal of the
>>> Concepts-lite proposal is to improve the ability of users to constrain
>>> templates. That involves two pieces: how to define constraints and how to
>>> *apply* them. "Natural syntax" is about application, and therefore
>>> falls under its purview.
>>>
>>
>> Hold on, what are the two pieces. Define and Apply. "to improve the
>> ability of users to constrain templates", where I assume natural syntax
>> fall in is *a third *goal.
>>
>
> You misunderstood my meaning. "To improve the ability of users to
> constrain templates" is why concepts exists at all. It is the very goal of
> concepts.
>
> "Define and Apply" are the *means* to achieve that goal; they are not the
> goal itself. My point is that "natural syntax" is within that goal;
> therefore, it is a perfectly reasonable thing for the Concepts proposal to
> include. It is not out-of-bounds, it is not scope creep or anything of the
> sort.
>

What is in or out of bounds depends on the point of view as the goals are
achieved without natural.
For you, to have natural is a worthy goal, "to finish things up", for me is
barely related bonus which brings downsides as well.



>
> The goal of generic code expressed naturally is unrelated - you might
>>>> want *un*constrained types expressed naturally.
>>>>
>>>
>>> You almost never want truly unconstrained types. Seriously, show me a
>>> template that genuinely imposes *no constraints* on its argument. It
>>> happens, but not very often. `any`'s constructor requires that `T` is
>>> CopyConstructible. Even `emplace` requires that the sequence of parameters
>>> can be forwarded to `allocator::construct`.
>>>
>>> We use unconstrained types mainly because constraining them requires
>>> lots of effort. The goal of concepts is to minimize that effort. The
>>> *fruits* of that goal is the ability to express those constraints
>>> "naturally".
>>>
>>
>> Prototyping, teaching, consistency. Unconstrained are hare to stay as a
>> baseline.
>>
>
> Where I come from, you start by creating an interface. In class
> hierarchies, that means a base class with pure virtual functions. With
> static polymorphism, that now means creating a concept.
>
> Any good teacher should start teaching static polymorphism with concepts.
> New users should be taught that unconstrained templates exist but *should
> be avoided*. And any decent prototype will have a prototype interface
> too, expressed as a concept.
>
> Now sure, you're still going to need `<typename T>`, but this will be for
> cases where `T` needs to be constrained by a `requires` clause. Truly
> unconstrained template parameters ought to go the way of the Dodo.
>

As I said that's an interesting topic. Should we declare typename/class
legacy and advocate the 'all' concept? Should we indeed teach against
concepts right away?
For prototyping/experimenting/learning unconstrained will be used, I
believe.


>
> So to say that constraints and "natural syntax" are unrelated is
>>> misleading. The existence of constraints makes "natural syntax" useful,
>>> readable, and digestible. And "natural syntax" makes constraint application
>>> more useable, readable, and digestible.
>>>
>>
>> First, there is no such thing as "natural syntax" as we cant agree what
>> it looks like.
>>
>
> Yes there is. The term "natural syntax" comes directly from Bjarne
> Stroustrup and *specifically* refers to the Concepts TS proposal's terse
> syntax. Indeed, you were the first one to bring the term up, precisely
> because the early Concepts TS proposals referred to that syntax as "natural
> syntax".
>
> What is being debated by the committee is what terse syntax will look
> like: Bjarne's "natural syntax" or Herb's alternative form.
>
> And even then, there is clear agreement on the basic principle behind
> terse templates: you replace a parameter typename and/or output value with
> a concept name; this causes the parameter/output value to be deduced via a
> constrained template/return value deduction. So the general look of the
> concept is well understood. The differences, while significant, are not
> that huge.
>
> Second, the benefits of Concepts alone are so massive that anyone will
>> gladly use them as they are now.
>> No one, ever, will boycott them because the lack of some magical syntax.
>> Why? Because they use the same old syntax one is using for ages!
>>
>
> Who are you arguing with? *Nobody* claimed that people would avoid
> concepts because of a lack of "natural syntax". Just because people will
> use a feature anyway does not mean we can't make it more readable and
> easier to use.
>
> Producing the bare minimum when you can do *more* and *better* than that
> doesn't make sense.
>
> Natural syntax is not related to Concepts directly, it is related to
>> Temples and generic programming.
>> The desire to have natural syntax will not disappear if Concepts are not
>> used and, with few expectations, it is not greater if Concepts are used.
>>
>>
>>> With all that out of the way, I intended to write a proposal to not
>>>> include any terse syntax for 20. Now I don't have a shadow of doubt this is
>>>> The Right Thing (for now). Luckily (not that it s luck!) the current
>>>> working paper does not includes any of it.
>>>>
>>>
>>> And luckily, most of the committee seems to disagree, since they're
>>> moving forward with these proposals. I highly doubt you're going to
>>> convince them that the very idea of terse syntax is not related to
>>> concepts, or that they should abandon the idea.
>>>
>>
>> They agree, there is a clear boundary.
>>
>
> No, they agree that terse syntax needs more discussion and has issues to
> be worked out compared to the rest of concepts.
>

Of course there is a boundary, C++ extensions for Concepts (Concepts WP) is
chopped from Concepts TS at exactly that boundary.


>
> They did not agree that terse syntax is unrelated to concepts, or that
> terse syntax should be abandoned or delayed.
>
> They can't agree on syntax and the differences are not minor, but major,
>> diametrical.
>>
>
> "Can't" is a far cry from "haven't". The latter is true; the former has
> yet to be determined.
>
>
>> Natural syntax is only partially related to Concepts, and is bigger then
>> we think - it does not flow naturally (that much was proven), it must be
>> invented, it is a different topic.
>> I am not for abandoned, but for it to be separate topic, not against
>> current Concepts WP and on later date so the 99% can give feedback.
>>
>
> Who is this 99% who are incapable of giving feedback on Concepts TS, but
> will be capable of giving feedback in a few years? Indeed, the entire terse
> syntax discussion *is feedback* on the "natural syntax" in Concepts TS.
>

The 99% of the C++ users have not touched or seen Concepts in any form.


>
> Why is that feedback insufficient? Why do you treat terse syntax as though
> it's some novel thing that nobody has ever heard of before? It's been over *four
> years* since the concepts-lite effort started.
>
> To iterate, I am not against natural, but
>>>> it MUST be tackled as separate problem,
>>>>
>>>
>>> It already is a separate problem. Suggesting that people keep doing the
>>> thing they're already doing isn't useful.
>>>
>>> it MUST be decupled from Concepts (physically and mentally)
>>>>
>>>
>>> See above.
>>>
>>>
>> Then why are natural syntax proposals against Concepts WP?
>>
>
> I don't know what you mean by "Concepts WP". The terse syntax proposals
> are EWG proposals, not proposals against the Concepts TS.
>
> Why it is officially listed as "issues with Concepts".
>>
>
> Because terse templates come from the Concepts TS. Therefore, adjustments
> to issues relating to the Concepts TS are issues with concepts.
>
> it MUST be tackled AFTER Concepts and
>>>>
>>>
>>> We already are "AFTER Concepts".
>>>
>>
>> Are we?
>> Concepts are not only not released, they are still worked on. And by
>> worked on I mean real issues like the Constraining Concepts Overload Sets
>> proposal
>>
>
> We are as "AFTER Concepts" as it is reasonable to get. Unless you are
> suggesting that there will be design changes to concepts that will impact
> terse syntax, there is no problem moving forward with both terse syntax
> discussions *and* tweaks to the concepts feature.
>
> Again, I don't know what it is that you're so concerned about here. What
> are you afraid will happen if the committee continues to debate these
> proposals (besides your technical issues with Herb's proposal)? Why do you
> feel it is *necessary* to shut down all discussion in this area?
>

What I am afraid is doing harm. Doing harm for a bonus feature is even
worse. I believe most, no, *all*, of current terse syntax proposals do some
harm.

Specifically.
A. Name introducers in any form are a harm. They are a harm because 1. they
de facto create new language 2. Are not "natural". 3. In some forms are not
better then the alternative.
B. Syntax-for-humans is a harm and is doomed to be attacked by counter
proposals for decades.

As I said, I am not against natural syntax in the form find(Searchable&)
but it seems there is some strong opposition ageist this OR some fears. Not
sure which one of the two.

And for the matter of fact am not against Herb proposal in general, I am
against it being sold as "natural evolution", where in reality it is a new
language.
New language with new possibilities, no matter we like it or not:
typename{T}, Container{C=std::vector}, concept{T} all = true;
*These will be coming. *
Herb's proposal should be evaluated on a bigger context. To adopted
something on that scale just to get a bonus feature will be a mistake.

--
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/edad4445-0238-4043-aae6-c7d7b810c2e8%40isocpp.org.

------=_Part_10081_66847082.1529651609569
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, June 21, 2018 at 11:05:17 PM UTC+3, N=
icol Bolas 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"><div>On Thursday, June 21, 2018 at 12:37:03 PM UTC-4, <a>mihailn...@gma=
il.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">O=
n Thursday, June 21, 2018 at 6:46:19 PM UTC+3, Nicol Bolas wrote:<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">On Thursday, June 21, 2018 a=
t 11:40:08 AM UTC-4, Nicol Bolas wrote:<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">On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, <a>mi=
hailn...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div>Ok, I was reading some old papers on the then-called Concep=
ts Light and then it hit me. =C2=A0</div><div><br></div><div><i>Terse synta=
x have nothing to do with Concepts</i>! And It never had. It was <i>a featu=
re creep</i> from the beginning, an additional goal, the goal to have gener=
ic code expressed naturally.</div><div><br></div><div>This goal however has=
 nothing to do with Concepts as the goal for Concepts is to have constraine=
d types and nothing more.</div></div></blockquote><div><br></div><div>That&=
#39;s
 one way to express it. Another way to express the goal of the=20
Concepts-lite proposal is to improve the ability of users to constrain=20
templates. That involves two pieces: how to define constraints and how=20
to <i>apply</i> them. &quot;Natural syntax&quot; is about application, and =
therefore falls under its purview.<br></div></div></blockquote><div><br></d=
iv><div>This is a point I wanted to elaborate on further.</div><div><br></d=
iv><div>Concepts-lite did not have to allow this:</div><div><br></div><div>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px"><code><div><span style=3D"color:#00=
8">template</span><span style=3D"color:#660">&lt;</span><span style=3D"colo=
r:#606">Concept</span><span style=3D"color:#000"> T</span><span style=3D"co=
lor:#660">&gt;</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">...;</span></div></code></div><br></div><div>It could have required=
 you to use an explicit requires clause:</div><div><br></div><div><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px"><code><div><span style=3D"color:#008">templa=
te</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">t=
ypename</span><span style=3D"color:#000"> T</span><span style=3D"color:#660=
">&gt;</span><span style=3D"color:#000"> requires </span><span style=3D"col=
or:#606">Concept</span><span style=3D"color:#660">&lt;</span><span style=3D=
"color:#000">T</span><span style=3D"color:#660">&gt;</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">...;</span></div></code></div=
><br></div><div>That would have been the bare minimum feature: requires cla=
uses applying concepts.</div><div><br></div><div>But
 the proposal didn&#39;t stop there; it allowed you to apply a concept to a=
=20
template parameter directly. It even implicitly instantiates that=20
concept without needing &lt;&gt;. Back when function concepts were=20
allowed/required, it even implicitly <i>called the function</i>.</div></div=
></blockquote><div><br></div><div>This
 does not introduce natural syntax. It builds on templates machinery. I=20
am not against shortcuts. Natural is much more then that however.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<br></div><div>Those are all usability enhancements: they make applying a c=
oncept to a template easier and more digestible.<br></div><div><br></div><d=
iv>Natural
 syntax is merely another form of usability enhancement. If the=20
replacing of `typename` with a type concept is reasonable for=20
Concepts-lite, then so too is the consideration of other usability=20
enhancements. Even ones that remove `template` boilerplate.<br></div></div>=
</blockquote><div><br></div><div>It is <i>obviously</i> not that simple as =
&quot;<span style=3D"display:inline!important;float:none;background-color:t=
ransparent;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;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">merel=
y another form</span>&quot;. If it was, then there would have been no issue=
s. But
 exactly because we cross a boundary outside templates, outside what we=20
used for 30 years, we can&#39;t agree how to proceed and the opinions vary=
=20
greatly - from minimalistic to new templates syntax.</div></div></blockquot=
e><div><br></div><div>Let me see if I&#39;ve got this right. Terse syntax i=
s not &quot;merely another form&quot; of usability enhancements. Why? Becau=
se if it trust were just that, there wouldn&#39;t be arguments about what f=
orm it should take.<br></div><div><br></div><div>By that reasoning, `templa=
te&lt;Concept T&gt;` is not &quot;merely another form&quot; either. Why? Be=
cause we have people <i>in this very thread</i> who have argued that it oug=
ht to be `template&lt;auto&lt;Concept&gt; T&gt;`. There have been <i>actual=
 proposals</i> for `template&lt;Concept typename T&gt;` (thankfully, they w=
ere expurgated). So there are arguments about what this form should take.</=
div><div><br></div><div>And therefore, <i>by your reasoning</i>, it is not =
&quot;merely another form&quot; of &quot;Apply&quot;. So which is it? Will =
you accept that we should also ditch `template&lt;Concept T&gt;`? Or can we=
 agree that disagreement alone does not represent some kind of &quot;bounda=
ry outside template&quot;?</div></div></div></blockquote><div><br></div><di=
v>The boundary is obvious - addition (requires) and improvement (<span styl=
e=3D"display: inline !important; float: none; background-color: transparent=
; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&qu=
ot;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; =
font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; tex=
t-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-st=
roke-width: 0px; white-space: normal; word-spacing: 0px;">&lt;Concept T&gt;=
</span>) to the current generic programing on one side, with (very) minor d=
isagreement=C2=A0</div><div>VS new way of defining generic functions, where=
 the disagreements is massive.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><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></div></div></blockquote><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>It
 is better to see and accepts there is boundary, then to pretend there=20
is some sort of &quot;natural evolution&quot; that happens to &quot;suddenl=
y&quot; not be so
 natural for many people.</div></div></blockquote><div><br></div><div>Nobod=
y is &quot;suddenly&quot; anything. People have had concerns about Bjarne&#=
39;s &quot;natural syntax&quot; since its inception.</div></div><div><br></=
div><div>On Thursday, June 21, 2018 at 1:58:18 PM UTC-4, <a>mihailn...@gmai=
l.com</a> wrote:</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">On Thursday, June 21, 2018 at 6:40:08 PM UTC+3, Nicol Bolas wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, June 21, 2=
018 at 10:55:38 AM UTC-4, <a>mihailn...@gmail.com</a> wrote:<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>Ok, I was reading some old p=
apers on the then-called Concepts Light and then it hit me. =C2=A0</div><di=
v><br></div><div><i>Terse syntax have nothing to do with Concepts</i>! And =
It never had. It was <i>a feature creep</i> from the beginning, an addition=
al goal, the goal to have generic code expressed naturally.</div><div><br><=
/div><div>This goal however has nothing to do with Concepts as the goal for=
 Concepts is to have constrained types and nothing more.</div></div></block=
quote><div><br></div><div>That&#39;s one way to express it. Another way to =
express the goal of the Concepts-lite proposal is to improve the ability of=
 users to constrain templates. That involves two pieces: how to define cons=
traints and how to <i>apply</i> them. &quot;Natural syntax&quot; is about a=
pplication, and therefore falls under its purview.<br></div></div></blockqu=
ote><div><br></div><div>Hold on, what are the two pieces. Define and Apply.=
 &quot;<span style=3D"display:inline!important;float:none;background-color:=
transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helveti=
ca&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;fo=
nt-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">to i=
mprove the ability of users to constrain templates&quot;, where I assume na=
tural syntax fall in is <i>a third </i>goal.</span></div></div></blockquote=
><div><br></div><div>You misunderstood my meaning. &quot;To improve the abi=
lity of users to constrain templates&quot; is why concepts exists at all. I=
t is the very goal of concepts.</div><div><br></div><div>&quot;Define and A=
pply&quot; are the <i>means</i> to achieve that goal; they are not the goal=
 itself. My point is that &quot;natural syntax&quot; is within that goal; t=
herefore, it is a perfectly reasonable thing for the Concepts proposal to i=
nclude. It is not out-of-bounds, it is not scope creep or anything of the s=
ort.<br></div></div></blockquote><div><br></div><div>What is in or out of b=
ounds depends on the point of view as the goals are achieved without natura=
l.=C2=A0</div><div>For you, to have natural is a worthy goal, &quot;to fini=
sh things up&quot;, for me is barely related bonus which brings downsides a=
s well.</div><div><br></div><div>=C2=A0</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></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><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div></div><div></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div></div><div>The goal of <span styl=
e=3D"display:inline!important;float:none;background-color:transparent;color=
:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-ser=
if;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;let=
ter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;tex=
t-transform:none;white-space:normal;word-spacing:0px">generic code expresse=
d naturally is unrelated - you might want <i>un</i>constrained types=C2=A0<=
span style=3D"display:inline!important;float:none;background-color:transpar=
ent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;=
,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-weigh=
t:400;letter-spacing:normal;text-align:left;text-decoration:none;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px">expressed na=
turally.</span></span></div></div></blockquote><div><br></div>You almost ne=
ver want truly unconstrained types. Seriously, show me a template that genu=
inely imposes <i>no constraints</i> on its argument. It happens, but not ve=
ry often. `any`&#39;s constructor requires that `T` is CopyConstructible. E=
ven `emplace` requires that the sequence of parameters can be forwarded to =
`allocator::construct`.<div><br></div><div>We use unconstrained types mainl=
y because constraining them requires lots of effort. The goal of concepts i=
s to minimize that effort. The <i>fruits</i> of that goal is the ability to=
 express those constraints &quot;naturally&quot;.<br></div></div></blockquo=
te><div><br></div><div>Prototyping, teaching, consistency. Unconstrained ar=
e hare to stay as a baseline.<br></div></div></blockquote><div><br></div><d=
iv>Where I come from, you start by creating an interface. In class hierarch=
ies, that means a base class with pure virtual functions. With static polym=
orphism, that now means creating a concept.</div><div><br></div><div>Any go=
od teacher should start teaching static polymorphism with concepts. New use=
rs should be taught that unconstrained templates exist but <i>should be avo=
ided</i>. And any decent prototype will have a prototype interface too, exp=
ressed as a concept.</div><div><br></div><div>Now sure, you&#39;re still go=
ing to need `&lt;typename T&gt;`, but this will be for cases where `T` need=
s to be constrained by a `requires` clause. Truly unconstrained template pa=
rameters ought to go the way of the Dodo.<br></div></div></blockquote><div>=
<br></div><div>As I said that&#39;s an interesting topic. Should we declare=
 typename/class legacy and advocate the &#39;all&#39; concept? Should we in=
deed teach against concepts right away?=C2=A0</div><div>For prototyping/exp=
erimenting/learning <span style=3D"display: inline !important; float: none;=
 background-color: transparent; color: rgb(34, 34, 34); font-family: &quot;=
Arial&quot;,&quot;Helvetica&quot;,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;">unconstrained will be used, I believe.=C2=A0</span></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></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></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></div><div></div><div>So to say that constraints and &quo=
t;natural syntax&quot; are unrelated is misleading. The existence of constr=
aints makes &quot;natural syntax&quot; useful, readable, and digestible. An=
d &quot;natural syntax&quot; makes constraint application more useable, rea=
dable, and digestible.</div></div></blockquote><div><br></div><div>First, t=
here is no such thing as &quot;natural syntax&quot; as we cant agree what i=
t looks like.</div></div></blockquote><div><br></div><div>Yes there is. The=
 term &quot;natural syntax&quot; comes directly from Bjarne Stroustrup and =
<i>specifically</i> refers to the Concepts TS proposal&#39;s terse syntax. =
Indeed, you were the first one to bring the term up, precisely because the =
early Concepts TS proposals referred to that syntax as &quot;natural syntax=
&quot;.<br></div><div><br></div><div>What is being debated by the committee=
 is what terse syntax will look like: Bjarne&#39;s &quot;natural syntax&quo=
t; or Herb&#39;s alternative form.</div><div><br></div><div>And even then, =
there is clear agreement on the basic principle behind terse templates: you=
 replace a parameter typename and/or output value with a concept name; this=
 causes the parameter/output value to be deduced via a constrained template=
/return value deduction. So the general look of the concept is well underst=
ood. The differences, while significant, are not that huge.<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>Seco=
nd, the benefits of Concepts alone are so massive that anyone will gladly u=
se them as they are now.=C2=A0</div><div>No one, ever, will boycott them be=
cause the lack of some magical syntax. Why? Because they use the same old s=
yntax one is using for ages!</div></div></blockquote><div><br></div><div>Wh=
o are you arguing with? <i>Nobody</i> claimed that people would avoid conce=
pts because of a lack of &quot;natural syntax&quot;. Just because people wi=
ll use a feature anyway does not mean we can&#39;t make it more readable an=
d easier to use.</div><div><br></div><div>Producing the bare minimum when y=
ou can do <i>more</i> and <i>better</i> than that doesn&#39;t make sense.<b=
r></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>Natural syntax is not related to Concepts directly, it=
 is related to Temples and generic programming.=C2=A0</div><div>The desire =
to have natural syntax will not disappear if Concepts are not used and, wit=
h few expectations, it is not greater if Concepts are used.<br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
/div><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><span st=
yle=3D"display:inline!important;float:none;background-color:transparent;col=
or:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-s=
erif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;l=
etter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;t=
ext-transform:none;white-space:normal;word-spacing:0px"></span></div><div><=
span style=3D"display:inline!important;float:none;background-color:transpar=
ent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;=
,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-weigh=
t:400;letter-spacing:normal;text-align:left;text-decoration:none;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px">With all tha=
t out of the way, I intended to write a proposal to not include any terse s=
yntax for 20. Now I don&#39;t have a shadow of doubt this is The Right Thin=
g (for now). Luckily (not that it s luck!) the current working paper does n=
ot includes any of it.</span></div></div></blockquote><div><br></div><div>A=
nd luckily, most of the committee seems to disagree, since they&#39;re movi=
ng forward with these proposals. I highly doubt you&#39;re going to convinc=
e them that the very idea of terse syntax is not related to concepts, or th=
at they should abandon the idea.<br></div></div></blockquote><div><br></div=
><div></div><div>They agree, there is a clear boundary.</div></div></blockq=
uote><div><br></div><div>No, they agree that terse syntax needs more discus=
sion and has issues to be worked out compared to the rest of concepts.</div=
></div></blockquote><div>=C2=A0</div><div>Of course there is a boundary, C+=
+ extensions for Concepts (Concepts WP) is chopped from Concepts TS at exac=
tly that boundary.</div><div>=C2=A0</div><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"><div><br></div><div>They did not agree that ter=
se syntax is unrelated to concepts, or that terse syntax should be abandone=
d or delayed.<br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>They can&#39;t agree on syntax and the differences=
 are not minor, but major, diametrical.</div></div></blockquote><div><br></=
div><div>&quot;Can&#39;t&quot; is a far cry from &quot;haven&#39;t&quot;. T=
he latter is true; the former has yet to be determined.<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>Natu=
ral syntax is only partially related to Concepts, and is bigger then we thi=
nk - it does not flow naturally (that much was proven), it must be invented=
, it is a different topic.=C2=A0</div><div>I am not for abandoned, but for =
it to be separate topic, not against current Concepts WP and on later date =
so the 99% can give feedback.</div></div></blockquote><div><br></div><div>W=
ho is this 99% who are incapable of giving feedback on Concepts TS, but wil=
l be capable of giving feedback in a few years? Indeed, the entire terse sy=
ntax discussion <i>is feedback</i> on the &quot;natural syntax&quot; in Con=
cepts TS.</div></div></blockquote><div>=C2=A0</div><div>The 99% of the C++ =
users have not touched or seen Concepts in any form.=C2=A0</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><b=
r></div><div>Why is that feedback insufficient? Why do you treat terse synt=
ax as though it&#39;s some novel thing that nobody has ever heard of before=
? It&#39;s been over <i>four years</i> since the concepts-lite effort start=
ed.<br></div><div></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></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div></div><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><span style=3D"display:inline!important;float:none;b=
ackground-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quo=
t;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-v=
ariant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-de=
coration:none;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px"></span></div><div><span style=3D"display:inline!important;float=
:none;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Ar=
ial&quot;,&quot;Helvetica&quot;,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;white-space:normal=
;word-spacing:0px">To iterate, I am not against natural, but=C2=A0</span></=
div><div><span style=3D"display:inline!important;float:none;background-colo=
r:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helve=
tica&quot;,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;white-space:normal;word-spacing:0px">it=
 MUST be tackled as separate problem,=C2=A0</span></div></div></blockquote>=
<div><br></div><div>It already is a separate problem. Suggesting that peopl=
e keep doing the thing they&#39;re already doing isn&#39;t useful.<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"><d=
iv><span style=3D"display:inline!important;float:none;background-color:tran=
sparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&q=
uot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-w=
eight:400;letter-spacing:normal;text-align:left;text-decoration:none;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px">it MUST =
be decupled from Concepts (physically and mentally)=C2=A0</span></div></div=
></blockquote><div><br></div><div>See above.<br></div><div><br></div></div>=
</blockquote><div><br></div><div>Then why are natural syntax proposals agai=
nst Concepts WP?</div></div></blockquote><div><br></div><div>I don&#39;t kn=
ow what you mean by &quot;Concepts WP&quot;. The terse syntax proposals are=
 EWG proposals, not proposals against the Concepts TS.<br></div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Why it is=
 officially listed as &quot;issues with Concepts&quot;.</div></div></blockq=
uote><div><br></div><div>Because terse templates come from the Concepts TS.=
 Therefore, adjustments to issues relating to the Concepts TS are issues wi=
th concepts.</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></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><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><span style=3D"display:inline!important;float:none;background-color:=
transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helveti=
ca&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;fo=
nt-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">it M=
UST be <span style=3D"display:inline!important;float:none;background-color:=
transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helveti=
ca&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;fo=
nt-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">tack=
led </span>AFTER Concepts and=C2=A0</span></div></div></blockquote><div><br=
></div><div>We already are &quot;AFTER Concepts&quot;.<br></div></div></blo=
ckquote><div><br></div><div>Are we?</div><div><span style=3D"display:inline=
!important;float:none;background-color:transparent;color:rgb(34,34,34);font=
-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;f=
ont-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;=
text-align:left;text-decoration:none;text-indent:0px;text-transform:none;wh=
ite-space:normal;word-spacing:0px">Concepts are not only not released, they=
 are still worked on. And by worked on I mean real issues like the Constrai=
ning Concepts Overload Sets proposal</span></div></div></blockquote><div><b=
r></div><div>We are as &quot;AFTER Concepts&quot; as it is reasonable to ge=
t. Unless you are suggesting that there will be design changes to concepts =
that will impact terse syntax, there is no problem moving forward with both=
 terse syntax discussions <i>and</i> tweaks to the concepts feature.</div><=
div><br></div><div>Again, I don&#39;t know what it is that you&#39;re so co=
ncerned about here. What are you afraid will happen if the committee contin=
ues to debate these proposals (besides your technical issues with Herb&#39;=
s proposal)? Why do you feel it is <i>necessary</i> to shut down all discus=
sion in this area?<br></div></div></blockquote><div><br></div><div>What I a=
m afraid is doing harm. Doing harm for a bonus feature is even worse. I bel=
ieve most, no, <i>all</i>, of current terse syntax proposals do some harm.=
=C2=A0</div><div><br></div><div>Specifically.=C2=A0</div><div>A. Name intro=
ducers in any form are a harm. They are a harm because 1. they de facto cre=
ate new language 2. Are not &quot;natural&quot;. 3. In some forms are not b=
etter then the alternative.</div><div>B. Syntax-for-humans is a harm and is=
 doomed to be attacked by counter proposals for decades. =C2=A0</div><div><=
br></div><div>As I said, I am not against natural syntax in the form <font =
face=3D"courier new,monospace">find(Searchable&amp;)</font> but it seems th=
ere is some strong opposition ageist this OR some fears. Not sure which one=
 of the two.</div><div><br></div><div>And for the matter of fact am not aga=
inst Herb proposal in general, I am against it being sold as &quot;natural =
evolution&quot;, where in reality it is a new language.=C2=A0</div><div>New=
 language with new possibilities, no matter we like it or not: <font face=
=3D"courier new,monospace">typename{T}</font><font face=3D"arial,sans-serif=
">,</font> <font face=3D"courier new,monospace">Container{C=3Dstd::vector}<=
/font><font face=3D"arial,sans-serif">, </font><font face=3D"courier new,mo=
nospace">concept{T} all =3D true;</font><br></div><div><font face=3D"arial,=
sans-serif"><font face=3D"&quot;Arial&quot;,&quot;Helvetica&quot;,sans-seri=
f"></font><i>These will be coming. </i></font></div><div><font face=3D"aria=
l,sans-serif">Herb&#39;s proposal should be evaluated on a bigger context.=
=C2=A0<span style=3D"display: inline !important; float: none; background-co=
lor: transparent; color: rgb(34, 34, 34); font-family: arial,sans-serif; fo=
nt-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; -webkit-text-stroke-width: 0px; w=
hite-space: normal; word-spacing: 0px;">To adopted something on that scale =
just to get a bonus feature will be a mistake.=C2=A0</span></font></div><di=
v><font face=3D"courier new,monospace"></font><font face=3D"arial,sans-seri=
f"></font><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br><=
/div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/edad4445-0238-4043-aae6-c7d7b810c2e8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/edad4445-0238-4043-aae6-c7d7b810c2e8=
%40isocpp.org</a>.<br />

------=_Part_10081_66847082.1529651609569--

------=_Part_10080_1438988149.1529651609568--

.

--0000000000009d7e05056f86fdc3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I wrote an article on convenient syntaxes
https://cor3ntin.github.io/posts/concepts_syntax/
Hopefully, the relatively thorough comparison and background may help some
people.

The article features a quick poll as I attempt to get a feeling of what
people think of these syntaxes, maybe it can inform the discussion.


Le ven. 22 juin 2018 =C3=A0 09:13, <mihailnajdenov@gmail.com> a =C3=A9crit =
:

>
>
> On Thursday, June 21, 2018 at 11:05:17 PM UTC+3, Nicol Bolas wrote:
>>
>> On Thursday, June 21, 2018 at 12:37:03 PM UTC-4, mihailn...@gmail.com
>> wrote:
>>>
>>> On Thursday, June 21, 2018 at 6:46:19 PM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Thursday, June 21, 2018 at 11:40:08 AM UTC-4, Nicol Bolas wrote:
>>>>>
>>>>> On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, mihailn...@gmail.com
>>>>> wrote:
>>>>>>
>>>>>> Ok, I was reading some old papers on the then-called Concepts Light
>>>>>> and then it hit me.
>>>>>>
>>>>>> *Terse syntax have nothing to do with Concepts*! And It never had.
>>>>>> It was *a feature creep* from the beginning, an additional goal, the
>>>>>> goal to have generic code expressed naturally.
>>>>>>
>>>>>> This goal however has nothing to do with Concepts as the goal for
>>>>>> Concepts is to have constrained types and nothing more.
>>>>>>
>>>>>
>>>>> That's one way to express it. Another way to express the goal of the
>>>>> Concepts-lite proposal is to improve the ability of users to constrai=
n
>>>>> templates. That involves two pieces: how to define constraints and ho=
w to
>>>>> *apply* them. "Natural syntax" is about application, and therefore
>>>>> falls under its purview.
>>>>>
>>>>
>>>> This is a point I wanted to elaborate on further.
>>>>
>>>> Concepts-lite did not have to allow this:
>>>>
>>>> template<Concept T> ...;
>>>>
>>>> It could have required you to use an explicit requires clause:
>>>>
>>>> template<typename T> requires Concept<T> ...;
>>>>
>>>> That would have been the bare minimum feature: requires clauses
>>>> applying concepts.
>>>>
>>>> But the proposal didn't stop there; it allowed you to apply a concept
>>>> to a template parameter directly. It even implicitly instantiates that
>>>> concept without needing <>. Back when function concepts were
>>>> allowed/required, it even implicitly *called the function*.
>>>>
>>>
>>> This does not introduce natural syntax. It builds on templates
>>> machinery. I am not against shortcuts. Natural is much more then that
>>> however.
>>>
>>>
>>>>
>>>> Those are all usability enhancements: they make applying a concept to =
a
>>>> template easier and more digestible.
>>>>
>>>> Natural syntax is merely another form of usability enhancement. If the
>>>> replacing of `typename` with a type concept is reasonable for
>>>> Concepts-lite, then so too is the consideration of other usability
>>>> enhancements. Even ones that remove `template` boilerplate.
>>>>
>>>
>>> It is *obviously* not that simple as "merely another form". If it was,
>>> then there would have been no issues. But exactly because we cross a
>>> boundary outside templates, outside what we used for 30 years, we can't
>>> agree how to proceed and the opinions vary greatly - from minimalistic =
to
>>> new templates syntax.
>>>
>>
>> Let me see if I've got this right. Terse syntax is not "merely another
>> form" of usability enhancements. Why? Because if it trust were just that=
,
>> there wouldn't be arguments about what form it should take.
>>
>> By that reasoning, `template<Concept T>` is not "merely another form"
>> either. Why? Because we have people *in this very thread* who have
>> argued that it ought to be `template<auto<Concept> T>`. There have been =
*actual
>> proposals* for `template<Concept typename T>` (thankfully, they were
>> expurgated). So there are arguments about what this form should take.
>>
>> And therefore, *by your reasoning*, it is not "merely another form" of
>> "Apply". So which is it? Will you accept that we should also ditch
>> `template<Concept T>`? Or can we agree that disagreement alone does not
>> represent some kind of "boundary outside template"?
>>
>
> The boundary is obvious - addition (requires) and improvement (<Concept T=
>)
> to the current generic programing on one side, with (very) minor
> disagreement
> VS new way of defining generic functions, where the disagreements is
> massive.
>
>
>>
>> It is better to see and accepts there is boundary, then to pretend there
>>> is some sort of "natural evolution" that happens to "suddenly" not be s=
o
>>> natural for many people.
>>>
>>
>> Nobody is "suddenly" anything. People have had concerns about Bjarne's
>> "natural syntax" since its inception.
>>
>> On Thursday, June 21, 2018 at 1:58:18 PM UTC-4, mihailn...@gmail.com
>> wrote:
>>
>>> On Thursday, June 21, 2018 at 6:40:08 PM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Thursday, June 21, 2018 at 10:55:38 AM UTC-4, mihailn...@gmail.com
>>>> wrote:
>>>>>
>>>>> Ok, I was reading some old papers on the then-called Concepts Light
>>>>> and then it hit me.
>>>>>
>>>>> *Terse syntax have nothing to do with Concepts*! And It never had. It
>>>>> was *a feature creep* from the beginning, an additional goal, the
>>>>> goal to have generic code expressed naturally.
>>>>>
>>>>> This goal however has nothing to do with Concepts as the goal for
>>>>> Concepts is to have constrained types and nothing more.
>>>>>
>>>>
>>>> That's one way to express it. Another way to express the goal of the
>>>> Concepts-lite proposal is to improve the ability of users to constrain
>>>> templates. That involves two pieces: how to define constraints and how=
 to
>>>> *apply* them. "Natural syntax" is about application, and therefore
>>>> falls under its purview.
>>>>
>>>
>>> Hold on, what are the two pieces. Define and Apply. "to improve the
>>> ability of users to constrain templates", where I assume natural syntax
>>> fall in is *a third *goal.
>>>
>>
>> You misunderstood my meaning. "To improve the ability of users to
>> constrain templates" is why concepts exists at all. It is the very goal =
of
>> concepts.
>>
>> "Define and Apply" are the *means* to achieve that goal; they are not
>> the goal itself. My point is that "natural syntax" is within that goal;
>> therefore, it is a perfectly reasonable thing for the Concepts proposal =
to
>> include. It is not out-of-bounds, it is not scope creep or anything of t=
he
>> sort.
>>
>
> What is in or out of bounds depends on the point of view as the goals are
> achieved without natural.
> For you, to have natural is a worthy goal, "to finish things up", for me
> is barely related bonus which brings downsides as well.
>
>
>
>>
>> The goal of generic code expressed naturally is unrelated - you might
>>>>> want *un*constrained types expressed naturally.
>>>>>
>>>>
>>>> You almost never want truly unconstrained types. Seriously, show me a
>>>> template that genuinely imposes *no constraints* on its argument. It
>>>> happens, but not very often. `any`'s constructor requires that `T` is
>>>> CopyConstructible. Even `emplace` requires that the sequence of parame=
ters
>>>> can be forwarded to `allocator::construct`.
>>>>
>>>> We use unconstrained types mainly because constraining them requires
>>>> lots of effort. The goal of concepts is to minimize that effort. The
>>>> *fruits* of that goal is the ability to express those constraints
>>>> "naturally".
>>>>
>>>
>>> Prototyping, teaching, consistency. Unconstrained are hare to stay as a
>>> baseline.
>>>
>>
>> Where I come from, you start by creating an interface. In class
>> hierarchies, that means a base class with pure virtual functions. With
>> static polymorphism, that now means creating a concept.
>>
>> Any good teacher should start teaching static polymorphism with concepts=
..
>> New users should be taught that unconstrained templates exist but *shoul=
d
>> be avoided*. And any decent prototype will have a prototype interface
>> too, expressed as a concept.
>>
>> Now sure, you're still going to need `<typename T>`, but this will be fo=
r
>> cases where `T` needs to be constrained by a `requires` clause. Truly
>> unconstrained template parameters ought to go the way of the Dodo.
>>
>
> As I said that's an interesting topic. Should we declare typename/class
> legacy and advocate the 'all' concept? Should we indeed teach against
> concepts right away?
> For prototyping/experimenting/learning unconstrained will be used, I
> believe.
>
>
>>
>> So to say that constraints and "natural syntax" are unrelated is
>>>> misleading. The existence of constraints makes "natural syntax" useful=
,
>>>> readable, and digestible. And "natural syntax" makes constraint applic=
ation
>>>> more useable, readable, and digestible.
>>>>
>>>
>>> First, there is no such thing as "natural syntax" as we cant agree what
>>> it looks like.
>>>
>>
>> Yes there is. The term "natural syntax" comes directly from Bjarne
>> Stroustrup and *specifically* refers to the Concepts TS proposal's terse
>> syntax. Indeed, you were the first one to bring the term up, precisely
>> because the early Concepts TS proposals referred to that syntax as "natu=
ral
>> syntax".
>>
>> What is being debated by the committee is what terse syntax will look
>> like: Bjarne's "natural syntax" or Herb's alternative form.
>>
>> And even then, there is clear agreement on the basic principle behind
>> terse templates: you replace a parameter typename and/or output value wi=
th
>> a concept name; this causes the parameter/output value to be deduced via=
 a
>> constrained template/return value deduction. So the general look of the
>> concept is well understood. The differences, while significant, are not
>> that huge.
>>
>> Second, the benefits of Concepts alone are so massive that anyone will
>>> gladly use them as they are now.
>>> No one, ever, will boycott them because the lack of some magical syntax=
..
>>> Why? Because they use the same old syntax one is using for ages!
>>>
>>
>> Who are you arguing with? *Nobody* claimed that people would avoid
>> concepts because of a lack of "natural syntax". Just because people will
>> use a feature anyway does not mean we can't make it more readable and
>> easier to use.
>>
>> Producing the bare minimum when you can do *more* and *better* than that
>> doesn't make sense.
>>
>> Natural syntax is not related to Concepts directly, it is related to
>>> Temples and generic programming.
>>> The desire to have natural syntax will not disappear if Concepts are no=
t
>>> used and, with few expectations, it is not greater if Concepts are used=
..
>>>
>>>
>>>> With all that out of the way, I intended to write a proposal to not
>>>>> include any terse syntax for 20. Now I don't have a shadow of doubt t=
his is
>>>>> The Right Thing (for now). Luckily (not that it s luck!) the current
>>>>> working paper does not includes any of it.
>>>>>
>>>>
>>>> And luckily, most of the committee seems to disagree, since they're
>>>> moving forward with these proposals. I highly doubt you're going to
>>>> convince them that the very idea of terse syntax is not related to
>>>> concepts, or that they should abandon the idea.
>>>>
>>>
>>> They agree, there is a clear boundary.
>>>
>>
>> No, they agree that terse syntax needs more discussion and has issues to
>> be worked out compared to the rest of concepts.
>>
>
> Of course there is a boundary, C++ extensions for Concepts (Concepts WP)
> is chopped from Concepts TS at exactly that boundary.
>
>
>>
>> They did not agree that terse syntax is unrelated to concepts, or that
>> terse syntax should be abandoned or delayed.
>>
>> They can't agree on syntax and the differences are not minor, but major,
>>> diametrical.
>>>
>>
>> "Can't" is a far cry from "haven't". The latter is true; the former has
>> yet to be determined.
>>
>>
>>> Natural syntax is only partially related to Concepts, and is bigger the=
n
>>> we think - it does not flow naturally (that much was proven), it must b=
e
>>> invented, it is a different topic.
>>> I am not for abandoned, but for it to be separate topic, not against
>>> current Concepts WP and on later date so the 99% can give feedback.
>>>
>>
>> Who is this 99% who are incapable of giving feedback on Concepts TS, but
>> will be capable of giving feedback in a few years? Indeed, the entire te=
rse
>> syntax discussion *is feedback* on the "natural syntax" in Concepts TS.
>>
>
> The 99% of the C++ users have not touched or seen Concepts in any form.
>
>
>>
>> Why is that feedback insufficient? Why do you treat terse syntax as
>> though it's some novel thing that nobody has ever heard of before? It's
>> been over *four years* since the concepts-lite effort started.
>>
>> To iterate, I am not against natural, but
>>>>> it MUST be tackled as separate problem,
>>>>>
>>>>
>>>> It already is a separate problem. Suggesting that people keep doing th=
e
>>>> thing they're already doing isn't useful.
>>>>
>>>> it MUST be decupled from Concepts (physically and mentally)
>>>>>
>>>>
>>>> See above.
>>>>
>>>>
>>> Then why are natural syntax proposals against Concepts WP?
>>>
>>
>> I don't know what you mean by "Concepts WP". The terse syntax proposals
>> are EWG proposals, not proposals against the Concepts TS.
>>
>> Why it is officially listed as "issues with Concepts".
>>>
>>
>> Because terse templates come from the Concepts TS. Therefore, adjustment=
s
>> to issues relating to the Concepts TS are issues with concepts.
>>
>> it MUST be tackled AFTER Concepts and
>>>>>
>>>>
>>>> We already are "AFTER Concepts".
>>>>
>>>
>>> Are we?
>>> Concepts are not only not released, they are still worked on. And by
>>> worked on I mean real issues like the Constraining Concepts Overload Se=
ts
>>> proposal
>>>
>>
>> We are as "AFTER Concepts" as it is reasonable to get. Unless you are
>> suggesting that there will be design changes to concepts that will impac=
t
>> terse syntax, there is no problem moving forward with both terse syntax
>> discussions *and* tweaks to the concepts feature.
>>
>> Again, I don't know what it is that you're so concerned about here. What
>> are you afraid will happen if the committee continues to debate these
>> proposals (besides your technical issues with Herb's proposal)? Why do y=
ou
>> feel it is *necessary* to shut down all discussion in this area?
>>
>
> What I am afraid is doing harm. Doing harm for a bonus feature is even
> worse. I believe most, no, *all*, of current terse syntax proposals do
> some harm.
>
> Specifically.
> A. Name introducers in any form are a harm. They are a harm because 1.
> they de facto create new language 2. Are not "natural". 3. In some forms
> are not better then the alternative.
> B. Syntax-for-humans is a harm and is doomed to be attacked by counter
> proposals for decades.
>
> As I said, I am not against natural syntax in the form find(Searchable&)
> but it seems there is some strong opposition ageist this OR some fears. N=
ot
> sure which one of the two.
>
> And for the matter of fact am not against Herb proposal in general, I am
> against it being sold as "natural evolution", where in reality it is a ne=
w
> language.
> New language with new possibilities, no matter we like it or not:
> typename{T}, Container{C=3Dstd::vector}, concept{T} all =3D true;
> *These will be coming. *
> Herb's proposal should be evaluated on a bigger context. To adopted
> something on that scale just to get a bonus feature will be a mistake.
>
> --
> 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/edad4445-023=
8-4043-aae6-c7d7b810c2e8%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/edad4445-02=
38-4043-aae6-c7d7b810c2e8%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%2BSg%2Bt0p3AyG%2B2Vm9yVunwV_3G%3DyTwX5K8=
H5O%2BEXO-61m%2BA%40mail.gmail.com.

--0000000000009d7e05056f86fdc3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I wrote an article on convenient syntaxes=C2=A0<a href=3D"=
https://cor3ntin.github.io/posts/concepts_syntax/">https://cor3ntin.github.=
io/posts/concepts_syntax/</a><div>Hopefully, the relatively thorough compar=
ison=C2=A0and background may help some people.</div><div><br></div><div>The=
 article features a quick poll as I attempt to get a feeling of what people=
 think of these syntaxes, maybe it can inform the discussion.</div><div>=C2=
=A0</div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0ven. =
22 juin 2018 =C3=A0=C2=A009:13, &lt;<a href=3D"mailto:mihailnajdenov@gmail.=
com">mihailnajdenov@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Thursday, June 21, 2018 =
at 11:05:17 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div>On Thursday, June 21, 2018 at 12:37:03 PM UTC-4,=
 <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">On Thursday, June 21, 2018 at 6:46:19 PM UTC+3, Nicol Bol=
as wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursd=
ay, June 21, 2018 at 11:40:08 AM UTC-4, Nicol Bolas wrote:<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">On Thursday, June 21, 2018 at 10:55=
:38 AM UTC-4, <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>Ok, I was reading some old papers on the=
 then-called Concepts Light and then it hit me. =C2=A0</div><div><br></div>=
<div><i>Terse syntax have nothing to do with Concepts</i>! And It never had=
.. It was <i>a feature creep</i> from the beginning, an additional goal, the=
 goal to have generic code expressed naturally.</div><div><br></div><div>Th=
is goal however has nothing to do with Concepts as the goal for Concepts is=
 to have constrained types and nothing more.</div></div></blockquote><div><=
br></div><div>That&#39;s
 one way to express it. Another way to express the goal of the=20
Concepts-lite proposal is to improve the ability of users to constrain=20
templates. That involves two pieces: how to define constraints and how=20
to <i>apply</i> them. &quot;Natural syntax&quot; is about application, and =
therefore falls under its purview.<br></div></div></blockquote><div><br></d=
iv><div>This is a point I wanted to elaborate on further.</div><div><br></d=
iv><div>Concepts-lite did not have to allow this:</div><div><br></div><div>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px"><code><div><span style=3D"color:#00=
8">template</span><span style=3D"color:#660">&lt;</span><span style=3D"colo=
r:#606">Concept</span><span style=3D"color:#000"> T</span><span style=3D"co=
lor:#660">&gt;</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">...;</span></div></code></div><br></div><div>It could have required=
 you to use an explicit requires clause:</div><div><br></div><div><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px"><code><div><span style=3D"color:#008">templa=
te</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">t=
ypename</span><span style=3D"color:#000"> T</span><span style=3D"color:#660=
">&gt;</span><span style=3D"color:#000"> requires </span><span style=3D"col=
or:#606">Concept</span><span style=3D"color:#660">&lt;</span><span style=3D=
"color:#000">T</span><span style=3D"color:#660">&gt;</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">...;</span></div></code></div=
><br></div><div>That would have been the bare minimum feature: requires cla=
uses applying concepts.</div><div><br></div><div>But
 the proposal didn&#39;t stop there; it allowed you to apply a concept to a=
=20
template parameter directly. It even implicitly instantiates that=20
concept without needing &lt;&gt;. Back when function concepts were=20
allowed/required, it even implicitly <i>called the function</i>.</div></div=
></blockquote><div><br></div><div>This
 does not introduce natural syntax. It builds on templates machinery. I=20
am not against shortcuts. Natural is much more then that however.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<br></div><div>Those are all usability enhancements: they make applying a c=
oncept to a template easier and more digestible.<br></div><div><br></div><d=
iv>Natural
 syntax is merely another form of usability enhancement. If the=20
replacing of `typename` with a type concept is reasonable for=20
Concepts-lite, then so too is the consideration of other usability=20
enhancements. Even ones that remove `template` boilerplate.<br></div></div>=
</blockquote><div><br></div><div>It is <i>obviously</i> not that simple as =
&quot;<span style=3D"display:inline!important;float:none;background-color:t=
ransparent;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;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">merel=
y another form</span>&quot;. If it was, then there would have been no issue=
s. But
 exactly because we cross a boundary outside templates, outside what we=20
used for 30 years, we can&#39;t agree how to proceed and the opinions vary=
=20
greatly - from minimalistic to new templates syntax.</div></div></blockquot=
e><div><br></div><div>Let me see if I&#39;ve got this right. Terse syntax i=
s not &quot;merely another form&quot; of usability enhancements. Why? Becau=
se if it trust were just that, there wouldn&#39;t be arguments about what f=
orm it should take.<br></div><div><br></div><div>By that reasoning, `templa=
te&lt;Concept T&gt;` is not &quot;merely another form&quot; either. Why? Be=
cause we have people <i>in this very thread</i> who have argued that it oug=
ht to be `template&lt;auto&lt;Concept&gt; T&gt;`. There have been <i>actual=
 proposals</i> for `template&lt;Concept typename T&gt;` (thankfully, they w=
ere expurgated). So there are arguments about what this form should take.</=
div><div><br></div><div>And therefore, <i>by your reasoning</i>, it is not =
&quot;merely another form&quot; of &quot;Apply&quot;. So which is it? Will =
you accept that we should also ditch `template&lt;Concept T&gt;`? Or can we=
 agree that disagreement alone does not represent some kind of &quot;bounda=
ry outside template&quot;?</div></div></div></blockquote><div><br></div></d=
iv><div dir=3D"ltr"><div>The boundary is obvious - addition (requires) and =
improvement (<span style=3D"display:inline!important;float:none;background-=
color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;H=
elvetica&quot;,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=
">&lt;Concept T&gt;</span>) to the current generic programing on one side, =
with (very) minor disagreement=C2=A0</div><div>VS new way of defining gener=
ic functions, where the disagreements is massive.</div></div><div dir=3D"lt=
r"><div>=C2=A0</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=
"><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></div></div></blockquote><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>It
 is better to see and accepts there is boundary, then to pretend there=20
is some sort of &quot;natural evolution&quot; that happens to &quot;suddenl=
y&quot; not be so
 natural for many people.</div></div></blockquote><div><br></div><div>Nobod=
y is &quot;suddenly&quot; anything. People have had concerns about Bjarne&#=
39;s &quot;natural syntax&quot; since its inception.</div></div><div><br></=
div><div>On Thursday, June 21, 2018 at 1:58:18 PM UTC-4, <a>mihailn...@gmai=
l.com</a> wrote:</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">On Thursday, June 21, 2018 at 6:40:08 PM UTC+3, Nicol Bolas wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, June 21, 2=
018 at 10:55:38 AM UTC-4, <a>mihailn...@gmail.com</a> wrote:<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>Ok, I was reading some old p=
apers on the then-called Concepts Light and then it hit me. =C2=A0</div><di=
v><br></div><div><i>Terse syntax have nothing to do with Concepts</i>! And =
It never had. It was <i>a feature creep</i> from the beginning, an addition=
al goal, the goal to have generic code expressed naturally.</div><div><br><=
/div><div>This goal however has nothing to do with Concepts as the goal for=
 Concepts is to have constrained types and nothing more.</div></div></block=
quote><div><br></div><div>That&#39;s one way to express it. Another way to =
express the goal of the Concepts-lite proposal is to improve the ability of=
 users to constrain templates. That involves two pieces: how to define cons=
traints and how to <i>apply</i> them. &quot;Natural syntax&quot; is about a=
pplication, and therefore falls under its purview.<br></div></div></blockqu=
ote><div><br></div><div>Hold on, what are the two pieces. Define and Apply.=
 &quot;<span style=3D"display:inline!important;float:none;background-color:=
transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helveti=
ca&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;fo=
nt-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">to i=
mprove the ability of users to constrain templates&quot;, where I assume na=
tural syntax fall in is <i>a third </i>goal.</span></div></div></blockquote=
><div><br></div><div>You misunderstood my meaning. &quot;To improve the abi=
lity of users to constrain templates&quot; is why concepts exists at all. I=
t is the very goal of concepts.</div><div><br></div><div>&quot;Define and A=
pply&quot; are the <i>means</i> to achieve that goal; they are not the goal=
 itself. My point is that &quot;natural syntax&quot; is within that goal; t=
herefore, it is a perfectly reasonable thing for the Concepts proposal to i=
nclude. It is not out-of-bounds, it is not scope creep or anything of the s=
ort.<br></div></div></blockquote><div><br></div></div><div dir=3D"ltr"><div=
>What is in or out of bounds depends on the point of view as the goals are =
achieved without natural.=C2=A0</div><div>For you, to have natural is a wor=
thy goal, &quot;to finish things up&quot;, for me is barely related bonus w=
hich brings downsides as well.</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"><d=
iv></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><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></div><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"lt=
r"><div></div><div>The goal of <span style=3D"display:inline!important;floa=
t:none;background-color:transparent;color:rgb(34,34,34);font-family:&quot;A=
rial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:left=
;text-decoration:none;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px">generic code expressed naturally is unrelated - you mig=
ht want <i>un</i>constrained types=C2=A0<span style=3D"display:inline!impor=
tant;float:none;background-color:transparent;color:rgb(34,34,34);font-famil=
y:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-st=
yle:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-a=
lign:left;text-decoration:none;text-indent:0px;text-transform:none;white-sp=
ace:normal;word-spacing:0px">expressed naturally.</span></span></div></div>=
</blockquote><div><br></div>You almost never want truly unconstrained types=
.. Seriously, show me a template that genuinely imposes <i>no constraints</i=
> on its argument. It happens, but not very often. `any`&#39;s constructor =
requires that `T` is CopyConstructible. Even `emplace` requires that the se=
quence of parameters can be forwarded to `allocator::construct`.<div><br></=
div><div>We use unconstrained types mainly because constraining them requir=
es lots of effort. The goal of concepts is to minimize that effort. The <i>=
fruits</i> of that goal is the ability to express those constraints &quot;n=
aturally&quot;.<br></div></div></blockquote><div><br></div><div>Prototyping=
, teaching, consistency. Unconstrained are hare to stay as a baseline.<br><=
/div></div></blockquote><div><br></div><div>Where I come from, you start by=
 creating an interface. In class hierarchies, that means a base class with =
pure virtual functions. With static polymorphism, that now means creating a=
 concept.</div><div><br></div><div>Any good teacher should start teaching s=
tatic polymorphism with concepts. New users should be taught that unconstra=
ined templates exist but <i>should be avoided</i>. And any decent prototype=
 will have a prototype interface too, expressed as a concept.</div><div><br=
></div><div>Now sure, you&#39;re still going to need `&lt;typename T&gt;`, =
but this will be for cases where `T` needs to be constrained by a `requires=
` clause. Truly unconstrained template parameters ought to go the way of th=
e Dodo.<br></div></div></blockquote><div><br></div></div><div dir=3D"ltr"><=
div>As I said that&#39;s an interesting topic. Should we declare typename/c=
lass legacy and advocate the &#39;all&#39; concept? Should we indeed teach =
against concepts right away?=C2=A0</div><div>For prototyping/experimenting/=
learning <span style=3D"display:inline!important;float:none;background-colo=
r:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helve=
tica&quot;,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;white-space:normal;word-spacing:0px">un=
constrained will be used, I believe.=C2=A0</span></div></div><div dir=3D"lt=
r"><div>=C2=A0</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=
"><div></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div></div><div></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div></div><div></div><div>So to say that constraints and &qu=
ot;natural syntax&quot; are unrelated is misleading. The existence of const=
raints makes &quot;natural syntax&quot; useful, readable, and digestible. A=
nd &quot;natural syntax&quot; makes constraint application more useable, re=
adable, and digestible.</div></div></blockquote><div><br></div><div>First, =
there is no such thing as &quot;natural syntax&quot; as we cant agree what =
it looks like.</div></div></blockquote><div><br></div><div>Yes there is. Th=
e term &quot;natural syntax&quot; comes directly from Bjarne Stroustrup and=
 <i>specifically</i> refers to the Concepts TS proposal&#39;s terse syntax.=
 Indeed, you were the first one to bring the term up, precisely because the=
 early Concepts TS proposals referred to that syntax as &quot;natural synta=
x&quot;.<br></div><div><br></div><div>What is being debated by the committe=
e is what terse syntax will look like: Bjarne&#39;s &quot;natural syntax&qu=
ot; or Herb&#39;s alternative form.</div><div><br></div><div>And even then,=
 there is clear agreement on the basic principle behind terse templates: yo=
u replace a parameter typename and/or output value with a concept name; thi=
s causes the parameter/output value to be deduced via a constrained templat=
e/return value deduction. So the general look of the concept is well unders=
tood. The differences, while significant, are not that huge.<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>Sec=
ond, the benefits of Concepts alone are so massive that anyone will gladly =
use them as they are now.=C2=A0</div><div>No one, ever, will boycott them b=
ecause the lack of some magical syntax. Why? Because they use the same old =
syntax one is using for ages!</div></div></blockquote><div><br></div><div>W=
ho are you arguing with? <i>Nobody</i> claimed that people would avoid conc=
epts because of a lack of &quot;natural syntax&quot;. Just because people w=
ill use a feature anyway does not mean we can&#39;t make it more readable a=
nd easier to use.</div><div><br></div><div>Producing the bare minimum when =
you can do <i>more</i> and <i>better</i> than that doesn&#39;t make sense.<=
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></div><div>Natural syntax is not related to Concepts directly, i=
t is related to Temples and generic programming.=C2=A0</div><div>The desire=
 to have natural syntax will not disappear if Concepts are not used and, wi=
th few expectations, it is not greater if Concepts are used.<br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
/div><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><span st=
yle=3D"display:inline!important;float:none;background-color:transparent;col=
or:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-s=
erif;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;l=
etter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px;t=
ext-transform:none;white-space:normal;word-spacing:0px"></span></div><div><=
span style=3D"display:inline!important;float:none;background-color:transpar=
ent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;=
,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-weigh=
t:400;letter-spacing:normal;text-align:left;text-decoration:none;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px">With all tha=
t out of the way, I intended to write a proposal to not include any terse s=
yntax for 20. Now I don&#39;t have a shadow of doubt this is The Right Thin=
g (for now). Luckily (not that it s luck!) the current working paper does n=
ot includes any of it.</span></div></div></blockquote><div><br></div><div>A=
nd luckily, most of the committee seems to disagree, since they&#39;re movi=
ng forward with these proposals. I highly doubt you&#39;re going to convinc=
e them that the very idea of terse syntax is not related to concepts, or th=
at they should abandon the idea.<br></div></div></blockquote><div><br></div=
><div></div><div>They agree, there is a clear boundary.</div></div></blockq=
uote><div><br></div><div>No, they agree that terse syntax needs more discus=
sion and has issues to be worked out compared to the rest of concepts.</div=
></div></blockquote><div>=C2=A0</div></div><div dir=3D"ltr"><div>Of course =
there is a boundary, C++ extensions for Concepts (Concepts WP) is chopped f=
rom Concepts TS at exactly that boundary.</div></div><div dir=3D"ltr"><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
br></div><div>They did not agree that terse syntax is unrelated to concepts=
, or that terse syntax should be abandoned or delayed.<br></div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>They can&=
#39;t agree on syntax and the differences are not minor, but major, diametr=
ical.</div></div></blockquote><div><br></div><div>&quot;Can&#39;t&quot; is =
a far cry from &quot;haven&#39;t&quot;. The latter is true; the former has =
yet to be determined.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>Natural syntax is only partially related=
 to Concepts, and is bigger then we think - it does not flow naturally (tha=
t much was proven), it must be invented, it is a different topic.=C2=A0</di=
v><div>I am not for abandoned, but for it to be separate topic, not against=
 current Concepts WP and on later date so the 99% can give feedback.</div><=
/div></blockquote><div><br></div><div>Who is this 99% who are incapable of =
giving feedback on Concepts TS, but will be capable of giving feedback in a=
 few years? Indeed, the entire terse syntax discussion <i>is feedback</i> o=
n the &quot;natural syntax&quot; in Concepts TS.</div></div></blockquote><d=
iv>=C2=A0</div></div><div dir=3D"ltr"><div>The 99% of the C++ users have no=
t touched or seen Concepts in any form.=C2=A0</div></div><div dir=3D"ltr"><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv><br></div><div>Why is that feedback insufficient? Why do you treat terse=
 syntax as though it&#39;s some novel thing that nobody has ever heard of b=
efore? It&#39;s been over <i>four years</i> since the concepts-lite effort =
started.<br></div><div></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></div><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"><div></div><div></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div><span style=3D"display:inline!important;float:n=
one;background-color:transparent;color:rgb(34,34,34);font-family:&quot;Aria=
l&quot;,&quot;Helvetica&quot;,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"></span></div><div><span style=3D"display:inline!important;=
float:none;background-color:transparent;color:rgb(34,34,34);font-family:&qu=
ot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:n=
ormal;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:=
left;text-decoration:none;text-indent:0px;text-transform:none;white-space:n=
ormal;word-spacing:0px">To iterate, I am not against natural, but=C2=A0</sp=
an></div><div><span style=3D"display:inline!important;float:none;background=
-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;=
Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:no=
rmal;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:=
none;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p=
x">it MUST be tackled as separate problem,=C2=A0</span></div></div></blockq=
uote><div><br></div><div>It already is a separate problem. Suggesting that =
people keep doing the thing they&#39;re already doing isn&#39;t useful.<br>=
</div><div><br></div><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"lt=
r"><div><span style=3D"display:inline!important;float:none;background-color=
:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvet=
ica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;f=
ont-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;t=
ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">it =
MUST be decupled from Concepts (physically and mentally)=C2=A0</span></div>=
</div></blockquote><div><br></div><div>See above.<br></div><div><br></div><=
/div></blockquote><div><br></div><div>Then why are natural syntax proposals=
 against Concepts WP?</div></div></blockquote><div><br></div><div>I don&#39=
;t know what you mean by &quot;Concepts WP&quot;. The terse syntax proposal=
s are EWG proposals, not proposals against the Concepts TS.<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>Why =
it is officially listed as &quot;issues with Concepts&quot;.</div></div></b=
lockquote><div><br></div><div>Because terse templates come from the Concept=
s TS. Therefore, adjustments to issues relating to the Concepts TS are issu=
es with concepts.</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div></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></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><span style=3D"display:inline!important;float:none;background-co=
lor:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Hel=
vetica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:norma=
l;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:non=
e;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">=
it MUST be <span style=3D"display:inline!important;float:none;background-co=
lor:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Hel=
vetica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:norma=
l;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:non=
e;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">=
tackled </span>AFTER Concepts and=C2=A0</span></div></div></blockquote><div=
><br></div><div>We already are &quot;AFTER Concepts&quot;.<br></div></div><=
/blockquote><div><br></div><div>Are we?</div><div><span style=3D"display:in=
line!important;float:none;background-color:transparent;color:rgb(34,34,34);=
font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13=
px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:nor=
mal;text-align:left;text-decoration:none;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px">Concepts are not only not released, =
they are still worked on. And by worked on I mean real issues like the Cons=
training Concepts Overload Sets proposal</span></div></div></blockquote><di=
v><br></div><div>We are as &quot;AFTER Concepts&quot; as it is reasonable t=
o get. Unless you are suggesting that there will be design changes to conce=
pts that will impact terse syntax, there is no problem moving forward with =
both terse syntax discussions <i>and</i> tweaks to the concepts feature.</d=
iv><div><br></div><div>Again, I don&#39;t know what it is that you&#39;re s=
o concerned about here. What are you afraid will happen if the committee co=
ntinues to debate these proposals (besides your technical issues with Herb&=
#39;s proposal)? Why do you feel it is <i>necessary</i> to shut down all di=
scussion in this area?<br></div></div></blockquote><div><br></div></div><di=
v dir=3D"ltr"><div>What I am afraid is doing harm. Doing harm for a bonus f=
eature is even worse. I believe most, no, <i>all</i>, of current terse synt=
ax proposals do some harm.=C2=A0</div><div><br></div><div>Specifically.=C2=
=A0</div><div>A. Name introducers in any form are a harm. They are a harm b=
ecause 1. they de facto create new language 2. Are not &quot;natural&quot;.=
 3. In some forms are not better then the alternative.</div><div>B. Syntax-=
for-humans is a harm and is doomed to be attacked by counter proposals for =
decades. =C2=A0</div><div><br></div><div>As I said, I am not against natura=
l syntax in the form <font face=3D"courier new,monospace">find(Searchable&a=
mp;)</font> but it seems there is some strong opposition ageist this OR som=
e fears. Not sure which one of the two.</div><div><br></div><div>And for th=
e matter of fact am not against Herb proposal in general, I am against it b=
eing sold as &quot;natural evolution&quot;, where in reality it is a new la=
nguage.=C2=A0</div><div>New language with new possibilities, no matter we l=
ike it or not: <font face=3D"courier new,monospace">typename{T}</font><font=
 face=3D"arial,sans-serif">,</font> <font face=3D"courier new,monospace">Co=
ntainer{C=3Dstd::vector}</font><font face=3D"arial,sans-serif">, </font><fo=
nt face=3D"courier new,monospace">concept{T} all =3D true;</font><br></div>=
<div><font face=3D"arial,sans-serif"><font face=3D"&quot;Arial&quot;,&quot;=
Helvetica&quot;,sans-serif"></font><i>These will be coming. </i></font></di=
v><div><font face=3D"arial,sans-serif">Herb&#39;s proposal should be evalua=
ted on a bigger context.=C2=A0<span style=3D"display:inline!important;float=
:none;background-color:transparent;color:rgb(34,34,34);font-family:arial,sa=
ns-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:4=
00;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0=
px;text-transform:none;white-space:normal;word-spacing:0px">To adopted some=
thing on that scale just to get a bonus feature will be a mistake.=C2=A0</s=
pan></font></div><div><font face=3D"courier new,monospace"></font><font fac=
e=3D"arial,sans-serif"></font><b></b><i></i><u></u><sub></sub><sup></sup><s=
trike></strike><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/edad4445-0238-4043-aae6-c7d7b810c2e8%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/edad4445-0238-=
4043-aae6-c7d7b810c2e8%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&quot; 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%2BSg%2Bt0p3AyG%2B2Vm9yVunwV_3=
G%3DyTwX5K8H5O%2BEXO-61m%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%=
2BOm%2BSg%2Bt0p3AyG%2B2Vm9yVunwV_3G%3DyTwX5K8H5O%2BEXO-61m%2BA%40mail.gmail=
..com</a>.<br />

--0000000000009d7e05056f86fdc3--

.

------=_Part_3611_1454281896.1530190958652
Content-Type: multipart/alternative;
 boundary="----=_Part_3612_945121058.1530190958653"

------=_Part_3612_945121058.1530190958653
Content-Type: text/plain; charset="UTF-8"


> This code is *clear to ANYONE who EVER worked with C++*, even to a time
traveler from 30 years ago!

I've worked with C++ and it is entirely clear to me. It will be also
extremely clear to anyone having ever worked with a ML-like language.

*> First* Comparable_ can be confused with a return type when one starts to
read.

.... and what's the problem ? It means that the function returns a type that
is comparable - that's hundred of miles better than whatever trickery with
enable_if one could devise.

*> Second* The syntax is COMPLETELY alien to templates - de facto new
language.

Is it ? Lambdas work exactly like this : [] (auto x) { } - it's clear for
everyone having read about them that it is equivalent to struct _anon {
template<typename T> void operator()(T x) { } };

*> Third *there is no obvious connection b/w the function and the clause  -
it just sits there like a separate declaration

that's like saying that in

    int
    foo(int x);

there's no obvious connection between the return type and the function name

*> Forth *Automatic names introductions is very uncommon and will be
confusing for sure.

no.

It seems that you would like to keep C++ as a walled garden for experts
that get high by typing pages upon pages of
template<std::enable_if_t<std::complicated_sfinae_expression(decltype(typename
T::whatever{}))...

Please don't. That's why so many people spit on C++ as a language, and for
once there  is an opportunity to make it simpler. You sound just like these
people who insisted for a complicated syntax for templates in thirty years
ago while Bjarne advocated for the much saner void f<T>(T x) { }.
There's an historical chance to correct this mistake, right here.

On Tuesday, June 19, 2018 at 11:33:54 AM UTC+2, mihailn...@gmail.com wrote:
>
> OK, right now in flight are about FOUR proposals, trying to "simplify" and
> "make more clear" concepts usage.
>
> This is madness. It is madness, because NONE of it make it more clear!
> None.
>
> By inviting new language constructs one does not make things "more clear",
> it only adds more things to learn.
>
> The worst part is - *we have working solution that is clear. Granted
> verbose, but clear. *
>
> If one makes it Not verbose but Not clear (not self-explanatory, need
> learning) also one gains nothing!
>
>
> Consider
>
> template<Iterator Iter1, Iterator Iter2>
>      requires Comparable_though_iterators<Iter1, Iter2>
> bool equal(Iter1 first, Iter1 last, Iter2)
> {}
>
> This code is *clear to ANYONE who EVER worked with C++*, even to a time
> traveler from 30 years ago!
>
> Comparable_through_iterators{Iter1,Iter2}
> bool equal(Iter1 first, Iter1 last, Iter2)
> {}
>
> This is *NOT clear*!
>
> *First* Comparable_ can be confused with a return type when one starts to
> read.
> *Second* The syntax is COMPLETELY alien to templates - de facto new
> language.
> *Third *there is no obvious connection b/w the function and the clause  -
> it just sits there like a separate declaration
> *Forth *Automatic names introductions is very uncommon and will be
> confusing for sure.
>
> The gain of one-less-line is DWARFED by the HEAP of "new stuff" that does
> NOT grant "new powers"!
>
>
>  --- Let's continue
>
>
> Between
>
> void sort(Sortable& s);
>
> and
>
> template void sort(Sortable& s);
>
> *The second is more confusing! *Why? Because it abuses an already
> established syntax for something *completely* different.
>
> Is the first confusing? Might be. What is the solution?
>
> Solution 1:
>
> If this is your code, and you might be confused - don't use it, use the
> more verbose, but more clear syntax!
>
> Solution 2:
>
> Just ctrl-click on Sortable (hell, just hover over it) and all you doubts
> will be solved!
>
>
> Inventing completely new syntax in the form of  Sortable{} is even worse:
>
> Consider
>
> Number x{};
> [](Number{} x)
> {}
> [x = Number{}]()
> {}
>
> Again, any gains are dwarfed by introducing new syntax to learn and/or new
> ways to read old constructs!
> And the biggest problem is - that syntax right now donates *an action *and
> here it will not, it will be just an indicator!
>
>
>  --- Let's continue further
>
> Another non-issue is "the problem one cannot differentiate b/w constrained
> value and a type concept"
>
> template<Concept T, Value v> void f() {}
>
> Why this is non-issue?
>
> *First* Because templates are inline, usage is visible and Types and
> Value are used RADICALLY differently.
> In real word it will *always* be clear which is which!
>
> *Second* as already mentioned in one of the papers - one can use a naming
> convection.
>
> *Third* the more verbose syntax (the a requires clause) is still
> available!
>
> And BTW lets not forget we have class template arguments now, so the
> template arguments are bound to be a bit overloaded now!
>
> template<Concept T, Value v, Class c> void f() {}
>
> Nothing wrong with that - we can use naming conventions and we have good
> IDEs to help us - no need for syntax noise.
>
>
> *The Solution To All This*
>
>
> For now, include *only* the syntax clear to a time traveler! Do not
> include ANYTHING new to learn!
>
> We are JUST introducing Concepts to the general public - *that alone is
> enough new  material!*
>
> For Simple cases
>
> template<Sortable S>
> void sort(S& s);
>
> For Complex cases
>
> template<Iterator Iter1, Iterator Iter2>
>      requires Comparable_though_iterators<Iter1, Iter2>
> bool equal(Iter1 first, Iter1 last, Iter2)
> {}
>
>       *THATS IT. DONE. *
>
> *No*
> template void sort(Sortable& s);
>
> *No*
> void sort(Sortable{}& s);
>
> *No*
> template<Arithmetic{N}, Arithmetic {} n> void f(N);
>
> *No*
> template<auto Arithmetic N> void f();
>
> *No*
> template<Comparable_through_iterators{Iter1,Iter2}>
> bool equal(Iter1 first, Iter1 last, Iter2)
> {}
>
> *And HELL No*
> Comparable_through_iterators{Iter1,Iter2}
> bool equal(Iter1 first, Iter1 last, Iter2)
> {}
>
> *Why?*
>
> *A. Because of the time traveler!!!*
>
> *B. Let the users have theirs say IN THE REAL WORD.*
>
> *C. We can ALWAYS add "simpler" syntax later, say in 5 years!*
>
>
> *Future Directions*
>
> Why not let arguments be comma separated lists if we care so much about
> typing
>
> template<class In1, In2, Out>
>    requires Mergeable<In1, In2, Out>
> Out merge(In1,In1,In2,In2,Out);
>
> Why not instead of the new syntax for names introducing we simply
>
> requires Mergeable<In1, In2, Out>
> Out merge(In1,In1,In2,In2,Out);
>
>
>
>
>
>

--
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/0be3ce68-ddb5-41b6-a5da-e587fcdc3084%40isocpp.org.

------=_Part_3612_945121058.1530190958653
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div></div><div>&gt; This code is <b>clear to ANYONE who E=
VER worked with C++</b>, even to a time traveler from 30 years ago!</div><d=
iv><br></div><div>I&#39;ve worked with C++ and it is entirely clear to me. =
It will be also extremely clear to anyone having ever worked with a ML-like=
 language.</div><div><div><br></div><div><b>&gt; First</b> <span style=3D"d=
isplay:inline!important;float:none;background-color:transparent;color:rgb(3=
4,34,34);font-family:courier new,monospace;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">Comparable<font face=3D"&quot;Arial&quot;,&quot;Helvetic=
a&quot;,sans-serif">_</font></span> can be confused with a return type when=
 one starts to read. <br></div><div><br></div>... and what&#39;s the proble=
m ? It means that the function returns a type that is comparable - that&#39=
;s hundred of miles better than whatever trickery with enable_if one could =
devise.<br><div><br></div><div><b>&gt; Second</b> The syntax is COMPLETELY =
alien to templates - de facto new language. <br></div><div><br></div><div>I=
s it ? Lambdas work exactly like this : [] (auto x) { } - it&#39;s clear fo=
r everyone having read about them that it is equivalent to struct _anon {=
=C2=A0 template&lt;typename T&gt; void operator()(T x) { } };<br></div><div=
><br></div><div><b>&gt; Third </b>there is no obvious connection b/w the fu=
nction and the clause=C2=A0 - it just sits there like a separate declaratio=
n</div><div><br></div><div>that&#39;s like saying that in<br></div><div><br=
></div><div>=C2=A0=C2=A0=C2=A0 int</div><div>=C2=A0=C2=A0=C2=A0 foo(int x);=
</div><div><br></div><div>there&#39;s no obvious connection between the ret=
urn type and the function name<br></div><div><br></div><div><b>&gt; Forth <=
/b>Automatic names introductions is very uncommon and will be confusing for=
 sure.</div><div><br></div><div>no.</div><div><br></div><div>It seems that =
you would like to keep C++ as a walled garden for experts that get high by =
typing pages upon pages of template&lt;std::enable_if_t&lt;std::complicated=
_sfinae_expression(decltype(typename T::whatever{}))...</div><div><br></div=
><div>Please don&#39;t. That&#39;s why so many people spit on C++ as a lang=
uage, and for once there=C2=A0 is an opportunity to make it simpler. You so=
und just like these people who insisted for a complicated syntax for templa=
tes in thirty years ago while Bjarne advocated for the much saner void f&lt=
;T&gt;(T x) { }.</div><div>There&#39;s an historical chance to correct this=
 mistake, right here. <br></div></div><br>On Tuesday, June 19, 2018 at 11:3=
3:54 AM UTC+2, mihailn...@gmail.com wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div>OK, right now in flight are about FOUR pr=
oposals, trying to &quot;simplify&quot; and &quot;make more clear&quot; con=
cepts usage.</div><div><br></div><div>This is madness. It is madness, becau=
se NONE of it make it more clear! None.=C2=A0</div><div><br></div><div>By i=
nviting new language constructs one does not make things &quot;more clear&q=
uot;, it only adds more things to learn.</div><div><br></div><div>The worst=
 part is - <i>we have working solution that is clear. Granted verbose, but =
clear.=C2=A0</i></div><div><i></i><br></div><div>If one makes it Not verbos=
e but Not clear (not self-explanatory, need learning) also one gains nothin=
g!=C2=A0</div><div><br></div><div><br></div><div>Consider</div><div><br></d=
iv><div><font face=3D"courier new,monospace">template&lt;Iterator Iter1, It=
erator Iter2&gt;=C2=A0</font></div><div><font face=3D"courier new,monospace=
">=C2=A0 =C2=A0=C2=A0 requires Comparable_though_iterators&lt;<wbr>Iter1, I=
ter2&gt;</font></div><div><font face=3D"courier new,monospace">bool equal(I=
ter1 first, Iter1 last, Iter2)=C2=A0</font></div><div><font face=3D"courier=
 new,monospace">{}=C2=A0</font></div><div><br></div><div>This code is <b>cl=
ear to ANYONE who EVER worked with C++</b>, even to a time traveler from 30=
 years ago!</div><div><br></div><div><font face=3D"courier new,monospace">C=
omparable_through_iterators{<wbr>Iter1,Iter2}=C2=A0</font></div><div><font =
face=3D"courier new,monospace">bool equal(Iter1 first, Iter1 last, Iter2)=
=C2=A0</font></div><div><font face=3D"courier new,monospace">{}=C2=A0</font=
></div><div><br></div><div>This is <b>NOT clear</b>!=C2=A0</div><div><br></=
div><div><b>First</b> <span style=3D"display:inline!important;float:none;ba=
ckground-color:transparent;color:rgb(34,34,34);font-family:courier new,mono=
space;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">Comparable<font fa=
ce=3D"&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif">_</font></span> c=
an be confused with a return type when one starts to read.=C2=A0</div><div>=
<b>Second</b> The syntax is COMPLETELY alien to templates - de facto new la=
nguage.=C2=A0</div><div><b>Third </b>there is no obvious connection b/w the=
 function and the clause=C2=A0 - it just sits there like a separate declara=
tion</div><div><b>Forth </b>Automatic names introductions is very uncommon =
and will be confusing for sure.</div><div><br></div><div>The gain of one-le=
ss-line is DWARFED by the HEAP of &quot;new stuff&quot; that does NOT grant=
 &quot;new powers&quot;!</div><div><br></div><div><br></div><div>=C2=A0--- =
Let&#39;s continue</div><div><br></div><div><br></div><div>Between=C2=A0</d=
iv><div><br></div><div><font face=3D"courier new,monospace">void sort(Sorta=
ble&amp; s); =C2=A0</font><font face=3D"courier new,monospace"><br></font><=
/div><div><font face=3D"courier new,monospace"><br></font></div><div><font =
face=3D"courier new,monospace">and</font></div><div><font face=3D"courier n=
ew,monospace"><br></font></div><div><font face=3D"courier new,monospace">te=
mplate void sort(Sortable&amp; s);=C2=A0</font></div><div><font face=3D"cou=
rier new,monospace"><br></font></div><div><i>The second is more confusing! =
</i>Why? Because it abuses an already established syntax for something <i>c=
ompletely</i> different.=C2=A0</div><div><br></div><div>Is the first confus=
ing? Might be. What is the solution?</div><div><br></div><div>Solution 1:</=
div><div><br></div><div>If this is your code, and you might be confused - d=
on&#39;t use it, use the more verbose, but more clear syntax!</div><div><br=
></div><div>Solution 2:</div><div><br></div><div>Just ctrl-click on Sortabl=
e (hell, just hover over it) and all you doubts will be solved!=C2=A0</div>=
<div><br></div><div><br></div><div>Inventing completely new syntax in the f=
orm of=C2=A0=C2=A0<span style=3D"display:inline!important;float:none;backgr=
ound-color:transparent;color:rgb(34,34,34);font-family:courier new,monospac=
e;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">Sortable{} <font face=
=3D"arial,sans-serif">is even worse:</font></span></div><div><span style=3D=
"display:inline!important;float:none;background-color:transparent;color:rgb=
(34,34,34);font-family:courier new,monospace;font-size:13px;font-style:norm=
al;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:lef=
t;text-decoration:none;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px"><font face=3D"arial,sans-serif"><br></font></span></di=
v><div><span style=3D"display:inline!important;float:none;background-color:=
transparent;color:rgb(34,34,34);font-family:courier new,monospace;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"><font face=3D"arial,sans-serif">C=
onsider=C2=A0</font></span></div><div><font face=3D"times new roman,serif">=
<i><b></b><u></u><sub></sub><sup></sup><strike></strike><b></b><u></u><sub>=
</sub><sup></sup><strike></strike><font face=3D"arial,sans-serif"></font><b=
r></i></font></div><div><span style=3D"text-align:left;color:rgb(34,34,34);=
text-transform:none;text-indent:0px;letter-spacing:normal;font-size:13px;fo=
nt-style:normal;font-variant:normal;font-weight:400;text-decoration:none;wo=
rd-spacing:0px;display:inline!important;white-space:normal;float:none;backg=
round-color:transparent"><font face=3D"courier new,monospace">Number x{};</=
font></span><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br=
></div><div><font face=3D"courier new,monospace">[](Number{} x)=C2=A0</font=
></div><div><font face=3D"courier new,monospace">{} </font></div><div><div>=
[<font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;=
border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:n=
one;border-left-width:0px;border-right-color:rgb(34,34,34);border-right-sty=
le:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-st=
yle:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-righ=
t:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;=
padding-top:0px" face=3D"courier new,monospace">x =3D Number{}]()</font></d=
iv><div><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-styl=
e:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-=
style:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-ri=
ght-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);border=
-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;marg=
in-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-rig=
ht:0px;padding-top:0px" face=3D"courier new,monospace">{}=C2=A0</font><br><=
/div></div><div><font face=3D"courier new,monospace"></font><br></div><div>=
Again, any gains are dwarfed by introducing new syntax to learn and/or new =
ways to read old constructs!=C2=A0</div><div>And the biggest problem is - t=
hat syntax right now donates <b><i>an action</i> </b>and here it will not, =
it will be just an indicator!=C2=A0</div><div><i></i><i></i><br></div><div>=
<br></div><div><span style=3D"display:inline!important;float:none;backgroun=
d-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot=
;Helvetica&quot;,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">=C2=A0--- Let&#39;s continue further</span></div><div><b></b><i></i><u>=
</u><sub></sub><sup></sup><strike></strike><br></div><div>Another non-issue=
 is &quot;the problem one cannot differentiate b/w constrained value and a =
type concept&quot;=C2=A0</div><div><br></div><div><font face=3D"courier new=
,monospace">template&lt;Concept T, Value v&gt; void f() {}</font></div><div=
><font face=3D"courier new,monospace"></font><br></div><div>Why this is non=
-issue?=C2=A0</div><div><br></div><div><b>First</b> Because templates are i=
nline, usage is visible and Types and Value are used RADICALLY differently.=
</div><div>In real word it will <i>always</i> be clear which is which!=C2=
=A0</div><div><br></div><div><b>Second</b> as already mentioned in one of t=
he papers - one can use a naming convection.</div><div><br></div><div><b>Th=
ird</b> the more verbose syntax (the a <font face=3D"courier new,monospace"=
>requires</font> clause) is still available!=C2=A0</div><div><b></b><b></b>=
<br></div><div>And BTW lets not forget we have class template arguments now=
, so the template arguments are bound to be a bit overloaded now!<br></div>=
<div><div><br></div><div><font style=3D"border-bottom-color:rgb(34,34,34);b=
order-bottom-style:none;border-bottom-width:0px;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-color:rgb=
(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;mar=
gin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-lef=
t:0px;padding-right:0px;padding-top:0px" face=3D"courier new,monospace">tem=
plate&lt;Concept T, Value v, Class c&gt; void f() {}</font></div><b></b><i>=
</i><u></u><sub></sub><sup></sup><strike></strike><br></div><div>Nothing wr=
ong with that - we can use naming conventions and we have good IDEs to help=
 us - no need for syntax noise. =C2=A0</div><div><br></div><div><br></div><=
div><b>The Solution To All This</b></div><div><b><br></b></div><div><b><br>=
</b></div><div>For now, include <i>only</i> the syntax clear to a time trav=
eler! Do not include ANYTHING new to learn!=C2=A0</div><div><br></div><div>=
We are JUST introducing Concepts to the general public - <i>that alone is e=
nough new=C2=A0 material!</i><br></div><div><i></i><i></i><br></div><div>Fo=
r Simple cases</div><div><br></div><div><span style=3D"display:inline!impor=
tant;float:none;background-color:transparent;color:rgb(34,34,34);font-famil=
y:courier new,monospace;font-size:13px;font-style:normal;font-variant:norma=
l;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:non=
e;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">=
template&lt;Sortable S&gt;=C2=A0</span></div><div><span style=3D"display:in=
line!important;float:none;background-color:transparent;color:rgb(34,34,34);=
font-family:courier new,monospace;font-size:13px;font-style:normal;font-var=
iant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-deco=
ration:none;text-indent:0px;text-transform:none;white-space:normal;word-spa=
cing:0px">void sort(S&amp; s);=C2=A0</span></div><div><span style=3D"displa=
y:inline!important;float:none;background-color:transparent;color:rgb(34,34,=
34);font-family:courier new,monospace;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"><br></span></div><div><span style=3D"text-align:left;color:rg=
b(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-=
size:13px;font-style:normal;font-variant:normal;font-weight:400;text-decora=
tion:none;word-spacing:0px;display:inline!important;white-space:normal;floa=
t:none;background-color:transparent"><font face=3D"arial,sans-serif">For Co=
mplex cases</font></span></div><div><span style=3D"display:inline!important=
;float:none;background-color:transparent;color:rgb(34,34,34);font-family:co=
urier new,monospace;font-size:13px;font-style:normal;font-variant:normal;fo=
nt-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><fon=
t face=3D"arial,sans-serif"></font><br></span></div><div><span style=3D"tex=
t-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter=
-spacing:normal;font-family:courier new,monospace;font-size:13px;font-varia=
nt:normal;word-spacing:0px;display:inline!important;white-space:normal;floa=
t:none;background-color:transparent"><div style=3D"margin:0px;padding:0px;b=
order:0px rgb(34,34,34);text-align:left;color:rgb(34,34,34);text-transform:=
none;text-indent:0px;letter-spacing:normal;font-size:13px;font-variant:norm=
al;word-spacing:0px;white-space:normal;background-color:transparent"><span =
style=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-align:left;co=
lor:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal=
;font-family:courier new,monospace;font-size:13px;font-variant:normal;word-=
spacing:0px;display:inline;white-space:normal;float:none;background-color:t=
ransparent"><div><font style=3D"border-bottom-color:rgb(34,34,34);border-bo=
ttom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);bor=
der-left-style:none;border-left-width:0px;border-right-color:rgb(34,34,34);=
border-right-style:none;border-right-width:0px;border-top-color:rgb(34,34,3=
4);border-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left=
:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;pa=
dding-right:0px;padding-top:0px" face=3D"courier new,monospace">template&lt=
;Iterator Iter1, Iterator Iter2&gt;=C2=A0</font></div><div><font style=3D"b=
order-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-wid=
th:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-w=
idth:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-ri=
ght-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-t=
op-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:=
0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" =
face=3D"courier new,monospace">=C2=A0 =C2=A0=C2=A0 requires Comparable_thou=
gh_iterators&lt;<wbr>Iter1, Iter2&gt;</font></div><div><font style=3D"borde=
r-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0=
px;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-color:rgb(34,34,34);border-top-style:none;border-top-w=
idth:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;=
padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=
=3D"courier new,monospace">bool equal(Iter1 first, Iter1 last, Iter2)=C2=A0=
</font></div><div><font style=3D"border-bottom-color:rgb(34,34,34);border-b=
ottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);bo=
rder-left-style:none;border-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-top-style:none;border-top-width:0px;margin-bottom:0px;margin-lef=
t:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;p=
adding-right:0px;padding-top:0px" face=3D"courier new,monospace">{}=C2=A0</=
font></div></span></div><b></b><i></i><u></u><sub></sub><sup></sup><strike>=
</strike><br></span></div><div>=C2=A0 =C2=A0 =C2=A0 <b>THATS IT. DONE.=C2=
=A0</b></div><div><b><br></b></div><div><b>No</b></div><div><span style=3D"=
display:inline!important;float:none;background-color:transparent;color:rgb(=
34,34,34);font-family:courier new,monospace;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:left=
;text-decoration:none;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px">template void sort(Sortable&amp; s);=C2=A0</span></div>=
<div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div>=
<div><b>No</b></div><div><span style=3D"display:inline!important;float:none=
;background-color:transparent;color:rgb(34,34,34);font-family:courier new,m=
onospace;font-size:13px;font-style:normal;font-variant:normal;font-weight:4=
00;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0=
px;text-transform:none;white-space:normal;word-spacing:0px">void sort(Sorta=
ble{}&amp; s);=C2=A0</span></div><div><span style=3D"display:inline!importa=
nt;float:none;background-color:transparent;color:rgb(34,34,34);font-family:=
courier new,monospace;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"><b=
r></span></div><div><span style=3D"text-align:left;color:rgb(34,34,34);text=
-transform:none;text-indent:0px;letter-spacing:normal;font-family:courier n=
ew,monospace;font-size:13px;font-variant:normal;word-spacing:0px;display:in=
line!important;white-space:normal;float:none;background-color:transparent">=
<div><span><div style=3D"background-color:transparent;border-bottom-color:r=
gb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-c=
olor:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-righ=
t-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;border=
-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;color:r=
gb(34,34,34);font-size:13px;font-style:normal;font-variant:normal;font-weig=
ht:400;letter-spacing:normal;margin-bottom:0px;margin-left:0px;margin-right=
:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;p=
adding-top:0px;text-align:left;text-decoration:none;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px"><span><font style=3D"bord=
er-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:=
0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-widt=
h:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-right=
-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-=
width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px=
;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" fac=
e=3D"arial,sans-serif"><b style=3D"border-bottom-color:rgb(34,34,34);border=
-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);=
border-left-style:none;border-left-width:0px;border-right-color:rgb(34,34,3=
4);border-right-style:none;border-right-width:0px;border-top-color:rgb(34,3=
4,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;margin-l=
eft:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px=
;padding-right:0px;padding-top:0px">No</b></font><font style=3D"border-bott=
om-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;bor=
der-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;b=
order-right-color:rgb(34,34,34);border-right-style:none;border-right-width:=
0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0=
px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;paddin=
g-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=3D"co=
urier new,monospace">=C2=A0</font></span><br style=3D"border-bottom-color:r=
gb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-left-c=
olor:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-righ=
t-color:rgb(34,34,34);border-right-style:none;border-right-width:0px;border=
-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;margin-=
bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0=
px;padding-left:0px;padding-right:0px;padding-top:0px"></div></span></div><=
div><span style=3D"background-color:transparent;border-bottom-color:rgb(34,=
34,34);border-bottom-style:none;border-bottom-width:0px;border-left-color:r=
gb(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;border-top-c=
olor:rgb(34,34,34);border-top-style:none;border-top-width:0px;color:rgb(34,=
34,34);display:inline;float:none;font-family:courier new,monospace;font-siz=
e:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing=
:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;p=
adding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px;text-a=
lign:left;text-decoration:none;text-indent:0px;text-transform:none;white-sp=
ace:normal;word-spacing:0px"><b style=3D"border-bottom-color:rgb(34,34,34);=
border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,3=
4,34);border-left-style:none;border-left-width:0px;border-right-color:rgb(3=
4,34,34);border-right-style:none;border-right-width:0px;border-top-color:rg=
b(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;ma=
rgin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-le=
ft:0px;padding-right:0px;padding-top:0px"></b><i style=3D"border-bottom-col=
or:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-le=
ft-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;bo=
rder-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0px;mar=
gin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bott=
om:0px;padding-left:0px;padding-right:0px;padding-top:0px"></i><u style=3D"=
border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-wi=
dth:0px;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-r=
ight-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-=
top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top=
:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px"=
></u><sub style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:no=
ne;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-styl=
e:none;border-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-top=
-style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-r=
ight:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0=
px;padding-top:0px"></sub><sup style=3D"border-bottom-color:rgb(34,34,34);b=
order-bottom-style:none;border-bottom-width:0px;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-color:rgb=
(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;mar=
gin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-lef=
t:0px;padding-right:0px;padding-top:0px"></sup><strike style=3D"border-bott=
om-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;bor=
der-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;b=
order-right-color:rgb(34,34,34);border-right-style:none;border-right-width:=
0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-width:0=
px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;paddin=
g-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px"></strike>t=
emplate&lt;Arithmetic{N}, Arithmetic {} n&gt; void f(N);</span><br></div></=
span></div><div><span style=3D"text-align:left;color:rgb(34,34,34);text-tra=
nsform:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-style=
:normal;font-variant:normal;font-weight:400;text-decoration:none;word-spaci=
ng:0px;display:inline!important;white-space:normal;float:none;background-co=
lor:transparent"><font face=3D"courier new,monospace"></font><b></b><i></i>=
<u></u><sub></sub><sup></sup><strike></strike><br></span></div><div><span s=
tyle=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent=
:0px;letter-spacing:normal;font-size:13px;font-variant:normal;word-spacing:=
0px;display:inline!important;white-space:normal;float:none;background-color=
:transparent"><div><b><font face=3D"arial,sans-serif">No</font></b></div><d=
iv><span style=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-alig=
n:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spaci=
ng:normal;font-size:13px;font-style:normal;font-variant:normal;font-weight:=
400;text-decoration:none;word-spacing:0px;display:inline;white-space:normal=
;float:none;background-color:transparent"><font face=3D"courier new,monospa=
ce">template&lt;auto Arithmetic N&gt; void f();</font></span></div></span><=
div><span style=3D"display:inline!important;float:none;background-color:tra=
nsparent;color:rgb(34,34,34);font-family:courier new,monospace;font-size:13=
px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:nor=
mal;text-align:left;text-decoration:none;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px"><br></span></div></div><div><span st=
yle=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:=
0px;letter-spacing:normal;font-size:13px;font-style:normal;font-variant:nor=
mal;text-decoration:none;word-spacing:0px;display:inline!important;white-sp=
ace:normal;float:none;background-color:transparent"><b><font face=3D"arial,=
sans-serif">No</font></b></span></div><div><div><font style=3D"border-botto=
m-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;bord=
er-left-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;bo=
rder-right-color:rgb(34,34,34);border-right-style:none;border-right-width:0=
px;border-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" face=3D"cou=
rier new,monospace">template&lt;Comparable_through_<wbr>iterators{Iter1,Ite=
r2}&gt;</font></div><div><font style=3D"border-bottom-color:rgb(34,34,34);b=
order-bottom-style:none;border-bottom-width:0px;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-color:rgb=
(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;mar=
gin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-lef=
t:0px;padding-right:0px;padding-top:0px" face=3D"courier new,monospace">boo=
l equal(Iter1 first, Iter1 last, Iter2)=C2=A0</font></div><div><font style=
=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-botto=
m-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-l=
eft-width:0px;border-right-color:rgb(34,34,34);border-right-style:none;bord=
er-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;bor=
der-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin=
-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:=
0px" face=3D"courier new,monospace">{}=C2=A0</font></div><b></b><i></i><u><=
/u><sub></sub><sup></sup><strike></strike><br></div><div><b>And HELL No</b>=
</div><div><div><font style=3D"border-bottom-color:rgb(34,34,34);border-bot=
tom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,34);bord=
er-left-style:none;border-left-width:0px;border-right-color:rgb(34,34,34);b=
order-right-style:none;border-right-width:0px;border-top-color:rgb(34,34,34=
);border-top-style:none;border-top-width:0px;margin-bottom:0px;margin-left:=
0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;pad=
ding-right:0px;padding-top:0px" face=3D"courier new,monospace">Comparable_t=
hrough_iterators{<wbr>Iter1,Iter2}=C2=A0</font></div><div><font style=3D"bo=
rder-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-widt=
h:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-wi=
dth: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;border-to=
p-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0=
px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px" f=
ace=3D"courier new,monospace">bool equal(Iter1 first, Iter1 last, Iter2)=C2=
=A0</font></div><div><font style=3D"border-bottom-color:rgb(34,34,34);borde=
r-bottom-style:none;border-bottom-width:0px;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-color:rgb(34,=
34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;margin-=
left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0p=
x;padding-right:0px;padding-top:0px" face=3D"courier new,monospace">{}=C2=
=A0</font><br></div><b></b><i></i><u></u><sub></sub><sup></sup><strike></st=
rike><br></div><div><b>Why?</b></div><div><b></b><i></i><br></div><div><i>A=
.. Because of the time traveler!!!</i></div><div><i><br></i></div><div><i>B.=
 Let the users have theirs say IN THE REAL WORD.</i></div><div><i><br></i><=
/div><div><i>C. We can ALWAYS add &quot;simpler&quot; syntax later, say in =
5 years!</i></div><div><i><br></i></div><div><i><br></i></div><div><b>Futur=
e Directions</b></div><div><b><br></b></div><div>Why not let arguments be c=
omma separated lists if we care so much about typing</div><div><span style=
=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-align:left;color:r=
gb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font=
-size:13px;font-style:normal;font-variant:normal;font-weight:400;text-decor=
ation:none;word-spacing:0px;display:inline;white-space:normal;float:none;ba=
ckground-color:transparent"><br style=3D"border-bottom-color:rgb(34,34,34);=
border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,3=
4,34);border-left-style:none;border-left-width:0px;border-right-color:rgb(3=
4,34,34);border-right-style:none;border-right-width:0px;border-top-color:rg=
b(34,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;ma=
rgin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-le=
ft:0px;padding-right:0px;padding-top:0px"></span></div><div><div><span styl=
e=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-align:left;color:=
rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;fon=
t-size:13px;font-style:normal;font-variant:normal;font-weight:400;text-deco=
ration:none;word-spacing:0px;display:inline;white-space:normal;float:none;b=
ackground-color:transparent"><div style=3D"background-color:transparent;bor=
der-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width=
:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-wid=
th:0px;border-right-color:rgb(34,34,34);border-right-style:none;border-righ=
t-width:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top=
-width:0px;color:rgb(34,34,34);font-size:13px;font-style:normal;font-varian=
t:normal;font-weight:400;letter-spacing:normal;margin-bottom:0px;margin-lef=
t:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;p=
adding-right:0px;padding-top:0px;text-align:left;text-decoration:none;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span s=
tyle=3D"margin:0px;padding:0px;border:0px rgb(34,34,34);text-align:left;col=
or:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;=
font-size:13px;font-style:normal;font-variant:normal;font-weight:400;text-d=
ecoration:none;word-spacing:0px;display:inline;white-space:normal;float:non=
e;background-color:transparent"><div style=3D"background-color:transparent;=
border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-wi=
dth:0px;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-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-size:13px;font-style:normal;font-var=
iant:normal;font-weight:400;letter-spacing:normal;margin-bottom:0px;margin-=
left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0p=
x;padding-right:0px;padding-top:0px;text-align:left;text-decoration:none;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><fon=
t style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;borde=
r-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;b=
order-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:no=
ne;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:n=
one;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px=
;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;paddi=
ng-top:0px" face=3D"courier new,monospace">template&lt;class In1, In2, Out&=
gt;=C2=A0</font></div><div style=3D"background-color:transparent;border-bot=
tom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;bo=
rder-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-color:rgb(34,34,34);border-top-style:none;border-top-width:=
0px;color:rgb(34,34,34);font-size:13px;font-style:normal;font-variant:norma=
l;font-weight:400;letter-spacing:normal;margin-bottom:0px;margin-left:0px;m=
argin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-=
right:0px;padding-top:0px;text-align:left;text-decoration:none;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px"><font style=3D=
"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-w=
idth:0px;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-color:rgb(34,34,34);border-top-style:none;border=
-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;margin-to=
p:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-top:0px=
" face=3D"courier new,monospace">=C2=A0=C2=A0 requires Mergeable&lt;In1, In=
2, Out&gt; =C2=A0</font></div><div style=3D"background-color:transparent;bo=
rder-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-widt=
h:0px;border-left-color:rgb(34,34,34);border-left-style:none;border-left-wi=
dth: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;border-to=
p-width:0px;color:rgb(34,34,34);font-size:13px;font-style:normal;font-varia=
nt:normal;font-weight:400;letter-spacing:normal;margin-bottom:0px;margin-le=
ft:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;=
padding-right:0px;padding-top:0px;text-align:left;text-decoration:none;text=
-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><font =
style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border-=
bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;bor=
der-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-top-style:non=
e;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;m=
argin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding=
-top:0px" face=3D"courier new,monospace">Out merge(In1,In1,In2,In2,Out);</f=
ont></div></span></div></span></div><font face=3D"courier new,monospace"></=
font><br></div><div>Why not instead of the new syntax for names introducing=
 we simply</div><div><br></div><div><div><font style=3D"border-bottom-color=
:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-left=
-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-ri=
ght-color: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:0px;margi=
n-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom=
:0px;padding-left:0px;padding-right:0px;padding-top:0px" face=3D"courier ne=
w,monospace">requires Mergeable&lt;In1, In2, Out&gt; =C2=A0</font></div><di=
v><font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none=
;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:=
none;border-left-width:0px;border-right-color:rgb(34,34,34);border-right-st=
yle:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-s=
tyle:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-rig=
ht:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px=
;padding-top:0px" face=3D"courier new,monospace">Out merge(In1,In1,In2,In2,=
Out);</font></div><div><font style=3D"border-bottom-color:rgb(34,34,34);bor=
der-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(34,34,3=
4);border-left-style:none;border-left-width:0px;border-right-color:rgb(34,3=
4,34);border-right-style:none;border-right-width:0px;border-top-color:rgb(3=
4,34,34);border-top-style:none;border-top-width:0px;margin-bottom:0px;margi=
n-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;padding-left:=
0px;padding-right:0px;padding-top:0px" face=3D"courier new,monospace"><br><=
/font></div><div><br></div></div><div><br></div><div><b></b><i></i><u></u><=
sub></sub><sup></sup><strike></strike><br></div><div><font face=3D"times ne=
w roman,serif"></font></div><div><font face=3D"times new roman,serif"><i><b=
r></i></font></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&quot; 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/0be3ce68-ddb5-41b6-a5da-e587fcdc3084%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0be3ce68-ddb5-41b6-a5da-e587fcdc3084=
%40isocpp.org</a>.<br />

------=_Part_3612_945121058.1530190958653--

------=_Part_3611_1454281896.1530190958652--

.

--0000000000004f3403056fb6bc28
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 21, 2018 at 10:55 AM, <mihailnajdenov@gmail.com> wrote:

> Ok, I was reading some old papers on the then-called Concepts Light and
> then it hit me.
>
> *Terse syntax have nothing to do with Concepts*! And It never had. It was *a
> feature creep* from the beginning, an additional goal, the goal to have
> generic code expressed naturally.
>
> This goal however has nothing to do with Concepts as the goal for Concepts
> is to have constrained types and nothing more.
>
> The goal of generic code expressed naturally is unrelated - you might
> want *un*constrained types expressed naturally.
>
> But, before concepts we didn't have "natural" templates! We didn't have func(auto)
> or some  func(class{}) for 30 years
>
> This is were ALL the problems stem from - the fact we try to "evolve"
> natural syntax, but there is no base to evolve from!
>
> As a result we create jump, a discontinuation, which either leads to the
> so called "natural" syntax looking more alien then templates themselves
> (incl. introducing new constructs).
> or
> We got confused "is auto func(Searchabe&)"  a template. It is normal to
> be confused - there is no continuous evolution. We/some resist the
> discontinuation.
>
> On the other hand Concepts, as an integral part of the template system
> *do* fit - it *is* a smooth evolution in both syntax and meaning.
>
>
> And it goes the other direction - because natural has nothing to do with
> Concepts, the syntax MUST work with unconstrained as well. We MUST have
> func(auto) or  func(class{T});
>
>
> With all that out of the way, I intended to write a proposal to not
> include any terse syntax for 20. Now I don't have a shadow of doubt this is
> The Right Thing (for now). Luckily (not that it s luck!) the current
> working paper does not includes any of it.
>
> To iterate, I am not against natural, but
> it MUST be tackled as separate problem,
>

For some, terse syntax points out problems with the non-terse syntax -
whether we ever get terse syntax or not.  So we should probably tackle that
now.
In particular,

template <X x>

Some would prefer that x is a value, not a type, regardless to whether X is
a type or a concept.


it MUST be decupled from Concepts (physically and mentally)
> it MUST be tackled AFTER Concepts and
> it MUST handle unconstrained as well.
>
> --
> 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/5083fdc0-5316-4b70-
> bb80-c0bc4c756232%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5083fdc0-5316-4b70-bb80-c0bc4c756232%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
Be seeing you,
Tony

--
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/CAOHCbisu7arOeMTHwB6zCoBjEqUUaJwgAFQ_wxFjgGsdiWfUVg%40mail.gmail.com.

--0000000000004f3403056fb6bc28
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Jun 21, 2018 at 10:55 AM,  <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:mihailnajdenov@gmail.com" target=3D"_blank">mihailnajdenov@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>Ok, I was reading some old papers on the then-called Concepts Light and th=
en it hit me. =C2=A0</div><div><br></div><div><i>Terse syntax have nothing =
to do with Concepts</i>! And It never had. It was <i>a feature creep</i> fr=
om the beginning, an additional goal, the goal to have generic code express=
ed naturally.</div><div><br></div><div>This goal however has nothing to do =
with Concepts as the goal for Concepts is to have constrained types and not=
hing more.=C2=A0</div><div><br></div><div>The goal of <span style=3D"displa=
y:inline!important;float:none;background-color:transparent;color:rgb(34,34,=
34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-siz=
e: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">generic code expressed naturally=
 is unrelated - you might want <i>un</i>constrained types=C2=A0<span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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">expressed naturally.=
=C2=A0</span></span></div><div><span style=3D"display:inline!important;floa=
t:none;background-color:transparent;color:rgb(34,34,34);font-family:&quot;A=
rial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:left=
;text-decoration:none;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px"><span style=3D"display:inline!important;float:none;back=
ground-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,=
&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-vari=
ant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-decor=
ation:none;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px"><br></span></span></div><div>But, before concepts we didn&#39;t ha=
ve &quot;natural&quot; templates! We didn&#39;t have <font face=3D"courier =
new,monospace">func(auto) <font face=3D"arial,sans-serif">or some=C2=A0 </f=
ont>func(class{}) <span style=3D"display:inline!important;float:none;backgr=
ound-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&q=
uot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-varian=
t:normal;font-weight:400;letter-spacing:normal;text-align:left;text-decorat=
ion:none;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px">for 30 years</span></font></div><div><br></div><div>This is were ALL=
 the problems stem from - the fact we try to &quot;evolve&quot; natural syn=
tax, but there is no base to evolve from!</div><div><br></div><div>As a res=
ult we create jump, a discontinuation, which either leads to the so called =
&quot;natural&quot; syntax looking more alien then templates themselves (in=
cl. introducing new constructs).<br></div><div>or<br></div><div>We got conf=
used &quot;is <font face=3D"courier new,monospace">auto func(Searchabe&amp;=
)</font>&quot;=C2=A0 a template. It is normal to be confused - there is no =
continuous evolution. We/some resist the discontinuation.=C2=A0</div><div><=
span><br style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:non=
e;border-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style=
:none;border-left-width:0px;border-right-color:rgb(34,34,34);border-right-s=
tyle:none;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-=
style:none;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-ri=
ght:0px;margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0p=
x;padding-top:0px"></span></div><div><div><span>On the other hand Concepts,=
 as an integral part of the template system <i style=3D"border-bottom-color=
:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0px;border-left=
-color:rgb(34,34,34);border-left-style:none;border-left-width:0px;border-ri=
ght-color: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:0px;margi=
n-bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom=
:0px;padding-left:0px;padding-right:0px;padding-top:0px">do</i> fit - it <i=
 style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;border=
-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:none;bo=
rder-left-width:0px;border-right-color:rgb(34,34,34);border-right-style:non=
e;border-right-width:0px;border-top-color:rgb(34,34,34);border-top-style:no=
ne;border-top-width:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;=
margin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;paddin=
g-top:0px">is</i> a smooth evolution in both syntax and meaning.</span></di=
v><div><br></div></div><div><br>And it goes the other direction <i></i>- be=
cause natural has nothing to do with Concepts, the syntax MUST work with un=
<span style=3D"display:inline!important;float:none;background-color:transpa=
rent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot=
;,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">constrained=
 as well. We MUST have func(auto) or=C2=A0 func(class{T});</span></div><div=
><span style=3D"display:inline!important;float:none;background-color:transp=
arent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quo=
t;,sans-serif;font-size:13px;font-style:normal;font-variant:normal;font-wei=
ght:400;letter-spacing:normal;text-align:left;text-decoration:none;text-ind=
ent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></span=
></div><div><span style=3D"display:inline!important;float:none;background-c=
olor:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;He=
lvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:norm=
al;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:no=
ne;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"=
><br></span></div><div><span style=3D"display:inline!important;float:none;b=
ackground-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quo=
t;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-v=
ariant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-de=
coration:none;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px">With all that out of the way, I intended to write a proposal to=
 not include any terse syntax for 20. Now I don&#39;t have a shadow of doub=
t this is The Right Thing (for now). Luckily (not that it s luck!) the curr=
ent working paper does not includes any of it.</span></div><div><span style=
=3D"display:inline!important;float:none;background-color:transparent;color:=
rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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"><br></span></div><div>=
<span style=3D"display:inline!important;float:none;background-color:transpa=
rent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot=
;,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">To iterate,=
 I am not against natural, but=C2=A0</span></div><div><span style=3D"displa=
y:inline!important;float:none;background-color:transparent;color:rgb(34,34,=
34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-siz=
e: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">it MUST be tackled as separate p=
roblem,=C2=A0</span></div></div></blockquote><div><br></div><div>For some, =
terse syntax points out problems with the non-terse syntax - whether we eve=
r get terse syntax or not.=C2=A0 So we should probably tackle that now.</di=
v><div>In particular,</div><div><br></div><div>template &lt;X x&gt;</div><d=
iv><br></div><div>Some would prefer that x is a value, not a type, regardle=
ss to whether X is a type or a concept.</div><div><br></div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"display=
:inline!important;float:none;background-color:transparent;color:rgb(34,34,3=
4);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,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;white-space:normal;word-spacing:0px">it MUST be decupled from Concepts=
 (physically and mentally)=C2=A0</span></div><div><span style=3D"display:in=
line!important;float:none;background-color:transparent;color:rgb(34,34,34);=
font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13=
px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:nor=
mal;text-align:left;text-decoration:none;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px">it MUST be <span style=3D"display:in=
line!important;float:none;background-color:transparent;color:rgb(34,34,34);=
font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13=
px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:nor=
mal;text-align:left;text-decoration:none;text-indent:0px;text-transform:non=
e;white-space:normal;word-spacing:0px">tackled </span>AFTER Concepts and=C2=
=A0</span></div><div><span style=3D"display:inline!important;float:none;bac=
kground-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;=
,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-var=
iant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-deco=
ration:none;text-indent:0px;text-transform:none;white-space:normal;word-spa=
cing:0px">it MUST handle unconstrained as well.=C2=A0</span></div><div><b><=
/b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div></div><sp=
an class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5083fdc0-5316-4b70-bb80-c0bc4c756232%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5083=
fdc0-5316-4b70-<wbr>bb80-c0bc4c756232%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAOHCbisu7arOeMTHwB6zCoBjEqUUaJwgAFQ_=
wxFjgGsdiWfUVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbisu7arOeMTH=
wB6zCoBjEqUUaJwgAFQ_wxFjgGsdiWfUVg%40mail.gmail.com</a>.<br />

--0000000000004f3403056fb6bc28--

.

------=_Part_5524_182250099.1530207614360
Content-Type: multipart/alternative;
 boundary="----=_Part_5525_907078942.1530207614360"

------=_Part_5525_907078942.1530207614360
Content-Type: text/plain; charset="UTF-8"

I make no defense of the OP's argument, but he is not talking stating that
we shouldn't have concepts *at all* (and thus must continue to use
`std::enable_if` gymnastics). He's talking specifically and only about
terse syntax for declaring conceptualized template functions.

He's saying that we're better off using explicit `requires` clauses than
having shorter syntax. He's not saying that we're better off with
`enable_if`".

--
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/41506c50-1c34-4af7-aff8-1736f5cfcd07%40isocpp.org.

------=_Part_5525_907078942.1530207614360
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I make no defense of the OP&#39;s argument, but he is=
 not talking stating that we shouldn&#39;t have concepts <i>at all</i> (and=
 thus must continue to use `std::enable_if` gymnastics). He&#39;s talking s=
pecifically and only about terse syntax for declaring conceptualized templa=
te functions.</div><div><br></div><div>He&#39;s saying that we&#39;re bette=
r off using explicit `requires` clauses than having shorter syntax. He&#39;=
s not saying that we&#39;re better off with `enable_if`&quot;.<font face=3D=
"times new roman,serif"><i><br></i></font></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/41506c50-1c34-4af7-aff8-1736f5cfcd07%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/41506c50-1c34-4af7-aff8-1736f5cfcd07=
%40isocpp.org</a>.<br />

------=_Part_5525_907078942.1530207614360--

------=_Part_5524_182250099.1530207614360--

.

------=_Part_8550_892626000.1530232409244
Content-Type: multipart/alternative;
 boundary="----=_Part_8551_519925942.1530232409244"

------=_Part_8551_519925942.1530232409244
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thursday, June 28, 2018 at 10:40:14 AM UTC-7, Nicol Bolas wrote:
>
> I make no defense of the OP's argument, but he is not talking stating tha=
t=20
> we shouldn't have concepts *at all* (and thus must continue to use=20
> `std::enable_if` gymnastics). He's talking specifically and only about=20
> terse syntax for declaring conceptualized template functions.
>
> He's saying that we're better off using explicit `requires` clauses than=
=20
> having shorter syntax. He's not saying that we're better off with=20
> `enable_if`".
>

Right. I, also, strongly support the new `requires` keyword, while being=20
skeptical of not only terse syntax but also Concepts Lite in general.
I highly recommend anyone interested in Concepts read these two short=20
position papers:

P0225 "Why I want Concepts, and why I want them sooner rather than later"=
=20
<https://isocpp.org/files/papers/p0225r0.html> (Ville Voutilainen, February=
=20
2016)
P0240 "Why I want Concepts, but why they should come later rather than=20
sooner"=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0240r0.html>=20
(Matt Calabrese, February 2016)

Ville's paper isn't really asking for Concepts, and certainly not for terse=
=20
syntax; he's asking *only* for the `requires` keyword (although he=20
conflates it with "Concepts" as a whole, because that was the=20
all-or-nothing zeitgeist at the time). Here's the benefits he lists:

   - [The `requires` keyword allows] constraining function arguments=20
   without turning off deduction and without disturbing the meta-arity of a=
=20
   constrained function template.
   - [The `requires` keyword makes] it much easier to write overloads with=
=20
   mutually exclusive constraints.
   - [The `requires` keyword enables] a broad range of constraint designs,=
=20
   giving the interface designer various tools to decide what sort of=20
   abstractions a particular interface needs.

Matt's paper is also asking for the `requires` keyword, but asking=20
specifically that we try not to conflate the `requires` keyword with the=20
much more controversial and less-fully-baked `concept` keyword.

And of course if `concept` itself isn't fully baked yet, naturally no terse=
=20
syntax based on `concept` can be!  But, at the same time, that doesn't mean=
=20
that we can't *discuss* things like terse syntax and so on. Most people=20
agree that the *abstract goal* is nice; it's just that no good *technical=
=20
means* has yet been devised to get us there.

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/58240ed1-4004-4b2e-8b70-98387b141c10%40isocpp.or=
g.

------=_Part_8551_519925942.1530232409244
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, June 28, 2018 at 10:40:14 AM UTC-7, Nicol Bol=
as wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>I make no defense of the OP&#39;s argument, but he is not talking stating =
that we shouldn&#39;t have concepts <i>at all</i> (and thus must continue t=
o use `std::enable_if` gymnastics). He&#39;s talking specifically and only =
about terse syntax for declaring conceptualized template functions.</div><d=
iv><br></div><div>He&#39;s saying that we&#39;re better off using explicit =
`requires` clauses than having shorter syntax. He&#39;s not saying that we&=
#39;re better off with `enable_if`&quot;.</div></div></blockquote><div><br>=
</div><div>Right. I, also, strongly support the new `requires` keyword, whi=
le being skeptical of not only terse syntax but also Concepts Lite in gener=
al.</div><div>I highly recommend anyone interested in Concepts read these t=
wo short position papers:</div><div><br></div><div><a href=3D"https://isocp=
p.org/files/papers/p0225r0.html">P0225 &quot;Why I want Concepts, and why I=
 want them sooner rather than later&quot;</a>=C2=A0(Ville Voutilainen, Febr=
uary 2016)<br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2016/p0240r0.html">P0240 &quot;Why I want Concepts, but why the=
y should come later rather than sooner&quot;</a> (Matt Calabrese, February =
2016)</div><div><br></div><div>Ville&#39;s paper isn&#39;t really asking fo=
r Concepts, and certainly not for terse syntax; he&#39;s asking <i><b>only<=
/b></i> for the `requires` keyword (although he conflates it with &quot;Con=
cepts&quot; as a whole, because that was the all-or-nothing zeitgeist at th=
e time). Here&#39;s the benefits he lists:</div><div><a name=3D"ConceptsAre=
Superior" style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-fam=
ily: -webkit-standard;"><ul><li style=3D"text-align: justify;">[The `requir=
es` keyword allows] constraining function arguments without turning off ded=
uction and without disturbing the meta-arity of a constrained function temp=
late.</li><li style=3D"text-align: justify;">[The `requires` keyword makes]=
 it much easier to write overloads with mutually exclusive constraints.</li=
><li style=3D"text-align: justify;">[The `requires` keyword enables] a broa=
d range of constraint designs, giving the interface designer various tools =
to decide what sort of abstractions a particular interface needs.</li></ul>=
</a></div><div>Matt&#39;s paper is also asking for the `requires` keyword, =
but asking specifically that we try not to conflate the `requires` keyword =
with the much more controversial and less-fully-baked `concept` keyword.<br=
></div><div><br></div><div>And of course if `concept` itself isn&#39;t full=
y baked yet, naturally no terse syntax based on `concept` can be! =C2=A0But=
, at the same time, that doesn&#39;t mean that we can&#39;t <i>discuss</i> =
things like terse syntax and so on. Most people agree that the <i>abstract =
goal</i> is nice; it&#39;s just that no good <i>technical means</i> has yet=
 been devised to get us there.</div><div><br></div><div>=E2=80=93Arthur</di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/58240ed1-4004-4b2e-8b70-98387b141c10%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/58240ed1-4004-4b2e-8b70-98387b141c10=
%40isocpp.org</a>.<br />

------=_Part_8551_519925942.1530232409244--

------=_Part_8550_892626000.1530232409244--

.