------=_Part_4778_1788107929.1529954428995
Content-Type: multipart/alternative;
 boundary="----=_Part_4779_105089167.1529954428996"

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

Concept type-name introducer is a proposed new mechanism to introduce=20
multiple template arguments with a single expression

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

or eventually=20

template<Mergeable{In,In2,Out}>
Out merge(In, In2, Out);

In any case the result will be the same as

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

The main motivation for an introducer is to "reduce the verbosity of=20
requires clause".
Second motivation is that "this concept type name introducer is necessary=
=20
to avoid cut&paste and macros."

However, the main motivation is served *not* by the introducer itself, but=
=20
by introduction of tailored concepts.
The second motivation is understandable - if we have such a repeated=20
pattern some people might use a macro and others will cut and paste.=20

That said, the name introducers come with problems on their own.

   - Completely new syntax that needs learning. A bit better with=20
   template<> as it is already the place for name introduction.=20
   - New syntax not for a new feature!
   - Completely "flat" and inflexible - no composition or decomposition. As=
=20
   a result all type information about the names is actually always hidden.=
 A=20
   bit better in the template<> variant, because one can add other=20
   names/constrains.=20
   - Extremely confusing "dual use" of concepts - sometimes they look like=
=20
   a template instantiation, sometimes they look like something b/w=20
   initializer list and structured bindings.
   - The syntax visually overloads already quite common syntax -=20
   Something{}, class Something{};

Given all this, the difference b/w standard notation with tailored concept=
=20
VS name introducer does not seem big and significant enough.

Still, undeniably there is repetition that might lead to some errors.
Can we have minimum solution to that alone? Can we make template<> optional=
=20
if requires is used?

In other words

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

Will introduce In, In2 and Out.=20

It seems plausible.=20
The main problem are name collisions - if some of the names are already=20
defined in the enclosing scope.

using Out =3D =E2=80=A6;

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

Let's investigate.

Can we use the previous name instead of introducing our own. Of course not.
Can we ignore the previous name. It depends.

Consider

using Num =3D =E2=80=A6;

requires Number<Num>
Num max(Num, Num);

Here we can! We introduce a new Num and that is always correct.

However

using MyClass =3D =E2=80=A6;

requires Assignable<Class, MyClass>
auto func(Class);

How about here?=20
Can we still blindly override? No, obviously.=20
Can we be "smart" and use only the type that is not already defined? No,=20
because at any point someone might define Class and change the meaning,=20
hell the definition, of our function.=20

We can only fail to compile.=20
What can we further do, what are the resolutions.

*A.* Do nothing. This variant is not that unacceptable. First, name=20
collision is highly unlikely IF we only intend to define local names (as=20
introducers do).
Consider, Mergeable<In,In2,Out>, these are perfectly acceptable local=20
names, yet terrible names to put in global/namespace scope!
In other words, if we stop just here, we only lose the ability to use=20
already defined types (introducers can't have that either), but this can=20
easily be worked around with a (sub-)tailored concept!
=20
requires AssignableToMyClass<Class>
auto func(Class);

Done.=20
At this point however we are still waaay more powerful then simple=20
introducer, as we have most of the requires clause powers!

requires Assignable<Value_type<It>> *//< note we use concepts inline, *
    || Something<It> *//< we can OR them and so on. *
auto func(It);

We have almost full control over the concept(s) we want to use as "terse".=
=20
This is a massive win.

*B.* If we find the do-nothing not good enough, we have to introduce some=
=20
syntactical hints.

Two options=20

*Var 1.* Mark the *names* we introduce.=20

requires Assignable<typename Class, MyClass>
auto func(Class);

or, to be terse

requires Assignable<{Class}, MyClass>
auto func(Class);

*Var 2.* Mark the *types* we use.=20

requires Assignable<Class, using MyClass>
auto func(Class);

Note that this is needed *IFF*, MyClass is user-defined type (not std type)=
=20
AND the concept has multiple arguments AND the type is in the same scope.

By example

using MyClass =3D =E2=80=A6;

requires Concept<MyClass> //< OK, one argument, introduces=20
template<typename MyClass>
MyClass max(MyClass, MyClass);=20

MyClass max(MyClass, MyClass)=20
    requires Concept<MyClass>; //< OK, NOT a template, just constrained=20
function=20

requires Assignable<Class, int> //< OK, std type
auto func(Class);

requires Assignable<Class, size_t> //< OK, std type
auto func(Class);

requires Assignable<Class, std::string> //< OK, different scope
auto func(Class);

requires Concept<Class> && Assignable<Class, MyClass> //< OK with Var 1 onl=
y
auto func(Class);

requires Assignable<Class, MyClass> //< error, need to pin either the name=
=20
(Var 1) or the type (Var 2)
auto func(Class);


What the advantages of is B. ?=20

Well, it let us have the *full* power of requires.

On a practical level, assuming tailored concepts are used to eliminate=20
verbosity, we can have tailored concepts that accept type arguments.=20
This is not a small win, as we eliminate a bunch of sub-tailored concepts=
=20
like AssignableToMyClass.

Needless to say nether composition nor type arguments are possible with=20
current name introducers.=20

Between *Var 1* and *Var 2*, which one is better.=20
*Var 1* has the advantage that one can write a clause, immune to outside=20
name introductions as it can pin names. It can also take advantage of=20
names, already introduced.=20
Main disadvantage is that, if terse syntax is not introduced, it can become=
=20
verbose.

*Var 2 *has the advantage that statistically, use of outside types in=20
introducing concepts is rare. Even if types are used, the number of=20
introduced names will probably be more then types.=20
In that sense Var 2 is completely minimalistic - you rarely have to write=
=20
it and you write less.=20
Another advantage is that there is no optional syntax - name is either=20
implicitly introduced or explicitly used as type. There are no unpinned=20
types (fails to compile), where in Var 1 one can have both optionally and i=
mplicitly=20
pinned names.
The main disadvantage is that you have to use standard notation instead in=
=20
order to really pin names.

That is pretty much it.=20

I believe it is a viable take, as we introduce *less* and gain *more* and=
=20
the disadvantages (some collision) seem to be not a big problem in practice=
=20
(local names are not good namespace-scope names)=20

Feedback is welcome=20

P.S Only concepts introduce names, not arbitrary expression like sizeof(T) =
or=20
constexpr functions.

--=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/0c0da3b7-02f4-4130-9441-5a1385864d39%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>Concept type-name introducer is a proposed new mechan=
ism to introduce multiple template arguments with a single expression</div>=
<div><br></div><div><font face=3D"courier new,monospace">Mergeable{In,In2,O=
ut}<br>Out merge(In, In2, Out);</font></div><div><font face=3D"courier new,=
monospace"></font><br></div><div>or eventually=C2=A0</div><div><font face=
=3D"courier new,monospace"></font><br></div><div><font face=3D"courier new,=
monospace">template&lt;Mergeable{In,In2,Out}&gt;<br>Out merge(In, In2, Out)=
;</font></div><div><font face=3D"courier new,monospace"></font><br></div><d=
iv>In any case the result will be the same as</div><div><font face=3D"couri=
er new,monospace"></font><br></div><div><font face=3D"courier new,monospace=
">template&lt;class In, class In2, class Out&gt;<br>=C2=A0 requires Mergeab=
le&lt;In,In2,Out&gt;<br>Out merge(In, In2, Out);</font></div><div><font fac=
e=3D"courier new,monospace"></font><br>The main motivation for an introduce=
r is to &quot;reduce the verbosity of requires clause&quot;.</div><div>Seco=
nd motivation is that &quot;this concept type name introducer is necessary =
to avoid cut&amp;paste and macros.&quot;</div><div><br></div><div>However, =
the main motivation is served <i>not</i> by the introducer itself, but by i=
ntroduction of tailored concepts.<br>The second motivation is understandabl=
e - if we have such a repeated pattern some people might use a macro and ot=
hers will cut and paste.=C2=A0</div><div><br></div><div>That said, the name=
 introducers come with problems on their own.<br></div><ul><li>Completely n=
ew syntax that needs learning. A bit better with template&lt;&gt; as it is =
already the place for name introduction.=C2=A0<br></li><li>New syntax not f=
or a new feature!<br></li><li>Completely &quot;flat&quot; and inflexible - =
no composition or decomposition. As a result all type information about the=
 names is actually always hidden. A bit better in the template&lt;&gt; vari=
ant, because one can add other names/constrains. <br></li><li>Extremely con=
fusing &quot;dual use&quot; of concepts - sometimes they look like a templa=
te instantiation, sometimes they look like something b/w initializer list a=
nd structured bindings.<br></li><li>The syntax visually overloads already q=
uite common syntax - Something{}, class Something{};</li></ul><div>Given al=
l this, the difference b/w standard notation with tailored concept VS name =
introducer does not seem big and significant enough.</div><div><br>Still, u=
ndeniably there is repetition that might lead to some errors.</div><div>Can=
 we have minimum solution to that alone? Can we make <font face=3D"courier =
new,monospace">template&lt;&gt;</font> optional if <font face=3D"courier ne=
w,monospace">requires</font> is used?</div><div><br></div><div>In other wor=
ds</div><div><br></div><div><font face=3D"courier new,monospace">requires M=
ergeable&lt;In,In2,Out&gt;<br>Out merge(In, In2, Out);</font></div><div><fo=
nt face=3D"courier new,monospace"><br></font></div><div>Will introduce <fon=
t face=3D"courier new,monospace">In</font>, <font face=3D"courier new,monos=
pace">In2</font> and <font face=3D"courier new,monospace">Out</font>.=C2=A0=
</div><div><br></div><div>It seems plausible. <br>The main problem are name=
 collisions - if some of the names are already defined in the enclosing sco=
pe.</div><div><br></div><div><font face=3D"courier new,monospace">using Out=
 =3D =E2=80=A6;</font></div><div><font face=3D"courier new,monospace"></fon=
t><br></div><div><font face=3D"courier new,monospace">requires Mergeable&lt=
;In,In2,Out&gt;<br>Out merge(In, In2, Out);</font></div><div><br></div><div=
>Let&#39;s investigate.</div><div><br></div><div>Can we use the previous na=
me instead of introducing our own. Of course not.<br>Can we ignore the prev=
ious name. It depends.</div><div><br></div><div>Consider</div><div><font fa=
ce=3D"courier new,monospace"></font><br></div><div><font face=3D"courier ne=
w,monospace">using Num =3D =E2=80=A6;</font></div><div><font face=3D"courie=
r new,monospace"></font><br></div><div><font face=3D"courier new,monospace"=
>requires Number&lt;Num&gt;<br>Num max(Num, Num);</font></div><div><font fa=
ce=3D"courier new,monospace"></font><br>Here we can! We introduce a new <fo=
nt face=3D"courier new,monospace">Num</font><font face=3D"arial,sans-serif"=
> and that is always correct.</font></div><div><font face=3D"courier new,mo=
nospace"></font><font face=3D"arial,sans-serif"></font><br></div><div>Howev=
er</div><div><br></div><div><font face=3D"courier new,monospace">using MyCl=
ass =3D =E2=80=A6;</font></div><div><font face=3D"courier new,monospace"><b=
r></font></div><div><font face=3D"courier new,monospace">requires Assignabl=
e&lt;Class, MyClass&gt;</font><br></div><div><font face=3D"courier new,mono=
space">auto func(Class);</font></div><div><font face=3D"courier new,monospa=
ce"><br></font></div><div>How about here? </div><div>Can we still blindly o=
verride? No, obviously. <br>Can we be &quot;smart&quot; and use only the ty=
pe that is not already defined? No, because at any point someone might defi=
ne <font face=3D"courier new,monospace">Class</font> and change the meaning=
, hell the definition, of our function.=C2=A0</div><div><br></div><div>We c=
an only fail to compile.=C2=A0<br></div><div>What can we further do, what a=
re the resolutions.</div><div><br></div><div><b>A.</b> Do nothing. This var=
iant is not that unacceptable. First, name collision is highly unlikely IF =
we only intend to define local names (as introducers do).<br>Consider, <fon=
t face=3D"courier new,monospace">Mergeable&lt;In,In2,Out&gt;</font>, these =
are perfectly acceptable local names, yet terrible names to put in global/n=
amespace scope!<br>In other words, if we stop just here, we only lose the a=
bility to use already defined types (introducers can&#39;t have that either=
), but this can easily be worked around with a (sub-)tailored concept!<br>=
=C2=A0<br><font face=3D"courier new,monospace">requires AssignableToMyClass=
&lt;Class&gt;<br>auto func(Class);</font></div><div><font face=3D"courier n=
ew,monospace"><br></font></div><div>Done. <br>At this point however we are =
still waaay more powerful then simple introducer, as we have most of the re=
quires clause powers!</div><div><br></div><div><font face=3D"courier new,mo=
nospace">requires Assignable&lt;Value_type&lt;It&gt;&gt; <i>//&lt; note we =
use concepts inline,=C2=A0</i><br>=C2=A0 =C2=A0 || Something&lt;It&gt; <i>/=
/&lt; we can OR them and so on. </i><br>auto func(It);</font></div><div><fo=
nt face=3D"courier new,monospace"><br></font></div><div>We have almost full=
 control over the concept(s) we want to use as &quot;terse&quot;. This is a=
 massive win.</div><div><br></div><div><b>B.</b> If we find the do-nothing =
not good enough, we have to introduce some syntactical hints.</div><div><br=
>Two options=C2=A0</div><div><br></div><div><b>Var 1.</b> Mark the <i>names=
</i> we introduce.=C2=A0</div><div><font face=3D"courier new,monospace"></f=
ont><br></div><div><font face=3D"courier new,monospace">requires Assignable=
&lt;typename Class, MyClass&gt;<br>auto func(Class);</font></div><div><font=
 face=3D"courier new,monospace"><br></font></div><div>or, to be terse</div>=
<div><font face=3D"courier new,monospace"></font><br></div><div><font face=
=3D"courier new,monospace">requires Assignable&lt;{Class}, MyClass&gt;<br>a=
uto func(Class);</font></div><div><font face=3D"courier new,monospace"></fo=
nt><br><font face=3D"arial,sans-serif"><b>Var 2.</b></font> Mark the <i>typ=
es</i> we use.=C2=A0</div><div><br></div><div><font face=3D"courier new,mon=
ospace">requires Assignable&lt;Class, using MyClass&gt;<br>auto func(Class)=
;</font></div><div><font face=3D"courier new,monospace"></font><br></div><d=
iv>Note that this is needed <b>IFF</b>, MyClass is user-defined type (not s=
td type) AND the concept has multiple arguments AND the type is in the same=
 scope.</div><div><br></div><div>By example</div><div><font face=3D"courier=
 new,monospace"></font><br></div><div><font face=3D"courier new,monospace">=
using MyClass =3D =E2=80=A6;</font></div><div><font face=3D"courier new,mon=
ospace"><br></font></div><div><font face=3D"courier new,monospace">requires=
 Concept&lt;MyClass&gt; //&lt; OK, one argument, introduces template&lt;typ=
ename MyClass&gt;<br>MyClass max(MyClass, MyClass);=C2=A0</font></div><div>=
<font face=3D"courier new,monospace"><br></font></div><div><font face=3D"co=
urier new,monospace">MyClass max(MyClass, MyClass)=C2=A0</font></div><div><=
font face=3D"courier new,monospace">=C2=A0 =C2=A0 requires Concept&lt;MyCla=
ss&gt;; //&lt; OK, NOT a template, just constrained function=C2=A0</font></=
div><div><font face=3D"courier new,monospace"><br></font></div><div><font f=
ace=3D"courier new,monospace">requires Assignable&lt;Class, int&gt; //&lt; =
OK, std type<br>auto func(Class);</font></div><div><font face=3D"courier ne=
w,monospace"><br></font></div><div><font face=3D"courier new,monospace">req=
uires Assignable&lt;Class, size_t&gt; //&lt; OK, std type<br>auto func(Clas=
s);</font></div><div><font face=3D"courier new,monospace"><br></font></div>=
<div><font face=3D"courier new,monospace">requires Assignable&lt;Class, std=
::string&gt; //&lt; OK, different scope<br>auto func(Class);</font></div><d=
iv><font face=3D"courier new,monospace"><br></font></div><div><font face=3D=
"courier new,monospace"><span 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); display: inline; float: none; =
font-family: courier new,monospace; font-size: 13px; font-style: normal; fo=
nt-variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom=
: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; pa=
dding-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: 0=
px;">requires <span 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); display: inline; float: none; font-famil=
y: courier new,monospace; 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;">Conce=
pt&lt;Class&gt; &amp;&amp; </span>Assignable&lt;Class, MyClass&gt; //&lt; O=
K with Var 1 only</span><br style=3D"background-attachment: scroll; backgro=
und-clip: border-box; background-color: transparent; background-image: none=
; background-origin: padding-box; background-position-x: 0%; background-pos=
ition-y: 0%; background-repeat: repeat; background-size: auto; border-botto=
m-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0=
px; border-image-outset: 0; border-image-repeat: stretch; border-image-slic=
e: 100%; border-image-source: none; border-image-width: 1; border-left-colo=
r: 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-to=
p-width: 0px; color: rgb(34, 34, 34); font-family: courier new,monospace; f=
ont-size: 13px; font-style: normal; font-variant: normal; font-weight: 400;=
 height: auto; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px=
; margin-right: 0px; margin-top: 0px; min-width: 0px; orphans: 2; overflow:=
 visible; overflow-x: visible; overflow-y: visible; 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;"><span style=3D"b=
ackground-color: transparent; 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; color: rgb(34, 34, =
34); display: inline; float: none; font-family: courier new,monospace; font=
-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; le=
tter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0=
px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; pa=
dding-right: 0px; padding-top: 0px; text-align: left; text-decoration: none=
; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; w=
hite-space: normal; word-spacing: 0px;">auto func(Class);</span><b style=3D=
"background-attachment: scroll; background-clip: border-box; background-col=
or: transparent; background-image: none; background-origin: padding-box; ba=
ckground-position-x: 0%; background-position-y: 0%; background-repeat: repe=
at; background-size: auto; border-bottom-color: rgb(34, 34, 34); border-bot=
tom-style: none; border-bottom-width: 0px; border-image-outset: 0; border-i=
mage-repeat: stretch; border-image-slice: 100%; border-image-source: none; =
border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-styl=
e: 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); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34)=
; font-family: courier new,monospace; font-size: 13px; font-style: normal; =
font-variant: normal; font-weight: 700; height: auto; letter-spacing: norma=
l; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px=
; min-width: 0px; orphans: 2; overflow: visible; overflow-x: visible; overf=
low-y: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px;=
 padding-top: 0px; text-align: left; text-decoration: none; text-indent: 0p=
x; text-transform: none; -webkit-text-stroke-width: 0px; white-space: norma=
l; word-spacing: 0px;"></b><i style=3D"background-attachment: scroll; backg=
round-clip: border-box; background-color: transparent; background-image: no=
ne; background-origin: padding-box; background-position-x: 0%; background-p=
osition-y: 0%; background-repeat: repeat; background-size: auto; 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: courier new,monospace;=
 font-size: 13px; font-style: italic; font-variant: normal; font-weight: 40=
0; height: auto; letter-spacing: normal; margin-bottom: 0px; margin-left: 0=
px; margin-right: 0px; margin-top: 0px; min-width: 0px; orphans: 2; overflo=
w: visible; overflow-x: visible; overflow-y: visible; padding-bottom: 0px; =
padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; =
text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text=
-stroke-width: 0px; white-space: normal; word-spacing: 0px;"></i><u style=
=3D"background-attachment: scroll; background-clip: border-box; background-=
color: transparent; background-image: none; background-origin: padding-box;=
 background-position-x: 0%; background-position-y: 0%; background-repeat: r=
epeat; background-size: auto; 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; color: rgb(34, 34, =
34); font-family: courier new,monospace; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: 400; height: auto; letter-spacing: no=
rmal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: =
0px; min-width: 0px; orphans: 2; overflow: visible; overflow-x: visible; ov=
erflow-y: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0=
px; padding-top: 0px; text-align: left; text-decoration: underline; text-in=
dent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-spac=
e: normal; word-spacing: 0px;"></u><sub style=3D"background-color: transpar=
ent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; borde=
r-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-w=
idth: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; b=
order-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: courier=
 new,monospace; font-size: 9px; 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;"></sub><sup 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: courier new,monospace; font-size: 9px; font-style: n=
ormal; font-variant: normal; font-weight: 400; letter-spacing: normal; marg=
in-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orpha=
ns: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-=
top: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-t=
ransform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-s=
pacing: 0px;"></sup><strike 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: courier new,monospa=
ce; 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: line-through; text-indent: 0px; text-transform: none; -webkit-text-stro=
ke-width: 0px; white-space: normal; word-spacing: 0px;"></strike><b></b><i>=
</i><u></u><sub></sub><sup></sup><strike></strike><br></font></div><div><fo=
nt face=3D"courier new,monospace"><b></b><i></i><u></u><sub></sub><sup></su=
p><strike></strike><br></font></div><div><font face=3D"courier new,monospac=
e">requires Assignable&lt;Class, MyClass&gt; //&lt; error, need to pin eith=
er the name (Var 1) or the type (Var 2)<br>auto func(Class);</font></div><d=
iv><font face=3D"courier new,monospace"><br></font></div><div><font face=3D=
"courier new,monospace"><br></font></div><div>What the advantages of is B. =
?=C2=A0</div><div><br></div><div>Well, it let us have the <i>full</i> power=
 of <font face=3D"courier new,monospace">requires</font>.</div><div><br></d=
iv><div>On a practical level, assuming tailored concepts are used to elimin=
ate verbosity, we can have tailored concepts that accept type arguments. <b=
r>This is not a small win, as we eliminate a bunch of sub-tailored concepts=
 like <span style=3D"display: inline !important; float: none; background-co=
lor: transparent; color: rgb(34, 34, 34); font-family: courier new,monospac=
e; 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;">AssignableToMyClass</span>.</d=
iv><div><br></div><div>Needless to say nether composition nor type argument=
s are possible with current name introducers.=C2=A0</div><div><br></div><di=
v>Between <b>Var 1</b> and <b>Var 2</b>, which one is better. </div><div><b=
>Var 1</b> has the advantage that one can write a clause, immune to outside=
 name introductions as it can pin names. It can also take advantage of name=
s, already introduced.=C2=A0</div><div>Main disadvantage is that, if terse =
syntax is not introduced, it can become verbose.</div><div><br><b>Var 2 </b=
>has the advantage that statistically, use of outside types in introducing =
concepts is rare. Even if types are used, the number of introduced names wi=
ll probably be more then types. <br>In that sense Var 2 is completely minim=
alistic - you rarely have to write it and you write less. <br>Another advan=
tage is that there is no optional syntax - name is either implicitly introd=
uced or explicitly used as type. There are no unpinned types (fails to comp=
ile), where in Var 1 one can have both optionally and=C2=A0<span style=3D"d=
isplay: inline !important; float: none; background-color: transparent; colo=
r: 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-w=
eight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-deco=
ration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-w=
idth: 0px; white-space: normal; word-spacing: 0px;">implicitly </span>pinne=
d names.</div><div>The main disadvantage is that you have to use standard n=
otation instead in order to really pin names.</div><div><br></div><div>That=
 is pretty much it.=C2=A0</div><div><br>I believe it is a viable take, as w=
e introduce <i>less</i> and gain <i>more</i> and the disadvantages (some co=
llision) seem to be not a big problem in practice (local names are not good=
 namespace-scope names)=C2=A0</div><div><br></div><div>Feedback is welcome=
=C2=A0</div><div><br></div><div>P.S Only concepts introduce names, not arbi=
trary expression like <font face=3D"courier new,monospace">sizeof(T) </font=
>or <font face=3D"courier new,monospace">constexpr</font> functions.<br></d=
iv></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/0c0da3b7-02f4-4130-9441-5a1385864d39%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0c0da3b7-02f4-4130-9441-5a1385864d39=
%40isocpp.org</a>.<br />

------=_Part_4779_105089167.1529954428996--

------=_Part_4778_1788107929.1529954428995--

.

------=_Part_35007_1018032733.1529958163831
Content-Type: multipart/alternative;
 boundary="----=_Part_35008_1953636045.1529958163831"

------=_Part_35008_1953636045.1529958163831
Content-Type: text/plain; charset="UTF-8"



On Monday, June 25, 2018 at 3:20:29 PM UTC-4, mihailn...@gmail.com wrote:
>
> Concept type-name introducer is a proposed new mechanism to introduce
> multiple template arguments with a single expression
>
> Mergeable{In,In2,Out}
> Out merge(In, In2, Out);
>
> or eventually
>
> template<Mergeable{In,In2,Out}>
> Out merge(In, In2, Out);
>
> In any case the result will be the same as
>
> template<class In, class In2, class Out>
>   requires Mergeable<In,In2,Out>
> Out merge(In, In2, Out);
>
> The main motivation for an introducer is to "reduce the verbosity of
> requires clause".
> Second motivation is that "this concept type name introducer is necessary
> to avoid cut&paste and macros."
>
> However, the main motivation is served *not* by the introducer itself,
> but by introduction of tailored concepts.
> The second motivation is understandable - if we have such a repeated
> pattern some people might use a macro and others will cut and paste.
>
> That said, the name introducers come with problems on their own.
>
>    - Completely new syntax that needs learning. A bit better with
>    template<> as it is already the place for name introduction.
>    - New syntax not for a new feature!
>
> I don't think repeating the same criticism is helpful.

>
>    -
>    - Completely "flat" and inflexible - no composition or decomposition.
>    As a result all type information about the names is actually always hidden.
>    A bit better in the template<> variant, because one can add other
>    names/constrains.
>    - Extremely confusing "dual use" of concepts - sometimes they look
>    like a template instantiation, sometimes they look like something b/w
>    initializer list and structured bindings.
>    - The syntax visually overloads already quite common syntax -
>    Something{}, class Something{};
>
> Given all this, the difference b/w standard notation with tailored concept
> VS name introducer does not seem big and significant enough.
>
> Still, undeniably there is repetition that might lead to some errors.
> Can we have minimum solution to that alone? Can we make template<>
> optional if requires is used?
>
> In other words
>
> requires Mergeable<In,In2,Out>
> Out merge(In, In2, Out);
>
> Will introduce In, In2 and Out.
>

How is this not new syntax? Because it doesn't use a new symbol? It's using
existing symbols in new ways, just like {} does. For example:

1. `Name<...>` always means "specialize this template". But that's not
happening here. Or rather it is, but that's not *all* that's happening here.
2. `<>` doesn't declare identifiers without explaining what those
identifiers actually are. That is, without `typename`, `template`, or an
actual type's name.
3. This new form of `<>` only works in a `requires` clause.
4. `requires` now has a third meaning. It's similar to the original
meaning, but because it's applied as a prefix, it now performs double-duty
as a template header. At least `template<Mergable>` looks like a template
header.

--
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/288df009-04d7-404a-b1ed-07b6bd9a71a3%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, June 25, 2018 at 3:20:29 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"><div>Concept type-name introducer is a proposed new mechanism to =
introduce multiple template arguments with a single expression</div><div><b=
r></div><div><font face=3D"courier new,monospace">Mergeable{In,In2,Out}<br>=
Out merge(In, In2, Out);</font></div><div><font face=3D"courier new,monospa=
ce"></font><br></div><div>or eventually=C2=A0</div><div><font face=3D"couri=
er new,monospace"></font><br></div><div><font face=3D"courier new,monospace=
">template&lt;Mergeable{In,In2,Out}<wbr>&gt;<br>Out merge(In, In2, Out);</f=
ont></div><div><font face=3D"courier new,monospace"></font><br></div><div>I=
n any case the result will be the same as</div><div><font face=3D"courier n=
ew,monospace"></font><br></div><div><font face=3D"courier new,monospace">te=
mplate&lt;class In, class In2, class Out&gt;<br>=C2=A0 requires Mergeable&l=
t;In,In2,Out&gt;<br>Out merge(In, In2, Out);</font></div><div><font face=3D=
"courier new,monospace"></font><br>The main motivation for an introducer is=
 to &quot;reduce the verbosity of requires clause&quot;.</div><div>Second m=
otivation is that &quot;this concept type name introducer is necessary to a=
void cut&amp;paste and macros.&quot;</div><div><br></div><div>However, the =
main motivation is served <i>not</i> by the introducer itself, but by intro=
duction of tailored concepts.<br>The second motivation is understandable - =
if we have such a repeated pattern some people might use a macro and others=
 will cut and paste.=C2=A0</div><div><br></div><div>That said, the name int=
roducers come with problems on their own.<br></div><ul><li>Completely new s=
yntax that needs learning. A bit better with template&lt;&gt; as it is alre=
ady the place for name introduction.=C2=A0<br></li><li>New syntax not for a=
 new feature!<br></li></ul></div></blockquote><div>I don&#39;t think repeat=
ing the same criticism is helpful. <br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><ul><li></li><li>Completely &quot;flat&quot=
; and inflexible - no composition or decomposition. As a result all type in=
formation about the names is actually always hidden. A bit better in the te=
mplate&lt;&gt; variant, because one can add other names/constrains. <br></l=
i><li>Extremely confusing &quot;dual use&quot; of concepts - sometimes they=
 look like a template instantiation, sometimes they look like something b/w=
 initializer list and structured bindings.<br></li><li>The syntax visually =
overloads already quite common syntax - Something{}, class Something{};</li=
></ul><div>Given all this, the difference b/w standard notation with tailor=
ed concept VS name introducer does not seem big and significant enough.</di=
v><div><br>Still, undeniably there is repetition that might lead to some er=
rors.</div><div>Can we have minimum solution to that alone? Can we make <fo=
nt face=3D"courier new,monospace">template&lt;&gt;</font> optional if <font=
 face=3D"courier new,monospace">requires</font> is used?</div><div><br></di=
v><div>In other words</div><div><br></div><div><font face=3D"courier new,mo=
nospace">requires Mergeable&lt;In,In2,Out&gt;<br>Out merge(In, In2, Out);</=
font></div><div><font face=3D"courier new,monospace"><br></font></div><div>=
Will introduce <font face=3D"courier new,monospace">In</font>, <font face=
=3D"courier new,monospace">In2</font> and <font face=3D"courier new,monospa=
ce">Out</font>.=C2=A0</div></div></blockquote><div><br></div><div>How is th=
is not new syntax? Because it doesn&#39;t use a new symbol? It&#39;s using =
existing symbols in new ways, just like {} does. For example:<br></div><div=
><br></div><div>1. `Name&lt;...&gt;` always means &quot;specialize this tem=
plate&quot;. But that&#39;s not happening here. Or rather it is, but that&#=
39;s not <i>all</i> that&#39;s happening here.</div><div>2. `&lt;&gt;` does=
n&#39;t declare identifiers without explaining what those identifiers actua=
lly are. That is, without `typename`, `template`, or an actual type&#39;s n=
ame.</div><div>3. This new form of `&lt;&gt;` only works in a `requires` cl=
ause.<br></div><div>4. `requires` now has a third meaning. It&#39;s similar=
 to the original meaning, but because it&#39;s applied as a prefix, it now =
performs double-duty as a template header. At least `template&lt;Mergable&g=
t;` looks like a template header.<br></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/288df009-04d7-404a-b1ed-07b6bd9a71a3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/288df009-04d7-404a-b1ed-07b6bd9a71a3=
%40isocpp.org</a>.<br />

------=_Part_35008_1953636045.1529958163831--

------=_Part_35007_1018032733.1529958163831--

.

------=_Part_40047_1387266436.1529998461230
Content-Type: multipart/alternative;
 boundary="----=_Part_40048_604294831.1529998461231"

------=_Part_40048_604294831.1529998461231
Content-Type: text/plain; charset="UTF-8"



On Monday, June 25, 2018 at 11:22:43 PM UTC+3, Nicol Bolas wrote:
>
>
>
> On Monday, June 25, 2018 at 3:20:29 PM UTC-4, mihailn...@gmail.com wrote:
>>
>> Concept type-name introducer is a proposed new mechanism to introduce
>> multiple template arguments with a single expression
>>
>> Mergeable{In,In2,Out}
>> Out merge(In, In2, Out);
>>
>> or eventually
>>
>> template<Mergeable{In,In2,Out}>
>> Out merge(In, In2, Out);
>>
>> In any case the result will be the same as
>>
>> template<class In, class In2, class Out>
>>   requires Mergeable<In,In2,Out>
>> Out merge(In, In2, Out);
>>
>> The main motivation for an introducer is to "reduce the verbosity of
>> requires clause".
>> Second motivation is that "this concept type name introducer is necessary
>> to avoid cut&paste and macros."
>>
>> However, the main motivation is served *not* by the introducer itself,
>> but by introduction of tailored concepts.
>> The second motivation is understandable - if we have such a repeated
>> pattern some people might use a macro and others will cut and paste.
>>
>>

> That said, the name introducers come with problems on their own.
>>
>>    - Completely new syntax that needs learning. A bit better with
>>    template<> as it is already the place for name introduction.
>>    - New syntax not for a new feature!
>>
>> I don't think repeating the same criticism is helpful.
>

It is not the same. A syntax might be new, but not a radically new
construct, effectively unparsable without explanations and examples.
Event if for a new feature radically new syntax is to be questioned. But it
is not a new feature, that's the second problem.

>
>>    -
>>    - Completely "flat" and inflexible - no composition or decomposition.
>>    As a result all type information about the names is actually always hidden.
>>    A bit better in the template<> variant, because one can add other
>>    names/constrains.
>>    - Extremely confusing "dual use" of concepts - sometimes they look
>>    like a template instantiation, sometimes they look like something b/w
>>    initializer list and structured bindings.
>>    - The syntax visually overloads already quite common syntax -
>>    Something{}, class Something{};
>>
>> Given all this, the difference b/w standard notation with tailored
>> concept VS name introducer does not seem big and significant enough.
>>
>> Still, undeniably there is repetition that might lead to some errors.
>> Can we have minimum solution to that alone? Can we make template<>
>> optional if requires is used?
>>
>> In other words
>>
>> requires Mergeable<In,In2,Out>
>> Out merge(In, In2, Out);
>>
>> Will introduce In, In2 and Out.
>>
>
> How is this not new syntax? Because it doesn't use a new symbol? It's
> using existing symbols in new ways, just like {} does. For example:
>

No, {} is used in a new context, creating new *construct*. No new
constructs are created here, simply using-is-a-declaration.


>
> 1. `Name<...>` always means "specialize this template". But that's not
> happening here. Or rather it is, but that's not *all* that's happening
> here.
> 2. `<>` doesn't declare identifiers without explaining what those
> identifiers actually are. That is, without `typename`, `template`, or an
> actual type's name.
>

The same argument can be made about both name introducers and even
shorthand notation.

template<template<typename> class X> concept C2 = true;

template<C2 X> void f2(); *//< WTF is X, must look the concept*

I am willing to argue, this is actually more clear in that particular case:

requires C2<X> void f2(); *//< X is what is written b/w the <> of the
concept! *

The fact that a concept, which is a template,* is used as such* is a huge
plus for requires in general.


> 3. This new form of `<>` only works in a `requires` clause.
>

It is not about <>, it is exclusively about 'requires'.
Alternatively,  if we would feel better, might be template
Mergeable<In,In2,Out>  Out merge(In, In2, Out);.


> 4. `requires` now has a third meaning. It's similar to the original
> meaning, but because it's applied as a prefix, it now performs double-duty
> as a template header. At least `template<Mergable>` looks like a template
> header.
>

But requires is already part of the template header!


I don't see any of these particularly troubling.  Yes, there is some new
context-sensitive interpretation, which is still better then new syntax for
a bonus feature.

But lets equate the new syntax (introducers) to these new rules in terms of
how troubling they are.* These new rules give us more power, full power*.
They also eliminate the question "what is a name introducer". This topic no
longer exist. Yes, new question arises - where are these template arguments
coming from, but that is a trivial question to answer.

--
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/fcb7c273-e0ea-4adb-a529-4c17bd06d29c%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, June 25, 2018 at 11:22:43 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 Monday, June 25, 2018 at 3:20:29 PM UTC-4, <a>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>Concept type-name introducer is a proposed new mechanism to introduce mul=
tiple template arguments with a single expression</div><div><br></div><div>=
<font face=3D"courier new,monospace">Mergeable{In,In2,Out}<br>Out merge(In,=
 In2, Out);</font></div><div><font face=3D"courier new,monospace"></font><b=
r></div><div>or eventually=C2=A0</div><div><font face=3D"courier new,monosp=
ace"></font><br></div><div><font face=3D"courier new,monospace">template&lt=
;Mergeable{In,In2,Out}<wbr>&gt;<br>Out merge(In, In2, Out);</font></div><di=
v><font face=3D"courier new,monospace"></font><br></div><div>In any case th=
e result will be the same as</div><div><font face=3D"courier new,monospace"=
></font><br></div><div><font face=3D"courier new,monospace">template&lt;cla=
ss In, class In2, class Out&gt;<br>=C2=A0 requires Mergeable&lt;In,In2,Out&=
gt;<br>Out merge(In, In2, Out);</font></div><div><font face=3D"courier new,=
monospace"></font><br>The main motivation for an introducer is to &quot;red=
uce the verbosity of requires clause&quot;.</div><div>Second motivation is =
that &quot;this concept type name introducer is necessary to avoid cut&amp;=
paste and macros.&quot;</div><div><br></div><div>However, the main motivati=
on is served <i>not</i> by the introducer itself, but by introduction of ta=
ilored concepts.<br>The second motivation is understandable - if we have su=
ch a repeated pattern some people might use a macro and others will cut and=
 paste.=C2=A0</div><div><br></div></div></blockquote></div></blockquote><di=
v>=C2=A0</div><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"=
><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></div><div>T=
hat said, the name introducers come with problems on their own.<br></div><u=
l><li>Completely new syntax that needs learning. A bit better with template=
&lt;&gt; as it is already the place for name introduction.=C2=A0<br></li><l=
i>New syntax not for a new feature!<br></li></ul></div></blockquote><div>I =
don&#39;t think repeating the same criticism is helpful. <br></div></div></=
blockquote><div><br></div><div>It is not the same. A syntax might be new, b=
ut not a radically new construct, effectively unparsable without explanatio=
ns and examples.</div><div>Event if for a new feature radically new syntax =
is to be questioned. But it is not a new feature, that&#39;s the second pro=
blem. =C2=A0</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><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"><u=
l><li></li><li>Completely &quot;flat&quot; and inflexible - no composition =
or decomposition. As a result all type information about the names is actua=
lly always hidden. A bit better in the template&lt;&gt; variant, because on=
e can add other names/constrains. <br></li><li>Extremely confusing &quot;du=
al use&quot; of concepts - sometimes they look like a template instantiatio=
n, sometimes they look like something b/w initializer list and structured b=
indings.<br></li><li>The syntax visually overloads already quite common syn=
tax - Something{}, class Something{};</li></ul><div>Given all this, the dif=
ference b/w standard notation with tailored concept VS name introducer does=
 not seem big and significant enough.</div><div><br>Still, undeniably there=
 is repetition that might lead to some errors.</div><div>Can we have minimu=
m solution to that alone? Can we make <font face=3D"courier new,monospace">=
template&lt;&gt;</font> optional if <font face=3D"courier new,monospace">re=
quires</font> is used?</div><div><br></div><div>In other words</div><div><b=
r></div><div><font face=3D"courier new,monospace">requires Mergeable&lt;In,=
In2,Out&gt;<br>Out merge(In, In2, Out);</font></div><div><font face=3D"cour=
ier new,monospace"><br></font></div><div>Will introduce <font face=3D"couri=
er new,monospace">In</font>, <font face=3D"courier new,monospace">In2</font=
> and <font face=3D"courier new,monospace">Out</font>.=C2=A0</div></div></b=
lockquote><div><br></div><div>How is this not new syntax? Because it doesn&=
#39;t use a new symbol? It&#39;s using existing symbols in new ways, just l=
ike {} does. For example:<br></div></div></blockquote><div><br></div><div>N=
o, {} is used in a new context, creating new <i>construct</i>. No new const=
ructs are created here, simply using-is-a-declaration.=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=
></div><div><br></div><div>1. `Name&lt;...&gt;` always means &quot;speciali=
ze this template&quot;. But that&#39;s not happening here. Or rather it is,=
 but that&#39;s not <i>all</i> that&#39;s happening here.</div><div>2. `&lt=
;&gt;` doesn&#39;t declare identifiers without explaining what those identi=
fiers actually are. That is, without `typename`, `template`, or an actual t=
ype&#39;s name.=C2=A0</div></div></blockquote><div>=C2=A0</div><div>The sam=
e argument can be made about both name introducers and even shorthand notat=
ion.</div><div><font face=3D"courier new,monospace"></font><br></div><div><=
font face=3D"courier new,monospace">template&lt;template&lt;typename&gt; cl=
ass X&gt; concept C2 =3D true;</font></div><div><font face=3D"courier new,m=
onospace"><br></font></div><div><font face=3D"courier new,monospace">templa=
te&lt;C2 X&gt; void f2(); <i>//&lt; WTF is X, must look the concept</i></fo=
nt></div><div><i></i><br></div><div>I am willing to argue, this is actually=
 more clear in that particular case:</div><div><b></b><i></i><u></u><sub></=
sub><sup></sup><strike></strike><br></div><div><font face=3D"courier new,mo=
nospace">requires C2&lt;X&gt; void f2(); <i>//&lt;=C2=A0<span style=3D"text=
-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0p=
x; letter-spacing: normal; font-family: courier new,monospace; font-size: 1=
3px; font-variant: normal; font-weight: 400; text-decoration: none; word-sp=
acing: 0px; display: inline !important; white-space: normal; orphans: 2; fl=
oat: none; -webkit-text-stroke-width: 0px; background-color: transparent;">=
X is what is written b/w the &lt;&gt; of the concept!=C2=A0</span></i></fon=
t><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, 3=
4); 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-to=
p-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; co=
lor: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helv=
etica&amp;quot;,sans-serif; 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;"><br=
></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;=
">The fact that a concept, which is a template,<i> is used as such</i> is a=
 huge plus for=C2=A0<span style=3D"display: inline !important; float: none;=
 background-color: transparent; color: rgb(34, 34, 34); font-family: courie=
r new,monospace; font-size: 13px; font-style: normal; font-variant: normal;=
 font-weight: 400; letter-spacing: normal; orphans: 2; 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;">requires <font f=
ace=3D"arial,sans-serif">in general.</font></span></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>3. T=
his new form of `&lt;&gt;` only works in a `requires` clause.<br></div></di=
v></blockquote><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;"><br></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;">It is not about &lt;&gt;, it is exclusively about &#39;=
requires&#39;.=C2=A0<br style=3D"background-attachment: scroll; background-=
clip: border-box; background-color: transparent; background-image: none; ba=
ckground-origin: padding-box; background-position-x: 0%; background-positio=
n-y: 0%; background-repeat: repeat; background-size: auto; 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; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&a=
mp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; height: auto; marg=
in-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-w=
idth: 0px; overflow: visible; overflow-x: visible; overflow-y: visible; pad=
ding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"=
></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;=
">Alternatively,=C2=A0 if we would feel better, might be <span style=3D"bac=
kground-color: transparent; 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; color: rgb(34, 34, 34=
); display: inline; float: none; font-family: courier new,monospace; 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;">template Mergeable&lt;In,In2,Out&gt;<=
font face=3D"&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif" style=3D"b=
order-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bott=
om-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border=
-image-slice: 100%; border-image-source: none; border-image-width: 1; borde=
r-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-rig=
ht: 0px; padding-top: 0px;">=C2=A0 </font></span><span style=3D"background-=
color: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-sty=
le: none; border-bottom-width: 0px; border-image-outset: 0; border-image-re=
peat: 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); b=
order-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); displ=
ay: inline; float: none; font-family: courier new,monospace; font-size: 13p=
x; font-style: normal; font-variant: normal; font-weight: 400; letter-spaci=
ng: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin=
-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-righ=
t: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-ind=
ent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space=
: normal; word-spacing: 0px;">Out merge(In, In2, Out);<font face=3D"arial,s=
ans-serif" style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-sty=
le: none; border-bottom-width: 0px; border-image-outset: 0; border-image-re=
peat: 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); b=
order-top-style: none; border-top-width: 0px; margin-bottom: 0px; margin-le=
ft: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-l=
eft: 0px; padding-right: 0px; padding-top: 0px;">.</font></span></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-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-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&a=
mp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: nor=
mal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-l=
eft: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0=
px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: le=
ft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-=
text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">=C2=A0</di=
v></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>4. `requires` now has a third meaning. It&#39;s similar to the o=
riginal meaning, but because it&#39;s applied as a prefix, it now performs =
double-duty as a template header. At least `template&lt;Mergable&gt;` looks=
 like a template header.<br></div></div></blockquote><div>=C2=A0</div><div>=
But <font face=3D"courier new,monospace">requires</font> is already part of=
 the template header!</div><div>=C2=A0</div><div><br></div><div>I don&#39;t=
 see any of these particularly troubling.=C2=A0 Yes, there is some new cont=
ext-sensitive interpretation, which is still better then new syntax for a b=
onus feature.=C2=A0</div><div><br></div><div>But lets equate the new syntax=
 (introducers) to these new rules in terms of how troubling they are.<i> Th=
ese new rules give us more power, full power</i>.=C2=A0</div><div>They also=
 eliminate the question &quot;what is a name introducer&quot;. This topic n=
o longer exist. Yes, new question arises - where are these template argumen=
ts coming from, but that is a trivial question to answer.</div><div><br></d=
iv></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/fcb7c273-e0ea-4adb-a529-4c17bd06d29c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fcb7c273-e0ea-4adb-a529-4c17bd06d29c=
%40isocpp.org</a>.<br />

------=_Part_40048_604294831.1529998461231--

------=_Part_40047_1387266436.1529998461230--

.

This is a multi-part message in MIME format.

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

Outside the debate of the you-know-that syntax, I think this
demand is easy to fulfill.  I think we can allow multi-argument
constrained parameters like this:

    template <Mergeable In In2 Out, class Other>
    Out merge(In, In2, Out);

constrained-parameter:
  qualified-concept-name ... identifieropt
  qualified-concept-name identifieropt default-template-argumentopt
  <ins>qualified-concept-name consecutive-identifier-list</ins>

consecutive-identifier-list:
  identifier
  consecutive-identifier-list identifier

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On June 25, 2018 3:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, June 25, 2018 at 3:20:29 PM UTC-4, mihailn...@gmail.com wrote:
>
>> Concept type-name introducer is a proposed new mechanism to introduce mu=
ltiple template arguments with a single expression
>>
>> Mergeable{In,In2,Out}
>> Out merge(In, In2, Out);
>>
>> or eventually
>>
>> template<Mergeable{In,In2,Out}>
>> Out merge(In, In2, Out);
>>
>> In any case the result will be the same as
>>
>> template<class In, class In2, class Out>
>>   requires Mergeable<In,In2,Out>
>> Out merge(In, In2, Out);
>>
>> The main motivation for an introducer is to "reduce the verbosity of req=
uires clause".

--=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/GQT2wsDfpqpglaSteBw1YjqmaWWafx7K0teqMg6HatmMjaJA=
OTOvzypvGdi_PSVK4etKJDZMIwD5fNmV3rMaqQaKgVZ7relKQTkLFMEiKPk%3D%40miator.net=
..

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

<div>Outside the debate of the you-know-that syntax, I think this<br></div>=
<div>demand is easy to fulfill.&nbsp; I think we can allow multi-argument<b=
r></div><div>constrained parameters like this:<br></div><div><br></div><div=
>&nbsp;&nbsp;&nbsp; template &lt;Mergeable In In2 Out, class Other&gt;<br><=
/div><div>&nbsp; &nbsp; Out merge(In, In2, Out);<br></div><div><br></div><d=
iv>constrained-parameter:<br></div><div>&nbsp; qualified-concept-name ... i=
dentifier<span style=3D"font-size: 10px" class=3D"size">opt</span><br></div=
><div>&nbsp; qualified-concept-name identifieropt default-template-argument=
<span style=3D"font-size: 10px" class=3D"size">opt</span><br></div><div>&nb=
sp; &lt;ins&gt;qualified-concept-name consecutive-identifier-list&lt;/ins&g=
t;<br></div><div><br></div><div>consecutive-identifier-list:<br></div><div>=
&nbsp; identifier<br></div><div>&nbsp; consecutive-identifier-list identifi=
er</div><div><br></div><div class=3D"protonmail_signature_block"><div class=
=3D"protonmail_signature_block-user"><div>--<br></div><div><span>Zhihao Yua=
n, ID lichray<br>The best way to predict the future is to invent it.<br>___=
____________________________________________</span></div></div><div class=
=3D"protonmail_signature_block-proton protonmail_signature_block-empty"><br=
></div></div><div><br></div><div>=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90=E2=80=90=E2=80=90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=
=E2=80=90=E2=80=90=E2=80=90<br></div><div> On June 25, 2018 3:22 PM, Nicol =
Bolas &lt;jmckesson@gmail.com&gt; wrote:<br></div><div> <br></div><blockquo=
te class=3D"protonmail_quote" type=3D"cite"><div dir=3D"ltr"><div><br></div=
><div><br></div><div>On Monday, June 25, 2018 at 3:20:29 PM UTC-4, mihailn.=
...@gmail.com wrote:<br></div><blockquote style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;" class=3D"gmail_quote"><=
div dir=3D"ltr"><div>Concept type-name introducer is a proposed new mechani=
sm to introduce multiple template arguments with a single expression<br></d=
iv><div><br></div><div><span style=3D"font-family:courier new,monospace" cl=
ass=3D"font">Mergeable{In,In2,Out}<br>Out merge(In, In2, Out);</span></div>=
<div><span style=3D"font-family:courier new,monospace" class=3D"font"></spa=
n><br></div><div>or eventually&nbsp;<br></div><div><span style=3D"font-fami=
ly:courier new,monospace" class=3D"font"></span><br></div><div><span style=
=3D"font-family:courier new,monospace" class=3D"font">template&lt;Mergeable=
{In,In2,Out}<wbr>&gt;<br>Out merge(In, In2, Out);</span></div><div><span st=
yle=3D"font-family:courier new,monospace" class=3D"font"></span><br></div><=
div>In any case the result will be the same as<br></div><div><span style=3D=
"font-family:courier new,monospace" class=3D"font"></span><br></div><div><s=
pan style=3D"font-family:courier new,monospace" class=3D"font">template&lt;=
class In, class In2, class Out&gt;<br>&nbsp; requires Mergeable&lt;In,In2,O=
ut&gt;<br>Out merge(In, In2, Out);</span></div><div><div><span style=3D"fon=
t-family:courier new,monospace" class=3D"font"></span><br></div><div>The ma=
in motivation for an introducer is to "reduce the verbosity of requires cla=
use".<br></div></div></div></blockquote></div></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/GQT2wsDfpqpglaSteBw1YjqmaWWafx7K0teqM=
g6HatmMjaJAOTOvzypvGdi_PSVK4etKJDZMIwD5fNmV3rMaqQaKgVZ7relKQTkLFMEiKPk%3D%4=
0miator.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/GQT2wsDfpqpglaSteBw1YjqmaWWafx7K0teqM=
g6HatmMjaJAOTOvzypvGdi_PSVK4etKJDZMIwD5fNmV3rMaqQaKgVZ7relKQTkLFMEiKPk%3D%4=
0miator.net</a>.<br />

--b1_64ccf503d959fa7c47869f3f0ecbeaa8--


.

------=_Part_11255_41596325.1530096040786
Content-Type: multipart/alternative;
 boundary="----=_Part_11256_76445290.1530096040787"

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



On Wednesday, June 27, 2018 at 12:44:13 PM UTC+3, Zhihao Yuan wrote:
>
> Outside the debate of the you-know-that syntax, I think this
> demand is easy to fulfill.  I think we can allow multi-argument
> constrained parameters like this:
>
>     template <Mergeable In In2 Out, class Other>
>     Out merge(In, In2, Out);
>

I actually like that idea.=20

   - We can pretend "name introducers" do not exist as a sperate thing, a=
=20
   construct. You name the concept, after that you have to name all the typ=
es=20
   that are in the <> of that concept. That's it, nothing new to learn!
   - We go away from that "its an action", "it does something" feel of the=
=20
   introducers and the slight unease "is it Mergeable actually instantiated=
 in=20
   some way here?" Is Mergeable "called" in some way? Is this related to=20
   struct. bindings? Can I use <> in place of {} and vice versa?=20
   - We go away (for now) from=20
   all-powerful-alternative-syntax-for-templates (the in-place)
  =20
I believe this is the most natural evolution of the shorthand syntax. Of=20
course some will argue listing things without commas is weird, but the=20
alternatives are not better.=20



> constrained-parameter:
>   qualified-concept-name ... identifieropt
>   qualified-concept-name identifieropt default-template-argumentopt
>   <ins>qualified-concept-name consecutive-identifier-list</ins>
>
> consecutive-identifier-list:
>   identifier
>   consecutive-identifier-list identifier
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On June 25, 2018 3:22 PM, Nicol Bolas <jmck...@gmail.com <javascript:>>=
=20
> wrote:
>
>
>
> On Monday, June 25, 2018 at 3:20:29 PM UTC-4, mihailn...@gmail.com wrote:
>
>> Concept type-name introducer is a proposed new mechanism to introduce=20
>> multiple template arguments with a single expression
>>
>> Mergeable{In,In2,Out}
>> Out merge(In, In2, Out);
>>
>> or eventually=20
>>
>> template<Mergeable{In,In2,Out}>
>> Out merge(In, In2, Out);
>>
>> In any case the result will be the same as
>>
>> template<class In, class In2, class Out>
>>   requires Mergeable<In,In2,Out>
>> Out merge(In, In2, Out);
>>
>> The main motivation for an introducer is to "reduce the verbosity of=20
>> requires clause".
>>
>
>

--=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/34a5af76-3d9a-4dc6-8af7-6081cdb62b4c%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Wednesday, June 27, 2018 at 12:44:13 PM UTC+3, =
Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Outside=
 the debate of the you-know-that syntax, I think this<br></div><div>demand =
is easy to fulfill.=C2=A0 I think we can allow multi-argument<br></div><div=
>constrained parameters like this:<br></div><div><br></div><div>=C2=A0=C2=
=A0=C2=A0 template &lt;Mergeable In In2 Out, class Other&gt;<br></div><div>=
=C2=A0 =C2=A0 Out merge(In, In2, Out);<br></div></blockquote><div><br></div=
><div>I actually like that idea.=C2=A0</div><ul><li>We can pretend &quot;na=
me introducers&quot; do not exist as a sperate thing, a construct. You name=
 the concept, after that you have to name all the types that are in the &lt=
;&gt; of that concept. That&#39;s it, nothing new to learn!</li><li>We go a=
way from that &quot;its an action&quot;, &quot;it does something&quot; feel=
 of the introducers and the slight unease &quot;is it Mergeable actually in=
stantiated in some way here?&quot; Is Mergeable &quot;called&quot; in some =
way? Is this related to struct. bindings? Can I use &lt;&gt; in place of {}=
 and vice versa?=C2=A0</li><li>We go away (for now) from all-powerful-alter=
native-syntax-for-templates (the in-place)<br></li></ul><div>I believe this=
 is the most natural evolution of the shorthand syntax. Of course some will=
 argue listing things without commas is weird, but the alternatives are not=
 better.=C2=A0</div><div><br></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></div><div><br></div><div>constrained-parameter:<b=
r></div><div>=C2=A0 qualified-concept-name ... identifier<span style=3D"fon=
t-size:10px">opt</span><br></div><div>=C2=A0 qualified-concept-name identif=
ieropt default-template-argument<span style=3D"font-size:10px">opt</span><b=
r></div><div>=C2=A0 &lt;ins&gt;qualified-concept-name consecutive-identifie=
r-list&lt;/<wbr>ins&gt;<br></div><div><br></div><div>consecutive-identifier=
-list:<br></div><div>=C2=A0 identifier<br></div><div>=C2=A0 consecutive-ide=
ntifier-list identifier</div><div><br></div><div><div><div>--<br></div><div=
><span>Zhihao Yuan, ID lichray<br>The best way to predict the future is to =
invent it.<br>______________________________<wbr>_________________</span></=
div></div><div><br></div></div><div><br></div><div>=E2=80=90=E2=80=90=E2=80=
=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Message =E2=80=90=E2=80=90=
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90<br></div><div> On June 25, 20=
18 3:22 PM, Nicol Bolas &lt;<a onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-m=
ailto=3D"pjmRYOfNCAAJ">jmck...@gmail.com</a>&gt; wrote:<br></div><div> <br>=
</div><blockquote type=3D"cite"><div dir=3D"ltr"><div><br></div><div><br></=
div><div>On Monday, June 25, 2018 at 3:20:29 PM UTC-4, <a>mihailn...@gmail.=
com</a> wrote:<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>Concept type-name introducer is a proposed new mechanism to intr=
oduce multiple template arguments with a single expression<br></div><div><b=
r></div><div><span style=3D"font-family:courier new,monospace">Mergeable{In=
,In2,Out}<br>Out merge(In, In2, Out);</span></div><div><span style=3D"font-=
family:courier new,monospace"></span><br></div><div>or eventually=C2=A0<br>=
</div><div><span style=3D"font-family:courier new,monospace"></span><br></d=
iv><div><span style=3D"font-family:courier new,monospace">template&lt;Merge=
able{In,In2,Out}<wbr>&gt;<br>Out merge(In, In2, Out);</span></div><div><spa=
n style=3D"font-family:courier new,monospace"></span><br></div><div>In any =
case the result will be the same as<br></div><div><span style=3D"font-famil=
y:courier new,monospace"></span><br></div><div><span style=3D"font-family:c=
ourier new,monospace">template&lt;class In, class In2, class Out&gt;<br>=C2=
=A0 requires Mergeable&lt;In,In2,Out&gt;<br>Out merge(In, In2, Out);</span>=
</div><div><div><span style=3D"font-family:courier new,monospace"></span><b=
r></div><div>The main motivation for an introducer is to &quot;reduce the v=
erbosity of requires clause&quot;.<br></div></div></div></blockquote></div>=
</blockquote><div><br></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/34a5af76-3d9a-4dc6-8af7-6081cdb62b4c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/34a5af76-3d9a-4dc6-8af7-6081cdb62b4c=
%40isocpp.org</a>.<br />

------=_Part_11256_76445290.1530096040787--

------=_Part_11255_41596325.1530096040786--

.

------=_Part_52808_1526666365.1530133659065
Content-Type: multipart/alternative;
 boundary="----=_Part_52809_2041309359.1530133659065"

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

On Wednesday, June 27, 2018 at 5:44:13 AM UTC-4, Zhihao Yuan wrote:
>
> Outside the debate of the you-know-that syntax, I think this
> demand is easy to fulfill.  I think we can allow multi-argument
> constrained parameters like this:
>
>     template <Mergeable In In2 Out, class Other>
>     Out merge(In, In2, Out);
>
"Functions" whose arity are non-obvious are (in my opinion) an unfortunate=
=20
aspect of certain languages.

K&R C gives us the perfectly usable idea of a list of identifiers that=20
introduce parameters; it even allows further attributes of the parameters=
=20
to be declared afterwards:
int f(a, b, c)
  int a, b, c;
{ return a + b + c; }

Lines (statements ending in semicolons) could be used to apply constraints.

template <In, In2, Out, Other>
{ Mergeable <In, In2, Out>; typename Other; }
Out merge(In, In2, Out);

That is perhaps not as short, but still shorter than:
template <typename In, typename In2, typename Out, typename Other>
requires Mergeable<In, In2, Out>
Out merge(In, In2, Out);


> constrained-parameter:
>   qualified-concept-name ... identifieropt
>   qualified-concept-name identifieropt default-template-argumentopt
>   <ins>qualified-concept-name consecutive-identifier-list</ins>
>
> consecutive-identifier-list:
>   identifier
>   consecutive-identifier-list identifier
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On June 25, 2018 3:22 PM, Nicol Bolas <jmck...@gmail.com <javascript:>>=
=20
> wrote:
>
>
>
> On Monday, June 25, 2018 at 3:20:29 PM UTC-4, mihailn...@gmail.com wrote:
>
>> Concept type-name introducer is a proposed new mechanism to introduce=20
>> multiple template arguments with a single expression
>>
>> Mergeable{In,In2,Out}
>> Out merge(In, In2, Out);
>>
>> or eventually=20
>>
>> template<Mergeable{In,In2,Out}>
>> Out merge(In, In2, Out);
>>
>> In any case the result will be the same as
>>
>> template<class In, class In2, class Out>
>>   requires Mergeable<In,In2,Out>
>> Out merge(In, In2, Out);
>>
>> The main motivation for an introducer is to "reduce the verbosity of=20
>> requires clause".
>>
>
>

--=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/427de55b-9ff8-407f-802c-8902422d4746%40isocpp.or=
g.

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

<div dir=3D"ltr">On Wednesday, June 27, 2018 at 5:44:13 AM UTC-4, Zhihao Yu=
an wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Outside the deba=
te of the you-know-that syntax, I think this<br></div><div>demand is easy t=
o fulfill.=C2=A0 I think we can allow multi-argument<br></div><div>constrai=
ned parameters like this:<br></div><div><br></div><div>=C2=A0=C2=A0=C2=A0 t=
emplate &lt;Mergeable In In2 Out, class Other&gt;<br></div><div>=C2=A0 =C2=
=A0 Out merge(In, In2, Out);<br></div></blockquote><div>&quot;Functions&quo=
t; whose arity are non-obvious are (in my opinion) an unfortunate aspect of=
 certain languages.<br><br>K&amp;R C gives us the perfectly usable idea of =
a list of identifiers that introduce parameters; it even allows further att=
ributes of the parameters to be declared afterwards:<br><span style=3D"font=
-family: courier new,monospace;">int f(a, b, c)<br>=C2=A0 int a, b, c;<br>{=
 return a + b + c; }</span><br><br>Lines (statements ending in semicolons) =
could be used to apply constraints.<br><br><span style=3D"font-family: cour=
ier new,monospace;">template &lt;In, In2, Out, Other&gt;<br>{ Mergeable &lt=
;In, In2, Out&gt;; typename Other; }<br>Out merge(In, In2, Out);</span><br>=
<br>That is perhaps not as short, but still shorter than:<br><span style=3D=
"font-family: courier new,monospace;">template &lt;typename In, typename In=
2, typename Out, typename Other&gt;<br>requires Mergeable&lt;In, In2, Out&g=
t;<br>Out merge(In, In2, Out);</span><br><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></div><div><br></div><div>constrained-parameter:<=
br></div><div>=C2=A0 qualified-concept-name ... identifier<span style=3D"fo=
nt-size:10px">opt</span><br></div><div>=C2=A0 qualified-concept-name identi=
fieropt default-template-argument<span style=3D"font-size:10px">opt</span><=
br></div><div>=C2=A0 &lt;ins&gt;qualified-concept-name consecutive-identifi=
er-list&lt;/<wbr>ins&gt;<br></div><div><br></div><div>consecutive-identifie=
r-list:<br></div><div>=C2=A0 identifier<br></div><div>=C2=A0 consecutive-id=
entifier-list identifier</div><div><br></div><div><div><div>--<br></div><di=
v><span>Zhihao Yuan, ID lichray<br>The best way to predict the future is to=
 invent it.<br>______________________________<wbr>_________________</span><=
/div></div><div><br></div></div><div><br></div><div>=E2=80=90=E2=80=90=E2=
=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Message =E2=80=90=E2=80=
=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90<br></div><div> On June 25,=
 2018 3:22 PM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"pjmRYOfNCAAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javas=
cript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:<br></div><div> <=
br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div><br></div><div><br=
></div><div>On Monday, June 25, 2018 at 3:20:29 PM UTC-4, <a>mihailn...@gma=
il.com</a> wrote:<br></div><blockquote style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex" class=3D"gmail_quote"><div dir=
=3D"ltr"><div>Concept type-name introducer is a proposed new mechanism to i=
ntroduce multiple template arguments with a single expression<br></div><div=
><br></div><div><span style=3D"font-family:courier new,monospace">Mergeable=
{In,In2,Out}<br>Out merge(In, In2, Out);</span></div><div><span style=3D"fo=
nt-family:courier new,monospace"></span><br></div><div>or eventually=C2=A0<=
br></div><div><span style=3D"font-family:courier new,monospace"></span><br>=
</div><div><span style=3D"font-family:courier new,monospace">template&lt;Me=
rgeable{In,In2,Out}<wbr>&gt;<br>Out merge(In, In2, Out);</span></div><div><=
span style=3D"font-family:courier new,monospace"></span><br></div><div>In a=
ny case the result will be the same as<br></div><div><span style=3D"font-fa=
mily:courier new,monospace"></span><br></div><div><span style=3D"font-famil=
y:courier new,monospace">template&lt;class In, class In2, class Out&gt;<br>=
=C2=A0 requires Mergeable&lt;In,In2,Out&gt;<br>Out merge(In, In2, Out);</sp=
an></div><div><div><span style=3D"font-family:courier new,monospace"></span=
><br></div><div>The main motivation for an introducer is to &quot;reduce th=
e verbosity of requires clause&quot;.<br></div></div></div></blockquote></d=
iv></blockquote><div><br></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/427de55b-9ff8-407f-802c-8902422d4746%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/427de55b-9ff8-407f-802c-8902422d4746=
%40isocpp.org</a>.<br />

------=_Part_52809_2041309359.1530133659065--

------=_Part_52808_1526666365.1530133659065--

.

This is a multi-part message in MIME format.

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

I found that view making sense, but I would argue that the
arity of the template parameters in a function template is
the least useful arity to the readers... If I remember correctly
the standard library only includes a few interfaces which
require you to supply the first template argument (like T in
get<T>(x)), all the other template parameters are deduced.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On June 27, 2018 4:07 PM, <hubert.reinterpretcast@gmail.com> wrote:

> "Functions" whose arity are non-obvious are (in my opinion) an unfortunat=
e aspect of certain languages.
>
> K&R C gives us the perfectly usable idea of a list of identifiers that in=
troduce parameters; it even allows further attributes of the parameters to =
be declared afterwards:
> int f(a, b, c)
>   int a, b, c;
> { return a + b + c; }
>
> Lines (statements ending in semicolons) could be used to apply constraint=
s.
>
> template <In, In2, Out, Other>
> { Mergeable <In, In2, Out>; typename Other; }
> Out merge(In, 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/Of5rZP4au9H0lnbbyWCMbyRYhuI6W1qMdK_o0fSMwTogG6r2=
1lHVs0S1LbT8QUptTsZrJubPWLe3XhVRsVWpR7MpV5TkdnHy9k8-f21rKiA%3D%40miator.net=
..

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

<div>I found that view making sense, but I would argue that the<br></div><d=
iv>arity of the template parameters in a function template is<br></div><div=
>the least useful arity to the readers... If I remember correctly<br></div>=
<div>the standard library only includes a few interfaces which<br></div><di=
v>require you to supply the first template argument (like T in<br></div><di=
v>get&lt;T&gt;(x)), all the other template parameters are deduced.<br></div=
><div><br></div><div class=3D"protonmail_signature_block"><div class=3D"pro=
tonmail_signature_block-user"><div>--<br></div><div><span>Zhihao Yuan, ID l=
ichray<br>The best way to predict the future is to invent it.<br>__________=
_____________________________________</span></div></div><div class=3D"proto=
nmail_signature_block-proton protonmail_signature_block-empty"><br></div></=
div><div><br></div><div>=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90=E2=80=90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=
=E2=80=90=E2=80=90<br></div><div> On June 27, 2018 4:07 PM,  &lt;hubert.rei=
nterpretcast@gmail.com&gt; wrote:<br></div><div> <br></div><blockquote clas=
s=3D"protonmail_quote" type=3D"cite"><div dir=3D"ltr"><div>"Functions" whos=
e arity are non-obvious are (in my opinion) an unfortunate aspect of certai=
n languages.<br></div><div><div><br></div><div>K&amp;R C gives us the perfe=
ctly usable idea of a list of identifiers that introduce parameters; it eve=
n allows further attributes of the parameters to be declared afterwards:<br=
></div><div><span style=3D"font-family:courier new,monospace" class=3D"font=
">int f(a, b, c)<br>&nbsp; int a, b, c;<br>{ return a + b + c; }</span></di=
v><div><br></div><div>Lines (statements ending in semicolons) could be used=
 to apply constraints.<br></div><div><br></div><div><span style=3D"font-fam=
ily:courier new,monospace" class=3D"font">template &lt;In, In2, Out, Other&=
gt;<br>{ Mergeable &lt;In, In2, Out&gt;; typename Other; }<br>Out merge(In,=
 In2, Out);</span><br></div></div></div></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/Of5rZP4au9H0lnbbyWCMbyRYhuI6W1qMdK_o0=
fSMwTogG6r21lHVs0S1LbT8QUptTsZrJubPWLe3XhVRsVWpR7MpV5TkdnHy9k8-f21rKiA%3D%4=
0miator.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/Of5rZP4au9H0lnbbyWCMbyRYhuI6W1qMdK_o0=
fSMwTogG6r21lHVs0S1LbT8QUptTsZrJubPWLe3XhVRsVWpR7MpV5TkdnHy9k8-f21rKiA%3D%4=
0miator.net</a>.<br />

--b1_f7089b3c1091b7c2d36e28fd349d4022--


.

------=_Part_2415_1274319483.1530176073417
Content-Type: multipart/alternative;
 boundary="----=_Part_2416_1715642877.1530176073418"

------=_Part_2416_1715642877.1530176073418
Content-Type: text/plain; charset="UTF-8"



On Thursday, June 28, 2018 at 12:07:39 AM UTC+3, hubert.rein...@gmail.com
wrote:
>
> On Wednesday, June 27, 2018 at 5:44:13 AM UTC-4, Zhihao Yuan wrote:
>>
>> Outside the debate of the you-know-that syntax, I think this
>> demand is easy to fulfill.  I think we can allow multi-argument
>> constrained parameters like this:
>>
>>     template <Mergeable In In2 Out, class Other>
>>     Out merge(In, In2, Out);
>>
> "Functions" whose arity are non-obvious are (in my opinion) an unfortunate
> aspect of certain languages.
>
> K&R C gives us the perfectly usable idea of a list of identifiers that
> introduce parameters; it even allows further attributes of the parameters
> to be declared afterwards:
> int f(a, b, c)
>   int a, b, c;
> { return a + b + c; }
>
> Lines (statements ending in semicolons) could be used to apply constraints.
>
> template <In, In2, Out, Other>
> { Mergeable <In, In2, Out>; typename Other; }
> Out merge(In, In2, Out);
>

The idea is to be able to introduce the types entirely in terms of the
concepts they represent so there would be less chance of errors.
For instance someone might pass Other in the place of Out or swap In and
In2 (this might or might not be a problem) and so on.

In any case, if we don't care of the repetition

template <typename In, In2, Out, Other>
  requires Mergeable<In, In2, Out>
Out merge(In, In2, Out);

is the best option


>
> That is perhaps not as short, but still shorter than:
> template <typename In, typename In2, typename Out, typename Other>
> requires Mergeable<In, In2, Out>
> Out merge(In, 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/d15af942-2e06-4384-b1a5-0fc8cafcd00f%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, June 28, 2018 at 12:07:39 AM UTC+3, h=
ubert.rein...@gmail.com 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 Wednesday, June 27, 2018 at 5:44:13 AM UTC-4, Zhihao Yu=
an wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Outside the debate of=
 the you-know-that syntax, I think this<br></div><div>demand is easy to ful=
fill.=C2=A0 I think we can allow multi-argument<br></div><div>constrained p=
arameters like this:<br></div><div><br></div><div>=C2=A0=C2=A0=C2=A0 templa=
te &lt;Mergeable In In2 Out, class Other&gt;<br></div><div>=C2=A0 =C2=A0 Ou=
t merge(In, In2, Out);<br></div></blockquote><div>&quot;Functions&quot; who=
se arity are non-obvious are (in my opinion) an unfortunate aspect of certa=
in languages.<br><br>K&amp;R C gives us the perfectly usable idea of a list=
 of identifiers that introduce parameters; it even allows further attribute=
s of the parameters to be declared afterwards:<br><span style=3D"font-famil=
y:courier new,monospace">int f(a, b, c)<br>=C2=A0 int a, b, c;<br>{ return =
a + b + c; }</span><br><br>Lines (statements ending in semicolons) could be=
 used to apply constraints.<br><br><span style=3D"font-family:courier new,m=
onospace">template &lt;In, In2, Out, Other&gt;<br>{ Mergeable &lt;In, In2, =
Out&gt;; typename Other; }<br>Out merge(In, In2, Out);</span></div></div></=
blockquote><div><br></div><div>The idea is to be able to introduce the type=
s entirely in terms of the concepts they represent so there would be less c=
hance of errors.=C2=A0<br style=3D"background-attachment: scroll; backgroun=
d-clip: border-box; background-color: transparent; background-image: none; =
background-origin: padding-box; background-position-x: 0%; background-posit=
ion-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; 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; height: auto; ma=
rgin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min=
-width: 0px; overflow: visible; overflow-x: visible; overflow-y: visible; p=
adding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px=
;"></div><div><div style=3D"background-color: transparent; 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; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&a=
mp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal=
; font-variant: normal; font-weight: 400; letter-spacing: normal; margin-bo=
ttom: 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-transf=
orm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacin=
g: 0px;">For instance someone might pass Other in the place of Out or swap =
In and In2 (this might or might not be a problem) and so on.<br></div></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>In any ca=
se, if we don&#39;t care of the repetition</div><div><br></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;">template &lt;typename In, In2, Out, Other&g=
t;</span><br 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: courier new,monospace; 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;"><span style=3D"display: inline !important;=
 float: none; background-color: transparent; color: rgb(34, 34, 34); font-f=
amily: courier new,monospace; font-size: 13px; font-style: normal; font-var=
iant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-al=
ign: left; text-decoration: none; text-indent: 0px; text-transform: none; -=
webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">=C2=
=A0 requires Mergeable&lt;In, In2, Out&gt;</span><br 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: courier new,monospace; 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;"><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;">Out merge(In, In2, Out);</span><b></b>=
<i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><div><b></b>=
<i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><div>is the =
best option</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><br>That is perhaps not as short, but still sho=
rter than:<br><span style=3D"font-family:courier new,monospace">template &l=
t;typename In, typename In2, typename Out, typename Other&gt;<br>requires M=
ergeable&lt;In, In2, Out&gt;<br>Out merge(In, In2, Out);</span></div></div>=
</blockquote><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/d15af942-2e06-4384-b1a5-0fc8cafcd00f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d15af942-2e06-4384-b1a5-0fc8cafcd00f=
%40isocpp.org</a>.<br />

------=_Part_2416_1715642877.1530176073418--

------=_Part_2415_1274319483.1530176073417--

.

------=_Part_9481_974811298.1530240260377
Content-Type: multipart/alternative;
 boundary="----=_Part_9482_550092737.1530240260378"

------=_Part_9482_550092737.1530240260378
Content-Type: text/plain; charset="UTF-8"

On Tuesday, June 26, 2018 at 3:34:21 AM UTC-4, mihailn...@gmail.com wrote:
>
> On Monday, June 25, 2018 at 11:22:43 PM UTC+3, Nicol Bolas wrote:
>>
>> On Monday, June 25, 2018 at 3:20:29 PM UTC-4, mihailn...@gmail.com wrote:
>>
>
>>>    -
>>>    - Completely "flat" and inflexible - no composition or
>>>    decomposition. As a result all type information about the names is actually
>>>    always hidden. A bit better in the template<> variant, because one can add
>>>    other names/constrains.
>>>    - Extremely confusing "dual use" of concepts - sometimes they look
>>>    like a template instantiation, sometimes they look like something b/w
>>>    initializer list and structured bindings.
>>>    - The syntax visually overloads already quite common syntax -
>>>    Something{}, class Something{};
>>>
>>> Given all this, the difference b/w standard notation with tailored
>>> concept VS name introducer does not seem big and significant enough.
>>>
>>> Still, undeniably there is repetition that might lead to some errors.
>>> Can we have minimum solution to that alone? Can we make template<>
>>> optional if requires is used?
>>>
>>> In other words
>>>
>>> requires Mergeable<In,In2,Out>
>>> Out merge(In, In2, Out);
>>>
>>> Will introduce In, In2 and Out.
>>>
>>
>> How is this not new syntax? Because it doesn't use a new symbol? It's
>> using existing symbols in new ways, just like {} does. For example:
>>
>
> No, {} is used in a new context, creating new *construct*. No new
> constructs are created here, simply using-is-a-declaration.
>

"New syntax", "new feature", "new context", "new construct", these phrases
don't mean anything in an absolute sense of the language.

You want to cause a template instantiation (ie: what `ConceptName<...>` is)
to create template parameters. That is a new thing; it is nothing like C++
has ever done before with template instantiation. But you don't want to
make this a general feature of template instantiation. No, it only works on
concept variable templates, and only when used in a `requires` clause. Or
maybe only from within *certain* `requires` clauses; those replacing
template headers.

It doesn't matter if you can argue that this is or isn't a "new context" or
"new construct" or whatever by some arbitrary definition. What matters is
behavior and the ability of people to understand what's going on. It is
undeniably novel behavior for a template instantiation to introduce
identifiers using <> syntax. As such, I see no reason why this is any
easier to understand than using a different token to introduce such
identifiers.

Users will have to learn it either way. Your hypothetical time traveler
will be equally baffled. Though at least with `{}`, they'll immediately
know something special is going on and thus be able to track down what it
is.

At least with a different token, concepts can *consistently* introduce
names anywhere. And it will use a syntax that *always* means "introduce
names". If you see {}, you're getting names introduced. If you see <>, a
template is being instantiated. This is a simple and easily digestible rule.

With yours, you're not sure if <> means "introduce names" in addition to
"template arguments" without looking at the context.

1. `Name<...>` always means "specialize this template". But that's not
>> happening here. Or rather it is, but that's not *all* that's happening
>> here.
>> 2. `<>` doesn't declare identifiers without explaining what those
>> identifiers actually are. That is, without `typename`, `template`, or an
>> actual type's name.
>>
>
> The same argument can be made about both name introducers and even
> shorthand notation.
>

My point was to show that your syntax fails at meeting your own standards.
These are the reasons you yourself gave for why the other terse syntaxes
are wrong, yet your own syntax falls afoul of them.

My issue with your syntax has nothing to do with it being "new" or
whatever. The main reason why *I* don't like your syntax is because it
overloads the meaning of <>, but only in a special place. Say what you will
about Herb's syntax, but his {} can be used *anywhere* that concepts are
employed. Consistency and uniformity are an aspect that your (and Bjarne's
template introduction syntax of any form) syntax lacks.

template<template<typename> class X> concept C2 = true;
>
> template<C2 X> void f2(); *//< WTF is X, must look the concept*
>
> I am willing to argue, this is actually more clear in that particular case:
>
> requires C2<X> void f2(); *//< X is what is written b/w the <> of the
> concept! *
>
> The fact that a concept, which is a template,* is used as such* is a huge
> plus for requires in general.
>

I fail to see how this is a benefit. Your new syntax isn't shorter than the
current syntax. And neither syntax makes it clear what `X` is. If the user
is unfamiliar with `C2`, they have to ask "WTF is X", regardless of which
syntax is used.

3. This new form of `<>` only works in a `requires` clause.
>>
>
> It is not about <>, it is exclusively about 'requires'.
>

And yet, it uses <>, which has a well-established meaning. And that
well-established meaning is being changed by `requires`.

Alternatively,  if we would feel better, might be template
> Mergeable<In,In2,Out>  Out merge(In, In2, Out);.
>

It's still using <> to do something that <> doesn't normally do.

4. `requires` now has a third meaning. It's similar to the original
>> meaning, but because it's applied as a prefix, it now performs double-duty
>> as a template header. At least `template<Mergable>` looks like a template
>> header.
>>
>
> But requires is already part of the template header!
>

There's a difference between "part of" something and "is something". Your
`requires` is not merely "part of" the template header; it *is a template
header*. Just like Bjarne's original template introduction syntax made
`Mergable{...}` be the actual template header.

I don't see any of these particularly troubling.  Yes, there is some new
> context-sensitive interpretation, which is still better then new syntax for
> a bonus feature.
>
> But lets equate the new syntax (introducers) to these new rules in terms
> of how troubling they are.* These new rules give us more power, full
> power*.
>

How? What new "power" do they give us that Herb's syntax couldn't? Yes,
P0745 specifically says that they're type names, but that doesn't have to
be that way. There's no reason it couldn't be extended to arbitrary
template parameters of a concept.

They also eliminate the question "what is a name introducer". This topic no
> longer exist. Yes, new question arises - where are these template arguments
> coming from, but that is a trivial question to answer.
>

You skipped a question: how is a template instantiation legal if some of
the arguments are names that don't exist? That's a question that your
syntax creates, because it overloads existing syntax that already has a
well-established meaning.

There is a difference between taking a syntax that couldn't be used at all
and giving it meaning, and taking a syntax that already exists with some
meaning and changing what that means. Personally, I prefer the former to
the latter.

You also skipped "when can we use that ability of template instantiation to
create template parameters?" Or more to the point, "why can I only use it
in a prefixed `requires` clause?"

This is reason #1 why I dislike template introduction syntax: it creates
new syntax that can only be used in a narrow way. Herb's syntax at least
has the benefit of being consistent, rather than this giant wart you can
sometime use.

On Wednesday, June 27, 2018 at 6:40:40 AM UTC-4, mihailn...@gmail.com wrote:
>
> On Wednesday, June 27, 2018 at 12:44:13 PM UTC+3, Zhihao Yuan wrote:
>>
>> Outside the debate of the you-know-that syntax, I think this
>> demand is easy to fulfill.  I think we can allow multi-argument
>> constrained parameters like this:
>>
>>     template <Mergeable In In2 Out, class Other>
>>     Out merge(In, In2, Out);
>>
>
> I actually like that idea.
>

So, your definition of "new syntax" does not include "list of identifiers
without separators in places where that's not normally allowed".

I'm starting to get the impression that your position is not based on
problems with "new syntax" in general or even terse templates as an idea.
It seems more like "not curly braces!" That you'll accept any solution as
long as it doesn't involve curly braces (and probably parentheses or square
brackets).

I'm not exactly enamored with curly braces myself. But you have to admit
that it's a *lot* less novel of syntax compared to "list of identifiers
with no separators that somehow introduce template parameter names based on
a concept". At least curly-braced-bound lists are a thing in C++ that
people are used to. They may have different meaning, but it is a normal
feature of the language to see `{identifier, identifier, identifier}` in
code.

By contrast, `identifier identifier identifier` doesn't happen in C++. Not
as a list of things, at least.

--
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/1726f11e-63fc-4b0f-a4a6-c2129b6e98b2%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, June 26, 2018 at 3:34:21 AM 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 Monday, June 25, 2018 at 11:22:43 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 Monday, June 25, 2018 =
at 3:20:29 PM UTC-4, <a>mihailn...@gmail.com</a> wrote:</div></blockquote><=
/div></blockquote><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><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><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"><ul><li><=
/li><li>Completely &quot;flat&quot; and inflexible - no composition or deco=
mposition. As a result all type information about the names is actually alw=
ays hidden. A bit better in the template&lt;&gt; variant, because one can a=
dd other names/constrains. <br></li><li>Extremely confusing &quot;dual use&=
quot; of concepts - sometimes they look like a template instantiation, some=
times they look like something b/w initializer list and structured bindings=
..<br></li><li>The syntax visually overloads already quite common syntax - S=
omething{}, class Something{};</li></ul><div>Given all this, the difference=
 b/w standard notation with tailored concept VS name introducer does not se=
em big and significant enough.</div><div><br>Still, undeniably there is rep=
etition that might lead to some errors.</div><div>Can we have minimum solut=
ion to that alone? Can we make <font face=3D"courier new,monospace">templat=
e&lt;&gt;</font> optional if <font face=3D"courier new,monospace">requires<=
/font> is used?</div><div><br></div><div>In other words</div><div><br></div=
><div><font face=3D"courier new,monospace">requires Mergeable&lt;In,In2,Out=
&gt;<br>Out merge(In, In2, Out);</font></div><div><font face=3D"courier new=
,monospace"><br></font></div><div>Will introduce <font face=3D"courier new,=
monospace">In</font>, <font face=3D"courier new,monospace">In2</font> and <=
font face=3D"courier new,monospace">Out</font>.=C2=A0</div></div></blockquo=
te><div><br></div><div>How is this not new syntax? Because it doesn&#39;t u=
se a new symbol? It&#39;s using existing symbols in new ways, just like {} =
does. For example:<br></div></div></blockquote><div><br></div><div>No, {} i=
s used in a new context, creating new <i>construct</i>. No new constructs a=
re created here, simply using-is-a-declaration.</div></div></blockquote><di=
v><br></div><div>&quot;New syntax&quot;, &quot;new feature&quot;, &quot;new=
 context&quot;, &quot;new construct&quot;, these phrases don&#39;t mean any=
thing in an absolute sense of the language.<br></div><div><br></div><div>Yo=
u want to cause a template instantiation (ie: what `ConceptName&lt;...&gt;`=
 is) to create template parameters. That is a new thing; it is nothing like=
 C++ has ever done before with template instantiation. But you don&#39;t wa=
nt to make this a general feature of template instantiation. No, it only wo=
rks on concept variable templates, and only when used in a `requires` claus=
e. Or maybe only from within <i>certain</i> `requires` clauses; those repla=
cing template headers.<br></div><div><br></div><div>It doesn&#39;t matter i=
f you can argue that this is or isn&#39;t a &quot;new context&quot; or &quo=
t;new construct&quot; or whatever by some arbitrary definition. What matter=
s is behavior and the ability of people to understand what&#39;s going on. =
It is undeniably novel behavior for a template instantiation to introduce i=
dentifiers using &lt;&gt; syntax. As such, I see no reason why this is any =
easier to understand than using a different token to introduce such identif=
iers.</div><div><br></div><div>Users will have to learn it either way. Your=
 hypothetical time traveler will be equally baffled. Though at least with `=
{}`, they&#39;ll immediately know something special is going on and thus be=
 able to track down what it is.<br></div><div><br></div><div>At least with =
a different token, concepts can <i>consistently</i> introduce names anywher=
e. And it will use a syntax that <i>always</i> means &quot;introduce names&=
quot;. If you see {}, you&#39;re getting names introduced. If you see &lt;&=
gt;, a template is being instantiated. This is a simple and easily digestib=
le rule.<br></div><div><br></div><div>With yours, you&#39;re not sure if &l=
t;&gt; means &quot;introduce names&quot; in addition to &quot;template argu=
ments&quot; without looking at the context.</div><br><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><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>1. `Name&lt;...=
&gt;` always means &quot;specialize this template&quot;. But that&#39;s not=
 happening here. Or rather it is, but that&#39;s not <i>all</i> that&#39;s =
happening here.</div><div>2. `&lt;&gt;` doesn&#39;t declare identifiers wit=
hout explaining what those identifiers actually are. That is, without `type=
name`, `template`, or an actual type&#39;s name.=C2=A0</div></div></blockqu=
ote><div>=C2=A0</div><div>The same argument can be made about both name int=
roducers and even shorthand notation.</div></div></blockquote><div><br></di=
v><div>My point was to show that your syntax fails at meeting your own stan=
dards. These are the reasons you yourself gave for why the other terse synt=
axes are wrong, yet your own syntax falls afoul of them.</div><div><br></di=
v><div>My issue with your syntax has nothing to do with it being &quot;new&=
quot; or whatever. The main reason why <i>I</i> don&#39;t like your syntax =
is because it overloads the meaning of &lt;&gt;, but only in a special plac=
e. Say what you will about Herb&#39;s syntax, but his {} can be used <i>any=
where</i> that concepts are employed. Consistency and uniformity are an asp=
ect that your (and Bjarne&#39;s template introduction syntax of any form) s=
yntax lacks.<br></div><div><br></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><font face=3D"courier new,monospace"></font></=
div><div><font face=3D"courier new,monospace">template&lt;template&lt;typen=
ame&gt; class X&gt; concept C2 =3D true;</font></div><div><font face=3D"cou=
rier new,monospace"><br></font></div><div><font face=3D"courier new,monospa=
ce">template&lt;C2 X&gt; void f2(); <i>//&lt; WTF is X, must look the conce=
pt</i></font></div><div><i></i><br></div><div>I am willing to argue, this i=
s actually more clear in that particular case:</div><div><b></b><i></i><u><=
/u><sub></sub><sup></sup><strike></strike><br></div><div><font face=3D"cour=
ier new,monospace">requires C2&lt;X&gt; void f2(); <i>//&lt;=C2=A0<span sty=
le=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0=
px;letter-spacing:normal;font-family:courier new,monospace;font-size:13px;f=
ont-variant:normal;font-weight:400;text-decoration:none;word-spacing:0px;di=
splay:inline!important;white-space:normal;float:none;background-color:trans=
parent">X is what is written b/w the &lt;&gt; of the concept!=C2=A0</span><=
/i></font><div><br></div><div>The fact that a concept, which is a template,=
<i> is used as such</i> is a huge plus for=C2=A0<span style=3D"display:inli=
ne!important;float:none;background-color:transparent;color:rgb(34,34,34);fo=
nt-family:courier new,monospace;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">requires <font face=3D"arial,sans-serif">in general.</font></span><=
/div></div></div></blockquote><div><br></div><div>I fail to see how this is=
 a benefit. Your new syntax isn&#39;t shorter than the current syntax. And =
neither syntax makes it clear what `X` is. If the user is unfamiliar with `=
C2`, they have to ask &quot;WTF is X&quot;, regardless of which syntax is u=
sed.</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>3. This new form of `&lt;&gt;` only works in a `requires` clause.=
<br></div></div></blockquote><div><div><br></div><div>It is not about &lt;&=
gt;, it is exclusively about &#39;requires&#39;.<br></div></div></div></blo=
ckquote><div><br></div><div>And yet, it uses &lt;&gt;, which has a well-est=
ablished meaning. And that well-established meaning is being changed by `re=
quires`.</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><div></div><div>Alternatively,=C2=A0 if we would feel =
better, might be <span 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;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;=
color:rgb(34,34,34);display:inline;float:none;font-family:courier new,monos=
pace;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;l=
etter-spacing:normal;margin-bottom:0px;margin-left:0px;margin-right:0px;mar=
gin-top:0px;padding-bottom:0px;padding-left:0px;padding-right:0px;padding-t=
op:0px;text-align:left;text-decoration:none;text-indent:0px;text-transform:=
none;white-space:normal;word-spacing:0px">template Mergeable&lt;In,In2,Out&=
gt;<font 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" face=3D"&quot;Arial&quot;,&quot;Helvetica&quot;,sans-ser=
if">=C2=A0 </font></span><span style=3D"background-color:transparent;border=
-bottom-color:rgb(34,34,34);border-bottom-style:none;border-bottom-width:0p=
x;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-w=
idth:0px;border-top-color:rgb(34,34,34);border-top-style:none;border-top-wi=
dth:0px;color:rgb(34,34,34);display:inline;float:none;font-family:courier n=
ew,monospace;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">Out merge(In, In2, Out);<=
font style=3D"border-bottom-color:rgb(34,34,34);border-bottom-style:none;bo=
rder-bottom-width:0px;border-left-color:rgb(34,34,34);border-left-style:non=
e;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;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" face=3D"arial,sans-serif">.</font></span> <br></div></div></=
div></blockquote><div><br></div><div>It&#39;s still using &lt;&gt; to do so=
mething that &lt;&gt; doesn&#39;t normally do.<br></div><div><br></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"><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>4. `requires` now h=
as a third meaning. It&#39;s similar to the original meaning, but because i=
t&#39;s applied as a prefix, it now performs double-duty as a template head=
er. At least `template&lt;Mergable&gt;` looks like a template header.<br></=
div></div></blockquote><div>=C2=A0</div><div>But <font face=3D"courier new,=
monospace">requires</font> is already part of the template header!</div></d=
iv></blockquote><div><br></div><div>There&#39;s a difference between &quot;=
part of&quot; something and &quot;is something&quot;. Your `requires` is no=
t merely &quot;part of&quot; the template header; it <i>is a template heade=
r</i>. Just like Bjarne&#39;s original template introduction syntax made `M=
ergable{...}` be the actual template header.<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></div><div>I d=
on&#39;t see any of these particularly troubling.=C2=A0 Yes, there is some =
new context-sensitive interpretation, which is still better then new syntax=
 for a bonus feature.=C2=A0</div><div><br></div><div>But lets equate the ne=
w syntax (introducers) to these new rules in terms of how troubling they ar=
e.<i> These new rules give us more power, full power</i>.</div></div></bloc=
kquote><div><br></div><div>How? What new &quot;power&quot; do they give us =
that Herb&#39;s syntax couldn&#39;t? Yes, P0745 specifically says that they=
&#39;re type names, but that doesn&#39;t have to be that way. There&#39;s n=
o reason it couldn&#39;t be extended to arbitrary template parameters of a =
concept.<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 also eliminate the question &quot;what is a n=
ame introducer&quot;. This topic no longer exist. Yes, new question arises =
- where are these template arguments coming from, but that is a trivial que=
stion to answer.</div></div></blockquote><div><br></div><div>You skipped a =
question: how is a template instantiation legal if some of the arguments ar=
e names that don&#39;t exist? That&#39;s a question that your syntax create=
s, because it overloads existing syntax that already has a well-established=
 meaning.</div><div><br></div>There is a difference between taking a syntax=
 that couldn&#39;t be used
 at all and giving it meaning, and taking a syntax that already exists=20
with some meaning and changing what that means. Personally, I prefer the fo=
rmer to the latter.<br><div><br></div><div><div>You also skipped &quot;when=
 can we use that ability of template=20
instantiation to create template parameters?&quot; Or more to the point, &q=
uot;why can I only use it in a prefixed `requires` clause?&quot;<br></div><=
div><br></div><div>This is reason #1 why I dislike template introduction sy=
ntax: it creates new syntax that can only be used in a narrow way. Herb&#39=
;s syntax at least has the benefit of being consistent, rather than this gi=
ant wart you can sometime use.<br></div><div><br></div>On Wednesday, June 2=
7, 2018 at 6:40:40 AM UTC-4, mihailn...@gmail.com wrote:<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">On Wednesday, June 27, 2018 at=
 12:44:13 PM UTC+3, Zhihao Yuan 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>Outside the debate of the you-know-that syntax, I think this<br></d=
iv><div>demand is easy to fulfill.=C2=A0 I think we can allow multi-argumen=
t<br></div><div>constrained parameters like this:<br></div><div><br></div><=
div>=C2=A0=C2=A0=C2=A0 template &lt;Mergeable In In2 Out, class Other&gt;<b=
r></div><div>=C2=A0 =C2=A0 Out merge(In, In2, Out);<br></div></blockquote><=
div><br></div><div>I actually like that idea.</div></div></blockquote><div>=
<br></div><div>So,
 your definition of &quot;new syntax&quot; does not include &quot;list of i=
dentifiers without separators in places where that&#39;s not normally allow=
ed&quot;.</div><div><br></div><div>I&#39;m starting to get the impression t=
hat your position is not based on problems with &quot;new syntax&quot; in g=
eneral or even terse templates as an idea. It seems more like &quot;not cur=
ly braces!&quot; That you&#39;ll accept any solution as long as it doesn&#3=
9;t involve curly braces (and probably parentheses or square brackets).<br>=
</div><div><br></div><div>I&#39;m not exactly enamored with curly braces my=
self. But you have to admit that it&#39;s a <i>lot</i> less novel of syntax=
 compared to &quot;list of identifiers with no separators that somehow intr=
oduce template parameter names based on a concept&quot;. At least curly-bra=
ced-bound lists are a thing in C++ that people are used to. They may have d=
ifferent meaning, but it is a normal feature of the language to see `{ident=
ifier, identifier, identifier}` in code.</div><div><br></div><div>By contra=
st, `identifier identifier identifier` doesn&#39;t happen in C++. Not as a =
list of things, at least.<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/1726f11e-63fc-4b0f-a4a6-c2129b6e98b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1726f11e-63fc-4b0f-a4a6-c2129b6e98b2=
%40isocpp.org</a>.<br />

------=_Part_9482_550092737.1530240260378--

------=_Part_9481_974811298.1530240260377--

.

This is a multi-part message in MIME format.

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

I merely used some CS knowledge here.  Any finite
automaton which can accept

    Sortable A B

is able to consume

    Sortable A

as a prefix, but not all finite automatons which accept

    Sortable{A, B}

also consume

    Sortable A

So I guess it=E2=80=99s not too unsound to treat =E2=80=9CSortable A B=E2=
=80=9D as,
grammatically, a generalization to =E2=80=9CSortable A=E2=80=9D?

Yes, I know, 1-tuple doesn=E2=80=99t need braces.  I will be
convinced when I can write (int 1).

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

From: Nicol Bolas <jmckesson@gmail.com>
Sent: Thursday, June 28, 2018 9:44 PM

>>     template <Mergeable In In2 Out, class Other>
>>
>>     Out merge(In, In2, Out);
>
> I actually like that idea.

So, your definition of "new syntax" does not include "list of identifiers w=
ithout separators in places where that's not normally allowed".

[=E2=80=A6]

I'm not exactly enamored with curly braces myself. But you have to admit th=
at it's a lot less novel of syntax compared to "list of identifiers with no=
 separators that somehow introduce template parameter names based on a conc=
ept". At least curly-braced-bound lists are a thing in C++ that people are =
used to. They may have different meaning, but it is a normal feature of the=
 language to see `{identifier, identifier, identifier}` in code.

--=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/GKLhvnT9yDx5sQxeJB_ZDkkzFMCsNq-C9OUlUQdxVxv66lat=
hyLXhT6l3EopKjb9ZM3QNl2HwiW3G44jF1-1HWskBwvmiPu5IhHLRtDSDbU%3D%40miator.net=
..

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

<html><head></head><body><div class=3D"WordSection1"><p class=3D"MsoNormal"=
>I merely used some CS knowledge here.=C2=A0 Any finite<br/>automaton which=
 can accept<br/><br/>=C2=A0=C2=A0=C2=A0 Sortable A B<br/><br/>is able to co=
nsume<br/><br/>=C2=A0=C2=A0=C2=A0 Sortable A<br/><br/>as a prefix, but not =
all finite automatons which accept<br/><br/>=C2=A0=C2=A0=C2=A0 Sortable{A, =
B}<br/><br/>also consume<br/><br/>=C2=A0=C2=A0=C2=A0 Sortable A<br/><br/>So=
 I guess it=E2=80=99s not too unsound to treat =E2=80=9CSortable A B=E2=80=
=9D as,<br/>grammatically, a generalization to =E2=80=9CSortable A=E2=80=9D=
?<br/><br/>Yes, I know, 1-tuple doesn=E2=80=99t need braces.=C2=A0 I will b=
e<br/>convinced when I can write (int 1).<br/><br/><o:p></o:p></p><p class=
=3D"MsoNormal">--<br/>Zhihao Yuan, ID lichray<br/>The best way to predict t=
he future is to invent it.<br/>____________________________________________=
___<o:p></o:p></p><p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p><div style=3D=
"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><=
div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0=
in 0in"><p class=3D"MsoNormal" style=3D"margin-left:5.25pt"><b>From:</b> Ni=
col Bolas &lt;jmckesson@gmail.com&gt; <br/><b>Sent:</b> Thursday, June 28, =
2018 9:44 PM<br/><br/><o:p></o:p></p></div></div><div><div><blockquote styl=
e=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;=
margin-left:4.8pt;margin-right:0in"><div><blockquote style=3D"border:none;b=
order-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;=
margin-right:0in"><div><p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0 template &=
lt;Mergeable In In2 Out, class Other&gt;<o:p></o:p></p></div><div><p class=
=3D"MsoNormal">=C2=A0 =C2=A0 Out merge(In, In2, Out);<o:p></o:p></p></div><=
/blockquote><div><p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p></div><div><p =
class=3D"MsoNormal">I actually like that idea.<o:p></o:p></p></div></div></=
blockquote><div><p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p></div><div><p c=
lass=3D"MsoNormal">So, your definition of &#34;new syntax&#34; does not inc=
lude &#34;list of identifiers without separators in places where that&#39;s=
 not normally allowed&#34;.<o:p></o:p></p></div><div><p class=3D"MsoNormal"=
><o:p>=C2=A0</o:p></p></div><div><p class=3D"MsoNormal">[=E2=80=A6]<o:p></o=
:p></p></div><div><p class=3D"MsoNormal"><o:p>=C2=A0</o:p></p></div><div><p=
 class=3D"MsoNormal">I&#39;m not exactly enamored with curly braces myself.=
 But you have to admit that it&#39;s a <i>lot</i> less novel of syntax comp=
ared to &#34;list of identifiers with no separators that somehow introduce =
template parameter names based on a concept&#34;. At least curly-braced-bou=
nd lists are a thing in C++ that people are used to. They may have differen=
t meaning, but it is a normal feature of the language to see `{identifier, =
identifier, identifier}` in code.<o:p></o:p></p></div></div></div></div></d=
iv></body></html>

<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/GKLhvnT9yDx5sQxeJB_ZDkkzFMCsNq-C9OUlU=
QdxVxv66lathyLXhT6l3EopKjb9ZM3QNl2HwiW3G44jF1-1HWskBwvmiPu5IhHLRtDSDbU%3D%4=
0miator.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/GKLhvnT9yDx5sQxeJB_ZDkkzFMCsNq-C9OUlU=
QdxVxv66lathyLXhT6l3EopKjb9ZM3QNl2HwiW3G44jF1-1HWskBwvmiPu5IhHLRtDSDbU%3D%4=
0miator.net</a>.<br />

--b1_17850817fcd147bfd87ce74abab79c64--


.

------=_Part_11043_2127091215.1530260295232
Content-Type: multipart/alternative;
 boundary="----=_Part_11044_1313629676.1530260295232"

------=_Part_11044_1313629676.1530260295232
Content-Type: text/plain; charset="UTF-8"



On Friday, June 29, 2018 at 5:44:20 AM UTC+3, Nicol Bolas wrote:
>
> On Tuesday, June 26, 2018 at 3:34:21 AM UTC-4, mihailn...@gmail.com wrote:
>>
>> On Monday, June 25, 2018 at 11:22:43 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Monday, June 25, 2018 at 3:20:29 PM UTC-4, mihailn...@gmail.com
>>> wrote:
>>>
>>
>>>>    -
>>>>    - Completely "flat" and inflexible - no composition or
>>>>    decomposition. As a result all type information about the names is actually
>>>>    always hidden. A bit better in the template<> variant, because one can add
>>>>    other names/constrains.
>>>>    - Extremely confusing "dual use" of concepts - sometimes they look
>>>>    like a template instantiation, sometimes they look like something b/w
>>>>    initializer list and structured bindings.
>>>>    - The syntax visually overloads already quite common syntax -
>>>>    Something{}, class Something{};
>>>>
>>>> Given all this, the difference b/w standard notation with tailored
>>>> concept VS name introducer does not seem big and significant enough.
>>>>
>>>> Still, undeniably there is repetition that might lead to some errors.
>>>> Can we have minimum solution to that alone? Can we make template<>
>>>> optional if requires is used?
>>>>
>>>> In other words
>>>>
>>>> requires Mergeable<In,In2,Out>
>>>> Out merge(In, In2, Out);
>>>>
>>>> Will introduce In, In2 and Out.
>>>>
>>>
>>> How is this not new syntax? Because it doesn't use a new symbol? It's
>>> using existing symbols in new ways, just like {} does. For example:
>>>
>>
>> No, {} is used in a new context, creating new *construct*. No new
>> constructs are created here, simply using-is-a-declaration.
>>
>
> "New syntax", "new feature", "new context", "new construct", these phrases
> don't mean anything in an absolute sense of the language.
>
> You want to cause a template instantiation (ie: what `ConceptName<...>`
> is) to create template parameters. That is a new thing; it is nothing like
> C++ has ever done before with template instantiation. But you don't want to
> make this a general feature of template instantiation. No, it only works on
> concept variable templates, and only when used in a `requires` clause. Or
> maybe only from within *certain* `requires` clauses; those replacing
> template headers.
>
> It doesn't matter if you can argue that this is or isn't a "new context"
> or "new construct" or whatever by some arbitrary definition. What matters
> is behavior and the ability of people to understand what's going on. It is
> undeniably novel behavior for a template instantiation to introduce
> identifiers using <> syntax. As such, I see no reason why this is any
> easier to understand than using a different token to introduce such
> identifiers.
>
> Users will have to learn it either way. Your hypothetical time traveler
> will be equally baffled. Though at least with `{}`, they'll immediately
> know something special is going on and thus be able to track down what it
> is.
>
> At least with a different token, concepts can *consistently* introduce
> names anywhere. And it will use a syntax that *always* means "introduce
> names". If you see {}, you're getting names introduced. If you see <>, a
> template is being instantiated. This is a simple and easily digestible rule.
>
> With yours, you're not sure if <> means "introduce names" in addition to
> "template arguments" without looking at the context.
>
> 1. `Name<...>` always means "specialize this template". But that's not
>>> happening here. Or rather it is, but that's not *all* that's happening
>>> here.
>>> 2. `<>` doesn't declare identifiers without explaining what those
>>> identifiers actually are. That is, without `typename`, `template`, or an
>>> actual type's name.
>>>
>>
>> The same argument can be made about both name introducers and even
>> shorthand notation.
>>
>
> My point was to show that your syntax fails at meeting your own standards.
> These are the reasons you yourself gave for why the other terse syntaxes
> are wrong, yet your own syntax falls afoul of them.
>
> My issue with your syntax has nothing to do with it being "new" or
> whatever. The main reason why *I* don't like your syntax is because it
> overloads the meaning of <>, but only in a special place. Say what you will
> about Herb's syntax, but his {} can be used *anywhere* that concepts are
> employed. Consistency and uniformity are an aspect that your (and Bjarne's
> template introduction syntax of any form) syntax lacks.
>
> template<template<typename> class X> concept C2 = true;
>>
>> template<C2 X> void f2(); *//< WTF is X, must look the concept*
>>
>> I am willing to argue, this is actually more clear in that particular
>> case:
>>
>> requires C2<X> void f2(); *//< X is what is written b/w the <> of the
>> concept! *
>>
>> The fact that a concept, which is a template,* is used as such* is a
>> huge plus for requires in general.
>>
>
> I fail to see how this is a benefit. Your new syntax isn't shorter than
> the current syntax. And neither syntax makes it clear what `X` is. If the
> user is unfamiliar with `C2`, they have to ask "WTF is X", regardless of
> which syntax is used.
>
> 3. This new form of `<>` only works in a `requires` clause.
>>>
>>
>> It is not about <>, it is exclusively about 'requires'.
>>
>
> And yet, it uses <>, which has a well-established meaning. And that
> well-established meaning is being changed by `requires`.
>
> Alternatively,  if we would feel better, might be template
>> Mergeable<In,In2,Out>  Out merge(In, In2, Out);.
>>
>
> It's still using <> to do something that <> doesn't normally do.
>
> 4. `requires` now has a third meaning. It's similar to the original
>>> meaning, but because it's applied as a prefix, it now performs double-duty
>>> as a template header. At least `template<Mergable>` looks like a template
>>> header.
>>>
>>
>> But requires is already part of the template header!
>>
>
> There's a difference between "part of" something and "is something". Your
> `requires` is not merely "part of" the template header; it *is a template
> header*. Just like Bjarne's original template introduction syntax made
> `Mergable{...}` be the actual template header.
>
> I don't see any of these particularly troubling.  Yes, there is some new
>> context-sensitive interpretation, which is still better then new syntax for
>> a bonus feature.
>>
>> But lets equate the new syntax (introducers) to these new rules in terms
>> of how troubling they are.* These new rules give us more power, full
>> power*.
>>
>
> How? What new "power" do they give us that Herb's syntax couldn't? Yes,
> P0745 specifically says that they're type names, but that doesn't have to
> be that way. There's no reason it couldn't be extended to arbitrary
> template parameters of a concept.
>
> They also eliminate the question "what is a name introducer". This topic
>> no longer exist. Yes, new question arises - where are these template
>> arguments coming from, but that is a trivial question to answer.
>>
>
> You skipped a question: how is a template instantiation legal if some of
> the arguments are names that don't exist? That's a question that your
> syntax creates, because it overloads existing syntax that already has a
> well-established meaning.
>
> There is a difference between taking a syntax that couldn't be used at all
> and giving it meaning, and taking a syntax that already exists with some
> meaning and changing what that means. Personally, I prefer the former to
> the latter.
>

And we have to leave it there. We agree to disagree. For me (a bit
weird/awkward) new rules and full power is better, for you clear new syntax
is better even if it risks creating new dialect for template creation.
I can't see how anyone can convince the other of the opposite and that's OK.


>
> You also skipped "when can we use that ability of template instantiation
> to create template parameters?" Or more to the point, "why can I only use
> it in a prefixed `requires` clause?"
>
> This is reason #1 why I dislike template introduction syntax: it creates
> new syntax that can only be used in a narrow way. Herb's syntax at least
> has the benefit of being consistent, rather than this giant wart you can
> sometime use.
>
> On Wednesday, June 27, 2018 at 6:40:40 AM UTC-4, mihailn...@gmail.com
> wrote:
>>
>> On Wednesday, June 27, 2018 at 12:44:13 PM UTC+3, Zhihao Yuan wrote:
>>>
>>> Outside the debate of the you-know-that syntax, I think this
>>> demand is easy to fulfill.  I think we can allow multi-argument
>>> constrained parameters like this:
>>>
>>>     template <Mergeable In In2 Out, class Other>
>>>     Out merge(In, In2, Out);
>>>
>>
>> I actually like that idea.
>>
>
> So, your definition of "new syntax" does not include "list of identifiers
> without separators in places where that's not normally allowed".
>
> I'm starting to get the impression that your position is not based on
> problems with "new syntax" in general or even terse templates as an idea.
> It seems more like "not curly braces!" That you'll accept any solution as
> long as it doesn't involve curly braces (and probably parentheses or square
> brackets).
>

I was never ageist terse/natural as I said in the other topic. But, yes am
against it if it introduces new syntax for humans only and/or new
constructs.
Introducers are a new construct, and I believe we can talk about that in
absolute sense.
The reason you like in-place is the fact that it makes this new construct
usable across the rest of the templates language, creating consistency and
giving power.
Here we agree to disagree, and there is no point repeating my counter
arguments.


> I'm not exactly enamored with curly braces myself. But you have to admit
> that it's a *lot* less novel of syntax compared to "list of identifiers
> with no separators that somehow introduce template parameter names based on
> a concept". At least curly-braced-bound lists are a thing in C++ that
> people are used to. They may have different meaning, but it is a normal
> feature of the language to see `{identifier, identifier, identifier}` in
> code.
>

I am hard press to remember a single place where identifiers are introduced
with a similar syntax.
Sure we have seen a lot of {something, something}, but that was, until now,
an act of initialization (ever since C) or enum {something, something}; an
act of definition (sure identifiers are introduced, but are in the scope,
given by the braces. We reaffirmed that rule with enum class).

This inevitably creates mental confusion (to some extend, at some point,
for some people, etc) as it literally uses the same syntax in a completely
new context for completely new meaning.


>
> By contrast, `identifier identifier identifier` doesn't happen in C++. Not
> as a list of things, at least.
>

True, but a list inside a list like that does not happen either. We are
both on the same scope but inside another

In any case you have to admit

template<Concept T, class A>

template<Concept T U, class A>

are pretty self explanatory and the questions that arise for a newcomer can
be answered by deduction.

Where braces do rise questions impossible to answer *without learning.*
Instantiation? Inline Definition? Scope? Relation to <>? Alternative to <>?

--
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/e69010d8-c8b0-4a1e-999f-af5dff75a8f2%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, June 29, 2018 at 5:44:20 AM UTC+3, Nico=
l Bolas 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"=
>On Tuesday, June 26, 2018 at 3:34:21 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">On Monday, =
June 25, 2018 at 11:22:43 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"><div dir=3D"ltr">On Monday, June 25, 2018 at 3:20:29 PM =
UTC-4, <a>mihailn...@gmail.com</a> wrote:</div></blockquote></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><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></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"><ul><li></li><li>Completely =
&quot;flat&quot; and inflexible - no composition or decomposition. As a res=
ult all type information about the names is actually always hidden. A bit b=
etter in the template&lt;&gt; variant, because one can add other names/cons=
trains. <br></li><li>Extremely confusing &quot;dual use&quot; of concepts -=
 sometimes they look like a template instantiation, sometimes they look lik=
e something b/w initializer list and structured bindings.<br></li><li>The s=
yntax visually overloads already quite common syntax - Something{}, class S=
omething{};</li></ul><div>Given all this, the difference b/w standard notat=
ion with tailored concept VS name introducer does not seem big and signific=
ant enough.</div><div><br>Still, undeniably there is repetition that might =
lead to some errors.</div><div>Can we have minimum solution to that alone? =
Can we make <font face=3D"courier new,monospace">template&lt;&gt;</font> op=
tional if <font face=3D"courier new,monospace">requires</font> is used?</di=
v><div><br></div><div>In other words</div><div><br></div><div><font face=3D=
"courier new,monospace">requires Mergeable&lt;In,In2,Out&gt;<br>Out merge(I=
n, In2, Out);</font></div><div><font face=3D"courier new,monospace"><br></f=
ont></div><div>Will introduce <font face=3D"courier new,monospace">In</font=
>, <font face=3D"courier new,monospace">In2</font> and <font face=3D"courie=
r new,monospace">Out</font>.=C2=A0</div></div></blockquote><div><br></div><=
div>How is this not new syntax? Because it doesn&#39;t use a new symbol? It=
&#39;s using existing symbols in new ways, just like {} does. For example:<=
br></div></div></blockquote><div><br></div><div>No, {} is used in a new con=
text, creating new <i>construct</i>. No new constructs are created here, si=
mply using-is-a-declaration.</div></div></blockquote><div><br></div><div>&q=
uot;New syntax&quot;, &quot;new feature&quot;, &quot;new context&quot;, &qu=
ot;new construct&quot;, these phrases don&#39;t mean anything in an absolut=
e sense of the language.<br></div><div><br></div><div>You want to cause a t=
emplate instantiation (ie: what `ConceptName&lt;...&gt;` is) to create temp=
late parameters. That is a new thing; it is nothing like C++ has ever done =
before with template instantiation. But you don&#39;t want to make this a g=
eneral feature of template instantiation. No, it only works on concept vari=
able templates, and only when used in a `requires` clause. Or maybe only fr=
om within <i>certain</i> `requires` clauses; those replacing template heade=
rs.<br></div><div><br></div><div>It doesn&#39;t matter if you can argue tha=
t this is or isn&#39;t a &quot;new context&quot; or &quot;new construct&quo=
t; or whatever by some arbitrary definition. What matters is behavior and t=
he ability of people to understand what&#39;s going on. It is undeniably no=
vel behavior for a template instantiation to introduce identifiers using &l=
t;&gt; syntax. As such, I see no reason why this is any easier to understan=
d than using a different token to introduce such identifiers.</div><div><br=
></div><div>Users will have to learn it either way. Your hypothetical time =
traveler will be equally baffled. Though at least with `{}`, they&#39;ll im=
mediately know something special is going on and thus be able to track down=
 what it is.<br></div><div><br></div><div>At least with a different token, =
concepts can <i>consistently</i> introduce names anywhere. And it will use =
a syntax that <i>always</i> means &quot;introduce names&quot;. If you see {=
}, you&#39;re getting names introduced. If you see &lt;&gt;, a template is =
being instantiated. This is a simple and easily digestible rule.<br></div><=
div><br></div><div>With yours, you&#39;re not sure if &lt;&gt; means &quot;=
introduce names&quot; in addition to &quot;template arguments&quot; without=
 looking at the context.</div><br><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"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div></div><div></div><div>1. `Name&lt;...&gt;` always means &qu=
ot;specialize this template&quot;. But that&#39;s not happening here. Or ra=
ther it is, but that&#39;s not <i>all</i> that&#39;s happening here.</div><=
div>2. `&lt;&gt;` doesn&#39;t declare identifiers without explaining what t=
hose identifiers actually are. That is, without `typename`, `template`, or =
an actual type&#39;s name.=C2=A0</div></div></blockquote><div>=C2=A0</div><=
div>The same argument can be made about both name introducers and even shor=
thand notation.</div></div></blockquote><div><br></div><div>My point was to=
 show that your syntax fails at meeting your own standards. These are the r=
easons you yourself gave for why the other terse syntaxes are wrong, yet yo=
ur own syntax falls afoul of them.</div><div><br></div><div>My issue with y=
our syntax has nothing to do with it being &quot;new&quot; or whatever. The=
 main reason why <i>I</i> don&#39;t like your syntax is because it overload=
s the meaning of &lt;&gt;, but only in a special place. Say what you will a=
bout Herb&#39;s syntax, but his {} can be used <i>anywhere</i> that concept=
s are employed. Consistency and uniformity are an aspect that your (and Bja=
rne&#39;s template introduction syntax of any form) syntax lacks.<br></div>=
<div><br></div><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><font face=3D"courier new,monospace"></font></div><div><font face=3D"cour=
ier new,monospace">template&lt;template&lt;typename&gt; class X&gt; concept=
 C2 =3D true;</font></div><div><font face=3D"courier new,monospace"><br></f=
ont></div><div><font face=3D"courier new,monospace">template&lt;C2 X&gt; vo=
id f2(); <i>//&lt; WTF is X, must look the concept</i></font></div><div><i>=
</i><br></div><div>I am willing to argue, this is actually more clear in th=
at particular case:</div><div><b></b><i></i><u></u><sub></sub><sup></sup><s=
trike></strike><br></div><div><font face=3D"courier new,monospace">requires=
 C2&lt;X&gt; void f2(); <i>//&lt;=C2=A0<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;font-wei=
ght:400;text-decoration:none;word-spacing:0px;display:inline!important;whit=
e-space:normal;float:none;background-color:transparent">X is what is writte=
n b/w the &lt;&gt; of the concept!=C2=A0</span></i></font><div><br></div><d=
iv>The fact that a concept, which is a template,<i> is used as such</i> is =
a huge plus for=C2=A0<span style=3D"display:inline!important;float:none;bac=
kground-color:transparent;color:rgb(34,34,34);font-family:courier new,monos=
pace;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">requires <font face=
=3D"arial,sans-serif">in general.</font></span></div></div></div></blockquo=
te><div><br></div><div>I fail to see how this is a benefit. Your new syntax=
 isn&#39;t shorter than the current syntax. And neither syntax makes it cle=
ar what `X` is. If the user is unfamiliar with `C2`, they have to ask &quot=
;WTF is X&quot;, regardless of which syntax is used.</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><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>3. This new form of `&=
lt;&gt;` only works in a `requires` clause.<br></div></div></blockquote><di=
v><div><br></div><div>It is not about &lt;&gt;, it is exclusively about &#3=
9;requires&#39;.<br></div></div></div></blockquote><div><br></div><div>And =
yet, it uses &lt;&gt;, which has a well-established meaning. And that well-=
established meaning is being changed by `requires`.</div><div><br></div><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><div></div><div>=
Alternatively,=C2=A0 if we would feel better, might be <span style=3D"backg=
round-color:transparent;border-bottom-color:rgb(34,34,34);border-bottom-sty=
le: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-r=
ight-style:none;border-right-width:0px;border-top-color:rgb(34,34,34);borde=
r-top-style:none;border-top-width:0px;color:rgb(34,34,34);display:inline;fl=
oat:none;font-family:courier new,monospace;font-size:13px;font-style:normal=
;font-variant:normal;font-weight:400;letter-spacing:normal;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;text-align:left;text-decoratio=
n:none;text-indent:0px;text-transform:none;white-space:normal;word-spacing:=
0px">template Mergeable&lt;In,In2,Out&gt;<font face=3D"&quot;Arial&quot;,&q=
uot;Helvetica&quot;,sans-serif" 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">=C2=A0 </font></span><span style=
=3D"background-color:transparent;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;color:rgb(34,34,34);display:=
inline;float:none;font-family:courier new,monospace;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;padding-bottom:0=
px;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">Out merge(In, In2, Out);<font face=3D"arial,sans-serif" 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">.</font></span> <br></div></div></div></blockquote><div><br></div><div=
>It&#39;s still using &lt;&gt; to do something that &lt;&gt; doesn&#39;t no=
rmally do.<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"><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></div><div>4. `requires` now has a third meaning. It&#39;s similar to =
the original meaning, but because it&#39;s applied as a prefix, it now perf=
orms double-duty as a template header. At least `template&lt;Mergable&gt;` =
looks like a template header.<br></div></div></blockquote><div>=C2=A0</div>=
<div>But <font face=3D"courier new,monospace">requires</font> is already pa=
rt of the template header!</div></div></blockquote><div><br></div><div>Ther=
e&#39;s a difference between &quot;part of&quot; something and &quot;is som=
ething&quot;. Your `requires` is not merely &quot;part of&quot; the templat=
e header; it <i>is a template header</i>. Just like Bjarne&#39;s original t=
emplate introduction syntax made `Mergable{...}` be the actual template hea=
der.<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 d=
ir=3D"ltr"><div></div><div>I don&#39;t see any of these particularly troubl=
ing.=C2=A0 Yes, there is some new context-sensitive interpretation, which i=
s still better then new syntax for a bonus feature.=C2=A0</div><div><br></d=
iv><div>But lets equate the new syntax (introducers) to these new rules in =
terms of how troubling they are.<i> These new rules give us more power, ful=
l power</i>.</div></div></blockquote><div><br></div><div>How? What new &quo=
t;power&quot; do they give us that Herb&#39;s syntax couldn&#39;t? Yes, P07=
45 specifically says that they&#39;re type names, but that doesn&#39;t have=
 to be that way. There&#39;s no reason it couldn&#39;t be extended to arbit=
rary template parameters of a concept.<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 also eliminate the q=
uestion &quot;what is a name introducer&quot;. This topic no longer exist. =
Yes, new question arises - where are these template arguments coming from, =
but that is a trivial question to answer.</div></div></blockquote><div><br>=
</div><div>You skipped a question: how is a template instantiation legal if=
 some of the arguments are names that don&#39;t exist? That&#39;s a questio=
n that your syntax creates, because it overloads existing syntax that alrea=
dy has a well-established meaning.</div><div><br></div>There is a differenc=
e between taking a syntax that couldn&#39;t be used
 at all and giving it meaning, and taking a syntax that already exists=20
with some meaning and changing what that means. Personally, I prefer the fo=
rmer to the latter.<br></div></blockquote><div><br></div><div>And we have t=
o leave it there. We agree to disagree. For me (a bit weird/awkward) new ru=
les and full power is better, for you clear new syntax is better even if it=
 risks creating new dialect for template creation.=C2=A0 <br>I can&#39;t se=
e how anyone can convince the other of the opposite and that&#39;s OK.<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><div>You also skipped &quot;when can we use th=
at ability of template=20
instantiation to create template parameters?&quot; Or more to the point, &q=
uot;why can I only use it in a prefixed `requires` clause?&quot;<br></div><=
div><br></div><div>This is reason #1 why I dislike template introduction sy=
ntax: it creates new syntax that can only be used in a narrow way. Herb&#39=
;s syntax at least has the benefit of being consistent, rather than this gi=
ant wart you can sometime use.<br></div><div><br></div>On Wednesday, June 2=
7, 2018 at 6:40:40 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">On Wednesday, June 27, 2018 at=
 12:44:13 PM UTC+3, Zhihao Yuan 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>Outside the debate of the you-know-that syntax, I think this<br></d=
iv><div>demand is easy to fulfill.=C2=A0 I think we can allow multi-argumen=
t<br></div><div>constrained parameters like this:<br></div><div><br></div><=
div>=C2=A0=C2=A0=C2=A0 template &lt;Mergeable In In2 Out, class Other&gt;<b=
r></div><div>=C2=A0 =C2=A0 Out merge(In, In2, Out);<br></div></blockquote><=
div><br></div><div>I actually like that idea.</div></div></blockquote><div>=
<br></div><div>So,
 your definition of &quot;new syntax&quot; does not include &quot;list of i=
dentifiers without separators in places where that&#39;s not normally allow=
ed&quot;.</div><div><br></div><div>I&#39;m starting to get the impression t=
hat your position is not based on problems with &quot;new syntax&quot; in g=
eneral or even terse templates as an idea. It seems more like &quot;not cur=
ly braces!&quot; That you&#39;ll accept any solution as long as it doesn&#3=
9;t involve curly braces (and probably parentheses or square brackets).<br>=
</div></div></div></blockquote><div><br></div><div>I was never ageist terse=
/natural as I said in the other topic. But, yes am against it if it introdu=
ces new syntax for humans only and/or new constructs. <br>Introducers are a=
 new construct, and I believe we can talk about that in absolute sense.=C2=
=A0=C2=A0 <br>The reason you like in-place is the fact that it makes this n=
ew construct usable across the rest of the templates language, creating con=
sistency and giving power. <br>Here we agree to disagree, and there is no p=
oint repeating my counter arguments.=C2=A0</div><div><br></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><div><br>=
</div><div>I&#39;m not exactly enamored with curly braces myself. But you h=
ave to admit that it&#39;s a <i>lot</i> less novel of syntax compared to &q=
uot;list of identifiers with no separators that somehow introduce template =
parameter names based on a concept&quot;. At least curly-braced-bound lists=
 are a thing in C++ that people are used to. They may have different meanin=
g, but it is a normal feature of the language to see `{identifier, identifi=
er, identifier}` in code.</div></div></div></blockquote><div><br></div><div=
>I am hard press to remember a single place where identifiers are introduce=
d with a similar syntax. <br>Sure we have seen a lot of {something, somethi=
ng}, but that was, until now, an act of initialization (ever since C) or en=
um {something, something}; an act of definition (sure identifiers are intro=
duced, but are in the scope, given by the braces. We reaffirmed that rule w=
ith enum class).</div><div>=C2=A0<br></div><div>This inevitably creates men=
tal confusion (to some extend, at some point, for some people, etc) as it l=
iterally uses the same syntax in a completely new context for completely ne=
w meaning.<br></div><div>=C2=A0</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><br></div><div>By contrast, `identifier i=
dentifier identifier` doesn&#39;t happen in C++. Not as a list of things, a=
t least.<br></div></div></div></blockquote><div><br></div><div>True, but a =
list inside a list like that does not happen either. We are both on the sam=
e scope but inside another=C2=A0</div><div><br></div><div>In any case<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;"> you have to =
admit</span></div><div><span style=3D"display: inline !important; float: no=
ne; background-color: transparent; color: rgb(34, 34, 34); font-family: &qu=
ot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-styl=
e: 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;"><br></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"courier new,monospac=
e">template&lt;Concept T, class A&gt;</font></span></div><div><span style=
=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none; text-in=
dent: 0px; letter-spacing: normal; font-size: 13px; font-style: normal; fon=
t-variant: normal; font-weight: 400; text-decoration: none; word-spacing: 0=
px; display: inline !important; white-space: normal; orphans: 2; float: non=
e; -webkit-text-stroke-width: 0px; background-color: transparent;"><font fa=
ce=3D"courier new,monospace"></font><br></span></div><div><span style=3D"te=
xt-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: =
0px; letter-spacing: normal; font-size: 13px; font-variant: normal; word-sp=
acing: 0px; display: inline !important; white-space: normal; orphans: 2; fl=
oat: none; -webkit-text-stroke-width: 0px; background-color: transparent;">=
<span style=3D"text-align: left; color: rgb(34, 34, 34); text-transform: no=
ne; 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; orphans: 2;=
 float: none; -webkit-text-stroke-width: 0px; background-color: transparent=
;"><font face=3D"courier new,monospace">template&lt;Concept T U, class A&gt=
;</font></span></span></div><div><span style=3D"text-align: left; color: rg=
b(34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing: norm=
al; font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-s=
ize: 13px; font-variant: normal; word-spacing: 0px; display: inline !import=
ant; white-space: normal; orphans: 2; float: none; -webkit-text-stroke-widt=
h: 0px; background-color: transparent;"><b></b><i></i><u></u><sub></sub><su=
p></sup><strike></strike><font face=3D"courier new,monospace"></font><br></=
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-family: =
&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-v=
ariant: normal; word-spacing: 0px; display: inline !important; white-space:=
 normal; orphans: 2; float: none; -webkit-text-stroke-width: 0px; backgroun=
d-color: transparent;">are pretty self explanatory and the questions that a=
rise for a newcomer can be answered by deduction.=C2=A0</span></div><div><s=
pan style=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none=
; text-indent: 0px; letter-spacing: normal; font-family: &quot;Arial&quot;,=
&quot;Helvetica&quot;,sans-serif; 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;"><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: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 1=
3px; font-variant: normal; word-spacing: 0px; display: inline !important; w=
hite-space: normal; orphans: 2; float: none; -webkit-text-stroke-width: 0px=
; background-color: transparent;">Where </span><span style=3D"text-align: l=
eft; 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; orphans: 2; float: none; =
-webkit-text-stroke-width: 0px; background-color: transparent;"><span style=
=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none; text-in=
dent: 0px; letter-spacing: normal; font-size: 13px; font-style: normal; fon=
t-variant: normal; font-weight: 400; text-decoration: none; word-spacing: 0=
px; display: inline !important; white-space: normal; orphans: 2; float: non=
e; -webkit-text-stroke-width: 0px; background-color: transparent;"><font fa=
ce=3D"arial,sans-serif">braces do rise questions</font> impossible to answe=
r <i>without learning.</i><font face=3D"arial,sans-serif">=C2=A0</font></sp=
an></span></div><div><span style=3D"text-align: left; color: rgb(34, 34, 34=
); text-transform: none; text-indent: 0px; letter-spacing: normal; font-siz=
e: 13px; font-variant: normal; word-spacing: 0px; display: inline !importan=
t; white-space: normal; orphans: 2; float: none; -webkit-text-stroke-width:=
 0px; background-color: transparent;"><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">In=
stantiation? Inline Definition? <span style=3D"display: inline !important; =
float: none; background-color: transparent; color: rgb(34, 34, 34); font-fa=
mily: arial,sans-serif; font-size: 13px; font-style: normal; font-variant: =
normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: l=
eft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit=
-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">Scope? </=
span>Relation to &lt;&gt;? Alternative to &lt;&gt;?=C2=A0</font></span></sp=
an></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/e69010d8-c8b0-4a1e-999f-af5dff75a8f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e69010d8-c8b0-4a1e-999f-af5dff75a8f2=
%40isocpp.org</a>.<br />

------=_Part_11044_1313629676.1530260295232--

------=_Part_11043_2127091215.1530260295232--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">template&lt;Concept T U, class A&gt;</div><div style=3D"width: =
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sa=
ns-serif; color: rgb(31, 73, 125); text-align: initial; background-color: r=
gb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initial=
; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31,=
 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">wher=
e do I put const?</div><div style=3D"width: 100%; font-size: initial; font-=
family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 12=
5); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><=
div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate =
Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial;=
 background-color: rgb(255, 255, 255);">template&lt;Concept T const U, clas=
s A&gt;</div><div style=3D"width: 100%; font-size: initial; font-family: Ca=
libri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-a=
lign: initial; background-color: rgb(255, 255, 255);"><span style=3D"font-s=
ize: initial; text-align: initial; line-height: initial;"><br></span></div>=
<div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate=
 Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial=
; background-color: rgb(255, 255, 255);"><span style=3D"font-size: initial;=
 text-align: initial; line-height: initial;">Would the committee be forced =
to make a final decision on</span></div><div style=3D"width: 100%; font-siz=
e: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; colo=
r: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 2=
55);"><span style=3D"font-size: initial; text-align: initial; line-height: =
initial;">&nbsp;east const vs const west?</span></div>                     =
                                                                           =
                                     <div style=3D"width: 100%; font-size: =
initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: =
rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255)=
;"><br style=3D"display:initial"></div>                                    =
                                                                           =
                                                                           =
         <div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro=
', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; ba=
ckground-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackBerry=
&nbsp;portable&nbsp;Babbage&nbsp;Device</div>                              =
                                                                           =
                                                                         <t=
able width=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <=
tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: initia=
l; background-color: rgb(255, 255, 255);">                           <div s=
tyle=3D"border-style: solid none none; border-top-color: rgb(181, 196, 223)=
; border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alp=
ha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>mihailnajdenov=
@gmail.com</div><div><b>Sent: </b>Friday, June 29, 2018 4:18 AM</div><div><=
b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b>st=
d-proposals@isocpp.org</div><div><b>Cc: </b>mihailnajdenov@gmail.com</div><=
div><b>Subject: </b>[std-proposals] Re: Concepts: Investigating implicit ty=
pe-name introduction</div></div></td></tr></tbody></table><div style=3D"bor=
der-style: solid none none; border-top-color: rgb(186, 188, 209); border-to=
p-width: 1pt; font-size: initial; text-align: initial; background-color: rg=
b(255, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div d=
ir=3D"ltr"><br><br>On Friday, June 29, 2018 at 5:44:20 AM UTC+3, Nicol Bola=
s 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 Tu=
esday, June 26, 2018 at 3:34:21 AM UTC-4, <a>mihailn...@gmail.com</a> 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 Monday, June 2=
5, 2018 at 11:22:43 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 Monday, June 25, 2018 at 3:20:29 PM UTC-4,=
 <a>mihailn...@gmail.com</a> wrote:</div></blockquote></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><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></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"><ul><li></li><li>Completely "flat"=
 and inflexible - no composition or decomposition. As a result all type inf=
ormation about the names is actually always hidden. A bit better in the tem=
plate&lt;&gt; variant, because one can add other names/constrains. <br></li=
><li>Extremely confusing "dual use" of concepts - sometimes they look like =
a template instantiation, sometimes they look like something b/w initialize=
r list and structured bindings.<br></li><li>The syntax visually overloads a=
lready quite common syntax - Something{}, class Something{};</li></ul><div>=
Given all this, the difference b/w standard notation with tailored concept =
VS name introducer does not seem big and significant enough.</div><div><br>=
Still, undeniably there is repetition that might lead to some errors.</div>=
<div>Can we have minimum solution to that alone? Can we make <font face=3D"=
courier new,monospace">template&lt;&gt;</font> optional if <font face=3D"co=
urier new,monospace">requires</font> is used?</div><div><br></div><div>In o=
ther words</div><div><br></div><div><font face=3D"courier new,monospace">re=
quires Mergeable&lt;In,In2,Out&gt;<br>Out merge(In, In2, Out);</font></div>=
<div><font face=3D"courier new,monospace"><br></font></div><div>Will introd=
uce <font face=3D"courier new,monospace">In</font>, <font face=3D"courier n=
ew,monospace">In2</font> and <font face=3D"courier new,monospace">Out</font=
>.&nbsp;</div></div></blockquote><div><br></div><div>How is this not new sy=
ntax? Because it doesn't use a new symbol? It's using existing symbols in n=
ew ways, just like {} does. For example:<br></div></div></blockquote><div><=
br></div><div>No, {} is used in a new context, creating new <i>construct</i=
>. No new constructs are created here, simply using-is-a-declaration.</div>=
</div></blockquote><div><br></div><div>"New syntax", "new feature", "new co=
ntext", "new construct", these phrases don't mean anything in an absolute s=
ense of the language.<br></div><div><br></div><div>You want to cause a temp=
late instantiation (ie: what `ConceptName&lt;...&gt;` is) to create templat=
e parameters. That is a new thing; it is nothing like C++ has ever done bef=
ore with template instantiation. But you don't want to make this a general =
feature of template instantiation. No, it only works on concept variable te=
mplates, and only when used in a `requires` clause. Or maybe only from with=
in <i>certain</i> `requires` clauses; those replacing template headers.<br>=
</div><div><br></div><div>It doesn't matter if you can argue that this is o=
r isn't a "new context" or "new construct" or whatever by some arbitrary de=
finition. What matters is behavior and the ability of people to understand =
what's going on. It is undeniably novel behavior for a template instantiati=
on to introduce identifiers using &lt;&gt; syntax. As such, I see no reason=
 why this is any easier to understand than using a different token to intro=
duce such identifiers.</div><div><br></div><div>Users will have to learn it=
 either way. Your hypothetical time traveler will be equally baffled. Thoug=
h at least with `{}`, they'll immediately know something special is going o=
n and thus be able to track down what it is.<br></div><div><br></div><div>A=
t least with a different token, concepts can <i>consistently</i> introduce =
names anywhere. And it will use a syntax that <i>always</i> means "introduc=
e names". If you see {}, you're getting names introduced. If you see &lt;&g=
t;, a template is being instantiated. This is a simple and easily digestibl=
e rule.<br></div><div><br></div><div>With yours, you're not sure if &lt;&gt=
; means "introduce names" in addition to "template arguments" without looki=
ng at the context.</div><br><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><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></div><div>1. `Name&lt;...&gt;` always means "specialize=
 this template". But that's not happening here. Or rather it is, but that's=
 not <i>all</i> that's happening here.</div><div>2. `&lt;&gt;` doesn't decl=
are identifiers without explaining what those identifiers actually are. Tha=
t is, without `typename`, `template`, or an actual type's name.&nbsp;</div>=
</div></blockquote><div>&nbsp;</div><div>The same argument can be made abou=
t both name introducers and even shorthand notation.</div></div></blockquot=
e><div><br></div><div>My point was to show that your syntax fails at meetin=
g your own standards. These are the reasons you yourself gave for why the o=
ther terse syntaxes are wrong, yet your own syntax falls afoul of them.</di=
v><div><br></div><div>My issue with your syntax has nothing to do with it b=
eing "new" or whatever. The main reason why <i>I</i> don't like your syntax=
 is because it overloads the meaning of &lt;&gt;, but only in a special pla=
ce. Say what you will about Herb's syntax, but his {} can be used <i>anywhe=
re</i> that concepts are employed. Consistency and uniformity are an aspect=
 that your (and Bjarne's template introduction syntax of any form) syntax l=
acks.<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><font face=3D"courier new,monospace"></font></div><div><fo=
nt face=3D"courier new,monospace">template&lt;template&lt;typename&gt; clas=
s X&gt; concept C2 =3D true;</font></div><div><font face=3D"courier new,mon=
ospace"><br></font></div><div><font face=3D"courier new,monospace">template=
&lt;C2 X&gt; void f2(); <i>//&lt; WTF is X, must look the concept</i></font=
></div><div><i></i><br></div><div>I am willing to argue, this is actually m=
ore clear in that particular case:</div><div><b></b><i></i><u></u><sub></su=
b><sup></sup><strike></strike><br></div><div><font face=3D"courier new,mono=
space">requires C2&lt;X&gt; void f2(); <i>//&lt;&nbsp;<span style=3D"text-a=
lign:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-sp=
acing:normal;font-family:courier new,monospace;font-size:13px;font-variant:=
normal;font-weight:400;text-decoration:none;word-spacing:0px;display:inline=
!important;white-space:normal;float:none;background-color:transparent">X is=
 what is written b/w the &lt;&gt; of the concept!&nbsp;</span></i></font><d=
iv><br></div><div>The fact that a concept, which is a template,<i> is used =
as such</i> is a huge plus for&nbsp;<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">requ=
ires <font face=3D"arial,sans-serif">in general.</font></span></div></div><=
/div></blockquote><div><br></div><div>I fail to see how this is a benefit. =
Your new syntax isn't shorter than the current syntax. And neither syntax m=
akes it clear what `X` is. If the user is unfamiliar with `C2`, they have t=
o ask "WTF is X", regardless of which syntax is used.</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><blockqu=
ote 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>3. This new form of `=
&lt;&gt;` only works in a `requires` clause.<br></div></div></blockquote><d=
iv><div><br></div><div>It is not about &lt;&gt;, it is exclusively about 'r=
equires'.<br></div></div></div></blockquote><div><br></div><div>And yet, it=
 uses &lt;&gt;, which has a well-established meaning. And that well-establi=
shed meaning is being changed by `requires`.</div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div></div><div>Alterna=
tively,&nbsp; if we would feel better, might be <span style=3D"background-c=
olor: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-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;color:rgb(34,34,34);display:inline;float:non=
e;font-family:courier new,monospace;font-size:13px;font-style:normal;font-v=
ariant:normal;font-weight:400;letter-spacing:normal;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;text-align:left;text-decoration:none;=
text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">te=
mplate Mergeable&lt;In,In2,Out&gt;<font face=3D"&quot;Arial&quot;,&quot;Hel=
vetica&quot;,sans-serif" style=3D"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;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">&nbsp; </font></span><span style=3D"back=
ground-color:transparent;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;color:rgb(34,34,34);display:inline;f=
loat:none;font-family:courier new,monospace;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;letter-spacing:normal;margin-bottom:0=
px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0px;paddi=
ng-left:0px;padding-right:0px;padding-top:0px;text-align:left;text-decorati=
on:none;text-indent:0px;text-transform:none;white-space:normal;word-spacing=
:0px">Out merge(In, In2, Out);<font face=3D"arial,sans-serif" 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">.</=
font></span> <br></div></div></div></blockquote><div><br></div><div>It's st=
ill using &lt;&gt; to do something that &lt;&gt; doesn't normally do.<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"=
><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></div><div>4=
.. `requires` now has a third meaning. It's similar to the original meaning,=
 but because it's applied as a prefix, it now performs double-duty as a tem=
plate header. At least `template&lt;Mergable&gt;` looks like a template hea=
der.<br></div></div></blockquote><div>&nbsp;</div><div>But <font face=3D"co=
urier new,monospace">requires</font> is already part of the template header=
!</div></div></blockquote><div><br></div><div>There's a difference between =
"part of" something and "is something". Your `requires` is not merely "part=
 of" the template header; it <i>is a template header</i>. Just like Bjarne'=
s original template introduction syntax made `Mergable{...}` be the actual =
template header.<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>I don't see any of these particularl=
y troubling.&nbsp; Yes, there is some new context-sensitive interpretation,=
 which is still better then new syntax for a bonus feature.&nbsp;</div><div=
><br></div><div>But lets equate the new syntax (introducers) to these new r=
ules in terms of how troubling they are.<i> These new rules give us more po=
wer, full power</i>.</div></div></blockquote><div><br></div><div>How? What =
new "power" do they give us that Herb's syntax couldn't? Yes, P0745 specifi=
cally says that they're type names, but that doesn't have to be that way. T=
here's no reason it couldn't be extended to arbitrary template parameters o=
f a concept.<br></div><div><br></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>They also eliminate the question "what is a name in=
troducer". This topic no longer exist. Yes, new question arises - where are=
 these template arguments coming from, but that is a trivial question to an=
swer.</div></div></blockquote><div><br></div><div>You skipped a question: h=
ow is a template instantiation legal if some of the arguments are names tha=
t don't exist? That's a question that your syntax creates, because it overl=
oads existing syntax that already has a well-established meaning.</div><div=
><br></div>There is a difference between taking a syntax that couldn't be u=
sed
 at all and giving it meaning, and taking a syntax that already exists=20
with some meaning and changing what that means. Personally, I prefer the fo=
rmer to the latter.<br></div></blockquote><div><br></div><div>And we have t=
o leave it there. We agree to disagree. For me (a bit weird/awkward) new ru=
les and full power is better, for you clear new syntax is better even if it=
 risks creating new dialect for template creation.&nbsp; <br>I can't see ho=
w anyone can convince the other of the opposite and that's OK.<br></div><di=
v>&nbsp;</div><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"=
><div><br></div><div><div>You also skipped "when can we use that ability of=
 template=20
instantiation to create template parameters?" Or more to the point, "why ca=
n I only use it in a prefixed `requires` clause?"<br></div><div><br></div><=
div>This is reason #1 why I dislike template introduction syntax: it create=
s new syntax that can only be used in a narrow way. Herb's syntax at least =
has the benefit of being consistent, rather than this giant wart you can so=
metime use.<br></div><div><br></div>On Wednesday, June 27, 2018 at 6:40:40 =
AM UTC-4, <a>mihailn...@gmail.com</a> wrote:<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 27, 2018 at 12:44:13 PM UTC+3,=
 Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Outside the=
 debate of the you-know-that syntax, I think this<br></div><div>demand is e=
asy to fulfill.&nbsp; I think we can allow multi-argument<br></div><div>con=
strained parameters like this:<br></div><div><br></div><div>&nbsp;&nbsp;&nb=
sp; template &lt;Mergeable In In2 Out, class Other&gt;<br></div><div>&nbsp;=
 &nbsp; Out merge(In, In2, Out);<br></div></blockquote><div><br></div><div>=
I actually like that idea.</div></div></blockquote><div><br></div><div>So,
 your definition of "new syntax" does not include "list of identifiers with=
out separators in places where that's not normally allowed".</div><div><br>=
</div><div>I'm starting to get the impression that your position is not bas=
ed on problems with "new syntax" in general or even terse templates as an i=
dea. It seems more like "not curly braces!" That you'll accept any solution=
 as long as it doesn't involve curly braces (and probably parentheses or sq=
uare brackets).<br></div></div></div></blockquote><div><br></div><div>I was=
 never ageist terse/natural as I said in the other topic. But, yes am again=
st it if it introduces new syntax for humans only and/or new constructs. <b=
r>Introducers are a new construct, and I believe we can talk about that in =
absolute sense.&nbsp;&nbsp; <br>The reason you like in-place is the fact th=
at it makes this new construct usable across the rest of the templates lang=
uage, creating consistency and giving power. <br>Here we agree to disagree,=
 and there is no point repeating my counter arguments.&nbsp;</div><div><br>=
</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><d=
iv></div><div><br></div><div>I'm not exactly enamored with curly braces mys=
elf. But you have to admit that it's a <i>lot</i> less novel of syntax comp=
ared to "list of identifiers with no separators that somehow introduce temp=
late parameter names based on a concept". At least curly-braced-bound lists=
 are a thing in C++ that people are used to. They may have different meanin=
g, but it is a normal feature of the language to see `{identifier, identifi=
er, identifier}` in code.</div></div></div></blockquote><div><br></div><div=
>I am hard press to remember a single place where identifiers are introduce=
d with a similar syntax. <br>Sure we have seen a lot of {something, somethi=
ng}, but that was, until now, an act of initialization (ever since C) or en=
um {something, something}; an act of definition (sure identifiers are intro=
duced, but are in the scope, given by the braces. We reaffirmed that rule w=
ith enum class).</div><div>&nbsp;<br></div><div>This inevitably creates men=
tal confusion (to some extend, at some point, for some people, etc) as it l=
iterally uses the same syntax in a completely new context for completely ne=
w meaning.<br></div><div>&nbsp;</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><br></div><div>By contrast, `identifier i=
dentifier identifier` doesn't happen in C++. Not as a list of things, at le=
ast.<br></div></div></div></blockquote><div><br></div><div>True, but a list=
 inside a list like that does not happen either. We are both on the same sc=
ope but inside another&nbsp;</div><div><br></div><div>In any case<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;"> you have to admi=
t</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"text-align: left; color: r=
gb(34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing: nor=
mal; 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: =
0px; background-color: transparent;"><font face=3D"courier new,monospace">t=
emplate&lt;Concept T, class A&gt;</font></span></div><div><span style=3D"te=
xt-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: =
0px; letter-spacing: normal; font-size: 13px; font-style: normal; font-vari=
ant: normal; font-weight: 400; text-decoration: none; word-spacing: 0px; di=
splay: inline !important; white-space: normal; orphans: 2; float: none; -we=
bkit-text-stroke-width: 0px; background-color: transparent;"><font face=3D"=
courier new,monospace"></font><br></span></div><div><span style=3D"text-ali=
gn: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; l=
etter-spacing: normal; font-size: 13px; font-variant: normal; word-spacing:=
 0px; display: inline !important; white-space: normal; orphans: 2; float: n=
one; -webkit-text-stroke-width: 0px; background-color: transparent;"><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-variant: normal; font-weight: 400; text-decoration: none; word-spaci=
ng: 0px; display: inline !important; white-space: normal; orphans: 2; float=
: none; -webkit-text-stroke-width: 0px; background-color: transparent;"><fo=
nt face=3D"courier new,monospace">template&lt;Concept T U, class A&gt;</fon=
t></span></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: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 1=
3px; font-variant: normal; word-spacing: 0px; display: inline !important; w=
hite-space: normal; orphans: 2; float: none; -webkit-text-stroke-width: 0px=
; background-color: transparent;"><b></b><i></i><u></u><sub></sub><sup></su=
p><strike></strike><font face=3D"courier new,monospace"></font><br></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-family: &quot;=
Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-variant=
: normal; word-spacing: 0px; display: inline !important; white-space: norma=
l; orphans: 2; float: none; -webkit-text-stroke-width: 0px; background-colo=
r: transparent;">are pretty self explanatory and the questions that arise f=
or a newcomer can be answered by deduction.&nbsp;</span></div><div><span st=
yle=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none; text=
-indent: 0px; letter-spacing: normal; font-family: &quot;Arial&quot;,&quot;=
Helvetica&quot;,sans-serif; font-size: 13px; font-variant: normal; word-spa=
cing: 0px; display: inline !important; white-space: normal; orphans: 2; flo=
at: none; -webkit-text-stroke-width: 0px; background-color: transparent;"><=
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-fam=
ily: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; f=
ont-variant: normal; word-spacing: 0px; display: inline !important; white-s=
pace: normal; orphans: 2; float: none; -webkit-text-stroke-width: 0px; back=
ground-color: transparent;">Where </span><span style=3D"text-align: left; c=
olor: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter-spaci=
ng: normal; font-size: 13px; font-variant: normal; word-spacing: 0px; displ=
ay: inline !important; white-space: normal; orphans: 2; float: none; -webki=
t-text-stroke-width: 0px; background-color: transparent;"><span style=3D"te=
xt-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: =
0px; letter-spacing: normal; font-size: 13px; font-style: normal; font-vari=
ant: normal; font-weight: 400; text-decoration: none; word-spacing: 0px; di=
splay: inline !important; white-space: normal; orphans: 2; float: none; -we=
bkit-text-stroke-width: 0px; background-color: transparent;"><font face=3D"=
arial,sans-serif">braces do rise questions</font> impossible to answer <i>w=
ithout learning.</i><font face=3D"arial,sans-serif">&nbsp;</font></span></s=
pan></div><div><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-variant: normal; word-spacing: 0px; display: inline !important; whi=
te-space: normal; orphans: 2; float: none; -webkit-text-stroke-width: 0px; =
background-color: transparent;"><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;"><font face=3D"arial,sans-serif">Instanti=
ation? Inline Definition? <span style=3D"display: inline !important; float:=
 none; background-color: transparent; color: rgb(34, 34, 34); font-family: =
arial,sans-serif; font-size: 13px; font-style: normal; font-variant: normal=
; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; t=
ext-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-=
stroke-width: 0px; white-space: normal; word-spacing: 0px;">Scope? </span>R=
elation to &lt;&gt;? Alternative to &lt;&gt;?&nbsp;</font></span></span></d=
iv></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e69010d8-c8b0-4a1e-999f-af5dff75a8f2%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/e69010d8-c8b0-4a1e-999f-af5dff75=
a8f2%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

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

.

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

On Fri, 29 Jun 2018, 13:53 Tony V E, <tvaneerd@gmail.com> wrote:

> template<Concept T U, class A>
>
> where do I put const?
>

You don't... do you? Maybe I'm missing out on something fundamental, but
const doesn't make sense to me in this context.


> template<Concept T const U, class A>
>
> Would the committee be forced to make a final decision on
>  east const vs const west?
>

--
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/CAC%2B0CCPqv5eoVLgXcuEaCSj%3D0qeV-UJ0%3Db8xEEknmkfPJMuw2w%40mail.gmail.com.

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

<div dir=3D"auto"><div dir=3D"auto"></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">On Fri, 29 Jun 2018, 13:53 Tony V E, &lt;<a href=3D"mailto:t=
vaneerd@gmail.com" target=3D"_blank" rel=3D"noreferrer">tvaneerd@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 lang=3D"en-US" =
style=3D"background-color:rgb(255,255,255);line-height:initial">           =
                                                                           =
<div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate P=
ro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backg=
round-color:rgb(255,255,255)">template&lt;Concept T U, class A&gt;</div><di=
v style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&=
#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgrou=
nd-color:rgb(255,255,255)"><br></div><div style=3D"width:100%;font-size:ini=
tial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rg=
b(31,73,125);text-align:initial;background-color:rgb(255,255,255)">where do=
 I put const?</div></div></blockquote></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">You don&#39;t... do you? Maybe I&#39;m missing out on someth=
ing fundamental, but const doesn&#39;t make sense to me in this context.</d=
iv><div dir=3D"auto"><br></div><div class=3D"gmail_quote" dir=3D"auto"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div lang=3D"en-US" style=3D"background-color:rg=
b(255,255,255);line-height:initial"><div style=3D"width:100%;font-size:init=
ial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb=
(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br></div=
><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate =
Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;back=
ground-color:rgb(255,255,255)">template&lt;Concept T const U, class A&gt;</=
div><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Sla=
te Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;b=
ackground-color:rgb(255,255,255)"><span style=3D"font-size:initial;text-ali=
gn:initial;line-height:initial"><br></span></div><div style=3D"width:100%;f=
ont-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-se=
rif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,25=
5)"><span style=3D"font-size:initial;text-align:initial;line-height:initial=
">Would the committee be forced to make a final decision on</span></div><di=
v style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&=
#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgrou=
nd-color:rgb(255,255,255)"><span style=3D"font-size:initial;text-align:init=
ial;line-height:initial">=C2=A0east const vs const west?</span></div></div>=
</blockquote></div></div>

<p></p>

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

--000000000000a1cc96056fc78ada--

.

--00000000000066a34e056fca2e42
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 29, 2018 at 9:08 AM, Jake Arkinstall <jake.arkinstall@gmail.com>
wrote:

>
> On Fri, 29 Jun 2018, 13:53 Tony V E, <tvaneerd@gmail.com> wrote:
>
>> template<Concept T U, class A>
>>
>> where do I put const?
>>
>
> You don't... do you? Maybe I'm missing out on something fundamental, but
> const doesn't make sense to me in this context.
>

ah maybe not

>
>
>> template<Concept T const U, class A>
>>
>> Would the committee be forced to make a final decision on
>>  east const vs const west?
>>
> --
> 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/CAC%2B0CCPqv5eoVLgXcuEaCSj%3D0qeV-
> UJ0%3Db8xEEknmkfPJMuw2w%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPqv5eoVLgXcuEaCSj%3D0qeV-UJ0%3Db8xEEknmkfPJMuw2w%40mail.gmail.com?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/CAOHCbisG89%2BWYCcB4h-U3raf3VSMPXABHLpJ8xyY3G%3DuKsd%3DTA%40mail.gmail.com.

--00000000000066a34e056fca2e42
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 Fri, Jun 29, 2018 at 9:08 AM, Jake Arkinstall <span dir=3D"ltr">&lt;=
<a href=3D"mailto:jake.arkinstall@gmail.com" target=3D"_blank">jake.arkinst=
all@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"auto"><span class=3D""><div dir=3D"auto"></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr">On Fri, 29 Jun 2018, 13:53 Tony V E, &lt;<a href=
=3D"mailto:tvaneerd@gmail.com" rel=3D"noreferrer" target=3D"_blank">tvaneer=
d@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 sty=
le=3D"background-color:rgb(255,255,255);line-height:initial" lang=3D"en-US"=
>                                                                          =
            <div style=3D"width:100%;font-size:initial;font-family:Calibri,=
&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:i=
nitial;background-color:rgb(255,255,255)">template&lt;Concept T U, class A&=
gt;</div><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#3=
9;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:init=
ial;background-color:rgb(255,255,255)"><br></div><div style=3D"width:100%;f=
ont-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-se=
rif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,25=
5)">where do I put const?</div></div></blockquote></div><div dir=3D"auto"><=
br></div></span><div dir=3D"auto">You don&#39;t... do you? Maybe I&#39;m mi=
ssing out on something fundamental, but const doesn&#39;t make sense to me =
in this context.</div></div></blockquote><div><br></div><div>ah maybe not <=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span class=3D"">=
<div dir=3D"auto"><br></div><div class=3D"gmail_quote" dir=3D"auto"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"background-color:rgb(255,255,255);lin=
e-height:initial" lang=3D"en-US"><div style=3D"width:100%;font-size:initial=
;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31=
,73,125);text-align:initial;background-color:rgb(255,255,255)"><br></div><d=
iv style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro=
&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgro=
und-color:rgb(255,255,255)">template&lt;Concept T const U, class A&gt;</div=
><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate =
Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;back=
ground-color:rgb(255,255,255)"><span style=3D"font-size:initial;text-align:=
initial;line-height:initial"><br></span></div><div style=3D"width:100%;font=
-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif=
;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"=
><span style=3D"font-size:initial;text-align:initial;line-height:initial">W=
ould the committee be forced to make a final decision on</span></div><div s=
tyle=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39=
;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-=
color:rgb(255,255,255)"><span style=3D"font-size:initial;text-align:initial=
;line-height:initial">=C2=A0east const vs const west?</span></div></div></b=
lockquote></div></span></div>

<p></p>

-- <br><span class=3D"">
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/CAC%2B0CCPqv5eoVLgXcuEaCSj%3D0qeV-UJ0=
%3Db8xEEknmkfPJMuw2w%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAC%<wbr>2B0CCPqv5eoVLgXcuEaCSj%3D0qeV-<wbr>UJ0%3Db8xE=
EknmkfPJMuw2w%<wbr>40mail.gmail.com</a>.<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/CAOHCbisG89%2BWYCcB4h-U3raf3VSMPXABHL=
pJ8xyY3G%3DuKsd%3DTA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbisG89=
%2BWYCcB4h-U3raf3VSMPXABHLpJ8xyY3G%3DuKsd%3DTA%40mail.gmail.com</a>.<br />

--00000000000066a34e056fca2e42--

.

------=_Part_54690_1605119884.1530668909237
Content-Type: multipart/alternative;
 boundary="----=_Part_54691_850168475.1530668909237"

------=_Part_54691_850168475.1530668909237
Content-Type: text/plain; charset="UTF-8"

Well, the new mailing strongly suggests that we all lose
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1141r0.html>.
Well, for a certain definition of "lose", I suppose.

What Sutter, Stroustrup, and 10 others (seriously, is that the longest
"authors" list in proposal history?) seem to have agreed on is basically
verbose terse syntax.

The core syntax is that adjective/noun stuff that was thrown around,
discarded, and then resurrected again. So instead of saying `ConceptName
param`, or even `ConceptName{} param`, you have to say `ConceptName auto
param`. I am very thankful it isn't `ConceptName typename param`.

Of course, this creates a bit of confusion around function parameters and
return types, since they both use the same `auto` keyword that means
different things in different contexts. Granted, that would have happened
regardless of terse syntax. And this syntax does have one unique advantage
in this respect: you get to use `decltype(auto)` return deduction alongside
`ConceptName` constraints. So that's something.

Also, we get to use `ConceptName auto/typename/template` when constraining
explicit template parameters. This unpleasantness is mitigated because
`typename` is optional; the most common case of a type constraint doesn't
need the extra verbosity. I dislike this, but I understand the importance
of being able to tell the difference.

Oh, and we get to do `ConceptName auto variableName` too. Though like with
return types, it does let us use `decltype(auto)` syntax, which is
occasionally nice. And the `auto` is at least not required. And uniformly
not required: in all of the places where `auto` does value deduction rather
than "I'm a template parameter", the `auto` is optional.

OK yes, this is all more verbose. But hey, at least we didn't introduce any
"new syntax", something that would be genuinely useful like a way to
actually name these deduced types. That would have been terrible ;)

Yes, I would have preferred Herb's syntax, because it means I don't have to
use `decltype`, but I can live with this.

--
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/4a42b005-ca66-474c-83ea-4273836db2df%40isocpp.org.

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

<div dir=3D"ltr"><div>Well, the new mailing strongly suggests that <a href=
=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1141r0.html">w=
e all lose</a>. Well, for a certain definition of &quot;lose&quot;, I suppo=
se.<br></div><div><br></div><div>What Sutter, Stroustrup, and 10 others (se=
riously, is that the longest &quot;authors&quot; list in proposal history?)=
 seem to have agreed on is basically verbose terse syntax.</div><div><br></=
div><div>The core syntax is that adjective/noun stuff that was thrown aroun=
d, discarded, and then resurrected again. So instead of saying `ConceptName=
 param`, or even `ConceptName{} param`, you have to say `ConceptName auto p=
aram`. I am very thankful it isn&#39;t `ConceptName typename param`.<br></d=
iv><div><br></div><div>Of course, this creates a bit of confusion around fu=
nction parameters and return types, since they both use the same `auto` key=
word that means different things in different contexts. Granted, that would=
 have happened regardless of terse syntax. And this syntax does have one un=
ique advantage in this respect: you get to use `decltype(auto)` return dedu=
ction alongside `ConceptName` constraints. So that&#39;s something.<br></di=
v><div><br></div><div>Also, we get to use `ConceptName auto/typename/templa=
te` when constraining explicit template parameters. This unpleasantness is =
mitigated because `typename` is optional; the most common case of a type co=
nstraint doesn&#39;t need the extra verbosity. I dislike this, but I unders=
tand the importance of being able to tell the difference.<br></div><div><br=
></div><div>Oh, and we get to do `ConceptName auto variableName` too. Thoug=
h like with return types, it does let us use `decltype(auto)` syntax, which=
 is occasionally nice. And the `auto` is at least not required. And uniform=
ly not required: in all of the places where `auto` does value deduction rat=
her than &quot;I&#39;m a template parameter&quot;, the `auto` is optional.<=
br></div><div><br></div><div>OK yes, this is all more verbose. But hey, at =
least we didn&#39;t introduce any &quot;new syntax&quot;, something that wo=
uld be genuinely useful like a way to actually name these deduced types. Th=
at would have been terrible ;)</div><div><br></div><div>Yes, I would have p=
referred Herb&#39;s syntax, because it means I don&#39;t have to use `declt=
ype`, but I can live with this.<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/4a42b005-ca66-474c-83ea-4273836db2df%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4a42b005-ca66-474c-83ea-4273836db2df=
%40isocpp.org</a>.<br />

------=_Part_54691_850168475.1530668909237--

------=_Part_54690_1605119884.1530668909237--

.

------=_Part_19636_821315144.1530774575483
Content-Type: multipart/alternative;
 boundary="----=_Part_19637_236239217.1530774575483"

------=_Part_19637_236239217.1530774575483
Content-Type: text/plain; charset="UTF-8"



On Wednesday, July 4, 2018 at 4:48:29 AM UTC+3, Nicol Bolas wrote:
>
> Well, the new mailing strongly suggests that we all lose
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1141r0.html>.
> Well, for a certain definition of "lose", I suppose.
>
> What Sutter, Stroustrup, and 10 others (seriously, is that the longest
> "authors" list in proposal history?) seem to have agreed on is basically
> verbose terse syntax.
>
> The core syntax is that adjective/noun stuff that was thrown around,
> discarded, and then resurrected again. So instead of saying `ConceptName
> param`, or even `ConceptName{} param`, you have to say `ConceptName auto
> param`. I am very thankful it isn't `ConceptName typename param`.
>
> Of course, this creates a bit of confusion around function parameters and
> return types, since they both use the same `auto` keyword that means
> different things in different contexts. Granted, that would have happened
> regardless of terse syntax. And this syntax does have one unique advantage
> in this respect: you get to use `decltype(auto)` return deduction alongside
> `ConceptName` constraints. So that's something.
>
> Also, we get to use `ConceptName auto/typename/template` when constraining
> explicit template parameters. This unpleasantness is mitigated because
> `typename` is optional; the most common case of a type constraint doesn't
> need the extra verbosity. I dislike this, but I understand the importance
> of being able to tell the difference.
>
> Oh, and we get to do `ConceptName auto variableName` too. Though like with
> return types, it does let us use `decltype(auto)` syntax, which is
> occasionally nice. And the `auto` is at least not required. And uniformly
> not required: in all of the places where `auto` does value deduction rather
> than "I'm a template parameter", the `auto` is optional.
>
> OK yes, this is all more verbose. But hey, at least we didn't introduce
> any "new syntax", something that would be genuinely useful like a way to
> actually name these deduced types. That would have been terrible ;)
>
> Yes, I would have preferred Herb's syntax, because it means I don't have
> to use `decltype`, but I can live with this.
>

Oh, well it is not that bad, in any case I would take func(Concept auto)
over template func(Concept), although it is a syntax I doubt would have be
suggested if we worked on a clear slate. I also really hope, only one
concept is allowed.

Now if only we can get rid of introducers in favor Zhihao Yuan suggestion.


--
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/f8c9e628-d969-4709-9e77-9898f5b42a96%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, July 4, 2018 at 4:48:29 AM 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"><div>Well, the new mailing strongly suggests that <a onmousedown=3D"this=
..href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2=
FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2018%2Fp1141r0.html\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNHVeza6mmG2pwEBUNej6TN0hwrYmw&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.ope=
n-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2018%2Fp1141r0.html\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHVeza6mmG2pwEBUNej6TN0hwrYmw&#39;;return =
true;" href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p114=
1r0.html" target=3D"_blank" rel=3D"nofollow">we all lose</a>. Well, for a c=
ertain definition of &quot;lose&quot;, I suppose.<br></div><div><br></div><=
div>What Sutter, Stroustrup, and 10 others (seriously, is that the longest =
&quot;authors&quot; list in proposal history?) seem to have agreed on is ba=
sically verbose terse syntax.</div><div><br></div><div>The core syntax is t=
hat adjective/noun stuff that was thrown around, discarded, and then resurr=
ected again. So instead of saying `ConceptName param`, or even `ConceptName=
{} param`, you have to say `ConceptName auto param`. I am very thankful it =
isn&#39;t `ConceptName typename param`.<br></div><div><br></div><div>Of cou=
rse, this creates a bit of confusion around function parameters and return =
types, since they both use the same `auto` keyword that means different thi=
ngs in different contexts. Granted, that would have happened regardless of =
terse syntax. And this syntax does have one unique advantage in this respec=
t: you get to use `decltype(auto)` return deduction alongside `ConceptName`=
 constraints. So that&#39;s something.<br></div><div><br></div><div>Also, w=
e get to use `ConceptName auto/typename/template` when constraining explici=
t template parameters. This unpleasantness is mitigated because `typename` =
is optional; the most common case of a type constraint doesn&#39;t need the=
 extra verbosity. I dislike this, but I understand the importance of being =
able to tell the difference.<br></div><div><br></div><div>Oh, and we get to=
 do `ConceptName auto variableName` too. Though like with return types, it =
does let us use `decltype(auto)` syntax, which is occasionally nice. And th=
e `auto` is at least not required. And uniformly not required: in all of th=
e places where `auto` does value deduction rather than &quot;I&#39;m a temp=
late parameter&quot;, the `auto` is optional.<br></div><div><br></div><div>=
OK yes, this is all more verbose. But hey, at least we didn&#39;t introduce=
 any &quot;new syntax&quot;, something that would be genuinely useful like =
a way to actually name these deduced types. That would have been terrible ;=
)</div><div><br></div><div>Yes, I would have preferred Herb&#39;s syntax, b=
ecause it means I don&#39;t have to use `decltype`, but I can live with thi=
s.<br></div></div></blockquote><div><br></div><div>Oh, well it is not that =
bad, in any case I would take func(Concept auto) over template <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;">func(Concept), alt=
hough it is a syntax I doubt would have be suggested if we worked on a clea=
r slate. I also really hope, only one concept is allowed</span>.=C2=A0</div=
><div><br></div><div>Now if only we can get rid of introducers in favor Zhi=
hao Yuan suggestion.=C2=A0<span style=3D"display: inline !important; float:=
 none; background-color: transparent; color: rgb(136, 136, 136); 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; line-height: 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;"></span></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/f8c9e628-d969-4709-9e77-9898f5b42a96%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f8c9e628-d969-4709-9e77-9898f5b42a96=
%40isocpp.org</a>.<br />

------=_Part_19637_236239217.1530774575483--

------=_Part_19636_821315144.1530774575483--

.

On 4 July 2018 at 04:48, Nicol Bolas <jmckesson@gmail.com> wrote:
> Well, the new mailing strongly suggests that we all lose. Well, for a
> certain definition of "lose", I suppose.
>
> What Sutter, Stroustrup, and 10 others (seriously, is that the longest
> "authors" list in proposal history?) seem to have agreed on is basically
> verbose terse syntax.

Well, it's as long as I could make it in the time it took to discuss
that paper with all those authors and revise it before the
pre-meeting deadline, which took a little over a week.

> The core syntax is that adjective/noun stuff that was thrown around,
> discarded, and then resurrected again. So instead of saying `ConceptName
> param`, or even `ConceptName{} param`, you have to say `ConceptName auto
> param`. I am very thankful it isn't `ConceptName typename param`.

The 'typename' part was deliberately omitted; the adjective approach suggested
'ConceptName typename T param', but we already have a way to name a constrained
type with 'template <ConceptName T>'.

> Of course, this creates a bit of confusion around function parameters and
> return types, since they both use the same `auto` keyword that means
> different things in different contexts. Granted, that would have happened
> regardless of terse syntax. And this syntax does have one unique advantage

Correct.

> in this respect: you get to use `decltype(auto)` return deduction alongside
> `ConceptName` constraints. So that's something.

Sure, filling that gap was one of the goals; make auto work, and make
'constrained auto' work,
and by extension, make 'constrained decltype(auto)' work.

> Also, we get to use `ConceptName auto/typename/template` when constraining
> explicit template parameters. This unpleasantness is mitigated because

There is no 'ConceptName typename' nor 'ConceptName template' in that proposal.

> Oh, and we get to do `ConceptName auto variableName` too. Though like with
> return types, it does let us use `decltype(auto)` syntax, which is
> occasionally nice. And the `auto` is at least not required. And uniformly
> not required: in all of the places where `auto` does value deduction rather
> than "I'm a template parameter", the `auto` is optional.

This was high on the wishlist, at least for variable declarations. For
a constrained deduced
return type, it's not necessarily that fundamental, but nice-to-have.

> Yes, I would have preferred Herb's syntax, because it means I don't have to
> use `decltype`, but I can live with this.

The biggest reason for this paper was to try and find an approach that
more people can live 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/CAFk2RUbR9HrEh6vDv3n47v93ss0e7GdR6Nh69VLjEU%2BL%3DwqBig%40mail.gmail.com.

.

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

 I personally would have loved to have both 'Concept T' and 'Concept
typename T'  such that 'Concept T' would be a shorthand notation for
'Concept typename T'  aka, you can omit the 'typename'.

This is purely for teaching, learning & consistency because we could just
say 'stick a ConceptName to the left of any declaration to constrain it.

<auto x>; //value
<typename T>; // type
<Concept auto x; //constrained variable;
<Concept typename T>; // constrained type;
<Concept T> //  type, as a sane default short hand in template parameter
lists
-> Concept  {}  // value, as a sane, unambiguous default for functions
return type
Concept auto x =3D ...; //variable

I think it would make it easier to teach ( start with the explicit
notation, then mention the shorthands), because then concepts really
"constrain a declaration", wherever the declaration is,
And I think these kinds of simple, consistent rules make the language more
accessible, even if we expect experienced developers to always reach for
the shorthand syntax.


Le jeu. 5 juil. 2018 =C3=A0 09:54, Ville Voutilainen <ville.voutilainen@gma=
il.com>
a =C3=A9crit :

> On 4 July 2018 at 04:48, Nicol Bolas <jmckesson@gmail.com> wrote:
> > Well, the new mailing strongly suggests that we all lose. Well, for a
> > certain definition of "lose", I suppose.
> >
> > What Sutter, Stroustrup, and 10 others (seriously, is that the longest
> > "authors" list in proposal history?) seem to have agreed on is basicall=
y
> > verbose terse syntax.
>
> Well, it's as long as I could make it in the time it took to discuss
> that paper with all those authors and revise it before the
> pre-meeting deadline, which took a little over a week.
>
> > The core syntax is that adjective/noun stuff that was thrown around,
> > discarded, and then resurrected again. So instead of saying `ConceptNam=
e
> > param`, or even `ConceptName{} param`, you have to say `ConceptName aut=
o
> > param`. I am very thankful it isn't `ConceptName typename param`.
>
> The 'typename' part was deliberately omitted; the adjective approach
> suggested
> 'ConceptName typename T param', but we already have a way to name a
> constrained
> type with 'template <ConceptName T>'.
>
> > Of course, this creates a bit of confusion around function parameters a=
nd
> > return types, since they both use the same `auto` keyword that means
> > different things in different contexts. Granted, that would have happen=
ed
> > regardless of terse syntax. And this syntax does have one unique
> advantage
>
> Correct.
>
> > in this respect: you get to use `decltype(auto)` return deduction
> alongside
> > `ConceptName` constraints. So that's something.
>
> Sure, filling that gap was one of the goals; make auto work, and make
> 'constrained auto' work,
> and by extension, make 'constrained decltype(auto)' work.
>
> > Also, we get to use `ConceptName auto/typename/template` when
> constraining
> > explicit template parameters. This unpleasantness is mitigated because
>
> There is no 'ConceptName typename' nor 'ConceptName template' in that
> proposal.
>
> > Oh, and we get to do `ConceptName auto variableName` too. Though like
> with
> > return types, it does let us use `decltype(auto)` syntax, which is
> > occasionally nice. And the `auto` is at least not required. And uniform=
ly
> > not required: in all of the places where `auto` does value deduction
> rather
> > than "I'm a template parameter", the `auto` is optional.
>
> This was high on the wishlist, at least for variable declarations. For
> a constrained deduced
> return type, it's not necessarily that fundamental, but nice-to-have.
>
> > Yes, I would have preferred Herb's syntax, because it means I don't hav=
e
> to
> > use `decltype`, but I can live with this.
>
> The biggest reason for this paper was to try and find an approach that
> more people can live 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/CAFk2RUbR9Hr=
Eh6vDv3n47v93ss0e7GdR6Nh69VLjEU%2BL%3DwqBig%40mail.gmail.com
> .
>

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

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

<div dir=3D"ltr">=C2=A0I personally=C2=A0would have loved to have both &#39=
;Concept T&#39; and &#39;Concept typename=C2=A0T&#39;=C2=A0 such that &#39;=
Concept T&#39; would be a shorthand notation for &#39;Concept=C2=A0<span cl=
ass=3D"inbox-inbox-gr_ inbox-inbox-gr_8 inbox-inbox-gr-alert inbox-inbox-gr=
_spell inbox-inbox-gr_inline_cards inbox-inbox-gr_run_anim inbox-inbox-Cont=
extualSpelling" id=3D"inbox-inbox-8" style=3D"display:inline;border-bottom:=
2px solid transparent;background-repeat:no-repeat">typename</span>=C2=A0T&#=
39;=C2=A0 aka, you can omit the &#39;typename&#39;.<div><br></div><div>This=
 is purely for teaching, learning &amp; consistency because we could just s=
ay &#39;stick a ConceptName to the left of any declaration to constrain it.=
</div><div><br></div><div>&lt;auto x&gt;; //value</div><div>&lt;typename T&=
gt;; // type</div><div>&lt;Concept auto x; //constrained variable;</div><di=
v>&lt;Concept typename T&gt;; // constrained type;</div><div>&lt;Concept T&=
gt; //=C2=A0 type, as a sane default short hand in template parameter lists=
</div><div>-&gt; Concept=C2=A0 {}=C2=A0 // value, as a sane, unambiguous de=
fault for functions return type</div><div>Concept auto x =3D ...; //variabl=
e</div><div><br></div><div>I think it would make it easier to teach ( start=
 with the explicit notation, then mention the shorthands), because=C2=A0the=
n concepts really &quot;constrain a declaration&quot;, wherever the declara=
tion is,</div><div>And I think these kinds of simple, consistent rules make=
 the language more accessible, even if we expect experienced developers to =
always reach for the shorthand syntax.</div><div><br></div><div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0jeu. 5 juil. 2018 =C3=A0=C2=A0=
09:54, Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.com"=
>ville.voutilainen@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">On 4 July 2018 at 04:48, Nicol Bolas &lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt; wr=
ote:<br>
&gt; Well, the new mailing strongly suggests that we all lose. Well, for a<=
br>
&gt; certain definition of &quot;lose&quot;, I suppose.<br>
&gt;<br>
&gt; What Sutter, Stroustrup, and 10 others (seriously, is that the longest=
<br>
&gt; &quot;authors&quot; list in proposal history?) seem to have agreed on =
is basically<br>
&gt; verbose terse syntax.<br>
<br>
Well, it&#39;s as long as I could make it in the time it took to discuss<br=
>
that paper with all those authors and revise it before the<br>
pre-meeting deadline, which took a little over a week.<br>
<br>
&gt; The core syntax is that adjective/noun stuff that was thrown around,<b=
r>
&gt; discarded, and then resurrected again. So instead of saying `ConceptNa=
me<br>
&gt; param`, or even `ConceptName{} param`, you have to say `ConceptName au=
to<br>
&gt; param`. I am very thankful it isn&#39;t `ConceptName typename param`.<=
br>
<br>
The &#39;typename&#39; part was deliberately omitted; the adjective approac=
h suggested<br>
&#39;ConceptName typename T param&#39;, but we already have a way to name a=
 constrained<br>
type with &#39;template &lt;ConceptName T&gt;&#39;.<br>
<br>
&gt; Of course, this creates a bit of confusion around function parameters =
and<br>
&gt; return types, since they both use the same `auto` keyword that means<b=
r>
&gt; different things in different contexts. Granted, that would have happe=
ned<br>
&gt; regardless of terse syntax. And this syntax does have one unique advan=
tage<br>
<br>
Correct.<br>
<br>
&gt; in this respect: you get to use `decltype(auto)` return deduction alon=
gside<br>
&gt; `ConceptName` constraints. So that&#39;s something.<br>
<br>
Sure, filling that gap was one of the goals; make auto work, and make<br>
&#39;constrained auto&#39; work,<br>
and by extension, make &#39;constrained decltype(auto)&#39; work.<br>
<br>
&gt; Also, we get to use `ConceptName auto/typename/template` when constrai=
ning<br>
&gt; explicit template parameters. This unpleasantness is mitigated because=
<br>
<br>
There is no &#39;ConceptName typename&#39; nor &#39;ConceptName template&#3=
9; in that proposal.<br>
<br>
&gt; Oh, and we get to do `ConceptName auto variableName` too. Though like =
with<br>
&gt; return types, it does let us use `decltype(auto)` syntax, which is<br>
&gt; occasionally nice. And the `auto` is at least not required. And unifor=
mly<br>
&gt; not required: in all of the places where `auto` does value deduction r=
ather<br>
&gt; than &quot;I&#39;m a template parameter&quot;, the `auto` is optional.=
<br>
<br>
This was high on the wishlist, at least for variable declarations. For<br>
a constrained deduced<br>
return type, it&#39;s not necessarily that fundamental, but nice-to-have.<b=
r>
<br>
&gt; Yes, I would have preferred Herb&#39;s syntax, because it means I don&=
#39;t have to<br>
&gt; use `decltype`, but I can live with this.<br>
<br>
The biggest reason for this paper was to try and find an approach that<br>
more people can live with.<br>
<br>
-- <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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbR9HrEh6vDv3n47v93ss0e7GdR6Nh6=
9VLjEU%2BL%3DwqBig%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbR9HrEh6=
vDv3n47v93ss0e7GdR6Nh69VLjEU%2BL%3DwqBig%40mail.gmail.com</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%2BSga5T5bZWFKEkHth%2B%2ByvpPM=
u8%2B0Bd5obgU8Ozyhc%2B3HFA%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%=
2BOm%2BSga5T5bZWFKEkHth%2B%2ByvpPMu8%2B0Bd5obgU8Ozyhc%2B3HFA%40mail.gmail.c=
om</a>.<br />

--000000000000355bc205703d7236--

.

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

I fully agree with this idea. Teachability should be facilitated and this
version of the notation looks easier to teach.

Le jeu. 5 juil. 2018 11:48, Corentin <corentin.jabot@gmail.com> a =C3=A9cri=
t :

>  I personally would have loved to have both 'Concept T' and 'Concept
> typename T'  such that 'Concept T' would be a shorthand notation for
> 'Concept typename T'  aka, you can omit the 'typename'.
>
> This is purely for teaching, learning & consistency because we could just
> say 'stick a ConceptName to the left of any declaration to constrain it.
>
> <auto x>; //value
> <typename T>; // type
> <Concept auto x; //constrained variable;
> <Concept typename T>; // constrained type;
> <Concept T> //  type, as a sane default short hand in template parameter
> lists
> -> Concept  {}  // value, as a sane, unambiguous default for functions
> return type
> Concept auto x =3D ...; //variable
>
> I think it would make it easier to teach ( start with the explicit
> notation, then mention the shorthands), because then concepts really
> "constrain a declaration", wherever the declaration is,
> And I think these kinds of simple, consistent rules make the language mor=
e
> accessible, even if we expect experienced developers to always reach for
> the shorthand syntax.
>
>
> Le jeu. 5 juil. 2018 =C3=A0 09:54, Ville Voutilainen <
> ville.voutilainen@gmail.com> a =C3=A9crit :
>
>> On 4 July 2018 at 04:48, Nicol Bolas <jmckesson@gmail.com> wrote:
>> > Well, the new mailing strongly suggests that we all lose. Well, for a
>> > certain definition of "lose", I suppose.
>> >
>> > What Sutter, Stroustrup, and 10 others (seriously, is that the longest
>> > "authors" list in proposal history?) seem to have agreed on is basical=
ly
>> > verbose terse syntax.
>>
>> Well, it's as long as I could make it in the time it took to discuss
>> that paper with all those authors and revise it before the
>> pre-meeting deadline, which took a little over a week.
>>
>> > The core syntax is that adjective/noun stuff that was thrown around,
>> > discarded, and then resurrected again. So instead of saying `ConceptNa=
me
>> > param`, or even `ConceptName{} param`, you have to say `ConceptName au=
to
>> > param`. I am very thankful it isn't `ConceptName typename param`.
>>
>> The 'typename' part was deliberately omitted; the adjective approach
>> suggested
>> 'ConceptName typename T param', but we already have a way to name a
>> constrained
>> type with 'template <ConceptName T>'.
>>
>> > Of course, this creates a bit of confusion around function parameters
>> and
>> > return types, since they both use the same `auto` keyword that means
>> > different things in different contexts. Granted, that would have
>> happened
>> > regardless of terse syntax. And this syntax does have one unique
>> advantage
>>
>> Correct.
>>
>> > in this respect: you get to use `decltype(auto)` return deduction
>> alongside
>> > `ConceptName` constraints. So that's something.
>>
>> Sure, filling that gap was one of the goals; make auto work, and make
>> 'constrained auto' work,
>> and by extension, make 'constrained decltype(auto)' work.
>>
>> > Also, we get to use `ConceptName auto/typename/template` when
>> constraining
>> > explicit template parameters. This unpleasantness is mitigated because
>>
>> There is no 'ConceptName typename' nor 'ConceptName template' in that
>> proposal.
>>
>> > Oh, and we get to do `ConceptName auto variableName` too. Though like
>> with
>> > return types, it does let us use `decltype(auto)` syntax, which is
>> > occasionally nice. And the `auto` is at least not required. And
>> uniformly
>> > not required: in all of the places where `auto` does value deduction
>> rather
>> > than "I'm a template parameter", the `auto` is optional.
>>
>> This was high on the wishlist, at least for variable declarations. For
>> a constrained deduced
>> return type, it's not necessarily that fundamental, but nice-to-have.
>>
>> > Yes, I would have preferred Herb's syntax, because it means I don't
>> have to
>> > use `decltype`, but I can live with this.
>>
>> The biggest reason for this paper was to try and find an approach that
>> more people can live with.
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/CAFk2RUbR9H=
rEh6vDv3n47v93ss0e7GdR6Nh69VLjEU%2BL%3DwqBig%40mail.gmail.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSg=
a5T5bZWFKEkHth%2B%2ByvpPMu8%2B0Bd5obgU8Ozyhc%2B3HFA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BS=
ga5T5bZWFKEkHth%2B%2ByvpPMu8%2B0Bd5obgU8Ozyhc%2B3HFA%40mail.gmail.com?utm_m=
edium=3Demail&utm_source=3Dfooter>
> .
>

--=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/CAOG9n2GXPPXFBP4U9Ax%2B5sda4APUQXOZSJs3e_4AsuMQd=
w4i2g%40mail.gmail.com.

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

<div dir=3D"auto">I fully agree with this idea. Teachability should be faci=
litated and this version of the notation looks easier to teach.</div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr">Le jeu. 5 juil. 2018 11:48, Coren=
tin &lt;<a href=3D"mailto:corentin.jabot@gmail.com">corentin.jabot@gmail.co=
m</a>&gt; a =C3=A9crit=C2=A0:<br></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">=C2=A0I personally=C2=A0would have loved to have both &#39;Conc=
ept T&#39; and &#39;Concept typename=C2=A0T&#39;=C2=A0 such that &#39;Conce=
pt T&#39; would be a shorthand notation for &#39;Concept=C2=A0<span class=
=3D"m_-6535110644904624962inbox-inbox-gr_ m_-6535110644904624962inbox-inbox=
-gr_8 m_-6535110644904624962inbox-inbox-gr-alert m_-6535110644904624962inbo=
x-inbox-gr_spell m_-6535110644904624962inbox-inbox-gr_inline_cards m_-65351=
10644904624962inbox-inbox-gr_run_anim m_-6535110644904624962inbox-inbox-Con=
textualSpelling" id=3D"m_-6535110644904624962inbox-inbox-8" style=3D"displa=
y:inline;border-bottom:2px solid transparent;background-repeat:no-repeat">t=
ypename</span>=C2=A0T&#39;=C2=A0 aka, you can omit the &#39;typename&#39;.<=
div><br></div><div>This is purely for teaching, learning &amp; consistency =
because we could just say &#39;stick a ConceptName to the left of any decla=
ration to constrain it.</div><div><br></div><div>&lt;auto x&gt;; //value</d=
iv><div>&lt;typename T&gt;; // type</div><div>&lt;Concept auto x; //constra=
ined variable;</div><div>&lt;Concept typename T&gt;; // constrained type;</=
div><div>&lt;Concept T&gt; //=C2=A0 type, as a sane default short hand in t=
emplate parameter lists</div><div>-&gt; Concept=C2=A0 {}=C2=A0 // value, as=
 a sane, unambiguous default for functions return type</div><div>Concept au=
to x =3D ...; //variable</div><div><br></div><div>I think it would make it =
easier to teach ( start with the explicit notation, then mention the shorth=
ands), because=C2=A0then concepts really &quot;constrain a declaration&quot=
;, wherever the declaration is,</div><div>And I think these kinds of simple=
, consistent rules make the language more accessible, even if we expect exp=
erienced developers to always reach for the shorthand syntax.</div><div><br=
></div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0jeu. 5 =
juil. 2018 =C3=A0=C2=A009:54, Ville Voutilainen &lt;<a href=3D"mailto:ville=
..voutilainen@gmail.com" target=3D"_blank" rel=3D"noreferrer">ville.voutilai=
nen@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">On 4 July 2018 at 04:48, Nicol Bolas &lt;<a href=3D"mailto:jmckesson=
@gmail.com" target=3D"_blank" rel=3D"noreferrer">jmckesson@gmail.com</a>&gt=
; wrote:<br>
&gt; Well, the new mailing strongly suggests that we all lose. Well, for a<=
br>
&gt; certain definition of &quot;lose&quot;, I suppose.<br>
&gt;<br>
&gt; What Sutter, Stroustrup, and 10 others (seriously, is that the longest=
<br>
&gt; &quot;authors&quot; list in proposal history?) seem to have agreed on =
is basically<br>
&gt; verbose terse syntax.<br>
<br>
Well, it&#39;s as long as I could make it in the time it took to discuss<br=
>
that paper with all those authors and revise it before the<br>
pre-meeting deadline, which took a little over a week.<br>
<br>
&gt; The core syntax is that adjective/noun stuff that was thrown around,<b=
r>
&gt; discarded, and then resurrected again. So instead of saying `ConceptNa=
me<br>
&gt; param`, or even `ConceptName{} param`, you have to say `ConceptName au=
to<br>
&gt; param`. I am very thankful it isn&#39;t `ConceptName typename param`.<=
br>
<br>
The &#39;typename&#39; part was deliberately omitted; the adjective approac=
h suggested<br>
&#39;ConceptName typename T param&#39;, but we already have a way to name a=
 constrained<br>
type with &#39;template &lt;ConceptName T&gt;&#39;.<br>
<br>
&gt; Of course, this creates a bit of confusion around function parameters =
and<br>
&gt; return types, since they both use the same `auto` keyword that means<b=
r>
&gt; different things in different contexts. Granted, that would have happe=
ned<br>
&gt; regardless of terse syntax. And this syntax does have one unique advan=
tage<br>
<br>
Correct.<br>
<br>
&gt; in this respect: you get to use `decltype(auto)` return deduction alon=
gside<br>
&gt; `ConceptName` constraints. So that&#39;s something.<br>
<br>
Sure, filling that gap was one of the goals; make auto work, and make<br>
&#39;constrained auto&#39; work,<br>
and by extension, make &#39;constrained decltype(auto)&#39; work.<br>
<br>
&gt; Also, we get to use `ConceptName auto/typename/template` when constrai=
ning<br>
&gt; explicit template parameters. This unpleasantness is mitigated because=
<br>
<br>
There is no &#39;ConceptName typename&#39; nor &#39;ConceptName template&#3=
9; in that proposal.<br>
<br>
&gt; Oh, and we get to do `ConceptName auto variableName` too. Though like =
with<br>
&gt; return types, it does let us use `decltype(auto)` syntax, which is<br>
&gt; occasionally nice. And the `auto` is at least not required. And unifor=
mly<br>
&gt; not required: in all of the places where `auto` does value deduction r=
ather<br>
&gt; than &quot;I&#39;m a template parameter&quot;, the `auto` is optional.=
<br>
<br>
This was high on the wishlist, at least for variable declarations. For<br>
a constrained deduced<br>
return type, it&#39;s not necessarily that fundamental, but nice-to-have.<b=
r>
<br>
&gt; Yes, I would have preferred Herb&#39;s syntax, because it means I don&=
#39;t have to<br>
&gt; use `decltype`, but I can live with this.<br>
<br>
The biggest reason for this paper was to try and find an approach that<br>
more people can live with.<br>
<br>
-- <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%2Bunsubscribe@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/CAFk2RUbR9HrEh6vDv3n47v93ss0e7GdR6Nh6=
9VLjEU%2BL%3DwqBig%40mail.gmail.com" rel=3D"noreferrer noreferrer" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA=
Fk2RUbR9HrEh6vDv3n47v93ss0e7GdR6Nh69VLjEU%2BL%3DwqBig%40mail.gmail.com</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" 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/CA%2BOm%2BSga5T5bZWFKEkHth%2B%2ByvpPM=
u8%2B0Bd5obgU8Ozyhc%2B3HFA%40mail.gmail.com?utm_medium=3Demail&amp;utm_sour=
ce=3Dfooter" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSga5T5bZWFKEkHth%2B%2ByvpPMu8=
%2B0Bd5obgU8Ozyhc%2B3HFA%40mail.gmail.com</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/CAOG9n2GXPPXFBP4U9Ax%2B5sda4APUQXOZSJ=
s3e_4AsuMQdw4i2g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOG9n2GXPPXFBP=
4U9Ax%2B5sda4APUQXOZSJs3e_4AsuMQdw4i2g%40mail.gmail.com</a>.<br />

--00000000000034eb3205703d8dc9--

.

------=_Part_69912_1493385023.1530797375755
Content-Type: multipart/alternative;
 boundary="----=_Part_69913_108743569.1530797375755"

------=_Part_69913_108743569.1530797375755
Content-Type: text/plain; charset="UTF-8"

On Thursday, July 5, 2018 at 3:54:32 AM UTC-4, Ville Voutilainen wrote:
>
> On 4 July 2018 at 04:48, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > Also, we get to use `ConceptName auto/typename/template` when
> constraining
> > explicit template parameters. This unpleasantness is mitigated because
>
> There is no 'ConceptName typename' nor 'ConceptName template' in that
> proposal.
>

.... I could have sworn I saw something about that. Maybe I got confused by
the block of standardese in Part 3.

--
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/2b547065-3ea6-4cfc-97a7-093d4b409ad5%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, July 5, 2018 at 3:54:32 AM UTC-4, Ville Vouti=
lainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 4 July 2018 at=
 04:48, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"RGrj7WfDCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; Also, we get to use `ConceptName auto/typename/template` when cons=
training
<br>&gt; explicit template parameters. This unpleasantness is mitigated bec=
ause
<br>
<br>There is no &#39;ConceptName typename&#39; nor &#39;ConceptName templat=
e&#39; in that proposal.<br></blockquote><div><br></div><div>... I could ha=
ve sworn I saw something about that. Maybe I got confused by the block of s=
tandardese in Part 3.<br></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/2b547065-3ea6-4cfc-97a7-093d4b409ad5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2b547065-3ea6-4cfc-97a7-093d4b409ad5=
%40isocpp.org</a>.<br />

------=_Part_69913_108743569.1530797375755--

------=_Part_69912_1493385023.1530797375755--

.

On 5 July 2018 at 16:29, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Thursday, July 5, 2018 at 3:54:32 AM UTC-4, Ville Voutilainen wrote:
>>
>> On 4 July 2018 at 04:48, Nicol Bolas <jmck...@gmail.com> wrote:
>> > Also, we get to use `ConceptName auto/typename/template` when
>> > constraining
>> > explicit template parameters. This unpleasantness is mitigated because
>>
>> There is no 'ConceptName typename' nor 'ConceptName template' in that
>> proposal.
>
>
> ... I could have sworn I saw something about that. Maybe I got confused by
> the block of standardese in Part 3.

Chances are that you looked at
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1142r0.html
which is rumination material for some parts of P1141.

--
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/CAFk2RUbTmPXN111D4Ve6_K1Ty34Kof63WBbauQNkhJ_%2BxXxVJw%40mail.gmail.com.

.

> From: Ville Voutilainen <ville.voutilainen@gmail.com>
> Sent: Thursday, July 5, 2018 2:55 AM
>
> > Yes, I would have preferred Herb's syntax, because it means I don't
> > have to use `decltype`, but I can live with this.
>
> The biggest reason for this paper was to try and find an approach that more
> people can live with.
>

This is the piece I dislike the most.  A wholesome proposal
must base on real code and real demand.  So far, neither
Ranges nor Text_view has any demand for anything what
P1141R0 proposes.  It looks like at this point we are not
just designing by committee, but also designing for
committee.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________



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

.

------=_Part_85304_1325856392.1530932619041
Content-Type: multipart/alternative;
 boundary="----=_Part_85305_1873972965.1530932619041"

------=_Part_85305_1873972965.1530932619041
Content-Type: text/plain; charset="UTF-8"

On Friday, July 6, 2018 at 8:25:43 PM UTC-4, Zhihao Yuan wrote:
>
> > From: Ville Voutilainen <ville.vo...@gmail.com <javascript:>>
> > Sent: Thursday, July 5, 2018 2:55 AM
> >
> > > Yes, I would have preferred Herb's syntax, because it means I don't
> > > have to use `decltype`, but I can live with this.
> >
> > The biggest reason for this paper was to try and find an approach that
> more
> > people can live with.
> >
>
> This is the piece I dislike the most.  A wholesome proposal
> must base on real code and real demand.  So far, neither
> Ranges nor Text_view has any demand for anything what
> P1141R0 proposes.  It looks like at this point we are not
> just designing by committee, but also designing for
> committee.
>

.... huh?

Pretty much everyone agrees that having terse syntax of some form is a good
thing. Real demand for terse syntax of some form is undeniable; just ask
actual users whether they want it or not.The only question which remains is
how you spell it. The Concepts TS had one spelling, but it had some issues.
This proposal resolves those issues in a way that most people can live with.

It has none of the parsing problems that the prefixed `template` has. It
has none of the oddness of Herb's syntax. And it even improves on the
Concepts TS syntax by allowing different kinds of deduction to be
constrained.

This is how compromise works; this is the committee process *working*.

--
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/a353758f-a09e-433d-8567-2212a810ff49%40isocpp.org.

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

<div dir=3D"ltr">On Friday, July 6, 2018 at 8:25:43 PM UTC-4, Zhihao Yuan w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; From: Ville Voutilai=
nen &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
krnMNRNICgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">ville.vo...@gmail.com</a>&gt;
<br>&gt; Sent: Thursday, July 5, 2018 2:55 AM
<br>&gt;=20
<br>&gt; &gt; Yes, I would have preferred Herb&#39;s syntax, because it mea=
ns I don&#39;t
<br>&gt; &gt; have to use `decltype`, but I can live with this.
<br>&gt;=20
<br>&gt; The biggest reason for this paper was to try and find an approach =
that more
<br>&gt; people can live with.
<br>&gt;=20
<br>
<br>This is the piece I dislike the most. =C2=A0A wholesome proposal
<br>must base on real code and real demand. =C2=A0So far, neither
<br>Ranges nor Text_view has any demand for anything what
<br>P1141R0 proposes. =C2=A0It looks like at this point we are not
<br>just designing by committee, but also designing for
<br>committee.<br></blockquote><div><br></div><div>... huh?<br></div><div><=
br></div><div>Pretty much everyone agrees that having terse syntax of some =
form is a good thing. Real demand for terse syntax of some form is undeniab=
le; just ask actual users whether they want it or not.The only question whi=
ch remains is how you spell it. The Concepts TS had one spelling, but it ha=
d some issues. This proposal resolves those issues in a way that most peopl=
e can live with.</div><div><br></div><div>It has none of the parsing proble=
ms that the prefixed `template` has. It has none of the oddness of Herb&#39=
;s syntax. And it even improves on the Concepts TS syntax by allowing diffe=
rent kinds of deduction to be constrained.<br></div><div><br></div><div>Thi=
s is how compromise works; this is the committee process <i>working</i>.<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/a353758f-a09e-433d-8567-2212a810ff49%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a353758f-a09e-433d-8567-2212a810ff49=
%40isocpp.org</a>.<br />

------=_Part_85305_1873972965.1530932619041--

------=_Part_85304_1325856392.1530932619041--

.

> From: Nicol Bolas <jmckesson@gmail.com>=20
> Sent: Friday, July 6, 2018 10:04 PM
>=20
>> A wholesome proposal=20
>> must base on real code and real demand.  So far, neither=20
>> Ranges nor Text_view has any demand for anything what=20
>> P1141R0 proposes.  It looks like at this point we are not=20
>> just designing by committee, but also designing for=20
>> committee.
>=20
> Pretty much everyone agrees that having terse syntax of some form is a go=
od thing. Real demand for terse syntax of some form is undeniable; just ask=
 actual users whether they want it or not.The only question which remains i=
s how you spell it. The Concepts TS had one spelling, but it had some issue=
s. This proposal resolves those issues in a way that most people can live w=
ith.
>=20

"Real demand for terse syntax of some form is undeniable"
!=3D " Real demand for terse syntax of any form is undeniable."
If the proposed syntax doesn't help Ranges, then where is
the demand?  Here is a roughly complete list of the
signatures that can benefit from P1141R0 in Ranges:

    destroy_at
    next (1 overload out of 4)
    prev (1 overload out of 3)
    operator=3D=3D, operator!=3D of =E2=80=9Cunreachable=E2=80=9D, 4 overlo=
ads

One might say that Ranges is complex -- how would he/she
prove it, show us a simple real-world Concept-enabled
library?

> It has none of the parsing problems that the prefixed `template` has. It =
has none of the oddness of Herb's syntax. And it even improves on the Conce=
pts TS syntax by allowing different kinds of deduction to be constrained.
>=20

None of these are in the working paper, so none of these is an
improvement to status quo.

--
Zhihao


--=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/nmFc31IRHWZYF81B6CG94aehv-K5nOq2n0WmX7BLJGSXT5P9=
AllALpNzk-syvvMN64-S4aO3-ar7j2c6PwEnsymJn03SRIXn12V0iDegwG0%3D%40miator.net=
..

.

------=_Part_69295_129223582.1530976371500
Content-Type: multipart/alternative;
 boundary="----=_Part_69296_215408932.1530976371501"

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

On Saturday, July 7, 2018 at 2:23:36 AM UTC-4, Zhihao Yuan wrote:
>
> > From: Nicol Bolas <jmck...@gmail.com <javascript:>>=20
> > Sent: Friday, July 6, 2018 10:04 PM=20
> >=20
> >> A wholesome proposal=20
> >> must base on real code and real demand.  So far, neither=20
> >> Ranges nor Text_view has any demand for anything what=20
> >> P1141R0 proposes.  It looks like at this point we are not=20
> >> just designing by committee, but also designing for=20
> >> committee.=20
> >=20
> > Pretty much everyone agrees that having terse syntax of some form is a=
=20
> good thing. Real demand for terse syntax of some form is undeniable; just=
=20
> ask actual users whether they want it or not.The only question which=20
> remains is how you spell it. The Concepts TS had one spelling, but it had=
=20
> some issues. This proposal resolves those issues in a way that most peopl=
e=20
> can live with.=20
> >=20
>
> "Real demand for terse syntax of some form is undeniable"=20
> !=3D " Real demand for terse syntax of any form is undeniable."=20
> If the proposed syntax doesn't help Ranges, then where is=20
> the demand?


I think the point you're trying to make is that applying the terse syntax=
=20
to most Range algorithms wouldn't make them shorter. Or at least, not much.

In some cases, the order of parameters directly forbids it. Anytime a=20
function takes a `Proj` and a `Pred` or a similar functor, the `Proj`=20
function parameter comes last in the function argument list, but the `Proj`=
=20
is always before the `Pred` in the *template* parameter list. The reason=20
being that lots of users won't need `Proj`, but `Proj` needs to constrain=
=20
`Pred`.

However, *no terse syntax* would help in those cases. Not the Concepts TS,=
=20
not Bjarne's `template` prefix, nor Herb's `{}` syntax. Once the order of=
=20
function parameters and template parameters has to differ, you lose the=20
ability to use any terse syntax.

So let's skip all of those. That's pretty much all of the algorithms.

Another case is when you need to actually get the name of one of the=20
deduced types. This is actually quite common:

template <Iterator I> constexpr void advance(I& i, difference_type_t<I> n);

That looks like a prime candidate for terse syntax, but what you get is:

constexpr void advance(Iterator auto &i, different_type_t<decltype(i)> n);

That is shorter... by one character.

This shows the strength of Herb's syntax:

constexpr void advance(Iterator{I} &i, difference_type_t<I> n);

That provides at least some reduction in verbosity.

=20

> Here is a roughly complete list of the=20
> signatures that can benefit from P1141R0 in Ranges:=20
>
>     destroy_at=20
>     next (1 overload out of 4)=20
>     prev (1 overload out of 3)=20
>     operator=3D=3D, operator!=3D of =E2=80=9Cunreachable=E2=80=9D, 4 over=
loads=20
>
> One might say that Ranges is complex -- how would he/she=20
> prove it, show us a simple real-world Concept-enabled=20
> library?
>

On the one hand, I think this is the wrong standard by which to judge terse=
=20
syntax.

That is, any generic conceptualized library will have complicated=20
relationships between the various parameters. So terse syntax was never=20
going to be viable for such libraries.

The principle users of terse syntax will not be writers of generic=20
libraries, but *users* of generic libraries. They're useful when you're=20
writing a quick lambda to be passed somewhere. `[](UnsignedInteger auto i)=
=20
{}` is going to be easier to digest than `[]<UnsignedInteger I> (I i)=20
{...}`. Not massively shorter of course, but still more readable.

The idea with terse syntax is to keep the simple cases simple. Pretty much=
=20
nothing in the Range TS is a simple case.

On the other hand... the complexity of the Range system I think has really=
=20
damaged the utility of terse syntax.

Consider the original Concepts-Lite proposal=20
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3580.pdf>, which=
=20
gave us a number of seemingly common-place examples of where terse syntax=
=20
would be used. In particular, `sort` and `merge`. The Range TS definitions=
=20
of these functions evolved to the point where terse syntax either wasn't=20
possible or wasn't practical (ie: the terse version wouldn't be appreciably=
=20
shorter).

For example, the Concepts-Lite proposal suggested this for `sort`:

void sort(Cont& c);

Well, in a range world obviously that would be some `Range` concept, but=20
the general structure is the same. What isn't the same is how that now has=
=20
to be generalized to allow for comparison functors. Using that terse syntax=
:

void sort(Range &&r, Comp<decltype(r)> comp =3D std::less<value_type<declty=
pe(
r)>{});

Where `Comp` knows how to act on a particular range to extract the value=20
type and detect that the functor provides comparisons against that value=20
type.

And of course, once you add projection-based-comparison, this becomes=20
completely unworkable. Because now you have template parameters in a=20
different order from function parameters.

The point being that the more conceptualized a function becomes, the chance=
=20
of it being able to use terse syntax *of any form* approaches 0.

And that suggests a potential problem: laziness. If users of simple cases=
=20
get used to terse syntax, they may avoid doing things that stop them from=
=20
being able to use terse syntax. So rather than write out the complex `sort`=
=20
in ranges, they'd just write `void sort(RandomAccessRange auto &&r, auto=20
comp =3D std::less<>{}, auto proj =3D std::identity{});` and just let it go=
 at=20
that.

Wheresas, if you force them to stick that `RandomAccessRange` in a template=
=20
argument list, and deny them the ability to use `auto` in function=20
parameters, then they have no choice but to spell it out explicitly. And=20
since they're having to write it long-form, they may as well constrain it=
=20
properly.

--=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/07ec2785-ec90-4b72-bdbe-3cf624eac38b%40isocpp.or=
g.

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

<div dir=3D"ltr">On Saturday, July 7, 2018 at 2:23:36 AM UTC-4, Zhihao Yuan=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; From: Nicol Bolas =
&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"IUlC=
tppbCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;=
;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">j=
mck...@gmail.com</a>&gt;=20
<br>&gt; Sent: Friday, July 6, 2018 10:04 PM
<br>&gt;=20
<br>&gt;&gt; A wholesome proposal=20
<br>&gt;&gt; must base on real code and real demand. =C2=A0So far, neither=
=20
<br>&gt;&gt; Ranges nor Text_view has any demand for anything what=20
<br>&gt;&gt; P1141R0 proposes. =C2=A0It looks like at this point we are not=
=20
<br>&gt;&gt; just designing by committee, but also designing for=20
<br>&gt;&gt; committee.
<br>&gt;=20
<br>&gt; Pretty much everyone agrees that having terse syntax of some form =
is a good thing. Real demand for terse syntax of some form is undeniable; j=
ust ask actual users whether they want it or not.The only question which re=
mains is how you spell it. The Concepts TS had one spelling, but it had som=
e issues. This proposal resolves those issues in a way that most people can=
 live with.
<br>&gt;=20
<br>
<br>&quot;Real demand for terse syntax of some form is undeniable&quot;
<br>!=3D &quot; Real demand for terse syntax of any form is undeniable.&quo=
t;
<br>If the proposed syntax doesn&#39;t help Ranges, then where is
<br>the demand?</blockquote><div><br></div><div>I think the point you&#39;r=
e trying to make is that applying the terse syntax to most Range algorithms=
 wouldn&#39;t make them shorter. Or at least, not much.<br></div><div><br><=
/div><div>In some cases, the order of parameters directly forbids it. Anyti=
me a function takes a `Proj` and a `Pred` or a similar functor, the `Proj` =
function parameter comes last in the function argument list, but the `Proj`=
 is always before the `Pred` in the <i>template</i> parameter list. The rea=
son being that lots of users won&#39;t need `Proj`, but `Proj` needs to con=
strain `Pred`.</div><div><br></div><div>However, <i>no terse syntax</i> wou=
ld help in those cases. Not the Concepts TS, not Bjarne&#39;s `template` pr=
efix, nor Herb&#39;s `{}` syntax. Once the order of function parameters and=
 template parameters has to differ, you lose the ability to use any terse s=
yntax.</div><div><br></div><div>So let&#39;s skip all of those. That&#39;s =
pretty much all of the algorithms.<br></div><div><br></div><div>Another cas=
e is when you need to actually get the name of one of the deduced types. Th=
is is actually quite common:</div><div><br></div><div style=3D"background-c=
olor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: s=
olid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">template</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Iterator</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> I</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: #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"styled-by-prettify">void</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> advance</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">I</span><span style=3D"col=
or: #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;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> difference_type_t</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">I</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span></div></code></div><br><div></div><div>That looks like a prime candid=
ate for terse syntax, but what you get is:</div><div><br></div><div><div st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; overflow-wrap: break-word;" cla=
ss=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> advance</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Iterator</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> different_typ=
e_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">decltype</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)&gt;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> n</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span></div></code></div></div><div><br></d=
iv><div>That is shorter... by one character.</div><div><br></div><div>This =
shows the strength of Herb&#39;s syntax:</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; 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">constexpr</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> advance</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span 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: #000;" class=3D"=
styled-by-prettify">I</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> difference_type_t</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">I</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"> n</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">);</span></div></code></div></div><div><br></div>=
<div>That provides at least some reduction in verbosity.</div><br><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;">Here is a roughly com=
plete list of the
<br>signatures that can benefit from P1141R0 in Ranges:
<br>
<br>=C2=A0 =C2=A0 destroy_at
<br>=C2=A0 =C2=A0 next (1 overload out of 4)
<br>=C2=A0 =C2=A0 prev (1 overload out of 3)
<br>=C2=A0 =C2=A0 operator=3D=3D, operator!=3D of =E2=80=9Cunreachable=E2=
=80=9D, 4 overloads
<br>
<br>One might say that Ranges is complex -- how would he/she
<br>prove it, show us a simple real-world Concept-enabled
<br>library?<br></blockquote><div><br></div><div>On the one hand, I think t=
his is the wrong standard by which to judge terse syntax.</div><div><br></d=
iv><div>That is, any generic conceptualized library will have complicated r=
elationships between the various parameters. So terse syntax was never goin=
g to be viable for such libraries.</div><div><br></div><div>The principle u=
sers of terse syntax will not be writers of generic libraries, but <i>users=
</i> of generic libraries. They&#39;re useful when you&#39;re writing a qui=
ck lambda to be passed somewhere. `[](UnsignedInteger auto i) {}` is going =
to be easier to digest than `[]&lt;UnsignedInteger I&gt; (I i) {...}`. Not =
massively shorter of course, but still more readable.</div><div><br></div><=
div>The idea with terse syntax is to keep the simple cases simple. Pretty m=
uch nothing in the Range TS is a simple case.<br></div><div><br></div><div>=
On the other hand... the complexity of the Range system I think has really =
damaged the utility of terse syntax.</div><div><br></div><div>Consider <a h=
ref=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3580.pdf">t=
he original Concepts-Lite proposal</a>, which gave us a number of seemingly=
 common-place examples of where terse syntax would be used. In particular, =
`sort` and `merge`. The Range TS definitions of these functions evolved to =
the point where terse syntax either wasn&#39;t possible or wasn&#39;t pract=
ical (ie: the terse version wouldn&#39;t be appreciably shorter).</div><div=
><br></div><div>For example, the Concepts-Lite proposal suggested this for =
`sort`:</div><div><br></div><div><div style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> sort</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Cont</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span></div=
></code></div><br></div><div></div><div>Well, in a range world obviously th=
at would be some `Range` concept, but the general structure is the same. Wh=
at isn&#39;t the same is how that now has to be generalized to allow for co=
mparison functors. Using that terse syntax:<br></div><div><br></div><div><d=
iv style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; overflow-wrap: break-word;=
" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpretty=
print"><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> sort</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Range</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">r</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">Comp</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">declty=
pe</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">r</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">)&gt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> comp </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">less</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">value_type</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>decltype</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">r</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)&gt;{});</span></d=
iv></code></div><br></div><div></div><div>Where `Comp` knows how to act on =
a particular range to extract the value type and detect that the functor pr=
ovides comparisons against that value type.<br></div><div><br></div><div>An=
d of course, once you add projection-based-comparison, this becomes complet=
ely unworkable. Because now you have template parameters in a different ord=
er from function parameters.<br></div><div><br></div><div>The point being t=
hat the more conceptualized a function becomes, the chance of it being able=
 to use terse syntax <i>of any form</i> approaches 0.</div><div><br></div><=
div>And that suggests a potential problem: laziness. If users of simple cas=
es get used to terse syntax, they may avoid doing things that stop them fro=
m being able to use terse syntax. So rather than write out the complex `sor=
t` in ranges, they&#39;d just write `void sort(RandomAccessRange auto &amp;=
&amp;r, auto comp =3D std::less&lt;&gt;{}, auto proj =3D std::identity{});`=
 and just let it go at that.</div><div><br></div><div>Wheresas, if you forc=
e them to stick that `RandomAccessRange` in a template argument list, and d=
eny them the ability to use `auto` in function parameters, then they have n=
o choice but to spell it out explicitly. And since they&#39;re having to wr=
ite it long-form, they may as well constrain it properly.<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/07ec2785-ec90-4b72-bdbe-3cf624eac38b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/07ec2785-ec90-4b72-bdbe-3cf624eac38b=
%40isocpp.org</a>.<br />

------=_Part_69296_215408932.1530976371501--

------=_Part_69295_129223582.1530976371500--

.

------=_Part_92011_1721426187.1530996364479
Content-Type: multipart/alternative;
 boundary="----=_Part_92012_1704439453.1530996364480"

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

Considering=20

class ConcreteType;

is an age-old way to introduce a type, can we extend that to Concepts?

Concept Type;

After all the suggested Concept auto var =3D something();

is not unlike class ConcreteType car =3D something();

And taking a note from in-place we could just let auto be a name of a=20
deduced type=20

Concept Type var =3D something();

I am not that a fan of 2-in-one declaration, but it does help with natural=
=20
syntax

void advance(Iterator I& i, different_type_t<I> n);

I am willing to argue it also looks most natural to the eye as there is a=
=20
type next to the name.

auto sort(RandomAccessIterator I first
        , Sentinel<I> S last
        , All Comp comp =3D less<>{}
        , All Proj proj =3D identity{}) requires Sortable<I, Comp, Proj>;



On Saturday, July 7, 2018 at 6:12:51 PM UTC+3, Nicol Bolas wrote:
>
> On Saturday, July 7, 2018 at 2:23:36 AM UTC-4, Zhihao Yuan wrote:
>>
>> > From: Nicol Bolas <jmck...@gmail.com>=20
>> > Sent: Friday, July 6, 2018 10:04 PM=20
>> >=20
>> >> A wholesome proposal=20
>> >> must base on real code and real demand.  So far, neither=20
>> >> Ranges nor Text_view has any demand for anything what=20
>> >> P1141R0 proposes.  It looks like at this point we are not=20
>> >> just designing by committee, but also designing for=20
>> >> committee.=20
>> >=20
>> > Pretty much everyone agrees that having terse syntax of some form is a=
=20
>> good thing. Real demand for terse syntax of some form is undeniable; jus=
t=20
>> ask actual users whether they want it or not.The only question which=20
>> remains is how you spell it. The Concepts TS had one spelling, but it ha=
d=20
>> some issues. This proposal resolves those issues in a way that most peop=
le=20
>> can live with.=20
>> >=20
>>
>> "Real demand for terse syntax of some form is undeniable"=20
>> !=3D " Real demand for terse syntax of any form is undeniable."=20
>> If the proposed syntax doesn't help Ranges, then where is=20
>> the demand?
>
>
> I think the point you're trying to make is that applying the terse syntax=
=20
> to most Range algorithms wouldn't make them shorter. Or at least, not muc=
h.
>
> In some cases, the order of parameters directly forbids it. Anytime a=20
> function takes a `Proj` and a `Pred` or a similar functor, the `Proj`=20
> function parameter comes last in the function argument list, but the `Pro=
j`=20
> is always before the `Pred` in the *template* parameter list. The reason=
=20
> being that lots of users won't need `Proj`, but `Proj` needs to constrain=
=20
> `Pred`.
>
> However, *no terse syntax* would help in those cases. Not the Concepts=20
> TS, not Bjarne's `template` prefix, nor Herb's `{}` syntax. Once the orde=
r=20
> of function parameters and template parameters has to differ, you lose th=
e=20
> ability to use any terse syntax.
>
> So let's skip all of those. That's pretty much all of the algorithms.
>
> Another case is when you need to actually get the name of one of the=20
> deduced types. This is actually quite common:
>
> template <Iterator I> constexpr void advance(I& i, difference_type_t<I> n
> );
>
> That looks like a prime candidate for terse syntax, but what you get is:
>
> constexpr void advance(Iterator auto &i, different_type_t<decltype(i)> n)=
;
>
> That is shorter... by one character.
>
> This shows the strength of Herb's syntax:
>
> constexpr void advance(Iterator{I} &i, difference_type_t<I> n);
>
> That provides at least some reduction in verbosity.
>
> =20
>
>> Here is a roughly complete list of the=20
>> signatures that can benefit from P1141R0 in Ranges:=20
>>
>>     destroy_at=20
>>     next (1 overload out of 4)=20
>>     prev (1 overload out of 3)=20
>>     operator=3D=3D, operator!=3D of =E2=80=9Cunreachable=E2=80=9D, 4 ove=
rloads=20
>>
>> One might say that Ranges is complex -- how would he/she=20
>> prove it, show us a simple real-world Concept-enabled=20
>> library?
>>
>
> On the one hand, I think this is the wrong standard by which to judge=20
> terse syntax.
>
> That is, any generic conceptualized library will have complicated=20
> relationships between the various parameters. So terse syntax was never=
=20
> going to be viable for such libraries.
>
> The principle users of terse syntax will not be writers of generic=20
> libraries, but *users* of generic libraries. They're useful when you're=
=20
> writing a quick lambda to be passed somewhere. `[](UnsignedInteger auto i=
)=20
> {}` is going to be easier to digest than `[]<UnsignedInteger I> (I i)=20
> {...}`. Not massively shorter of course, but still more readable.
>
> The idea with terse syntax is to keep the simple cases simple. Pretty muc=
h=20
> nothing in the Range TS is a simple case.
>
> On the other hand... the complexity of the Range system I think has reall=
y=20
> damaged the utility of terse syntax.
>
> Consider the original Concepts-Lite proposal=20
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3580.pdf>,=20
> which gave us a number of seemingly common-place examples of where terse=
=20
> syntax would be used. In particular, `sort` and `merge`. The Range TS=20
> definitions of these functions evolved to the point where terse syntax=20
> either wasn't possible or wasn't practical (ie: the terse version wouldn'=
t=20
> be appreciably shorter).
>
> For example, the Concepts-Lite proposal suggested this for `sort`:
>
> void sort(Cont& c);
>
> Well, in a range world obviously that would be some `Range` concept, but=
=20
> the general structure is the same. What isn't the same is how that now ha=
s=20
> to be generalized to allow for comparison functors. Using that terse synt=
ax:
>
> void sort(Range &&r, Comp<decltype(r)> comp =3D std::less<value_type<
> decltype(r)>{});
>
> Where `Comp` knows how to act on a particular range to extract the value=
=20
> type and detect that the functor provides comparisons against that value=
=20
> type.
>
> And of course, once you add projection-based-comparison, this becomes=20
> completely unworkable. Because now you have template parameters in a=20
> different order from function parameters.
>
> The point being that the more conceptualized a function becomes, the=20
> chance of it being able to use terse syntax *of any form* approaches 0.
>
> And that suggests a potential problem: laziness. If users of simple cases=
=20
> get used to terse syntax, they may avoid doing things that stop them from=
=20
> being able to use terse syntax. So rather than write out the complex `sor=
t`=20
> in ranges, they'd just write `void sort(RandomAccessRange auto &&r, auto=
=20
> comp =3D std::less<>{}, auto proj =3D std::identity{});` and just let it =
go at=20
> that.
>
> Wheresas, if you force them to stick that `RandomAccessRange` in a=20
> template argument list, and deny them the ability to use `auto` in functi=
on=20
> parameters, then they have no choice but to spell it out explicitly. And=
=20
> since they're having to write it long-form, they may as well constrain it=
=20
> properly.
>

--=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/66e44c1e-6ec9-4d52-aaf0-7e79a1818d3a%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>Considering=C2=A0</div><div><br></div><div><font face=
=3D"courier new,monospace">class ConcreteType;</font></div><div><font face=
=3D"courier new,monospace"></font><br></div><div>is an age-old way to intro=
duce a type, can we extend that to Concepts?</div><div><font face=3D"courie=
r new,monospace"></font></div><div><font face=3D"courier new,monospace"><br=
></font></div><div><font face=3D"courier new,monospace">Concept Type;</font=
></div><div><font face=3D"courier new,monospace"></font><br></div><div><fon=
t face=3D"arial,sans-serif">After all the suggested</font><font face=3D"cou=
rier new,monospace"> Concept auto var =3D something();</font></div><div><fo=
nt face=3D"courier new,monospace"><br></font></div><div><font face=3D"arial=
,sans-serif">is not unlike</font><font face=3D"courier new,monospace"> clas=
s <span style=3D"display: inline !important; float: none; background-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; orphans: 2; text-align: left; text-decoration: non=
e; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; =
white-space: normal; word-spacing: 0px;">ConcreteType car =3D something();<=
/span></font></div><div><font face=3D"courier new,monospace"></font><font f=
ace=3D"courier new,monospace"></font><font face=3D"courier new,monospace"><=
/font><font face=3D"courier new,monospace"></font><font face=3D"arial,sans-=
serif"></font><font face=3D"courier new,monospace"></font><font face=3D"cou=
rier new,monospace"></font><font face=3D"arial,sans-serif"></font><font fac=
e=3D"courier new,monospace"></font><b></b><i></i><u></u><sub></sub><sup></s=
up><strike></strike><font face=3D"arial,sans-serif"></font><br></div><div>A=
nd taking a note from in-place we could just let auto be a name of a deduce=
d type=C2=A0</div><div><br></div><div><span style=3D"display: inline !impor=
tant; float: none; background-color: transparent; color: rgb(34, 34, 34); f=
ont-family: courier new,monospace; 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;=
">Concept Type var =3D something();</span><b></b><i></i><u></u><sub></sub><=
sup></sup><strike></strike></div><div><br></div><div>I am not that a fan of=
 2-in-one declaration, but it does help with natural syntax</div><div><br><=
/div><font face=3D"courier new,monospace">void advance(Iterator I&amp; i, d=
ifferent_type_t&lt;I&gt; n);</font><br><div><font face=3D"courier new,monos=
pace"></font><font face=3D"courier new,monospace"></font><font face=3D"cour=
ier new,monospace"></font><br></div><div><font face=3D"arial,sans-serif">I =
am willing to argue it also looks most natural to the eye as there is a typ=
e next to the name.</font><br></div><div><br></div><div><font face=3D"couri=
er new,monospace">auto sort(RandomAccessIterator I first</font></div><div><=
font face=3D"courier new,monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 , Sentinel&=
lt;I&gt; S last</font></div><div><font face=3D"courier new,monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 , All Comp comp =3D less&lt;&gt;{}</font></div><di=
v><font face=3D"courier new,monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 , All Pr=
oj proj =3D identity{}) requires Sortable&lt;I, Comp, Proj&gt;;</font></div=
><div><br></div><div><br></div><b></b><i></i><u></u><sub></sub><sup></sup><=
strike></strike><font face=3D"arial,sans-serif"></font><font face=3D"courie=
r new,monospace"></font><font face=3D"courier new,monospace"></font><br>On =
Saturday, July 7, 2018 at 6:12:51 PM UTC+3, Nicol Bolas wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Saturday, July 7, 2018 =
at 2:23:36 AM UTC-4, Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">&gt; From: Nicol Bolas &lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt=
;=20
<br>&gt; Sent: Friday, July 6, 2018 10:04 PM
<br>&gt;=20
<br>&gt;&gt; A wholesome proposal=20
<br>&gt;&gt; must base on real code and real demand. =C2=A0So far, neither=
=20
<br>&gt;&gt; Ranges nor Text_view has any demand for anything what=20
<br>&gt;&gt; P1141R0 proposes. =C2=A0It looks like at this point we are not=
=20
<br>&gt;&gt; just designing by committee, but also designing for=20
<br>&gt;&gt; committee.
<br>&gt;=20
<br>&gt; Pretty much everyone agrees that having terse syntax of some form =
is a good thing. Real demand for terse syntax of some form is undeniable; j=
ust ask actual users whether they want it or not.The only question which re=
mains is how you spell it. The Concepts TS had one spelling, but it had som=
e issues. This proposal resolves those issues in a way that most people can=
 live with.
<br>&gt;=20
<br>
<br>&quot;Real demand for terse syntax of some form is undeniable&quot;
<br>!=3D &quot; Real demand for terse syntax of any form is undeniable.&quo=
t;
<br>If the proposed syntax doesn&#39;t help Ranges, then where is
<br>the demand?</blockquote><div><br></div><div>I think the point you&#39;r=
e trying to make is that applying the terse syntax to most Range algorithms=
 wouldn&#39;t make them shorter. Or at least, not much.<br></div><div><br><=
/div><div>In some cases, the order of parameters directly forbids it. Anyti=
me a function takes a `Proj` and a `Pred` or a similar functor, the `Proj` =
function parameter comes last in the function argument list, but the `Proj`=
 is always before the `Pred` in the <i>template</i> parameter list. The rea=
son being that lots of users won&#39;t need `Proj`, but `Proj` needs to con=
strain `Pred`.</div><div><br></div><div>However, <i>no terse syntax</i> wou=
ld help in those cases. Not the Concepts TS, not Bjarne&#39;s `template` pr=
efix, nor Herb&#39;s `{}` syntax. Once the order of function parameters and=
 template parameters has to differ, you lose the ability to use any terse s=
yntax.</div><div><br></div><div>So let&#39;s skip all of those. That&#39;s =
pretty much all of the algorithms.<br></div><div><br></div><div>Another cas=
e is when you need to actually get the name of one of the deduced types. Th=
is is actually quite common:</div><div><br></div><div style=3D"background-c=
olor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bord=
er-width:1px"><code><div><span style=3D"color:#008">template</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">&lt;</span><span styl=
e=3D"color:#606">Iterator</span><span style=3D"color:#000"> I</span><span s=
tyle=3D"color:#660">&gt;</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">constexpr</span><span style=3D"color:#000"> </span><span =
style=3D"color:#008">void</span><span style=3D"color:#000"> advance</span><=
span style=3D"color:#660">(</span><span style=3D"color:#000">I</span><span =
style=3D"color:#660">&amp;</span><span style=3D"color:#000"> i</span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"> difference_type_t<=
/span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">I</s=
pan><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> n</sp=
an><span style=3D"color:#660">);</span></div></code></div><br><div></div><d=
iv>That looks like a prime candidate for terse syntax, but what you get is:=
</div><div><br></div><div><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><di=
v><span style=3D"color:#008">constexpr</span><span style=3D"color:#000"> </=
span><span style=3D"color:#008">void</span><span style=3D"color:#000"> adva=
nce</span><span style=3D"color:#660">(</span><span style=3D"color:#606">Ite=
rator</span><span style=3D"color:#000"> </span><span style=3D"color:#008">a=
uto</span><span style=3D"color:#000"> </span><span style=3D"color:#660">&am=
p;</span><span style=3D"color:#000">i</span><span style=3D"color:#660">,</s=
pan><span style=3D"color:#000"> different_type_t</span><span style=3D"color=
:#660">&lt;</span><span style=3D"color:#008">decltype</span><span style=3D"=
color:#660">(</span><span style=3D"color:#000">i</span><span style=3D"color=
:#660">)&gt;</span><span style=3D"color:#000"> n</span><span style=3D"color=
:#660">);</span></div></code></div></div><div><br></div><div>That is shorte=
r... by one character.</div><div><br></div><div>This shows the strength of =
Herb&#39;s syntax:</div><div><br></div><div><div style=3D"background-color:=
rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wi=
dth:1px"><code><div><span style=3D"color:#008">constexpr</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">void</span><span style=
=3D"color:#000"> advance</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#606">Iterator</span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000">I</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">i</span><span style=3D"color:#660">,</span><span style=3D"c=
olor:#000"> difference_type_t</span><span style=3D"color:#660">&lt;</span><=
span style=3D"color:#000">I</span><span style=3D"color:#660">&gt;</span><sp=
an style=3D"color:#000"> n</span><span style=3D"color:#660">);</span></div>=
</code></div></div><div><br></div><div>That provides at least some reductio=
n in verbosity.</div><br><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">Here is a roughly complete list of the
<br>signatures that can benefit from P1141R0 in Ranges:
<br>
<br>=C2=A0 =C2=A0 destroy_at
<br>=C2=A0 =C2=A0 next (1 overload out of 4)
<br>=C2=A0 =C2=A0 prev (1 overload out of 3)
<br>=C2=A0 =C2=A0 operator=3D=3D, operator!=3D of =E2=80=9Cunreachable=E2=
=80=9D, 4 overloads
<br>
<br>One might say that Ranges is complex -- how would he/she
<br>prove it, show us a simple real-world Concept-enabled
<br>library?<br></blockquote><div><br></div><div>On the one hand, I think t=
his is the wrong standard by which to judge terse syntax.</div><div><br></d=
iv><div>That is, any generic conceptualized library will have complicated r=
elationships between the various parameters. So terse syntax was never goin=
g to be viable for such libraries.</div><div><br></div><div>The principle u=
sers of terse syntax will not be writers of generic libraries, but <i>users=
</i> of generic libraries. They&#39;re useful when you&#39;re writing a qui=
ck lambda to be passed somewhere. `[](UnsignedInteger auto i) {}` is going =
to be easier to digest than `[]&lt;UnsignedInteger I&gt; (I i) {...}`. Not =
massively shorter of course, but still more readable.</div><div><br></div><=
div>The idea with terse syntax is to keep the simple cases simple. Pretty m=
uch nothing in the Range TS is a simple case.<br></div><div><br></div><div>=
On the other hand... the complexity of the Range system I think has really =
damaged the utility of terse syntax.</div><div><br></div><div>Consider <a o=
nmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2F=
www.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2013%2Fn3580.pdf\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNECTX4g0hHZJlJSN5nJVa6nDG8NMQ&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%=
3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2013%2Fn358=
0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNECTX4g0hHZJlJSN5nJVa6nDG8NMQ&=
#39;;return true;" href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/pape=
rs/2013/n3580.pdf" target=3D"_blank" rel=3D"nofollow">the original Concepts=
-Lite proposal</a>, which gave us a number of seemingly common-place exampl=
es of where terse syntax would be used. In particular, `sort` and `merge`. =
The Range TS definitions of these functions evolved to the point where ters=
e syntax either wasn&#39;t possible or wasn&#39;t practical (ie: the terse =
version wouldn&#39;t be appreciably shorter).</div><div><br></div><div>For =
example, the Concepts-Lite proposal suggested this for `sort`:</div><div><b=
r></div><div><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-style:solid;border-width:1px"><code><div><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> sort</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#606">Cont</span><span style=
=3D"color:#660">&amp;</span><span style=3D"color:#000"> c</span><span style=
=3D"color:#660">);</span></div></code></div><br></div><div></div><div>Well,=
 in a range world obviously that would be some `Range` concept, but the gen=
eral structure is the same. What isn&#39;t the same is how that now has to =
be generalized to allow for comparison functors. Using that terse syntax:<b=
r></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 style=3D"color:#008">void</span><span style=3D"color:#000"> sort<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#606">Range</=
span><span style=3D"color:#000"> </span><span style=3D"color:#660">&amp;&am=
p;</span><span style=3D"color:#000">r</span><span style=3D"color:#660">,</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#606">Comp</spa=
n><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">decltype=
</span><span style=3D"color:#660">(</span><span style=3D"color:#000">r</spa=
n><span style=3D"color:#660">)&gt;</span><span style=3D"color:#000"> comp <=
/span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> std<=
/span><span style=3D"color:#660">::</span><span style=3D"color:#000">less</=
span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">value=
_type</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008=
">decltype</span><span style=3D"color:#660">(</span><span style=3D"color:#0=
00"><wbr>r</span><span style=3D"color:#660">)&gt;{});</span></div></code></=
div><br></div><div></div><div>Where `Comp` knows how to act on a particular=
 range to extract the value type and detect that the functor provides compa=
risons against that value type.<br></div><div><br></div><div>And of course,=
 once you add projection-based-comparison, this becomes completely unworkab=
le. Because now you have template parameters in a different order from func=
tion parameters.<br></div><div><br></div><div>The point being that the more=
 conceptualized a function becomes, the chance of it being able to use ters=
e syntax <i>of any form</i> approaches 0.</div><div><br></div><div>And that=
 suggests a potential problem: laziness. If users of simple cases get used =
to terse syntax, they may avoid doing things that stop them from being able=
 to use terse syntax. So rather than write out the complex `sort` in ranges=
, they&#39;d just write `void sort(RandomAccessRange auto &amp;&amp;r, auto=
 comp =3D std::less&lt;&gt;{}, auto proj =3D std::identity{});` and just le=
t it go at that.</div><div><br></div><div>Wheresas, if you force them to st=
ick that `RandomAccessRange` in a template argument list, and deny them the=
 ability to use `auto` in function parameters, then they have no choice but=
 to spell it out explicitly. And since they&#39;re having to write it long-=
form, they may as well constrain it properly.<br></div></div></blockquote><=
/div>

<p></p>

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

------=_Part_92012_1704439453.1530996364480--

------=_Part_92011_1721426187.1530996364479--

.

> From: Nicol Bolas <jmckesson@gmail.com>=20
> Sent: Saturday, July 7, 2018 10:13 AM
>=20
> I think the point you're trying to make is that applying the terse syntax=
 to most Range algorithms wouldn't make them shorter. Or at least, not much=
..

Not making them simpler, or readable, or conveying more
precise information.  From

    template <Iterator I>
    void advance(I& i, difference_type_t<I> n);

to

    void advance(Iterator auto &i, different_type_t<decltype(i)> n);

, the latter is just cryptic.

> In some cases, the order of parameters directly forbids it.
>=20
> However, no terse syntax would help in those cases. Not the Concepts TS, =
not Bjarne's `template` prefix, nor Herb's `{}` syntax. Once the order of f=
unction parameters and template parameters has to differ, you lose the abil=
ity to use any terse syntax.
>=20
> So let's skip all of those. That's pretty much all of the algorithms.

We need to look at the right problem to find the right solution;
you cannot hold a solution, and tell me my problem doesn't
work.  Here is an example, from

    template<InputIterator I, Sentinel<I> S, class Proj =3D identity,
    IndirectUnaryPredicate<projected<I, Proj>> Pred>
    bool all_of(I first, S last, Pred pred, Proj proj =3D Proj{});

to

    template<InputIterator I, Sentinel<I> S, IndirectUnaryPredicate<I> Pred=
>
    bool all_of(I first, S last, Pred pred);

    template<InputIterator I, Sentinel<I> S, ProjectedUnaryPredicate<I> Pro=
j Pred>
    bool all_of(I first, S last, Pred pred, Proj proj);

, isn't the latter more readable?

> The idea with terse syntax is to keep the simple cases simple. Pretty muc=
h nothing in the Range TS is a simple case.
>=20
> On the other hand... the complexity of the Range system I think has reall=
y damaged the utility of terse syntax.
> [...]
> The point being that the more conceptualized a function becomes, the chan=
ce of it being able to use terse syntax of any form approaches 0.

I don't care a bit what terse syntax can do; I care only what
problem we can solve.

> The principal users of terse syntax will not be writers of generic librar=
ies, but users of generic libraries.

That's an interesting way to formulate the problem, but before
I calling it hypothetical --

> And that suggests a potential problem: laziness. If users of simple cases=
 get used to terse syntax, they may avoid doing things that stop them from =
being able to use terse syntax. So rather than write out the complex `sort`=
 in ranges, they'd just write `void sort(RandomAccessRange auto &&r, auto c=
omp =3D std::less<>{}, auto proj =3D std::identity{});` and just let it go =
at that.

> Whereas, if you force them to stick that `RandomAccessRange` in a templat=
e argument list, and deny them the ability to use `auto` in function parame=
ters, then they have no choice but to spell it out explicitly. And since th=
ey're having to write it long-form, they may as well constrain it properly.

, you may as well find it's hard to defend.

> They're useful when you're writing a quick lambda to be passed somewhere.=
 `[](UnsignedInteger auto i) {}` is going to be easier to digest than `[]<U=
nsignedInteger I> (I i) {...}`. Not massively shorter of course, but still =
more readable.

If I'm told that from

    []<typename I> (I i)

to

    [](typename auto i)

is an simplification I will be very mad, so how the
following transition can be better?

    []<UnsignedInteger I> (I i)  --->
    [](UnsignedInteger auto i)

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________



--=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/KtHC-tQtAo2fYfABHgG-oCNs7yeXCFYrh0COPJsL7peDoiOH=
TM6EOUjsOhW2HA5ksCJkPf-aIWQQPNzWDd-crPlCs46-GufKBretik-dP-g%3D%40miator.net=
..

.

------=_Part_93912_966934240.1531003930126
Content-Type: multipart/alternative;
 boundary="----=_Part_93913_1565230617.1531003930126"

------=_Part_93913_1565230617.1531003930126
Content-Type: text/plain; charset="UTF-8"

On Saturday, July 7, 2018 at 5:49:32 PM UTC-4, Zhihao Yuan wrote:
>
> > From: Nicol Bolas <jmck...@gmail.com <javascript:>>
> > Sent: Saturday, July 7, 2018 10:13 AM
> >
> > I think the point you're trying to make is that applying the terse
> syntax to most Range algorithms wouldn't make them shorter. Or at least,
> not much.
>
> Not making them simpler, or readable, or conveying more
> precise information.  From
>
>     template <Iterator I>
>     void advance(I& i, difference_type_t<I> n);
>
> to
>
>     void advance(Iterator auto &i, different_type_t<decltype(i)> n);
>
> , the latter is just cryptic.
>

I'd hardly call it "cryptic". It's very clear what it's doing, once you
understand the syntax. A lambda could be considered "cryptic" if you've
never seen the syntax before.

Also, it's not like we don't see this sort of thing with lambdas today:
`[](auto &i, difference_type_t<decltype(i)> n);`. Now yes, with C++20
allowing template header syntax in lambdas, we may not need it anymore, but
this idiom is hardly unfamiliar to users.

> In some cases, the order of parameters directly forbids it.
> >
> > However, no terse syntax would help in those cases. Not the Concepts TS,
> not Bjarne's `template` prefix, nor Herb's `{}` syntax. Once the order of
> function parameters and template parameters has to differ, you lose the
> ability to use any terse syntax.
> >
> > So let's skip all of those. That's pretty much all of the algorithms.
>
> We need to look at the right problem to find the right solution;
> you cannot hold a solution, and tell me my problem doesn't
> work.


But nobody said it's supposed to be a solution to those problems.

Here is an example, from
>
>     template<InputIterator I, Sentinel<I> S, class Proj = identity,
>     IndirectUnaryPredicate<projected<I, Proj>> Pred>
>     bool all_of(I first, S last, Pred pred, Proj proj = Proj{});
>
> to
>
>     template<InputIterator I, Sentinel<I> S, IndirectUnaryPredicate<I>
> Pred>
>     bool all_of(I first, S last, Pred pred);
>
>     template<InputIterator I, Sentinel<I> S, ProjectedUnaryPredicate<I>
> Proj Pred>
>     bool all_of(I first, S last, Pred pred, Proj proj);
>
> , isn't the latter more readable?
>

Um... no? I don't know what that third template argument is supposed to be
doing. Are Proj and Pred both types? Are they the same type? Different
types? How does that work?

> The idea with terse syntax is to keep the simple cases simple. Pretty
> much nothing in the Range TS is a simple case.
> >
> > On the other hand... the complexity of the Range system I think has
> really damaged the utility of terse syntax.
> > [...]
> > The point being that the more conceptualized a function becomes, the
> chance of it being able to use terse syntax of any form approaches 0.
>
> I don't care a bit what terse syntax can do; I care only what
> problem we can solve.
>

Terse syntax is syntactic sugar. By definition, it doesn't solve problems.
Sugar makes things taste better; that's all it needs to do.

So the only question is whether the sugar is useful enough to be worth
incorporating.

> The principal users of terse syntax will not be writers of generic
> libraries, but users of generic libraries.
>
> That's an interesting way to formulate the problem, but before
> I calling it hypothetical --
>
> > And that suggests a potential problem: laziness. If users of simple
> cases get used to terse syntax, they may avoid doing things that stop them
> from being able to use terse syntax. So rather than write out the complex
> `sort` in ranges, they'd just write `void sort(RandomAccessRange auto &&r,
> auto comp = std::less<>{}, auto proj = std::identity{});` and just let it
> go at that.
>
> > Whereas, if you force them to stick that `RandomAccessRange` in a
> template argument list, and deny them the ability to use `auto` in function
> parameters, then they have no choice but to spell it out explicitly. And
> since they're having to write it long-form, they may as well constrain it
> properly.
>
> , you may as well find it's hard to defend.
>
> > They're useful when you're writing a quick lambda to be passed
> somewhere. `[](UnsignedInteger auto i) {}` is going to be easier to digest
> than `[]<UnsignedInteger I> (I i) {...}`. Not massively shorter of course,
> but still more readable.
>
> If I'm told that from
>
>     []<typename I> (I i)
>
> to
>
>     [](typename auto i)
>
> is an simplification I will be very mad,


The proposed solution would just be `[](auto i)`, just like it is in C++14.
Unconstrained is spelled by not using a constraint.

so how the
> following transition can be better?
>
>     []<UnsignedInteger I> (I i)  --->
>     [](UnsignedInteger auto i)
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>
>
>
>

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

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

<div dir=3D"ltr">On Saturday, July 7, 2018 at 5:49:32 PM UTC-4, Zhihao Yuan=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; From: Nicol Bolas =
&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Op7l=
7iGOCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;=
;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">j=
mck...@gmail.com</a>&gt;=20
<br>&gt; Sent: Saturday, July 7, 2018 10:13 AM
<br>&gt;=20
<br>&gt; I think the point you&#39;re trying to make is that applying the t=
erse syntax to most Range algorithms wouldn&#39;t make them shorter. Or at =
least, not much.
<br>
<br>Not making them simpler, or readable, or conveying more
<br>precise information. =C2=A0From
<br>
<br>=C2=A0 =C2=A0 template &lt;Iterator I&gt;
<br>=C2=A0 =C2=A0 void advance(I&amp; i, difference_type_t&lt;I&gt; n);
<br>
<br>to
<br>
<br>=C2=A0 =C2=A0 void advance(Iterator auto &amp;i, different_type_t&lt;de=
cltype(i)&gt; n);
<br>
<br>, the latter is just cryptic.<br></blockquote><div><br></div><div>I&#39=
;d hardly call it &quot;cryptic&quot;. It&#39;s very clear what it&#39;s do=
ing, once you understand the syntax. A lambda could be considered &quot;cry=
ptic&quot; if you&#39;ve never seen the syntax before.</div><div><br></div>=
<div>Also, it&#39;s not like we don&#39;t see this sort of thing with lambd=
as today: `[](auto &amp;i, difference_type_t&lt;decltype(i)&gt; n);`. Now y=
es, with C++20 allowing template header syntax in lambdas, we may not need =
it anymore, but this idiom is hardly unfamiliar to users.<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;">
&gt; In some cases, the order of parameters directly forbids it.
<br>&gt;=20
<br>&gt; However, no terse syntax would help in those cases. Not the Concep=
ts TS, not Bjarne&#39;s `template` prefix, nor Herb&#39;s `{}` syntax. Once=
 the order of function parameters and template parameters has to differ, yo=
u lose the ability to use any terse syntax.
<br>&gt;=20
<br>&gt; So let&#39;s skip all of those. That&#39;s pretty much all of the =
algorithms.
<br>
<br>We need to look at the right problem to find the right solution;
<br>you cannot hold a solution, and tell me my problem doesn&#39;t
<br>work.</blockquote><div><br></div><div>But nobody said it&#39;s supposed=
 to be a solution to those problems.<br></div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"> Here is an example, from
<br>
<br>=C2=A0 =C2=A0 template&lt;InputIterator I, Sentinel&lt;I&gt; S, class P=
roj =3D identity,
<br>=C2=A0 =C2=A0 IndirectUnaryPredicate&lt;<wbr>projected&lt;I, Proj&gt;&g=
t; Pred&gt;
<br>=C2=A0 =C2=A0 bool all_of(I first, S last, Pred pred, Proj proj =3D Pro=
j{});
<br>
<br>to
<br>
<br>=C2=A0 =C2=A0 template&lt;InputIterator I, Sentinel&lt;I&gt; S, Indirec=
tUnaryPredicate&lt;I&gt; Pred&gt;
<br>=C2=A0 =C2=A0 bool all_of(I first, S last, Pred pred);
<br>
<br>=C2=A0 =C2=A0 template&lt;InputIterator I, Sentinel&lt;I&gt; S, Project=
edUnaryPredicate&lt;I&gt; Proj Pred&gt;
<br>=C2=A0 =C2=A0 bool all_of(I first, S last, Pred pred, Proj proj);
<br>
<br>, isn&#39;t the latter more readable?<br></blockquote><div><br></div><d=
iv>Um... no? I don&#39;t know what that third template argument is supposed=
 to be doing. Are Proj and Pred both types? Are they the same type? Differe=
nt types? How does that work?<br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">
&gt; The idea with terse syntax is to keep the simple cases simple. Pretty =
much nothing in the Range TS is a simple case.
<br>&gt;=20
<br>&gt; On the other hand... the complexity of the Range system I think ha=
s really damaged the utility of terse syntax.
<br>&gt; [...]
<br>&gt; The point being that the more conceptualized a function becomes, t=
he chance of it being able to use terse syntax of any form approaches 0.
<br>
<br>I don&#39;t care a bit what terse syntax can do; I care only what
<br>problem we can solve.<br></blockquote><div><br></div><div>Terse syntax =
is syntactic sugar. By definition, it doesn&#39;t solve problems. Sugar mak=
es things taste better; that&#39;s all it needs to do.</div><div><br></div>=
<div>So the only question is whether the sugar is useful enough to be worth=
 incorporating.<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;">
&gt; The principal users of terse syntax will not be writers of generic lib=
raries, but users of generic libraries.
<br>
<br>That&#39;s an interesting way to formulate the problem, but before
<br>I calling it hypothetical --
<br>
<br>&gt; And that suggests a potential problem: laziness. If users of simpl=
e cases get used to terse syntax, they may avoid doing things that stop the=
m from being able to use terse syntax. So rather than write out the complex=
 `sort` in ranges, they&#39;d just write `void sort(RandomAccessRange auto =
&amp;&amp;r, auto comp =3D std::less&lt;&gt;{}, auto proj =3D std::identity=
{});` and just let it go at that.
<br>
<br>&gt; Whereas, if you force them to stick that `RandomAccessRange` in a =
template argument list, and deny them the ability to use `auto` in function=
 parameters, then they have no choice but to spell it out explicitly. And s=
ince they&#39;re having to write it long-form, they may as well constrain i=
t properly.
<br>
<br>, you may as well find it&#39;s hard to defend.
<br>
<br>&gt; They&#39;re useful when you&#39;re writing a quick lambda to be pa=
ssed somewhere. `[](UnsignedInteger auto i) {}` is going to be easier to di=
gest than `[]&lt;UnsignedInteger I&gt; (I i) {...}`. Not massively shorter =
of course, but still more readable.
<br>
<br>If I&#39;m told that from
<br>
<br>=C2=A0 =C2=A0 []&lt;typename I&gt; (I i)
<br>
<br>to
<br>
<br>=C2=A0 =C2=A0 [](typename auto i)
<br>
<br>is an simplification I will be very mad,</blockquote><div><br></div><di=
v>The proposed solution would just be `[](auto i)`, just like it is in C++1=
4. Unconstrained is spelled by not using a constraint.<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;">so how the
<br>following transition can be better?
<br>
<br>=C2=A0 =C2=A0 []&lt;UnsignedInteger I&gt; (I i) =C2=A0---&gt;
<br>=C2=A0 =C2=A0 [](UnsignedInteger auto i)
<br>
<br>--
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_________________
<br>
<br>
<br>
<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/77785201-b43f-4369-89d6-c8a6290f3532%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/77785201-b43f-4369-89d6-c8a6290f3532=
%40isocpp.org</a>.<br />

------=_Part_93913_1565230617.1531003930126--

------=_Part_93912_966934240.1531003930126--

.

On Saturday, July 7, 2018 at 5:49:32 PM UTC-4, Zhihao Yuan wrote:
>> so how the
>> following transition can be better?
>>
>>     []<UnsignedInteger I> (I i)  --->
>>     [](UnsignedInteger auto i)

It's better because it moves the constraint closer to the deduction
context. Consider

[]<UnsignedInteger I, Container C, SomethingElse E>(I i, C c, E e);
[](UnsignedInteger auto i, Container auto c, SomethingElse auto e);

--
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/CAFk2RUY%3D3ReLA7Yid9MrgzSXJZMyRz1L%2Bw%3DWRJHsKm3DFOzVYA%40mail.gmail.com.

.

> From: Nicol Bolas <jmckesson@gmail.com>=20
> Sent: Saturday, July 7, 2018 5:52 PM
>=20
> Also, it's not like we don't see this sort of thing with lambdas today: `=
[](auto &i, difference_type_t<decltype(i)> n);`. Now yes, with C++20 allowi=
ng template header syntax in lambdas, we may not need it anymore, but this =
idiom is hardly unfamiliar to users.

I never write that even in C++14, never.

>> Here is an example, from=20
>>=20
>>     template<InputIterator I, Sentinel<I> S, class Proj =3D identity,=20
>>     IndirectUnaryPredicate<projected<I, Proj>> Pred>=20
>>     bool all_of(I first, S last, Pred pred, Proj proj =3D Proj{});=20
>>=20
>> to=20
>>=20
>>     template<InputIterator I, Sentinel<I> S, IndirectUnaryPredicate<I> P=
red>=20
>>     bool all_of(I first, S last, Pred pred);=20
>>=20
>>     template<InputIterator I, Sentinel<I> S, ProjectedUnaryPredicate<I> =
Proj Pred>=20
>>     bool all_of(I first, S last, Pred pred, Proj proj);=20
>>=20
>> , isn't the latter more readable?
>=20
> Um... no? I don't know what that third template argument is supposed to b=
e doing. Are Proj and Pred both types? Are they the same type? Different ty=
pes? How does that work?

I had the same feeling when looking at Mergeable{I, S, O}
at the first time, but like you said, "It's very clear what it's
doing, once you understand the syntax." And my point is,
the latter is structurally simpler comparing to the former,
and that's how readability comes.

But comparing to

>>    template <Iterator I>=20
>>    void advance(I& i, difference_type_t<I> n);=20
,
>>    void advance(Iterator auto &i, different_type_t<decltype(i)> n);

is structurally more complex and introduces words that
are unrelated to the context, and that's why I called it
cryptic, or you can find a better word for that.

> Terse syntax is syntactic sugar. By definition, it doesn't solve problems=
.. Sugar makes things taste better; that's all it needs to do.

A proposal must solve problems.  Lambda is a syntax
sugar and it solves the problem of not able to write
callbacks in expressions.  Vittorio's P0915 solves the
problem of unable to express the constraints on
variables.  Comparing to

    auto item =3D producer.next();
    static_assert(StandardLayoutType<decltype(item)>);
,
    auto<StandardLayoutType> item =3D producer.next();

expresses the idea directly in code.  Although I'm a little
surprised that nobody has thought about the most
obvious solution,

    StandardLayoutType T;
    T item =3D producer.next();

but I won't say that the proposed solution is not solving
a problem.  What problem does P1141R0 solve?

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________


--=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/S47FrS9nPH4Z6Dm3gvEfH4L--CbnOxAyDRlH0cBQVDFzLd6p=
tA4vQOnGR1R7G-RCTeFl74a4wkdVkrOVfqR6fkBsH0EUbDX7XN5BPOozY1E%3D%40miator.net=
..

.

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

On Sun, Jul 8, 2018 at 12:05 AM, Zhihao Yuan <zy@miator.net> wrote:

> > From: Nicol Bolas <jmckesson@gmail.com>
> > Sent: Saturday, July 7, 2018 5:52 PM
> >
> > Also, it's not like we don't see this sort of thing with lambdas today:
> `[](auto &i, difference_type_t<decltype(i)> n);`. Now yes, with C++20
> allowing template header syntax in lambdas, we may not need it anymore, but
> this idiom is hardly unfamiliar to users.
>
> I never write that even in C++14, never.
>
> >> Here is an example, from
> >>
> >>     template<InputIterator I, Sentinel<I> S, class Proj = identity,
> >>     IndirectUnaryPredicate<projected<I, Proj>> Pred>
> >>     bool all_of(I first, S last, Pred pred, Proj proj = Proj{});
> >>
> >> to
> >>
> >>     template<InputIterator I, Sentinel<I> S, IndirectUnaryPredicate<I>
> Pred>
> >>     bool all_of(I first, S last, Pred pred);
> >>
> >>     template<InputIterator I, Sentinel<I> S, ProjectedUnaryPredicate<I>
> Proj Pred>
> >>     bool all_of(I first, S last, Pred pred, Proj proj);
> >>
> >> , isn't the latter more readable?
> >
> > Um... no? I don't know what that third template argument is supposed to
> be doing. Are Proj and Pred both types? Are they the same type? Different
> types? How does that work?
>
> I had the same feeling when looking at Mergeable{I, S, O}
> at the first time, but like you said, "It's very clear what it's
> doing, once you understand the syntax." And my point is,
> the latter is structurally simpler comparing to the former,
> and that's how readability comes.
>
Loss of visual anchors can lead to less readability. What's noise to some
are important eyecatchers to others.
Unscoped enumerations and anonymous unions come to mind with regards to the
Mergeable{I, S, O} syntax.


> But comparing to
>
> >>    template <Iterator I>
> >>    void advance(I& i, difference_type_t<I> n);
> ,
> >>    void advance(Iterator auto &i, different_type_t<decltype(i)> n);
>
> is structurally more complex and introduces words that
> are unrelated to the context, and that's why I called it
> cryptic, or you can find a better word for that.
>
> > Terse syntax is syntactic sugar. By definition, it doesn't solve
> problems. Sugar makes things taste better; that's all it needs to do.
>
> A proposal must solve problems.  Lambda is a syntax
> sugar and it solves the problem of not able to write
> callbacks in expressions.  Vittorio's P0915 solves the
> problem of unable to express the constraints on
> variables.  Comparing to
>
>     auto item = producer.next();
>     static_assert(StandardLayoutType<decltype(item)>);
> ,
>     auto<StandardLayoutType> item = producer.next();
>
> expresses the idea directly in code.  Although I'm a little
> surprised that nobody has thought about the most
> obvious solution,
>
>     StandardLayoutType T;
>     T item = producer.next();
>
Probably because it is unclear where T is bound to a concrete type in this
syntax.
Is the first binding privileged? Or is this a way of saying that all
deductions of T must agree on the deduced type?
Or perhaps T has independent binding on each use?


> but I won't say that the proposed solution is not solving
> a problem.  What problem does P1141R0 solve?
>
Wait for it...

auto item = producer.next();
static_assert(StandardLayoutType<decltype(item)>);

StandardLayoutType auto item = producer.next();


> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/R5J4t8pUi5E/unsubscribe.
> To unsubscribe from this group and all its topics, 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/S47FrS9nPH4Z6Dm3gvEfH4L--
> CbnOxAyDRlH0cBQVDFzLd6ptA4vQOnGR1R7G-RCTeFl74a4wkdVkrOVfqR6fkBsH0EU
> bDX7XN5BPOozY1E%3D%40miator.net.
>

--
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/CACvkUqb6wfcoOwcMLKm0zxRpd9v5CJXdVjD1tQY%2B-cHpkgo6Cw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jul 8, 2018 at 12:05 AM, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; From: Nicol Bolas=
 &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; <br=
>
&gt; Sent: Saturday, July 7, 2018 5:52 PM<br>
<span class=3D"gmail-">&gt; <br>
&gt; Also, it&#39;s not like we don&#39;t see this sort of thing with lambd=
as today: `[](auto &amp;i, difference_type_t&lt;decltype(i)&gt; n);`. Now y=
es, with C++20 allowing template header syntax in lambdas, we may not need =
it anymore, but this idiom is hardly unfamiliar to users.<br>
<br>
</span>I never write that even in C++14, never.<br>
<span class=3D"gmail-"><br>
&gt;&gt; Here is an example, from <br>
&gt;&gt; <br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0template&lt;InputIterator I, Sentinel&lt;I&gt; =
S, class Proj =3D identity, <br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0IndirectUnaryPredicate&lt;<wbr>projected&lt;I, =
Proj&gt;&gt; Pred&gt; <br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0bool all_of(I first, S last, Pred pred, Proj pr=
oj =3D Proj{}); <br>
&gt;&gt; <br>
&gt;&gt; to <br>
&gt;&gt; <br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0template&lt;InputIterator I, Sentinel&lt;I&gt; =
S, IndirectUnaryPredicate&lt;I&gt; Pred&gt; <br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0bool all_of(I first, S last, Pred pred); <br>
&gt;&gt; <br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0template&lt;InputIterator I, Sentinel&lt;I&gt; =
S, ProjectedUnaryPredicate&lt;I&gt; Proj Pred&gt; <br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0bool all_of(I first, S last, Pred pred, Proj pr=
oj); <br>
&gt;&gt; <br>
&gt;&gt; , isn&#39;t the latter more readable?<br>
&gt; <br>
&gt; Um... no? I don&#39;t know what that third template argument is suppos=
ed to be doing. Are Proj and Pred both types? Are they the same type? Diffe=
rent types? How does that work?<br>
<br>
</span>I had the same feeling when looking at Mergeable{I, S, O}<br>
at the first time, but like you said, &quot;It&#39;s very clear what it&#39=
;s<br>
doing, once you understand the syntax.&quot; And my point is,<br>
the latter is structurally simpler comparing to the former,<br>
and that&#39;s how readability comes.<br></blockquote><div><div>Loss of vis=
ual anchors can lead to less readability. What&#39;s noise to some are impo=
rtant eyecatchers to others.<br></div>Unscoped enumerations and anonymous u=
nions come to mind with regards to the Mergeable{I, S, O} syntax.<br><br> <=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But comparing to<br>
<span class=3D"gmail-"><br>
&gt;&gt;=C2=A0 =C2=A0 template &lt;Iterator I&gt; <br>
&gt;&gt;=C2=A0 =C2=A0 void advance(I&amp; i, difference_type_t&lt;I&gt; n);=
 <br>
</span>,<br>
<span class=3D"gmail-">&gt;&gt;=C2=A0 =C2=A0 void advance(Iterator auto &am=
p;i, different_type_t&lt;decltype(i)&gt; n);<br>
<br>
</span>is structurally more complex and introduces words that<br>
are unrelated to the context, and that&#39;s why I called it<br>
cryptic, or you can find a better word for that.<br>
<span class=3D"gmail-"><br>
&gt; Terse syntax is syntactic sugar. By definition, it doesn&#39;t solve p=
roblems. Sugar makes things taste better; that&#39;s all it needs to do.<br=
>
<br>
</span>A proposal must solve problems.=C2=A0 Lambda is a syntax<br>
sugar and it solves the problem of not able to write<br>
callbacks in expressions.=C2=A0 Vittorio&#39;s P0915 solves the<br>
problem of unable to express the constraints on<br>
variables.=C2=A0 Comparing to<br>
<br>
=C2=A0 =C2=A0 auto item =3D producer.next();<br>
=C2=A0 =C2=A0 static_assert(<wbr>StandardLayoutType&lt;decltype(<wbr>item)&=
gt;);<br>
,<br>
=C2=A0 =C2=A0 auto&lt;StandardLayoutType&gt; item =3D producer.next();<br>
<br>
expresses the idea directly in code.=C2=A0 Although I&#39;m a little<br>
surprised that nobody has thought about the most<br>
obvious solution,<br>
<br>
=C2=A0 =C2=A0 StandardLayoutType T;<br>
=C2=A0 =C2=A0 T item =3D producer.next();<br></blockquote><div>Probably bec=
ause it is unclear where T is bound to a concrete type in this syntax.<br><=
/div><div>Is the first binding privileged? Or is this a way of saying that =
all deductions of T must agree on the deduced type?<br></div><div>Or perhap=
s T has independent binding on each use?<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
<br>
but I won&#39;t say that the proposed solution is not solving<br>
a problem.=C2=A0 What problem does P1141R0 solve?<br></blockquote><div>Wait=
 for it...<br><br>auto item =3D producer.next();<br>static_assert(StandardL=
ayoutType&lt;decltype(item)&gt;);<br><br>StandardLayoutType auto item =3D p=
roducer.next();<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
<span class=3D"gmail-"><br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
______________________________<wbr>_________________<br>
<br>
<br>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/R5J4t8pUi5E/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/R5J4t8pUi5E/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/S47FrS9nPH4Z6Dm3gvEfH4L--CbnOx=
AyDRlH0cBQVDFzLd6ptA4vQOnGR1R7G-RCTeFl74a4wkdVkrOVfqR6fkBsH0EUbDX7XN5BPOozY=
1E%3D%40miator.net" rel=3D"noreferrer" target=3D"_blank">https://groups.goo=
gle.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/<wbr>S47FrS9nPH4Z6Dm3g=
vEfH4L--<wbr>CbnOxAyDRlH0cBQVDFzLd6ptA4vQOn<wbr>GR1R7G-<wbr>RCTeFl74a4wkdVk=
rOVfqR6fkBsH0EU<wbr>bDX7XN5BPOozY1E%3D%40miator.<wbr>net</a>.<br>
</blockquote></div><br></div></div>

<p></p>

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

--0000000000008b2c9c05707551bc--

.

> From: Hubert Tong <hubert.reinterpretcast@gmail.com>
> Sent: Saturday, July 7, 2018 11:27 PM
>
> Loss of visual anchors can lead to less readability. What's noise to some are important eyecatchers to others.
> Unscoped enumerations and anonymous unions come to mind with regards to the Mergeable{I, S, O} syntax.

I hope that "Mergeable I S O" is doing better since this
structure is less often seen in the language.

>>
>>    StandardLayoutType T;
>>    T item = producer.next();
>
> Probably because it is unclear where T is bound to a concrete type in this syntax.
> Is the first binding privileged? Or is this a way of saying that all deductions of T must agree on the deduced type?
Or perhaps T has independent binding on each use?

All deductions of T must agree on the same type, just
like what

    template<StandardLayoutType T>
    void(T a, T b)

does.

We can even extend this to

    EqualityComparable T U;
    T x = ...;
    U y = ...;

>> What problem does P1141R0 solve?
> Wait for it...
>
> auto item = producer.next();
> static_assert(StandardLayoutType<decltype(item)>);
>
> StandardLayoutType auto item = producer.next();

And I did not comment on that part, right?  Of course
there can be a consistency argument to defend the
constraints on parameters, but P0915R0 did not do
that since this argument would be too weak.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________


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

.

> From: Ville Voutilainen <ville.voutilainen@gmail.com>
> Sent: Saturday, July 7, 2018 6:05 PM
>
> It's better because it moves the constraint closer to the deduction context.
> Consider
>
> []<UnsignedInteger I, Container C, SomethingElse E>(I i, C c, E e);
> [](UnsignedInteger auto i, Container auto c, SomethingElse auto e);
>

Yes, and I'm not mad after seeing that, but the cost is
a much longer function parameter list plus some "auto"
noises, so I probably won't use it by myself :/

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________


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

.

------=_Part_69451_735287165.1531030987886
Content-Type: multipart/alternative;
 boundary="----=_Part_69452_912642815.1531030987887"

------=_Part_69452_912642815.1531030987887
Content-Type: text/plain; charset="UTF-8"

On Sunday, July 8, 2018 at 1:14:00 AM UTC-4, Zhihao Yuan wrote:
>
> > From: Hubert Tong <hubert.rein...@gmail.com <javascript:>>
> > Sent: Saturday, July 7, 2018 11:27 PM
> >
> > Loss of visual anchors can lead to less readability. What's noise to
> some are important eyecatchers to others.
> > Unscoped enumerations and anonymous unions come to mind with regards to
> the Mergeable{I, S, O} syntax.
>
> I hope that "Mergeable I S O" is doing better since this
> structure is less often seen in the language.
>

It's not seen "less often"; it is seen precisely *never*. It is completely
unlikely any syntax in C++. A general sequence of N tokens, with no
separator token between them, is something that appears nowhere in the
entire C++ standard.

Oh, and please note that I said "general sequence of". Yes, I know C++ does
have places where identifiers follow one another. But when this happens,
the grammar restricts how many are around; this is not defined by some
language construct. `Identifier Identifier` can declare a variable if
`Identifier` is a typename, but `Identifier Identifier Identifier` is
always syntactic nonsense. So let's not get bogged down in pedantry here.

Whenever C++ creates a new list of stuff, it *always* used C-style: there
is some kind of token pair bracketing the list (`()` and `{}` in C, `<>` in
C++), and each list item is separated from other list items by a comma
token. That's how C and C++ work when a list can be arbitrarily long.

A distinction should be made between syntax which is merely unfamiliar and
syntax which is *alien*. What you're talking about is very much the latter.

You may not understand what `Mergeable{I, S, O}` is doing, but at least you
know that the given identifiers are associated with Mergeable in some way
(since they're in a pair of braces directly after `Mergeable`), and that
the tokens that follow the {} are not involved in the same process as the
ones inside the `{}`.

>>
> >>    StandardLayoutType T;
> >>    T item = producer.next();
> >
> > Probably because it is unclear where T is bound to a concrete type in
> this syntax.
> > Is the first binding privileged? Or is this a way of saying that all
> deductions of T must agree on the deduced type?
> Or perhaps T has independent binding on each use?
>
> All deductions of T must agree on the same type, just
> like what
>
>     template<StandardLayoutType T>
>     void(T a, T b)
>
> does.
>

When you write `template<StandardLayoutType T>`, that `T` is a typename.
You can use it wherever you could use a typename. You can use it in a
function parameter, return type, or just internally in the function. Or
never at all.

That is, this is perfectly legal:

template<StandardLayoutType T>
void func(int i = sizeof(T)) {...}

But what you're talking about is not like a template parameter declaration
at all. The name you're introducing here cannot be used for anything until
it gets used in a deduction context. Only then does it become a typename.

So the analogy you're trying to create between template parameters and this
syntax simply doesn't work, because proper template parameters don't have
to be deduced at all.

Furthermore, consider your syntax. `T` is utterly useless until it is used
in a deduction context, which blesses it with a type. As such, you should
combine the declaration of `T` with the deduction context in which it is
used. The two should go hand-in-hand, so logically you should do the both
at the same time.

But you know why you didn't suggest that. It's because your alien syntax
doesn't abide by C++'s conventions on these things, and therefore could
never be used in a variable declaration:

StandardLayoutType T next = producer.next();

That's just begging for confusion. Is `next` of type `T`, or does
`StandardLayoutType` have two template arguments?

Clarifying which identifiers go with the concept and which are constrained
by it would require more C++-like lists. Like:

StandardLayoutType{T} next = producer.next();

Which of course is parseable syntax. And while it may be unfamiliar, it
isn't fundamentally alien.

Oh sure, you could do this:

StandardLayoutType T auto next = producer.next();

But really, who wants to do that? P1141 made `auto` not be required for a
good reason.


> >> What problem does P1141R0 solve?
> > Wait for it...
> >
> > auto item = producer.next();
> > static_assert(StandardLayoutType<decltype(item)>);
> >
> > StandardLayoutType auto item = producer.next();
>
> And I did not comment on that part, right?  Of course
> there can be a consistency argument to defend the
> constraints on parameters, but P0915R0 did not do
> that since this argument would be too weak.
>

Um, why is it weak? Consistency in a language is not something that should
be so idly tossed aside.

On the one hand, we have a proposal that is consistent with itself and
consistent with other aspects of C++ (lambda `auto` syntax). And on the
other, we have a pair of proposals (your idea and P0915) that both dabble
in the same idea, but are not consistent with each other nor with existing
aspects of C++.

Why adopt the latter when we can adopt the former? Especially since the
former doesn't resolve the non-type template parameter conceptualization
issue. That is, `<Concept auto val>` making `val` a value parameter, whose
type is constrained by `Concept`.

And I say, take P1141 and add Herb's syntax to it (in deduction contexts,
and only *optionally*). That is, allow me to write: `[](Iterator{I} auto
&i, different_type_t<I> n);`. It's the best of both worlds.

By "in deduction contexts", what I mean is anytime you could do `Concept
auto ...`, you can also do `Concept{T} auto ...` (in a template parameter
list, it does not create a template parameter for this `T`. It just gives
it a name). The fact that I could take a specific part of the syntax and
add an extension that applies to all uses of that syntax shows just how
regular P1141 is compared to your pair of proposals.

--
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/340d7333-282f-4b54-bb43-bed735371c30%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, July 8, 2018 at 1:14:00 AM UTC-4, Zhihao Yuan w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; From: Hubert Tong &l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fSq2Bm=
OmCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">hub=
ert.rein...@gmail.<wbr>com</a>&gt;=20
<br>&gt; Sent: Saturday, July 7, 2018 11:27 PM
<br>&gt;=20
<br>&gt; Loss of visual anchors can lead to less readability. What&#39;s no=
ise to some are important eyecatchers to others.
<br>&gt; Unscoped enumerations and anonymous unions come to mind with regar=
ds to the Mergeable{I, S, O} syntax.
<br>
<br>I hope that &quot;Mergeable I S O&quot; is doing better since this
<br>structure is less often seen in the language.<br></blockquote><div><br>=
</div><div>It&#39;s not seen &quot;less often&quot;; it is seen precisely <=
i>never</i>. It is completely unlikely any syntax in C++. A general sequenc=
e of N tokens, with no separator token between them, is something that appe=
ars nowhere in the entire C++ standard.</div><div><br></div><div>Oh, and pl=
ease note that I said &quot;general sequence of&quot;. Yes, I know C++ does=
 have places where identifiers follow one another. But when this happens, t=
he grammar restricts how many are around; this is not defined by some langu=
age construct. `Identifier Identifier` can declare a variable if `Identifie=
r` is a typename, but `Identifier Identifier Identifier` is always syntacti=
c nonsense. So let&#39;s not get bogged down in pedantry here.<br></div><di=
v><br></div><div>Whenever C++ creates a new list of stuff, it <i>always</i>=
 used C-style: there is some kind of token pair bracketing the list (`()` a=
nd `{}` in C, `&lt;&gt;` in C++), and each list item is separated from othe=
r list items by a comma token. That&#39;s how C and C++ work when a list ca=
n be arbitrarily long.<br></div><div><br></div><div>A distinction should be=
 made between syntax which is merely unfamiliar and syntax which is <i>alie=
n</i>. What you&#39;re talking about is very much the latter.<br></div><div=
><br></div><div>You may not understand what `Mergeable{I, S, O}` is doing, =
but at least you know that the given identifiers are associated with Mergea=
ble in some way (since they&#39;re in a pair of braces directly after `Merg=
eable`), and that the tokens that follow the {} are not involved in the sam=
e process as the ones inside the `{}`.</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">
&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0StandardLayoutType T;
<br>&gt;&gt; =C2=A0 =C2=A0T item =3D producer.next();
<br>&gt;=20
<br>&gt; Probably because it is unclear where T is bound to a concrete type=
 in this syntax.
<br>&gt; Is the first binding privileged? Or is this a way of saying that a=
ll deductions of T must agree on the deduced type?
<br>Or perhaps T has independent binding on each use?
<br>
<br>All deductions of T must agree on the same type, just
<br>like what
<br>
<br>=C2=A0 =C2=A0 template&lt;StandardLayoutType T&gt;
<br>=C2=A0 =C2=A0 void(T a, T b)
<br>
<br>does.<br></blockquote><div><br></div><div>When you write `template&lt;S=
tandardLayoutType T&gt;`, that `T` is a typename. You can use it wherever y=
ou could use a typename. You can use it in a function parameter, return typ=
e, or just internally in the function. Or never at all.</div><div><br></div=
><div>That is, this is perfectly legal:</div><div><br></div><div style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pr=
ettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span =
style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">StandardLayoutType</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"><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> func</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> 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: #008;" class=3D"styled-by-prettify">sizeof</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">))</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{...}</span></div></code></div><div></div><div><br></d=
iv><div>But what you&#39;re talking about is not like a template parameter =
declaration at all. The name you&#39;re introducing here cannot be used for=
 anything until it gets used in a deduction context. Only then does it beco=
me a typename.<br></div><div><br></div><div>So the analogy you&#39;re tryin=
g to create between template parameters and this syntax simply doesn&#39;t =
work, because proper template parameters don&#39;t have to be deduced at al=
l.</div><div><br></div><div>Furthermore, consider your syntax. `T` is utter=
ly useless until it is used in a deduction context, which blesses it with a=
 type. As such, you should combine the declaration of `T` with the deductio=
n context in which it is used. The two should go hand-in-hand, so logically=
 you should do the both at the same time.<br></div><br><div>But you know wh=
y you didn&#39;t suggest that. It&#39;s because your alien syntax doesn&#39=
;t abide by C++&#39;s conventions on these things, and therefore could neve=
r be used in a variable declaration:</div><div><br></div><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: #606;" class=3D"styled-by-prettify">StandardLayoutType</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> T </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">next</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> producer</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">next</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">();</span></div></code></div></div><div><br></div><div>Th=
at&#39;s just begging for confusion. Is `next` of type `T`, or does `Standa=
rdLayoutType` have two template arguments?<br></div><div><br></div><div>Cla=
rifying which identifiers go with the concept and which are constrained by =
it would require more C++-like lists. Like:</div><div><br></div><div><div s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); border-style: solid; border-width: 1px; overflow-wrap: break-word;" cl=
ass=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #606;" class=3D"styled-by-prettify">StandardLayout=
Type</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">next</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> producer</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>next</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</=
span></div></code></div><br>Which of course is parseable syntax. And while =
it may be unfamiliar, it isn&#39;t fundamentally alien.</div><div><br></div=
><div>Oh sure, you could do this:</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: #606;" class=3D"styled-by-prettify">StandardLayoutType</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> T </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">next</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"sty=
led-by-prettify"> producer</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">next</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>();</span></div></code></div><br></div><div>But really, who wants to do th=
at? P1141 made `auto` not be required for a good reason.<br></div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt;&gt; What problem does P1141R0 solve?
<br>&gt; Wait for it...
<br>&gt;=20
<br>&gt; auto item =3D producer.next();
<br>&gt; static_assert(<wbr>StandardLayoutType&lt;decltype(<wbr>item)&gt;);
<br>&gt;=20
<br>&gt; StandardLayoutType auto item =3D producer.next();
<br>
<br>And I did not comment on that part, right? =C2=A0Of course
<br>there can be a consistency argument to defend the
<br>constraints on parameters, but P0915R0 did not do
<br>that since this argument would be too weak.<br></blockquote><div><br></=
div><div>Um, why is it weak? Consistency in a language is not something tha=
t should be so idly tossed aside.</div><div><br></div><div>On the one hand,=
 we have a proposal that is consistent with itself and consistent with othe=
r aspects of C++ (lambda `auto` syntax). And on the other, we have a pair o=
f proposals (your idea and P0915) that both dabble in the same idea, but ar=
e not consistent with each other nor with existing aspects of C++. <br></di=
v><div><br></div><div>Why adopt the latter when we can adopt the former? Es=
pecially since the former doesn&#39;t resolve the non-type template paramet=
er conceptualization issue. That is, `&lt;Concept auto val&gt;` making `val=
` a value parameter, whose type is constrained by `Concept`.<br></div><div>=
<br></div><div>And I say, take P1141 and add Herb&#39;s syntax to it (in de=
duction contexts, and only <i>optionally</i>). That is, allow me to write: =
`[](Iterator{I} auto &amp;i, different_type_t&lt;I&gt; n);`. It&#39;s the b=
est of both worlds.</div><div><br></div><div>By &quot;in deduction contexts=
&quot;, what I mean is anytime you could do `Concept auto ...`, you can als=
o do `Concept{T} auto ...` (in a template parameter list, it does not creat=
e a template parameter for this `T`. It just gives it a name). The fact tha=
t I could take a specific part of the syntax and add an extension that appl=
ies to all uses of that syntax shows just how regular P1141 is compared to =
your pair of proposals.</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/340d7333-282f-4b54-bb43-bed735371c30%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/340d7333-282f-4b54-bb43-bed735371c30=
%40isocpp.org</a>.<br />

------=_Part_69452_912642815.1531030987887--

------=_Part_69451_735287165.1531030987886--

.

------=_Part_83925_990110634.1531033638361
Content-Type: multipart/alternative;
 boundary="----=_Part_83926_1849534964.1531033638361"

------=_Part_83926_1849534964.1531033638361
Content-Type: text/plain; charset="UTF-8"



On Sunday, July 8, 2018 at 2:23:07 AM UTC-4, Nicol Bolas wrote:
>
> On Sunday, July 8, 2018 at 1:14:00 AM UTC-4, Zhihao Yuan wrote:
>>
>> > From: Hubert Tong <hubert.rein...@gmail.com>
>> > Sent: Saturday, July 7, 2018 11:27 PM
>> >
>> > Loss of visual anchors can lead to less readability. What's noise to
>> some are important eyecatchers to others.
>> > Unscoped enumerations and anonymous unions come to mind with regards to
>> the Mergeable{I, S, O} syntax.
>>
>> I hope that "Mergeable I S O" is doing better since this
>> structure is less often seen in the language.
>>
>
> It's not seen "less often"; it is seen precisely *never*. It is
> completely unlikely any syntax in C++. A general sequence of N tokens, with
> no separator token between them, is something that appears nowhere in the
> entire C++ standard.
>
> Oh, and please note that I said "general sequence of". Yes, I know C++
> does have places where identifiers follow one another. But when this
> happens, the grammar restricts how many are around; this is not defined by
> some language construct. `Identifier Identifier` can declare a variable if
> `Identifier` is a typename, but `Identifier Identifier Identifier` is
> always syntactic nonsense. So let's not get bogged down in pedantry here.
>
> Whenever C++ creates a new list of stuff, it *always* used C-style: there
> is some kind of token pair bracketing the list (`()` and `{}` in C, `<>` in
> C++), and each list item is separated from other list items by a comma
> token. That's how C and C++ work when a list can be arbitrarily long.
>

Note that member initialization lists in constructors don't have a token
pair bracketing them, but they are still comma separated. There was no
grammatical *necessity* for comma separation; after all, each member's
initializer has to be in parenthesis (C++11 added braces). So it was
theoretically possible to just have a non-separated list.

They didn't do that because... well, that's just not how C and C++ are
expected to list things.

--
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/1870f8c8-53b3-412a-8f4a-cfc986f1f730%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Sunday, July 8, 2018 at 2:23:07 AM UTC-4, Nicol=
 Bolas 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">=
On Sunday, July 8, 2018 at 1:14:00 AM UTC-4, Zhihao Yuan wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">&gt; From: Hubert Tong &lt;<a rel=3D"nofollow">=
hubert.rein...@gmail.com</a>&gt;=20
<br>&gt; Sent: Saturday, July 7, 2018 11:27 PM
<br>&gt;=20
<br>&gt; Loss of visual anchors can lead to less readability. What&#39;s no=
ise to some are important eyecatchers to others.
<br>&gt; Unscoped enumerations and anonymous unions come to mind with regar=
ds to the Mergeable{I, S, O} syntax.
<br>
<br>I hope that &quot;Mergeable I S O&quot; is doing better since this
<br>structure is less often seen in the language.<br></blockquote><div><br>=
</div><div>It&#39;s not seen &quot;less often&quot;; it is seen precisely <=
i>never</i>. It is completely unlikely any syntax in C++. A general sequenc=
e of N tokens, with no separator token between them, is something that appe=
ars nowhere in the entire C++ standard.</div><div><br></div><div>Oh, and pl=
ease note that I said &quot;general sequence of&quot;. Yes, I know C++ does=
 have places where identifiers follow one another. But when this happens, t=
he grammar restricts how many are around; this is not defined by some langu=
age construct. `Identifier Identifier` can declare a variable if `Identifie=
r` is a typename, but `Identifier Identifier Identifier` is always syntacti=
c nonsense. So let&#39;s not get bogged down in pedantry here.<br></div><di=
v><br></div><div>Whenever C++ creates a new list of stuff, it <i>always</i>=
 used C-style: there is some kind of token pair bracketing the list (`()` a=
nd `{}` in C, `&lt;&gt;` in C++), and each list item is separated from othe=
r list items by a comma token. That&#39;s how C and C++ work when a list ca=
n be arbitrarily long.<br></div></div></blockquote><div><br></div><div>Note=
 that member initialization lists in constructors don&#39;t have a token pa=
ir bracketing them, but they are still comma separated. There was no gramma=
tical <i>necessity</i> for comma separation; after all, each member&#39;s i=
nitializer has to be in parenthesis (C++11 added braces). So it was theoret=
ically possible to just have a non-separated list.</div><div><br></div><div=
>They didn&#39;t do that because... well, that&#39;s just not how C and C++=
 are expected to list things.<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/1870f8c8-53b3-412a-8f4a-cfc986f1f730%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1870f8c8-53b3-412a-8f4a-cfc986f1f730=
%40isocpp.org</a>.<br />

------=_Part_83926_1849534964.1531033638361--

------=_Part_83925_990110634.1531033638361--

.

> From: Nicol Bolas <jmckesson@gmail.com>=20
> Sent: Sunday, July 8, 2018 1:23 AM
>=20
>> I hope that "Mergeable I S O" is doing better since this=20
>> structure is less often seen in the language.
>=20
> It's not seen "less often"; it is seen precisely never. It is completely =
unlikely any syntax in C++. A general sequence of N tokens, with no separat=
or token between them, is something that appears nowhere in the entire C++ =
standard.
> [...]
> A distinction should be made between syntax which is merely unfamiliar an=
d syntax which is alien. What you're talking about is very much the latter.

Looks good to me since alien subsumes unfamiliar.

> That is, this is perfectly legal:
>=20
> template<StandardLayoutType T>
> void func(int i =3D sizeof(T)) {...}
>=20
> But what you're talking about is not like a template parameter declaratio=
n at all. The name you're introducing here cannot be used for anything unti=
l it gets used in a deduction context. Only then does it become a typename.
>=20
> So the analogy you're trying to create between template parameters and th=
is syntax simply doesn't work, because proper template parameters don't hav=
e to be deduced at all.

Based on the same logic people should not build
analogy between

    void foo(auto x);

and

    auto x =3D ...;

because you can do

    foo<int>('a');

?

> Furthermore, consider your syntax. `T` is utterly useless until it is use=
d in a deduction context, which blesses it with a type. As such, you should=
 combine the declaration of `T` with the deduction context in which it is u=
sed. The two should go hand-in-hand, so logically you should do the both at=
 the same time.

Why they have to?  What's the problem with

    Copyable T;
    int sz =3D sizeof(T);
    T x =3D foo();

?

> But you know why you didn't suggest that. It's because your alien syntax =
doesn't abide by C++'s conventions on these things, and therefore could nev=
er be used in a variable declaration:
>=20
> StandardLayoutType T next =3D producer.next();

I do not know why I didn't suggest that, maybe
because that the idea of putting a type declaration
and a variable declaration in one statement is alien
to me?  It's a strawman that I don't even know how
to comment on...

And which part makes

    StandardLayoutType T;

an alien syntax?  How this is different from

    MyIntType X;

?

Both follow C++ declaration style, right? =20

>> Of course=20
>> there can be a consistency argument to defend the=20
>> constraints on parameters, but P0915R0 did not do=20
>> that since this argument would be too weak.
>=20
> Um, why is it weak? Consistency in a language is not something that shoul=
d be so idly tossed aside.

Feature A with a small demand which creates a
consistency argument for feature B with a different
demand is a basic example of camel's nose.

> [...] , we have a pair of proposals (your idea and P0915)

I did not endorse P0915; I only said that it solves a
problem.

"My pair of proposals" would be

    template<EqualityComparable T U>
    void foo(T a, b a);

and

    EqualityComparable T U;
    T a =3D ...;
    U b =3D ...;

> By "in deduction contexts", what I mean is anytime you could do `Concept =
auto ...`, you can also do `Concept{T} auto ...` (in a template parameter l=
ist, it does not create a template parameter for this `T`. It just gives it=
 a name). The fact that I could take a specific part of the syntax and add =
an extension that applies to all uses of that syntax shows just how regular=
 P1141 is compared to your pair of proposals.

I don't understand the logic behind the "regular"
qualification.  My idea is compatible with various
things,

    +Status quo: template<IntType a b>
    +P1141: template<EqualityComparable T U>
    +P1142 if needed: template<TwoContainerLike template V Q>

is that "regular?"

--
Zhihao


--=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/JBNTYXvRKl-dQzIDFOPmA5jgGjB36JagfWzawDT6ZLVoME0G=
0Zj5nzzv9RYcIYuA-E-mAenGKr4N-BFx2g4kCcFE2SHksGq9P_zDyF3t3bs%3D%40miator.net=
..

.

------=_Part_97057_1366770513.1531042068095
Content-Type: multipart/alternative;
 boundary="----=_Part_97058_97471003.1531042068095"

------=_Part_97058_97471003.1531042068095
Content-Type: text/plain; charset="UTF-8"



On Sunday, July 8, 2018 at 9:23:07 AM UTC+3, Nicol Bolas wrote:
>
> On Sunday, July 8, 2018 at 1:14:00 AM UTC-4, Zhihao Yuan wrote:
>>
>> > From: Hubert Tong <hubert.rein...@gmail.com>
>> > Sent: Saturday, July 7, 2018 11:27 PM
>> >
>> > Loss of visual anchors can lead to less readability. What's noise to
>> some are important eyecatchers to others.
>> > Unscoped enumerations and anonymous unions come to mind with regards to
>> the Mergeable{I, S, O} syntax.
>>
>> I hope that "Mergeable I S O" is doing better since this
>> structure is less often seen in the language.
>>
>
> It's not seen "less often"; it is seen precisely *never*. It is
> completely unlikely any syntax in C++. A general sequence of N tokens, with
> no separator token between them, is something that appears nowhere in the
> entire C++ standard.
>
> Oh, and please note that I said "general sequence of". Yes, I know C++
> does have places where identifiers follow one another. But when this
> happens, the grammar restricts how many are around; this is not defined by
> some language construct. `Identifier Identifier` can declare a variable if
> `Identifier` is a typename, but `Identifier Identifier Identifier` is
> always syntactic nonsense. So let's not get bogged down in pedantry here.
>
> Whenever C++ creates a new list of stuff, it *always* used C-style: there
> is some kind of token pair bracketing the list (`()` and `{}` in C, `<>` in
> C++), and each list item is separated from other list items by a comma
> token. That's how C and C++ work when a list can be arbitrarily long.
>
> A distinction should be made between syntax which is merely unfamiliar and
> syntax which is *alien*. What you're talking about is very much the
> latter.
>
> You may not understand what `Mergeable{I, S, O}` is doing, but at least
> you know that the given identifiers are associated with Mergeable in some
> way (since they're in a pair of braces directly after `Mergeable`), and
> that the tokens that follow the {} are not involved in the same process as
> the ones inside the `{}`.
>
> >>
>> >>    StandardLayoutType T;
>> >>    T item = producer.next();
>> >
>> > Probably because it is unclear where T is bound to a concrete type in
>> this syntax.
>> > Is the first binding privileged? Or is this a way of saying that all
>> deductions of T must agree on the deduced type?
>> Or perhaps T has independent binding on each use?
>>
>> All deductions of T must agree on the same type, just
>> like what
>>
>>     template<StandardLayoutType T>
>>     void(T a, T b)
>>
>> does.
>>
>
> When you write `template<StandardLayoutType T>`, that `T` is a typename.
> You can use it wherever you could use a typename. You can use it in a
> function parameter, return type, or just internally in the function. Or
> never at all.
>
> That is, this is perfectly legal:
>
> template<StandardLayoutType T>
> void func(int i = sizeof(T)) {...}
>
> But what you're talking about is not like a template parameter declaration
> at all. The name you're introducing here cannot be used for anything until
> it gets used in a deduction context. Only then does it become a typename.
>
> So the analogy you're trying to create between template parameters and
> this syntax simply doesn't work, because proper template parameters don't
> have to be deduced at all.
>
> Furthermore, consider your syntax. `T` is utterly useless until it is used
> in a deduction context, which blesses it with a type. As such, you should
> combine the declaration of `T` with the deduction context in which it is
> used. The two should go hand-in-hand, so logically you should do the both
> at the same time.
>
> But you know why you didn't suggest that. It's because your alien syntax
> doesn't abide by C++'s conventions on these things, and therefore could
> never be used in a variable declaration:
>
> StandardLayoutType T next = producer.next();
>
> That's just begging for confusion. Is `next` of type `T`, or does
> `StandardLayoutType` have two template arguments?
>


Well, I suggested it above.

It is not confusing, considering we introduce stuff left to right
Class var;
or even
class Class var;

Once we learn Concept Type is "instantiation" of a new type based on a
concept we "only" have to deal with two declarations.

HOWEVER this is not new!

func(class Class& var)

*This is double declaration *- we introduce both a new type and a variable!

*We only tweak the rule*

If concept is used instead - the name is still introduced* exactly as
before*, however the type is not a concrete type, but will be late-bound on
instantiation!

It is that simple! No new syntax, just natural evolution of type name
introduction - concrete type vs late-bound one.


It is another topic if let instantiation of a type to be undefined until
the first use.
Concept Type;
Type var = . . .


>
> Clarifying which identifiers go with the concept and which are constrained
> by it would require more C++-like lists. Like:
>
> StandardLayoutType{T} next = producer.next();
>
> Which of course is parseable syntax. And while it may be unfamiliar, it
> isn't fundamentally alien.
>
> Oh sure, you could do this:
>
> StandardLayoutType T auto next = producer.next();
>
> But really, who wants to do that? P1141 made `auto` not be required for a
> good reason.
>
>
>> >> What problem does P1141R0 solve?
>> > Wait for it...
>> >
>> > auto item = producer.next();
>> > static_assert(StandardLayoutType<decltype(item)>);
>> >
>> > StandardLayoutType auto item = producer.next();
>>
>> And I did not comment on that part, right?  Of course
>> there can be a consistency argument to defend the
>> constraints on parameters, but P0915R0 did not do
>> that since this argument would be too weak.
>>
>
> Um, why is it weak? Consistency in a language is not something that should
> be so idly tossed aside.
>
> On the one hand, we have a proposal that is consistent with itself and
> consistent with other aspects of C++ (lambda `auto` syntax). And on the
> other, we have a pair of proposals (your idea and P0915) that both dabble
> in the same idea, but are not consistent with each other nor with existing
> aspects of C++.
>
> Why adopt the latter when we can adopt the former? Especially since the
> former doesn't resolve the non-type template parameter conceptualization
> issue. That is, `<Concept auto val>` making `val` a value parameter, whose
> type is constrained by `Concept`.
>
> And I say, take P1141 and add Herb's syntax to it (in deduction contexts,
> and only *optionally*). That is, allow me to write: `[](Iterator{I} auto
> &i, different_type_t<I> n);`. It's the best of both worlds.
>
> By "in deduction contexts", what I mean is anytime you could do `Concept
> auto ...`, you can also do `Concept{T} auto ...` (in a template parameter
> list, it does not create a template parameter for this `T`. It just gives
> it a name). The fact that I could take a specific part of the syntax and
> add an extension that applies to all uses of that syntax shows just how
> regular P1141 is compared to your pair of proposals.
>

--
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/47b7e404-66ec-467b-bce1-e6abb47b45a6%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Sunday, July 8, 2018 at 9:23:07 AM UTC+3, Nicol=
 Bolas 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">=
On Sunday, July 8, 2018 at 1:14:00 AM UTC-4, Zhihao Yuan wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">&gt; From: Hubert Tong &lt;<a rel=3D"nofollow">=
hubert.rein...@gmail.com</a>&gt;=20
<br>&gt; Sent: Saturday, July 7, 2018 11:27 PM
<br>&gt;=20
<br>&gt; Loss of visual anchors can lead to less readability. What&#39;s no=
ise to some are important eyecatchers to others.
<br>&gt; Unscoped enumerations and anonymous unions come to mind with regar=
ds to the Mergeable{I, S, O} syntax.
<br>
<br>I hope that &quot;Mergeable I S O&quot; is doing better since this
<br>structure is less often seen in the language.<br></blockquote><div><br>=
</div><div>It&#39;s not seen &quot;less often&quot;; it is seen precisely <=
i>never</i>. It is completely unlikely any syntax in C++. A general sequenc=
e of N tokens, with no separator token between them, is something that appe=
ars nowhere in the entire C++ standard.</div><div><br></div><div>Oh, and pl=
ease note that I said &quot;general sequence of&quot;. Yes, I know C++ does=
 have places where identifiers follow one another. But when this happens, t=
he grammar restricts how many are around; this is not defined by some langu=
age construct. `Identifier Identifier` can declare a variable if `Identifie=
r` is a typename, but `Identifier Identifier Identifier` is always syntacti=
c nonsense. So let&#39;s not get bogged down in pedantry here.<br></div><di=
v><br></div><div>Whenever C++ creates a new list of stuff, it <i>always</i>=
 used C-style: there is some kind of token pair bracketing the list (`()` a=
nd `{}` in C, `&lt;&gt;` in C++), and each list item is separated from othe=
r list items by a comma token. That&#39;s how C and C++ work when a list ca=
n be arbitrarily long.<br></div><div><br></div><div>A distinction should be=
 made between syntax which is merely unfamiliar and syntax which is <i>alie=
n</i>. What you&#39;re talking about is very much the latter.<br></div><div=
><br></div><div>You may not understand what `Mergeable{I, S, O}` is doing, =
but at least you know that the given identifiers are associated with Mergea=
ble in some way (since they&#39;re in a pair of braces directly after `Merg=
eable`), and that the tokens that follow the {} are not involved in the sam=
e process as the ones inside the `{}`.</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">
&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0StandardLayoutType T;
<br>&gt;&gt; =C2=A0 =C2=A0T item =3D producer.next();
<br>&gt;=20
<br>&gt; Probably because it is unclear where T is bound to a concrete type=
 in this syntax.
<br>&gt; Is the first binding privileged? Or is this a way of saying that a=
ll deductions of T must agree on the deduced type?
<br>Or perhaps T has independent binding on each use?
<br>
<br>All deductions of T must agree on the same type, just
<br>like what
<br>
<br>=C2=A0 =C2=A0 template&lt;StandardLayoutType T&gt;
<br>=C2=A0 =C2=A0 void(T a, T b)
<br>
<br>does.<br></blockquote><div><br></div><div>When you write `template&lt;S=
tandardLayoutType T&gt;`, that `T` is a typename. You can use it wherever y=
ou could use a typename. You can use it in a function parameter, return typ=
e, or just internally in the function. Or never at all.</div><div><br></div=
><div>That is, this is perfectly legal:</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:#008">template</sp=
an><span style=3D"color:#660">&lt;</span><span style=3D"color:#606">Standar=
dLayoutType</span><span style=3D"color:#000"> T</span><span style=3D"color:=
#660">&gt;</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#008">void</span><span style=3D"color:#000"> func</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#008">int</span><span style=3D"color:=
#000"> i </span><span style=3D"color:#660">=3D</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">sizeof</span><span style=3D"color:#=
660">(</span><span style=3D"color:#000">T</span><span style=3D"color:#660">=
))</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{...=
}</span></div></code></div><div></div><div><br></div><div>But what you&#39;=
re talking about is not like a template parameter declaration at all. The n=
ame you&#39;re introducing here cannot be used for anything until it gets u=
sed in a deduction context. Only then does it become a typename.<br></div><=
div><br></div><div>So the analogy you&#39;re trying to create between templ=
ate parameters and this syntax simply doesn&#39;t work, because proper temp=
late parameters don&#39;t have to be deduced at all.</div><div><br></div><d=
iv>Furthermore, consider your syntax. `T` is utterly useless until it is us=
ed in a deduction context, which blesses it with a type. As such, you shoul=
d combine the declaration of `T` with the deduction context in which it is =
used. The two should go hand-in-hand, so logically you should do the both a=
t the same time.<br></div><br><div>But you know why you didn&#39;t suggest =
that. It&#39;s because your alien syntax doesn&#39;t abide by C++&#39;s con=
ventions on these things, and therefore could never be used in a variable d=
eclaration:</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 style=3D"color:#606">StandardLayoutType</span><span styl=
e=3D"color:#000"> T </span><span style=3D"color:#008">next</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> producer</span><span style=3D"color:#660">.</span><span st=
yle=3D"color:#008">next</span><span style=3D"color:#660">();</span></div></=
code></div></div><div><br></div><div>That&#39;s just begging for confusion.=
 Is `next` of type `T`, or does `StandardLayoutType` have two template argu=
ments?<br></div></div></blockquote><div><br></div><div><br></div><div>Well,=
 I suggested it above.</div><div><br></div><div>It is not confusing, consid=
ering we introduce stuff left to right=C2=A0</div><div><font face=3D"courie=
r new,monospace">Class var;=C2=A0</font></div><div><font face=3D"courier ne=
w,monospace"><font face=3D"arial,sans-serif">or even=C2=A0</font></font></d=
iv><div><font face=3D"courier new,monospace">class Class var;</font></div><=
div><font face=3D"courier new,monospace"><br></font></div><div>Once we lear=
n <font face=3D"courier new,monospace">Concept Type</font> is &quot;instant=
iation&quot; of a new type based on a concept we &quot;only&quot; have to d=
eal with two declarations.=C2=A0<br></div><div><br></div><div>HOWEVER this =
is not new!</div><div><br></div><div><font face=3D"courier new,monospace">f=
unc(class Class&amp; var)</font></div><div><font face=3D"courier new,monosp=
ace"><br></font></div><div><i><font face=3D"arial,sans-serif">This is doubl=
e declaration</font><font face=3D"courier new,monospace"> </font></i><font =
face=3D"arial,sans-serif">- we introduce both a new type and a variable!</f=
ont></div><div><font face=3D"arial,sans-serif"><br></font></div><div><font =
face=3D"arial,sans-serif"><b>We only tweak the rule</b></font></div><div><f=
ont face=3D"arial,sans-serif"><b></b><br></font></div><div><font face=3D"ar=
ial,sans-serif">If concept is used instead -=C2=A0</font>the name is still =
introduced<font face=3D"arial,sans-serif"><i> exactly as before</i>, </font=
>however <font face=3D"arial,sans-serif">the type is not a concrete type, b=
ut will be late-bound on instantiation!=C2=A0</font></div><div><font face=
=3D"arial,sans-serif"><br></font></div><div><font face=3D"arial,sans-serif"=
>It is that simple! No new syntax, just natural evolution of type name intr=
oduction - concrete type vs late-bound one.</font></div><div><font face=3D"=
courier new,monospace"></font><font face=3D"arial,sans-serif"></font><font =
face=3D"arial,sans-serif"></font><font face=3D"arial,sans-serif"></font><i>=
</i><i></i><br></div><div><br style=3D"background-attachment: scroll; backg=
round-clip: border-box; background-color: transparent; background-image: no=
ne; background-origin: padding-box; background-position-x: 0%; background-p=
osition-y: 0%; background-repeat: repeat; background-size: auto; 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; height: auto=
; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;=
 min-width: 0px; overflow: visible; overflow-x: visible; overflow-y: visibl=
e; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top:=
 0px;"></div><div><div style=3D"background-color: transparent; border-botto=
m-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0=
px; border-image-outset: 0; border-image-repeat: stretch; border-image-slic=
e: 100%; border-image-source: none; border-image-width: 1; border-left-colo=
r: 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-to=
p-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: 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;">It is another topic if let instantiation of a type to be undef=
ined until the first use.=C2=A0</div><b></b><i></i><u></u><sub></sub><sup><=
/sup><strike></strike><font face=3D"courier new,monospace">Concept Type;</f=
ont></div><div><font face=3D"courier new,monospace">Type var =3D . . .=C2=
=A0</font></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div></div><div><br></div><div>Clarifying which identif=
iers go with the concept and which are constrained by it would require more=
 C++-like lists. Like:</div><div><br></div><div><div style=3D"background-co=
lor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;borde=
r-width:1px"><code><div><span style=3D"color:#606">StandardLayoutType</span=
><span style=3D"color:#660">{</span><span style=3D"color:#000">T</span><spa=
n style=3D"color:#660">}</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">next</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> producer</span><span =
style=3D"color:#660">.</span><span style=3D"color:#008">next</span><span st=
yle=3D"color:#660">();</span></div></code></div><br>Which of course is pars=
eable syntax. And while it may be unfamiliar, it isn&#39;t fundamentally al=
ien.</div><div><br></div><div>Oh sure, you could do this:</div><div><br></d=
iv><div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px"><code><div><span style=3D"c=
olor:#606">StandardLayoutType</span><span style=3D"color:#000"> T </span><s=
pan style=3D"color:#008">auto</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#008">next</span><span style=3D"color:#000"> </span><span =
style=3D"color:#660">=3D</span><span style=3D"color:#000"> producer</span><=
span style=3D"color:#660">.</span><span style=3D"color:#008">next</span><sp=
an style=3D"color:#660">();</span></div></code></div><br></div><div>But rea=
lly, who wants to do that? P1141 made `auto` not be required for a good rea=
son.<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">
<br>&gt;&gt; What problem does P1141R0 solve?
<br>&gt; Wait for it...
<br>&gt;=20
<br>&gt; auto item =3D producer.next();
<br>&gt; static_assert(<wbr>StandardLayoutType&lt;decltype(<wbr>item)&gt;);
<br>&gt;=20
<br>&gt; StandardLayoutType auto item =3D producer.next();
<br>
<br>And I did not comment on that part, right? =C2=A0Of course
<br>there can be a consistency argument to defend the
<br>constraints on parameters, but P0915R0 did not do
<br>that since this argument would be too weak.<br></blockquote><div><br></=
div><div>Um, why is it weak? Consistency in a language is not something tha=
t should be so idly tossed aside.</div><div><br></div><div>On the one hand,=
 we have a proposal that is consistent with itself and consistent with othe=
r aspects of C++ (lambda `auto` syntax). And on the other, we have a pair o=
f proposals (your idea and P0915) that both dabble in the same idea, but ar=
e not consistent with each other nor with existing aspects of C++. <br></di=
v><div><br></div><div>Why adopt the latter when we can adopt the former? Es=
pecially since the former doesn&#39;t resolve the non-type template paramet=
er conceptualization issue. That is, `&lt;Concept auto val&gt;` making `val=
` a value parameter, whose type is constrained by `Concept`.<br></div><div>=
<br></div><div>And I say, take P1141 and add Herb&#39;s syntax to it (in de=
duction contexts, and only <i>optionally</i>). That is, allow me to write: =
`[](Iterator{I} auto &amp;i, different_type_t&lt;I&gt; n);`. It&#39;s the b=
est of both worlds.</div><div><br></div><div>By &quot;in deduction contexts=
&quot;, what I mean is anytime you could do `Concept auto ...`, you can als=
o do `Concept{T} auto ...` (in a template parameter list, it does not creat=
e a template parameter for this `T`. It just gives it a name). The fact tha=
t I could take a specific part of the syntax and add an extension that appl=
ies to all uses of that syntax shows just how regular P1141 is compared to =
your pair of proposals.</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/47b7e404-66ec-467b-bce1-e6abb47b45a6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/47b7e404-66ec-467b-bce1-e6abb47b45a6=
%40isocpp.org</a>.<br />

------=_Part_97058_97471003.1531042068095--

------=_Part_97057_1366770513.1531042068095--

.

------=_Part_40458_658168638.1531048930378
Content-Type: multipart/alternative;
 boundary="----=_Part_40459_619899894.1531048930380"

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



On Sunday, July 8, 2018 at 9:23:07 AM UTC+3, Nicol Bolas wrote:
>
> On Sunday, July 8, 2018 at 1:14:00 AM UTC-4, Zhihao Yuan wrote:
>>
>> > From: Hubert Tong <hubert.rein...@gmail.com>=20
>> > Sent: Saturday, July 7, 2018 11:27 PM=20
>> >=20
>> > Loss of visual anchors can lead to less readability. What's noise to=
=20
>> some are important eyecatchers to others.=20
>> > Unscoped enumerations and anonymous unions come to mind with regards t=
o=20
>> the Mergeable{I, S, O} syntax.=20
>>
>> I hope that "Mergeable I S O" is doing better since this=20
>> structure is less often seen in the language.
>>
>
> It's not seen "less often"; it is seen precisely *never*. It is=20
> completely unlikely any syntax in C++. A general sequence of N tokens, wi=
th=20
> no separator token between them, is something that appears nowhere in the=
=20
> entire C++ standard.
>
> Oh, and please note that I said "general sequence of". Yes, I know C++=20
> does have places where identifiers follow one another. But when this=20
> happens, the grammar restricts how many are around; this is not defined b=
y=20
> some language construct. `Identifier Identifier` can declare a variable i=
f=20
> `Identifier` is a typename, but `Identifier Identifier Identifier` is=20
> always syntactic nonsense. So let's not get bogged down in pedantry here.
>
> Whenever C++ creates a new list of stuff, it *always* used C-style: there=
=20
> is some kind of token pair bracketing the list (`()` and `{}` in C, `<>` =
in=20
> C++), and each list item is separated from other list items by a comma=20
> token. That's how C and C++ work when a list can be arbitrarily long.
>
> A distinction should be made between syntax which is merely unfamiliar an=
d=20
> syntax which is *alien*. What you're talking about is very much the=20
> latter.
>
> You may not understand what `Mergeable{I, S, O}` is doing, but at least=
=20
> you know that the given identifiers are associated with Mergeable in some=
=20
> way (since they're in a pair of braces directly after `Mergeable`), and=
=20
> that the tokens that follow the {} are not involved in the same process a=
s=20
> the ones inside the `{}`.
>
> >>=20
>> >>    StandardLayoutType T;=20
>> >>    T item =3D producer.next();=20
>> >=20
>> > Probably because it is unclear where T is bound to a concrete type in=
=20
>> this syntax.=20
>> > Is the first binding privileged? Or is this a way of saying that all=
=20
>> deductions of T must agree on the deduced type?=20
>> Or perhaps T has independent binding on each use?=20
>>
>> All deductions of T must agree on the same type, just=20
>> like what=20
>>
>>     template<StandardLayoutType T>=20
>>     void(T a, T b)=20
>>
>> does.
>>
>
> When you write `template<StandardLayoutType T>`, that `T` is a typename.=
=20
> You can use it wherever you could use a typename. You can use it in a=20
> function parameter, return type, or just internally in the function. Or=
=20
> never at all.
>
> That is, this is perfectly legal:
>
> template<StandardLayoutType T>
> void func(int i =3D sizeof(T)) {...}
>
> But what you're talking about is not like a template parameter declaratio=
n=20
> at all. The name you're introducing here cannot be used for anything unti=
l=20
> it gets used in a deduction context. Only then does it become a typename.
>
> So the analogy you're trying to create between template parameters and=20
> this syntax simply doesn't work, because proper template parameters don't=
=20
> have to be deduced at all.
>
> Furthermore, consider your syntax. `T` is utterly useless until it is use=
d=20
> in a deduction context, which blesses it with a type. As such, you should=
=20
> combine the declaration of `T` with the deduction context in which it is=
=20
> used. The two should go hand-in-hand, so logically you should do the both=
=20
> at the same time.
>
> But you know why you didn't suggest that. It's because your alien syntax=
=20
> doesn't abide by C++'s conventions on these things, and therefore could=
=20
> never be used in a variable declaration:
>
> StandardLayoutType T next =3D producer.next();
>
> That's just begging for confusion. Is `next` of type `T`, or does=20
> `StandardLayoutType` have two template arguments?
>


Well, I suggested it above.

It is not confusing, considering we introduce stuff left to right=20
Class var;=20
or even=20
class Class var;

Once we learn Concept Type is "instantiation" of a new type based on a=20
concept we "only" have to deal with two declarations.=20

HOWEVER this is not new!

func(class Class& var)

*This is double declaration *- we introduce both a new type and a variable!

*We only tweak the rule*

If concept is used instead - the name is still introduced* exactly as=20
before*, however the type is not a concrete type, but will be late-bound on=
=20
instantiation!=20

It is that simple! No new syntax, just natural evolution of type name=20
introduction - concrete type vs late-bound one.


It is another topic if let instantiation of a type to be undefined until=20
the first use.=20
Concept Type;
Type var =3D . . .=20

=20

>
> Clarifying which identifiers go with the concept and which are constraine=
d=20
> by it would require more C++-like lists. Like:
>
> StandardLayoutType{T} next =3D producer.next();
>
Which of course is parseable syntax. And while it may be unfamiliar, it=20
> isn't fundamentally alien.
>

Not alien, but for the wrong reasons

enum Hi{v} var =3D =E2=80=A6;
class Something{T t;} var =3D ...;

considering we already can omit class (as in class S v;) one will think of=
=20
Hi{v} as a shorthand declaration!
Things are arguably even worse with anonymous structs/enums.


Not only that, but if we add decorations to the mix things start to get ugl=
y

StandardLayoutType{T}&& next =3D . . .;
StandardLayoutType{T}* next =3D . . .;

I looks like we are decorating the Concept! The decoration is barely=20
related to the type=20


Compare that to the natural

StandardLayoutType T* next =3D . . .;

Also, lets read this right to left
Variable next, what is next, a pointer, to what, to type T, what is T,=20
a StandardLayoutType=20

Lets read in-place
Variable next, what is next, a pointer, to what, instantiate StandardLayout=
Type=20
and declare a type named T constrained by it, the pointer is to T

There is no denying which one is more natural!
And this is not a surprise - we just tweak current rules, no new=20
constructs. =20

class T* next =3D . . .;

Variable next, what is next, a pointer, to what, to type T, what is T, a=20
type



> Oh sure, you could do this:
>
> StandardLayoutType T auto next =3D producer.next();
>
> But really, who wants to do that? P1141 made `auto` not be required for a=
=20
> good reason.
>
>
>> >> What problem does P1141R0 solve?=20
>> > Wait for it...=20
>> >=20
>> > auto item =3D producer.next();=20
>> > static_assert(StandardLayoutType<decltype(item)>);=20
>> >=20
>> > StandardLayoutType auto item =3D producer.next();=20
>>
>> And I did not comment on that part, right?  Of course=20
>> there can be a consistency argument to defend the=20
>> constraints on parameters, but P0915R0 did not do=20
>> that since this argument would be too weak.
>>
>
> Um, why is it weak? Consistency in a language is not something that shoul=
d=20
> be so idly tossed aside.
>
> On the one hand, we have a proposal that is consistent with itself and=20
> consistent with other aspects of C++ (lambda `auto` syntax). And on the=
=20
> other, we have a pair of proposals (your idea and P0915) that both dabble=
=20
> in the same idea, but are not consistent with each other nor with existin=
g=20
> aspects of C++.=20
>
> Why adopt the latter when we can adopt the former? Especially since the=
=20
> former doesn't resolve the non-type template parameter conceptualization=
=20
> issue. That is, `<Concept auto val>` making `val` a value parameter, whos=
e=20
> type is constrained by `Concept`.
>
> And I say, take P1141 and add Herb's syntax to it (in deduction contexts,=
=20
> and only *optionally*). That is, allow me to write: `[](Iterator{I} auto=
=20
> &i, different_type_t<I> n);`. It's the best of both worlds.
>
> By "in deduction contexts", what I mean is anytime you could do `Concept=
=20
> auto ...`, you can also do `Concept{T} auto ...` (in a template parameter=
=20
> list, it does not create a template parameter for this `T`. It just gives=
=20
> it a name). The fact that I could take a specific part of the syntax and=
=20
> add an extension that applies to all uses of that syntax shows just how=
=20
> regular P1141 is compared to your pair of proposals.
>

--=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/470ba5b5-e77a-4b4e-b0ca-9ae30848b251%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Sunday, July 8, 2018 at 9:23:07 AM UTC+3, Nicol=
 Bolas 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">=
On Sunday, July 8, 2018 at 1:14:00 AM UTC-4, Zhihao Yuan wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">&gt; From: Hubert Tong &lt;<a rel=3D"nofollow">=
hubert.rein...@gmail.com</a>&gt;=20
<br>&gt; Sent: Saturday, July 7, 2018 11:27 PM
<br>&gt;=20
<br>&gt; Loss of visual anchors can lead to less readability. What&#39;s no=
ise to some are important eyecatchers to others.
<br>&gt; Unscoped enumerations and anonymous unions come to mind with regar=
ds to the Mergeable{I, S, O} syntax.
<br>
<br>I hope that &quot;Mergeable I S O&quot; is doing better since this
<br>structure is less often seen in the language.<br></blockquote><div><br>=
</div><div>It&#39;s not seen &quot;less often&quot;; it is seen precisely <=
i>never</i>. It is completely unlikely any syntax in C++. A general sequenc=
e of N tokens, with no separator token between them, is something that appe=
ars nowhere in the entire C++ standard.</div><div><br></div><div>Oh, and pl=
ease note that I said &quot;general sequence of&quot;. Yes, I know C++ does=
 have places where identifiers follow one another. But when this happens, t=
he grammar restricts how many are around; this is not defined by some langu=
age construct. `Identifier Identifier` can declare a variable if `Identifie=
r` is a typename, but `Identifier Identifier Identifier` is always syntacti=
c nonsense. So let&#39;s not get bogged down in pedantry here.<br></div><di=
v><br></div><div>Whenever C++ creates a new list of stuff, it <i>always</i>=
 used C-style: there is some kind of token pair bracketing the list (`()` a=
nd `{}` in C, `&lt;&gt;` in C++), and each list item is separated from othe=
r list items by a comma token. That&#39;s how C and C++ work when a list ca=
n be arbitrarily long.<br></div><div><br></div><div>A distinction should be=
 made between syntax which is merely unfamiliar and syntax which is <i>alie=
n</i>. What you&#39;re talking about is very much the latter.<br></div><div=
><br></div><div>You may not understand what `Mergeable{I, S, O}` is doing, =
but at least you know that the given identifiers are associated with Mergea=
ble in some way (since they&#39;re in a pair of braces directly after `Merg=
eable`), and that the tokens that follow the {} are not involved in the sam=
e process as the ones inside the `{}`.</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">
&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0StandardLayoutType T;
<br>&gt;&gt; =C2=A0 =C2=A0T item =3D producer.next();
<br>&gt;=20
<br>&gt; Probably because it is unclear where T is bound to a concrete type=
 in this syntax.
<br>&gt; Is the first binding privileged? Or is this a way of saying that a=
ll deductions of T must agree on the deduced type?
<br>Or perhaps T has independent binding on each use?
<br>
<br>All deductions of T must agree on the same type, just
<br>like what
<br>
<br>=C2=A0 =C2=A0 template&lt;StandardLayoutType T&gt;
<br>=C2=A0 =C2=A0 void(T a, T b)
<br>
<br>does.<br></blockquote><div><br></div><div>When you write `template&lt;S=
tandardLayoutType T&gt;`, that `T` is a typename. You can use it wherever y=
ou could use a typename. You can use it in a function parameter, return typ=
e, or just internally in the function. Or never at all.</div><div><br></div=
><div>That is, this is perfectly legal:</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:#008">template</sp=
an><span style=3D"color:#660">&lt;</span><span style=3D"color:#606">Standar=
dLayoutType</span><span style=3D"color:#000"> T</span><span style=3D"color:=
#660">&gt;</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#008">void</span><span style=3D"color:#000"> func</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#008">int</span><span style=3D"color:=
#000"> i </span><span style=3D"color:#660">=3D</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">sizeof</span><span style=3D"color:#=
660">(</span><span style=3D"color:#000">T</span><span style=3D"color:#660">=
))</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{...=
}</span></div></code></div><div></div><div><br></div><div>But what you&#39;=
re talking about is not like a template parameter declaration at all. The n=
ame you&#39;re introducing here cannot be used for anything until it gets u=
sed in a deduction context. Only then does it become a typename.<br></div><=
div><br></div><div>So the analogy you&#39;re trying to create between templ=
ate parameters and this syntax simply doesn&#39;t work, because proper temp=
late parameters don&#39;t have to be deduced at all.</div><div><br></div><d=
iv>Furthermore, consider your syntax. `T` is utterly useless until it is us=
ed in a deduction context, which blesses it with a type. As such, you shoul=
d combine the declaration of `T` with the deduction context in which it is =
used. The two should go hand-in-hand, so logically you should do the both a=
t the same time.<br></div><br><div>But you know why you didn&#39;t suggest =
that. It&#39;s because your alien syntax doesn&#39;t abide by C++&#39;s con=
ventions on these things, and therefore could never be used in a variable d=
eclaration:</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 style=3D"color:#606">StandardLayoutType</span><span styl=
e=3D"color:#000"> T </span><span style=3D"color:#008">next</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> producer</span><span style=3D"color:#660">.</span><span st=
yle=3D"color:#008">next</span><span style=3D"color:#660">();</span></div></=
code></div></div><div><br></div><div>That&#39;s just begging for confusion.=
 Is `next` of type `T`, or does `StandardLayoutType` have two template argu=
ments?<br></div></div></blockquote><div><br></div><div><br></div><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-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-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&a=
mp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: nor=
mal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-l=
eft: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0=
px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: le=
ft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-=
text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">Well, I su=
ggested it above.</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;"><br style=3D"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); line-height: normal; 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;"></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;">It is not confusing, considering we introduc=
e stuff left to right=C2=A0</div><div style=3D"background-color: transparen=
t; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-=
bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; bo=
rder-image-slice: 100%; border-image-source: none; border-image-width: 1; b=
order-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; bor=
der-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; letter-spacing=
: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-t=
op: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right:=
 0px; padding-top: 0px; text-align: left; text-decoration: none; text-inden=
t: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: =
normal; word-spacing: 0px;"><font face=3D"courier new,monospace" style=3D"b=
order-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bott=
om-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border=
-image-slice: 100%; border-image-source: none; border-image-width: 1; borde=
r-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-rig=
ht: 0px; padding-top: 0px;">Class var;=C2=A0</font></div><div style=3D"back=
ground-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bot=
tom-style: none; border-bottom-width: 0px; border-image-outset: 0; border-i=
mage-repeat: stretch; border-image-slice: 100%; border-image-source: none; =
border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-styl=
e: 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); 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-wei=
ght: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; mar=
gin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-l=
eft: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-deco=
ration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-w=
idth: 0px; white-space: normal; word-spacing: 0px;"><font face=3D"courier n=
ew,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; 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; margin-bottom: 0px; margin=
-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; paddin=
g-left: 0px; padding-right: 0px; padding-top: 0px;"><font face=3D"arial,san=
s-serif" 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;">or even=C2=A0</font></font><=
/div><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;">=
<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-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; mar=
gin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padd=
ing-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">=
class Class var;</font></div><div style=3D"background-color: transparent; b=
order-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bott=
om-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border=
-image-slice: 100%; border-image-source: none; border-image-width: 1; borde=
r-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;Ari=
al&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; fon=
t-style: normal; font-variant: normal; font-weight: 400; letter-spacing: no=
rmal; 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: 0=
px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: norm=
al; word-spacing: 0px;"><font face=3D"courier new,monospace" style=3D"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; margin-bottom: 0px; margin-left: 0px; margin-right: 0p=
x; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: =
0px; padding-top: 0px;"><br 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-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); line-height: normal; 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;"></font></div><div style=3D"background-c=
olor: transparent; 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; color: rgb(34, 34, 34); font-f=
amily: &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-righ=
t: 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: 0p=
x; white-space: normal; word-spacing: 0px;">Once we learn <font face=3D"cou=
rier new,monospace" style=3D"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; margin-bottom: 0px; =
margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; =
padding-left: 0px; padding-right: 0px; padding-top: 0px;">Concept Type</fon=
t> is &quot;instantiation&quot; of a new type based on a concept we &quot;o=
nly&quot; have to deal with two declarations.=C2=A0<br 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; color: rgb(34, 34, 34); line-height: 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;"></div><div s=
tyle=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-so=
urce: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); bord=
er-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&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;"><br 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; color: rgb(34, 34, 34); line-height: 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=
;"></div><div style=3D"background-color: transparent; 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; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;qu=
ot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; fon=
t-variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom:=
 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; pad=
ding-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: 0p=
x;">HOWEVER this is not new!</div><div style=3D"background-color: transpare=
nt; 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; color: rgb(34, 34, 34); font-family: &amp;quo=
t;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px=
; font-style: normal; font-variant: normal; font-weight: 400; letter-spacin=
g: 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-inde=
nt: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space:=
 normal; word-spacing: 0px;"><br style=3D"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); line-height: 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;"></div><div style=3D"background-col=
or: transparent; 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; color: rgb(34, 34, 34); font-fam=
ily: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; fo=
nt-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: no=
ne; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px;=
 white-space: normal; word-spacing: 0px;"><font face=3D"courier new,monospa=
ce" style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: non=
e; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: s=
tretch; border-image-slice: 100%; border-image-source: none; border-image-w=
idth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; borde=
r-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style:=
 none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-t=
op-style: none; border-top-width: 0px; 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;">func(class Class&amp; var)</font>=
</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;"=
><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, 3=
4); 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-to=
p-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; ma=
rgin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; pad=
ding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"=
><br style=3D"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); line-height=
: normal; 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;"></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;"><i 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; color: rgb(34, 3=
4, 34); line-height: normal; margin-bottom: 0px; margin-left: 0px; margin-r=
ight: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding=
-right: 0px; padding-top: 0px;"><font face=3D"arial,sans-serif" 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;">This is double declaration</font><font face=3D"c=
ourier new,monospace" style=3D"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; margin-bottom: 0px=
; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px=
; padding-left: 0px; padding-right: 0px; padding-top: 0px;"> </font></i><fo=
nt face=3D"arial,sans-serif" 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;">- we int=
roduce both a new type and a variable!</font></div><div 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); 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: 4=
00; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-ri=
ght: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0=
px; padding-right: 0px; padding-top: 0px; text-align: left; text-decoration=
: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: =
0px; white-space: normal; word-spacing: 0px;"><font face=3D"arial,sans-seri=
f" style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none=
; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: st=
retch; border-image-slice: 100%; border-image-source: none; border-image-wi=
dth: 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-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;"><br 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; color: rgb(34, 34, 34); line-height: normal; 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;"></font></div><div styl=
e=3D"background-color: transparent; border-bottom-color: rgb(34, 34, 34); b=
order-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0;=
 border-image-repeat: stretch; border-image-slice: 100%; border-image-sourc=
e: 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, 3=
4); border-right-style: none; border-right-width: 0px; border-top-color: rg=
b(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;q=
uot;,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-text=
-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><font face=3D"=
arial,sans-serif" style=3D"border-bottom-color: rgb(34, 34, 34); border-bot=
tom-style: none; border-bottom-width: 0px; border-image-outset: 0; border-i=
mage-repeat: stretch; border-image-slice: 100%; border-image-source: none; =
border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-styl=
e: 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); 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;"><b style=3D"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); line-height: normal; 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;">We only =
tweak the rule</b></font></div><div style=3D"background-color: transparent;=
 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; color: rgb(34, 34, 34); 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;"><font face=3D"arial,sans-serif" 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;"><b 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; color: rgb(34, 3=
4, 34); line-height: normal; margin-bottom: 0px; margin-left: 0px; margin-r=
ight: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding=
-right: 0px; padding-top: 0px;"></b><br 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; =
color: rgb(34, 34, 34); line-height: normal; 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;"></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; 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; 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; paddi=
ng-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-=
decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stro=
ke-width: 0px; white-space: normal; word-spacing: 0px;"><font face=3D"arial=
,sans-serif" 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;">If concept is used inste=
ad -=C2=A0</font>the name is still introduced<font face=3D"arial,sans-serif=
" style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: none;=
 border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: str=
etch; border-image-slice: 100%; border-image-source: none; border-image-wid=
th: 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: n=
one; 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 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; color: rgb(34, 34, 34); line-height: 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;"> exactly as before</i>, =
</font>however <font face=3D"arial,sans-serif" 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;">the type is not a concrete type, but will be late-bound on instan=
tiation!=C2=A0</font></div><div style=3D"background-color: transparent; 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; font-=
style: normal; font-variant: normal; font-weight: 400; letter-spacing: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; 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;"><font face=3D"arial,sans-serif" style=3D"border-botto=
m-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0=
px; border-image-outset: 0; border-image-repeat: stretch; border-image-slic=
e: 100%; border-image-source: none; border-image-width: 1; border-left-colo=
r: 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-to=
p-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; marg=
in-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; pa=
dding-top: 0px;"><br 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; color: rgb(34, 34, =
34); line-height: normal; margin-bottom: 0px; margin-left: 0px; margin-righ=
t: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-ri=
ght: 0px; padding-top: 0px;"></font></div><div style=3D"background-color: t=
ransparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none=
; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: st=
retch; border-image-slice: 100%; border-image-source: none; border-image-wi=
dth: 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-to=
p-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-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; lette=
r-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
 margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; paddi=
ng-right: 0px; padding-top: 0px; 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;"><font face=3D"arial,sans-serif" 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;">It is that simple! No new syntax, just nat=
ural evolution of type name introduction - concrete type vs late-bound one.=
</font></div><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-family: &amp;quot;Arial&amp;quot;,&am=
p;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal;=
 font-variant: normal; font-weight: 400; letter-spacing: normal; margin-bot=
tom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2;=
 padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0=
px; 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"courier new,monospace" 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;"></font><font face=3D"arial,sans-serif" 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;"></font><font face=3D"arial,sans-serif" style=3D"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; 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;"></font><font face=3D"arial,sans-serif" style=3D"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; 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;"></font><i 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; color: rgb(34, 3=
4, 34); line-height: normal; margin-bottom: 0px; margin-left: 0px; margin-r=
ight: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding=
-right: 0px; padding-top: 0px;"></i><i 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; c=
olor: rgb(34, 34, 34); line-height: normal; 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;"></i><br 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; color: rgb(34, 34, 34); line-height: 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;"></div><div s=
tyle=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-so=
urce: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); bord=
er-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&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;"><br 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; color: rgb(34, 34, 34); line-height: 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=
;"></div><div style=3D"background-color: transparent; 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; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;qu=
ot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: normal; fon=
t-variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom:=
 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; pad=
ding-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: 0p=
x;"><div 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;">It is another topic if let i=
nstantiation of a type to be undefined until the first use.=C2=A0</div><b s=
tyle=3D"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); line-height: norm=
al; 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;"></b><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; 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); li=
ne-height: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
 margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0p=
x; 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-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; color: rgb(=
34, 34, 34); line-height: normal; margin-bottom: 0px; margin-left: 0px; mar=
gin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; pa=
dding-right: 0px; padding-top: 0px;"></u><sub style=3D"border-bottom-color:=
 rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bord=
er-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%;=
 border-image-source: none; border-image-width: 1; border-left-color: rgb(3=
4, 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; b=
order-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-to=
p: 0px;"></sub><sup style=3D"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; margin-bottom: 0px; =
margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; =
padding-left: 0px; padding-right: 0px; padding-top: 0px;"></sup><strike sty=
le=3D"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; margin-bottom: 0px; margin-left: 0px; margi=
n-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padd=
ing-right: 0px; padding-top: 0px;"></strike><font face=3D"courier new,monos=
pace" style=3D"border-bottom-color: rgb(34, 34, 34); border-bottom-style: n=
one; 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; bor=
der-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-styl=
e: 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: 0=
px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: =
0px; padding-right: 0px; padding-top: 0px;">Concept Type;</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-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-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&a=
mp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: nor=
mal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-l=
eft: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0=
px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: le=
ft; 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); b=
order-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0;=
 border-image-repeat: stretch; border-image-slice: 100%; border-image-sourc=
e: 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, 3=
4); 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; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom=
: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">Type var =
=3D . . .=C2=A0</font></div><b></b><i></i><u></u><sub></sub><sup></sup><str=
ike></strike><br></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>Clarifying which =
identifiers go with the concept and which are constrained by it would requi=
re more C++-like lists. Like:</div><div><br></div><div><div style=3D"backgr=
ound-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:soli=
d;border-width:1px"><div><code><span style=3D"color:#606">StandardLayoutTyp=
e</span><span style=3D"color:#660">{</span><span style=3D"color:#000">T</sp=
an><span style=3D"color:#660">}</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#008">next</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">=3D</span><span style=3D"color:#000"> producer</span=
><span style=3D"color:#660">.</span><span style=3D"color:#008">next</span><=
span style=3D"color:#660">();</span></code><br></div></div></div></div></bl=
ockquote><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=
>Which of course is parseable syntax. And while it may be unfamiliar, it is=
n&#39;t fundamentally alien.</div></div></blockquote><div><br></div><div>No=
t alien, but for the wrong reasons</div><div><br></div><div><font face=3D"c=
ourier new,monospace">enum Hi{v} var =3D =E2=80=A6;</font><br></div><div><f=
ont face=3D"courier new,monospace">class Something{T t;} var =3D ...;</font=
></div><div><br></div><div><font face=3D"arial,sans-serif">considering we a=
lready can omit class (as in class S v;) one will </font>think of<font face=
=3D"courier new,monospace"> Hi{v}</font> as a shorthand declaration!<font f=
ace=3D"arial,sans-serif"><span style=3D"display: inline !important; float: =
none; background-color: transparent; color: rgb(34, 34, 34); font-family: c=
ourier new,monospace; font-size: 13px; font-style: normal; font-variant: no=
rmal; font-weight: 400; letter-spacing: normal; orphans: 2; 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;"></span></fo=
nt></div><div><font face=3D"arial,sans-serif">Things are arguably even wors=
e with anonymous structs/enums.</font></div><div><font face=3D"arial,sans-s=
erif"><br></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">Not only that, but if we add decorations to the mix things start to=
 get ugly</font></div><div><font face=3D"arial,sans-serif"><br></font></div=
><div><font face=3D"courier new,monospace">StandardLayoutType{T}&amp;&amp; =
next =3D .  . .;</font></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-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;">St=
andardLayoutType{T}* next =3D .  . .;</span><b></b><i></i><u></u><sub></sub=
><sup></sup><strike></strike></div><div><br></div><div>I looks like we are =
decorating the Concept! The decoration is barely related to the type=C2=A0<=
/div><div><br></div><div><br></div><div>Compare that to the natural</div><d=
iv><br></div><div><span style=3D"display: inline !important; float: none; b=
ackground-color: transparent; color: rgb(34, 34, 34); font-family: courier =
new,monospace; 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;">StandardLayoutType=
 T* next =3D .  . .;</span><b></b><i></i><u></u><sub></sub><sup></sup><stri=
ke></strike><br></div><div><font face=3D"courier new,monospace"></font><fon=
t face=3D"arial,sans-serif"></font><b></b><i></i><u></u><sub></sub><sup></s=
up><strike></strike><font face=3D"courier new,monospace"></font><font face=
=3D"courier new,monospace"></font><b></b><i></i><u></u><sub></sub><sup></su=
p><strike></strike><br></div><div>Also, lets read this right to left</div><=
div>Variable next, what is next, a pointer, to what, to type T, what is T, =
a=C2=A0StandardLayoutType=C2=A0<br></div><div><br></div><div>Lets read in-p=
lace<br></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;">Variable next, what is next, a pointer, to what, instantiate </=
span><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;">St=
andardLayoutType and declare a type named T constrained by it, the pointer =
is to T</span><br></div><div><b></b><i></i><u></u><sub></sub><sup></sup><st=
rike></strike><br></div><div>There is no denying which one is more natural!=
</div><div>And this is not a surprise - we just tweak current rules, no new=
 constructs. =C2=A0</div><div><br></div><div><div style=3D"background-color=
: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: n=
one; 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; bor=
der-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-styl=
e: 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-famil=
y: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font=
-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; le=
tter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0=
px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; pa=
dding-right: 0px; padding-top: 0px; text-align: left; text-decoration: none=
; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; w=
hite-space: normal; word-spacing: 0px;"><span style=3D"background-color: tr=
ansparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none;=
 border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: str=
etch; border-image-slice: 100%; border-image-source: none; border-image-wid=
th: 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: n=
one; 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: inlin=
e; float: none; font-family: courier new,monospace; 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;">class T* next =3D .  . .;</span><b style=3D"background=
-attachment: scroll; background-clip: border-box; background-color: transpa=
rent; background-image: none; background-origin: padding-box; background-po=
sition-x: 0%; background-position-y: 0%; background-repeat: repeat; backgro=
und-size: auto; 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-imag=
e-width: 1; 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-sty=
le: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); borde=
r-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-fami=
ly: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; fon=
t-size: 13px; height: auto; margin-bottom: 0px; margin-left: 0px; margin-ri=
ght: 0px; margin-top: 0px; min-width: 0px; overflow: visible; overflow-x: v=
isible; overflow-y: visible; padding-bottom: 0px; padding-left: 0px; paddin=
g-right: 0px; padding-top: 0px;"></b><i style=3D"background-attachment: scr=
oll; background-clip: border-box; background-color: transparent; background=
-image: none; background-origin: padding-box; background-position-x: 0%; ba=
ckground-position-y: 0%; background-repeat: repeat; background-size: auto; =
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; he=
ight: 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-left: 0px; padding-right: 0px; pa=
dding-top: 0px;"></i><u style=3D"background-attachment: scroll; background-=
clip: border-box; background-color: transparent; background-image: none; ba=
ckground-origin: padding-box; background-position-x: 0%; background-positio=
n-y: 0%; background-repeat: repeat; background-size: auto; 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; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&a=
mp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; height: auto; marg=
in-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-w=
idth: 0px; overflow: visible; overflow-x: visible; overflow-y: visible; pad=
ding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"=
></u><sub 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;"></sub><sup style=3D"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; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
 margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0p=
x; padding-top: 0px;"></sup><strike 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;"><=
/strike><br style=3D"background-attachment: scroll; background-clip: border=
-box; background-color: transparent; background-image: none; background-ori=
gin: padding-box; background-position-x: 0%; background-position-y: 0%; bac=
kground-repeat: repeat; background-size: auto; 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, 3=
4); 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-to=
p-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; co=
lor: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helv=
etica&amp;quot;,sans-serif; font-size: 13px; height: auto; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-width: 0px; o=
verflow: visible; overflow-x: visible; overflow-y: visible; padding-bottom:=
 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"></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-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-family: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&a=
mp;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: nor=
mal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-l=
eft: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0=
px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: le=
ft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-=
text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><br></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;">Varia=
ble next, what is next, a pointer, to what, to type T, what is T, a type</d=
iv><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></div><d=
iv><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><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>Oh sure, y=
ou could do this:</div><div><br></div><div><div style=3D"background-color:r=
gb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wid=
th:1px"><code><div><span style=3D"color:#606">StandardLayoutType</span><spa=
n style=3D"color:#000"> T </span><span style=3D"color:#008">auto</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">next</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> producer</span><span style=3D"color:#660">.</span><span =
style=3D"color:#008">next</span><span style=3D"color:#660">();</span></div>=
</code></div><br></div><div>But really, who wants to do that? P1141 made `a=
uto` not be required for a good reason.<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">
<br>&gt;&gt; What problem does P1141R0 solve?
<br>&gt; Wait for it...
<br>&gt;=20
<br>&gt; auto item =3D producer.next();
<br>&gt; static_assert(<wbr>StandardLayoutType&lt;decltype(<wbr>item)&gt;);
<br>&gt;=20
<br>&gt; StandardLayoutType auto item =3D producer.next();
<br>
<br>And I did not comment on that part, right? =C2=A0Of course
<br>there can be a consistency argument to defend the
<br>constraints on parameters, but P0915R0 did not do
<br>that since this argument would be too weak.<br></blockquote><div><br></=
div><div>Um, why is it weak? Consistency in a language is not something tha=
t should be so idly tossed aside.</div><div><br></div><div>On the one hand,=
 we have a proposal that is consistent with itself and consistent with othe=
r aspects of C++ (lambda `auto` syntax). And on the other, we have a pair o=
f proposals (your idea and P0915) that both dabble in the same idea, but ar=
e not consistent with each other nor with existing aspects of C++. <br></di=
v><div><br></div><div>Why adopt the latter when we can adopt the former? Es=
pecially since the former doesn&#39;t resolve the non-type template paramet=
er conceptualization issue. That is, `&lt;Concept auto val&gt;` making `val=
` a value parameter, whose type is constrained by `Concept`.<br></div><div>=
<br></div><div>And I say, take P1141 and add Herb&#39;s syntax to it (in de=
duction contexts, and only <i>optionally</i>). That is, allow me to write: =
`[](Iterator{I} auto &amp;i, different_type_t&lt;I&gt; n);`. It&#39;s the b=
est of both worlds.</div><div><br></div><div>By &quot;in deduction contexts=
&quot;, what I mean is anytime you could do `Concept auto ...`, you can als=
o do `Concept{T} auto ...` (in a template parameter list, it does not creat=
e a template parameter for this `T`. It just gives it a name). The fact tha=
t I could take a specific part of the syntax and add an extension that appl=
ies to all uses of that syntax shows just how regular P1141 is compared to =
your pair of proposals.</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/470ba5b5-e77a-4b4e-b0ca-9ae30848b251%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/470ba5b5-e77a-4b4e-b0ca-9ae30848b251=
%40isocpp.org</a>.<br />

------=_Part_40459_619899894.1531048930380--

------=_Part_40458_658168638.1531048930378--

.

------=_Part_87940_1921861191.1531049316395
Content-Type: multipart/alternative;
 boundary="----=_Part_87941_364020337.1531049316395"

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



On Sunday, July 8, 2018 at 9:23:07 AM UTC+3, Nicol Bolas wrote:
>
> On Sunday, July 8, 2018 at 1:14:00 AM UTC-4, Zhihao Yuan wrote:
>>
>> > From: Hubert Tong <hubert.rein...@gmail.com>=20
>> > Sent: Saturday, July 7, 2018 11:27 PM=20
>> >=20
>> > Loss of visual anchors can lead to less readability. What's noise to=
=20
>> some are important eyecatchers to others.=20
>> > Unscoped enumerations and anonymous unions come to mind with regards t=
o=20
>> the Mergeable{I, S, O} syntax.=20
>>
>> I hope that "Mergeable I S O" is doing better since this=20
>> structure is less often seen in the language.
>>
>
> It's not seen "less often"; it is seen precisely *never*. It is=20
> completely unlikely any syntax in C++. A general sequence of N tokens, wi=
th=20
> no separator token between them, is something that appears nowhere in the=
=20
> entire C++ standard.
>
> Oh, and please note that I said "general sequence of". Yes, I know C++=20
> does have places where identifiers follow one another. But when this=20
> happens, the grammar restricts how many are around; this is not defined b=
y=20
> some language construct. `Identifier Identifier` can declare a variable i=
f=20
> `Identifier` is a typename, but `Identifier Identifier Identifier` is=20
> always syntactic nonsense. So let's not get bogged down in pedantry here.
>
> Whenever C++ creates a new list of stuff, it *always* used C-style: there=
=20
> is some kind of token pair bracketing the list (`()` and `{}` in C, `<>` =
in=20
> C++), and each list item is separated from other list items by a comma=20
> token. That's how C and C++ work when a list can be arbitrarily long.
>
> A distinction should be made between syntax which is merely unfamiliar an=
d=20
> syntax which is *alien*. What you're talking about is very much the=20
> latter.
>
> You may not understand what `Mergeable{I, S, O}` is doing, but at least=
=20
> you know that the given identifiers are associated with Mergeable in some=
=20
> way (since they're in a pair of braces directly after `Mergeable`), and=
=20
> that the tokens that follow the {} are not involved in the same process a=
s=20
> the ones inside the `{}`.
>
> >>=20
>> >>    StandardLayoutType T;=20
>> >>    T item =3D producer.next();=20
>> >=20
>> > Probably because it is unclear where T is bound to a concrete type in=
=20
>> this syntax.=20
>> > Is the first binding privileged? Or is this a way of saying that all=
=20
>> deductions of T must agree on the deduced type?=20
>> Or perhaps T has independent binding on each use?=20
>>
>> All deductions of T must agree on the same type, just=20
>> like what=20
>>
>>     template<StandardLayoutType T>=20
>>     void(T a, T b)=20
>>
>> does.
>>
>
> When you write `template<StandardLayoutType T>`, that `T` is a typename.=
=20
> You can use it wherever you could use a typename. You can use it in a=20
> function parameter, return type, or just internally in the function. Or=
=20
> never at all.
>
> That is, this is perfectly legal:
>
> template<StandardLayoutType T>
> void func(int i =3D sizeof(T)) {...}
>
> But what you're talking about is not like a template parameter declaratio=
n=20
> at all. The name you're introducing here cannot be used for anything unti=
l=20
> it gets used in a deduction context. Only then does it become a typename.
>
> So the analogy you're trying to create between template parameters and=20
> this syntax simply doesn't work, because proper template parameters don't=
=20
> have to be deduced at all.
>
> Furthermore, consider your syntax. `T` is utterly useless until it is use=
d=20
> in a deduction context, which blesses it with a type. As such, you should=
=20
> combine the declaration of `T` with the deduction context in which it is=
=20
> used. The two should go hand-in-hand, so logically you should do the both=
=20
> at the same time.
>
> But you know why you didn't suggest that. It's because your alien syntax=
=20
> doesn't abide by C++'s conventions on these things, and therefore could=
=20
> never be used in a variable declaration:
>
> StandardLayoutType T next =3D producer.next();
>
> That's just begging for confusion. Is `next` of type `T`, or does=20
> `StandardLayoutType` have two template arguments?
>


Well, I suggested it above.

It is not confusing, considering we introduce stuff left to right=20
Class var;=20
or even=20
class Class var;

Once we learn Concept Type is "instantiation" of a new type based on a=20
concept we "only" have to deal with two declarations.=20

HOWEVER this is not new!

func(class Class& var)

This is double declaration - we introduce both a new type and a variable!

We only tweak the rule

If concept is used instead - the name is still introduced *exactly as=20
before*, however the type is not a concrete type, but will be late-bound on=
=20
instantiation!=20

It is that simple! No new syntax, just natural evolution of type name=20
introduction - concrete type vs late-bound one.

It is another topic if let instantiation of a type to be undefined until=20
the first use.=20
Concept Type;
Type var =3D . . .=20

=20

>
> Clarifying which identifiers go with the concept and which are constraine=
d=20
> by it would require more C++-like lists. Like:
>
> StandardLayoutType{T} next =3D producer.next();
>
> Which of course is parseable syntax. And while it may be unfamiliar, it=
=20
> isn't fundamentally alien.
>


Not alien, but for the wrong reasons

enum Hi{v} var =3D =E2=80=A6;
class Something{T t;} var =3D =E2=80=A6;

considering we already can omit class (as in class S v;) one will think of=
=20
Hi{v} as a shorthand declaration
Things are arguably even worse with anonymous structs/enums=20

Not only that but if we add decorations to the mix things start to get ugly

StandardLayoutType{T}&& next =3D . . .;
StandardLayoutType{T}* next =3D . . .;

I looks like we are decorating the Concept. The decoration is barely=20
related to the type=20

Compare that to the natural

StandardLayoutType T* next =3D . . .;

Also, lets read this right to left
Variable next, what is next, a pointer, to what, to type T, what is T, a=20
StandardLayoutType=20

Lets read in-place
Variable next, what is next, a pointer, to what, instantiate=20
StandardLayoutType and declare a type named T constrained by it, the=20
pointer is to T

There is no denying which one is more natural!
And this is not a surprise - we just tweak current rules, no new=20
constructs. =20

class T* next =3D . . .;
Variable next, what is next, a pointer, to what, to type T, what is T, a=20
type
=20

>
> Oh sure, you could do this:
>
> StandardLayoutType T auto next =3D producer.next();
>
> But really, who wants to do that? P1141 made `auto` not be required for a=
=20
> good reason.
>
>
>> >> What problem does P1141R0 solve?=20
>> > Wait for it...=20
>> >=20
>> > auto item =3D producer.next();=20
>> > static_assert(StandardLayoutType<decltype(item)>);=20
>> >=20
>> > StandardLayoutType auto item =3D producer.next();=20
>>
>> And I did not comment on that part, right?  Of course=20
>> there can be a consistency argument to defend the=20
>> constraints on parameters, but P0915R0 did not do=20
>> that since this argument would be too weak.
>>
>
> Um, why is it weak? Consistency in a language is not something that shoul=
d=20
> be so idly tossed aside.
>
> On the one hand, we have a proposal that is consistent with itself and=20
> consistent with other aspects of C++ (lambda `auto` syntax). And on the=
=20
> other, we have a pair of proposals (your idea and P0915) that both dabble=
=20
> in the same idea, but are not consistent with each other nor with existin=
g=20
> aspects of C++.=20
>
> Why adopt the latter when we can adopt the former? Especially since the=
=20
> former doesn't resolve the non-type template parameter conceptualization=
=20
> issue. That is, `<Concept auto val>` making `val` a value parameter, whos=
e=20
> type is constrained by `Concept`.
>
> And I say, take P1141 and add Herb's syntax to it (in deduction contexts,=
=20
> and only *optionally*). That is, allow me to write: `[](Iterator{I} auto=
=20
> &i, different_type_t<I> n);`. It's the best of both worlds.
>
> By "in deduction contexts", what I mean is anytime you could do `Concept=
=20
> auto ...`, you can also do `Concept{T} auto ...` (in a template parameter=
=20
> list, it does not create a template parameter for this `T`. It just gives=
=20
> it a name). The fact that I could take a specific part of the syntax and=
=20
> add an extension that applies to all uses of that syntax shows just how=
=20
> regular P1141 is compared to your pair of proposals.
>

--=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/6b657f87-26ba-46a4-a378-3d4fab46d4db%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Sunday, July 8, 2018 at 9:23:07 AM UTC+3, Nicol=
 Bolas 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">=
On Sunday, July 8, 2018 at 1:14:00 AM UTC-4, Zhihao Yuan wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">&gt; From: Hubert Tong &lt;<a rel=3D"nofollow">=
hubert.rein...@gmail.com</a>&gt;=20
<br>&gt; Sent: Saturday, July 7, 2018 11:27 PM
<br>&gt;=20
<br>&gt; Loss of visual anchors can lead to less readability. What&#39;s no=
ise to some are important eyecatchers to others.
<br>&gt; Unscoped enumerations and anonymous unions come to mind with regar=
ds to the Mergeable{I, S, O} syntax.
<br>
<br>I hope that &quot;Mergeable I S O&quot; is doing better since this
<br>structure is less often seen in the language.<br></blockquote><div><br>=
</div><div>It&#39;s not seen &quot;less often&quot;; it is seen precisely <=
i>never</i>. It is completely unlikely any syntax in C++. A general sequenc=
e of N tokens, with no separator token between them, is something that appe=
ars nowhere in the entire C++ standard.</div><div><br></div><div>Oh, and pl=
ease note that I said &quot;general sequence of&quot;. Yes, I know C++ does=
 have places where identifiers follow one another. But when this happens, t=
he grammar restricts how many are around; this is not defined by some langu=
age construct. `Identifier Identifier` can declare a variable if `Identifie=
r` is a typename, but `Identifier Identifier Identifier` is always syntacti=
c nonsense. So let&#39;s not get bogged down in pedantry here.<br></div><di=
v><br></div><div>Whenever C++ creates a new list of stuff, it <i>always</i>=
 used C-style: there is some kind of token pair bracketing the list (`()` a=
nd `{}` in C, `&lt;&gt;` in C++), and each list item is separated from othe=
r list items by a comma token. That&#39;s how C and C++ work when a list ca=
n be arbitrarily long.<br></div><div><br></div><div>A distinction should be=
 made between syntax which is merely unfamiliar and syntax which is <i>alie=
n</i>. What you&#39;re talking about is very much the latter.<br></div><div=
><br></div><div>You may not understand what `Mergeable{I, S, O}` is doing, =
but at least you know that the given identifiers are associated with Mergea=
ble in some way (since they&#39;re in a pair of braces directly after `Merg=
eable`), and that the tokens that follow the {} are not involved in the sam=
e process as the ones inside the `{}`.</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">
&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0StandardLayoutType T;
<br>&gt;&gt; =C2=A0 =C2=A0T item =3D producer.next();
<br>&gt;=20
<br>&gt; Probably because it is unclear where T is bound to a concrete type=
 in this syntax.
<br>&gt; Is the first binding privileged? Or is this a way of saying that a=
ll deductions of T must agree on the deduced type?
<br>Or perhaps T has independent binding on each use?
<br>
<br>All deductions of T must agree on the same type, just
<br>like what
<br>
<br>=C2=A0 =C2=A0 template&lt;StandardLayoutType T&gt;
<br>=C2=A0 =C2=A0 void(T a, T b)
<br>
<br>does.<br></blockquote><div><br></div><div>When you write `template&lt;S=
tandardLayoutType T&gt;`, that `T` is a typename. You can use it wherever y=
ou could use a typename. You can use it in a function parameter, return typ=
e, or just internally in the function. Or never at all.</div><div><br></div=
><div>That is, this is perfectly legal:</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:#008">template</sp=
an><span style=3D"color:#660">&lt;</span><span style=3D"color:#606">Standar=
dLayoutType</span><span style=3D"color:#000"> T</span><span style=3D"color:=
#660">&gt;</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#008">void</span><span style=3D"color:#000"> func</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#008">int</span><span style=3D"color:=
#000"> i </span><span style=3D"color:#660">=3D</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">sizeof</span><span style=3D"color:#=
660">(</span><span style=3D"color:#000">T</span><span style=3D"color:#660">=
))</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{...=
}</span></div></code></div><div></div><div><br></div><div>But what you&#39;=
re talking about is not like a template parameter declaration at all. The n=
ame you&#39;re introducing here cannot be used for anything until it gets u=
sed in a deduction context. Only then does it become a typename.<br></div><=
div><br></div><div>So the analogy you&#39;re trying to create between templ=
ate parameters and this syntax simply doesn&#39;t work, because proper temp=
late parameters don&#39;t have to be deduced at all.</div><div><br></div><d=
iv>Furthermore, consider your syntax. `T` is utterly useless until it is us=
ed in a deduction context, which blesses it with a type. As such, you shoul=
d combine the declaration of `T` with the deduction context in which it is =
used. The two should go hand-in-hand, so logically you should do the both a=
t the same time.<br></div><br><div>But you know why you didn&#39;t suggest =
that. It&#39;s because your alien syntax doesn&#39;t abide by C++&#39;s con=
ventions on these things, and therefore could never be used in a variable d=
eclaration:</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 style=3D"color:#606">StandardLayoutType</span><span styl=
e=3D"color:#000"> T </span><span style=3D"color:#008">next</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> producer</span><span style=3D"color:#660">.</span><span st=
yle=3D"color:#008">next</span><span style=3D"color:#660">();</span></div></=
code></div></div><div><br></div><div>That&#39;s just begging for confusion.=
 Is `next` of type `T`, or does `StandardLayoutType` have two template argu=
ments?<br></div></div></blockquote><div><br></div><div><br></div><div>Well,=
 I suggested it above.</div><div><br></div><div>It is not confusing, consid=
ering we introduce stuff left to right <br><font face=3D"courier new,monosp=
ace">Class var; </font><br>or even <br><font face=3D"courier new,monospace"=
>class Class var;</font></div><div><font face=3D"courier new,monospace"><br=
></font></div><div>Once we learn Concept Type is &quot;instantiation&quot; =
of a new type based on a concept we &quot;only&quot; have to deal with two =
declarations.=C2=A0</div><div><br></div><div>HOWEVER this is not new!</div>=
<div><br></div><div><font face=3D"courier new,monospace">func(class Class&a=
mp; var)</font></div><div><font face=3D"courier new,monospace"><br></font><=
/div><div>This is double declaration - we introduce both a new type and a v=
ariable!</div><div><br></div><div>We only tweak the rule</div><div><br></di=
v><div>If concept is used instead - the name is still introduced <i>exactly=
 as before</i>, however the type is not a concrete type, but will be late-b=
ound on instantiation!=C2=A0</div><div><br></div><div>It is that simple! No=
 new syntax, just natural evolution of type name introduction - concrete ty=
pe vs late-bound one.</div><div><br>It is another topic if let instantiatio=
n of a type to be undefined until the first use. <br><font face=3D"courier =
new,monospace">Concept Type;<br>Type var =3D . . . </font><br></div><div><f=
ont face=3D"courier new,monospace"></font><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div><br=
></div><div>Clarifying which identifiers go with the concept and which are =
constrained by it would require more C++-like lists. Like:</div><div><br></=
div><div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px"><code><div><span style=3D"=
color:#606">StandardLayoutType</span><span style=3D"color:#660">{</span><sp=
an style=3D"color:#000">T</span><span style=3D"color:#660">}</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">next</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> producer</span><span style=3D"color:#660">.</span><span st=
yle=3D"color:#008">next</span><span style=3D"color:#660">();</span></div></=
code></div><br>Which of course is parseable syntax. And while it may be unf=
amiliar, it isn&#39;t fundamentally alien.</div></div></blockquote><div><br=
></div><div><br>Not alien, but for the wrong reasons</div><div><br></div><d=
iv><font face=3D"courier new,monospace">enum Hi{v} var =3D =E2=80=A6;<br>cl=
ass Something{T t;} var =3D =E2=80=A6;</font></div><div><font face=3D"couri=
er new,monospace"><br></font></div><div>considering we already can omit cla=
ss (as in class S v;) one will think of <font face=3D"courier new,monospace=
">Hi{v}</font> as a shorthand declaration<br>Things are arguably even worse=
 with anonymous structs/enums </div><div><br>Not only that but if we add de=
corations to the mix things start to get ugly</div><div><br></div><div><fon=
t face=3D"courier new,monospace">StandardLayoutType{T}&amp;&amp; next =3D .=
 . .;<br>StandardLayoutType{T}* next =3D . . .;</font></div><div><font face=
=3D"courier new,monospace"><br></font></div><div>I looks like we are decora=
ting the Concept. The decoration is barely related to the type </div><div><=
br>Compare that to the natural</div><div><br></div><div><font face=3D"couri=
er new,monospace">StandardLayoutType T* next =3D . . .;</font></div><div><f=
ont face=3D"courier new,monospace"><br></font></div><div>Also, lets read th=
is right to left<br>Variable next, what is next, a pointer, to what, to typ=
e T, what is T, a StandardLayoutType </div><div><br>Lets read in-place<br>V=
ariable next, what is next, a pointer, to what, instantiate StandardLayoutT=
ype and declare a type named T constrained by it, the pointer is to T</div>=
<div><br></div><div>There is no denying which one is more natural!<br>And t=
his is not a surprise - we just tweak current rules, no new constructs. =C2=
=A0</div><div><br></div><div><font face=3D"courier new,monospace">class T* =
next =3D . . .;</font></div><div>Variable next, what is next, a pointer, to=
 what, to type T, what is T, a type<br></div><div>=C2=A0</div><blockquote c=
lass=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>Oh sur=
e, you could do this:</div><div><br></div><div><div style=3D"background-col=
or:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border=
-width:1px"><code><div><span style=3D"color:#606">StandardLayoutType</span>=
<span style=3D"color:#000"> T </span><span style=3D"color:#008">auto</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#008">next</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span=
 style=3D"color:#000"> producer</span><span style=3D"color:#660">.</span><s=
pan style=3D"color:#008">next</span><span style=3D"color:#660">();</span></=
div></code></div><br></div><div>But really, who wants to do that? P1141 mad=
e `auto` not be required for a good reason.<br></div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<br>&gt;&gt; What problem does P1141R0 solve?
<br>&gt; Wait for it...
<br>&gt;=20
<br>&gt; auto item =3D producer.next();
<br>&gt; static_assert(<wbr>StandardLayoutType&lt;decltype(<wbr>item)&gt;);
<br>&gt;=20
<br>&gt; StandardLayoutType auto item =3D producer.next();
<br>
<br>And I did not comment on that part, right? =C2=A0Of course
<br>there can be a consistency argument to defend the
<br>constraints on parameters, but P0915R0 did not do
<br>that since this argument would be too weak.<br></blockquote><div><br></=
div><div>Um, why is it weak? Consistency in a language is not something tha=
t should be so idly tossed aside.</div><div><br></div><div>On the one hand,=
 we have a proposal that is consistent with itself and consistent with othe=
r aspects of C++ (lambda `auto` syntax). And on the other, we have a pair o=
f proposals (your idea and P0915) that both dabble in the same idea, but ar=
e not consistent with each other nor with existing aspects of C++. <br></di=
v><div><br></div><div>Why adopt the latter when we can adopt the former? Es=
pecially since the former doesn&#39;t resolve the non-type template paramet=
er conceptualization issue. That is, `&lt;Concept auto val&gt;` making `val=
` a value parameter, whose type is constrained by `Concept`.<br></div><div>=
<br></div><div>And I say, take P1141 and add Herb&#39;s syntax to it (in de=
duction contexts, and only <i>optionally</i>). That is, allow me to write: =
`[](Iterator{I} auto &amp;i, different_type_t&lt;I&gt; n);`. It&#39;s the b=
est of both worlds.</div><div><br></div><div>By &quot;in deduction contexts=
&quot;, what I mean is anytime you could do `Concept auto ...`, you can als=
o do `Concept{T} auto ...` (in a template parameter list, it does not creat=
e a template parameter for this `T`. It just gives it a name). The fact tha=
t I could take a specific part of the syntax and add an extension that appl=
ies to all uses of that syntax shows just how regular P1141 is compared to =
your pair of proposals.</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/6b657f87-26ba-46a4-a378-3d4fab46d4db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6b657f87-26ba-46a4-a378-3d4fab46d4db=
%40isocpp.org</a>.<br />

------=_Part_87941_364020337.1531049316395--

------=_Part_87940_1921861191.1531049316395--

.

------=_Part_39533_1170181255.1531134689328
Content-Type: multipart/alternative;
 boundary="----=_Part_39534_890489627.1531134689328"

------=_Part_39534_890489627.1531134689328
Content-Type: text/plain; charset="UTF-8"


Let's start by saying that I like P1141. I believe that some of the
objections I saw in this thread are due to the attempt of using an approach
that worked for some of the previously proposed syntaxes. However, I
believe the syntax proposed in P1141 and, in particular, the consistent of
"auto", allows for a completely different approach, that not only addresses
most use-cases but also allows new programming techniques. Allow me to
explain my idea that I call "placeholder type alias". The idea is simple:
in every place I can write auto, I can write auto{Type} and have Type being
defined as an alias of whatever type has been deduced by auto. This means:

In templates:

    void f(auto{T} x) // equivalent to template <class T> void f(T x);

    void f(auto{T} x, T y) // equivalent to template <class T> void f(T x,
T y)

    void f(const auto{T}& x) // equivalent to template <class T> void
f(const T& x)

    void advance(auto{I}& i, difference_type_t<I> n);

    template <Constraint auto{T} N> void f(); // T is an alias for
decltype(N)

    template <auto{T} N> requires /* complex constraint involving T */ void
f();

In variable declarations:

   auto{T} x = f(); // T is alias for decltype(x)

In return value:

   auto{Result} f() -> /* complex type declarator */; // Result is an alias
for complex type declarator

in this case, Result would be declared right after the
trailing-return-type, so it is avaiable in the requires-clause of the
function, as well as inside the function body. We should require a
trailing-return-type, though, to avoid getting into a catch-22 situation
where the type-alias deduction depends on the type-alias itself.

In operators:

    operator Sortable auto{Result}() { /* Result is an alias of the return
type */ }

With the same rationale of P1141 I would leave structured bindings alone.
The same syntax could be extended to decltype(auto), where applicable.

Comments?

--
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/120f7272-55aa-4796-910d-6a3c3cd3504e%40isocpp.org.

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

<div dir=3D"ltr"><div></div><div>Let&#39;s start by saying that I like P114=
1. I believe that some of the objections I saw in this thread are due to th=
e attempt of using an approach that worked for some of the previously propo=
sed syntaxes. However, I believe the syntax proposed in P1141 and, in parti=
cular, the consistent of &quot;auto&quot;, allows for a completely differen=
t approach, that not only addresses most use-cases but also allows new prog=
ramming techniques. Allow me to explain my idea that I call &quot;placehold=
er type alias&quot;. The idea is simple: in every place I can write auto, I=
 can write auto{Type} and have Type being defined as an alias of whatever t=
ype has been deduced by auto. This means:</div><div><br></div><div>In templ=
ates:</div><div><br></div><div>=C2=A0=C2=A0=C2=A0 void f(auto{T} x) // equi=
valent to template &lt;class T&gt; void f(T x);</div><div><br></div><div><d=
iv>=C2=A0=C2=A0=C2=A0 void f(auto{T} x, T y) // equivalent to template &lt;=
class T&gt; void f(T x, T y)</div><div><br></div><div><div>=C2=A0=C2=A0=C2=
=A0 void f(const auto{T}&amp; x) // equivalent to template &lt;class T&gt; =
void f(const T&amp; x)</div><div><br></div><div>=C2=A0=C2=A0=C2=A0 void adv=
ance(auto{I}&amp; i, difference_type_t&lt;I&gt; n); <br></div><div><br></di=
v><div>=C2=A0=C2=A0=C2=A0 template &lt;Constraint auto{T} N&gt; void f(); /=
/ T is an alias for decltype(N)<br></div><div><br></div><div><div>=C2=A0=C2=
=A0=C2=A0 template &lt;auto{T} N&gt; requires /* complex constraint involvi=
ng T */ void f();<br></div><div><br></div></div></div><div>In variable decl=
arations:<br></div><br><div>=C2=A0=C2=A0 auto{T} x =3D f(); // T is alias f=
or decltype(x)</div><div><br></div><div>In return value:</div><div><br></di=
v><div><div>=C2=A0=C2=A0 auto{Result} f() -&gt; /* complex type declarator =
*/; // Result is an alias for complex type declarator</div><div><br></div><=
div>in this case, Result would be declared right after the trailing-return-=
type, so it is avaiable in the requires-clause of the function, as well as =
inside the function body. We should require a trailing-return-type, though,=
 to avoid getting into a catch-22 situation where the type-alias deduction =
depends on the type-alias itself.</div><div><br></div><div>In operators:</d=
iv><div><br></div><div>=C2=A0=C2=A0=C2=A0 operator Sortable auto{Result}() =
{ /* Result is an alias of the return type */ }</div><div><br></div><div>Wi=
th the same rationale of P1141 I would leave structured bindings alone. The=
 same syntax could be extended to decltype(auto), where applicable.<br></di=
v><div><br></div><div>Comments?</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/120f7272-55aa-4796-910d-6a3c3cd3504e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/120f7272-55aa-4796-910d-6a3c3cd3504e=
%40isocpp.org</a>.<br />

------=_Part_39534_890489627.1531134689328--

------=_Part_39533_1170181255.1531134689328--

.