Topic: Most vexing parse and p0745r0
Author: inkwizytoryankes@gmail.com
Date: Mon, 9 Apr 2018 06:33:57 -0700 (PDT)
Raw View
------=_Part_23539_872499111.1523280837967
Content-Type: multipart/alternative;
boundary="----=_Part_23540_284033723.1523280837967"
------=_Part_23540_284033723.1523280837967
Content-Type: text/plain; charset="UTF-8"
In p0745r0 is introduced new syntax:
X f(Concept{T}&& a){ /* ... */ }
But after looking on it I get feeling this could end up in new most vexing
parse MK 2:
X f(Concept{}); //forward function declaration
X h(int{}); //new variable
Is this valid concern? Is possible that someone write code that will have
opposite meaning than intended? Can same concept and type name exist in
same scope?
Probably one thing for sure we will loose is ability automatic visual
distinction:
Foo a(X()); //function, even if I wanted variable
Foo b(Y(1)); //variable
Foo f(Z{}); //C++11: always variable, C++20: ??, you need to know what Z is
--
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/cdd0423a-e29e-4b75-b90f-35be5e01880d%40isocpp.org.
------=_Part_23540_284033723.1523280837967
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>In p0745r0 is introduced new syntax:<br><br><div style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; overflow-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">X f</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Concept</span><span style=3D"colo=
r: #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"> a</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">){</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #800;" 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><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></c=
ode></div><br>But after looking on it I get feeling this could end up in ne=
w most vexing parse MK 2:<br><br><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: #000;" clas=
s=3D"styled-by-prettify">X f</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">Concept</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{});</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//forward=
function declaration</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>X h</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{});</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">//new variable</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></=
code></div><br>Is this valid concern? Is possible that someone write code t=
hat will have opposite meaning than intended? Can same concept and type nam=
e exist in same scope?<br><br>Probably one thing <span id=3D"result_box" cl=
ass=3D"short_text" lang=3D"en"><span class=3D"">for sure</span></span> we w=
ill loose is ability automatic visual distinction:<br><div style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettypr=
int"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">X</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">());</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">=
//function, even if I wanted variable</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Foo</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">Y</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;=
" class=3D"styled-by-prettify">//variable</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #606;" clas=
s=3D"styled-by-prettify">Foo</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>Z</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{});</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">//C++11: always variabl=
e, C++20: ??, you need to know what Z is</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br></span></div></code></div><br><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cdd0423a-e29e-4b75-b90f-35be5e01880d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cdd0423a-e29e-4b75-b90f-35be5e01880d=
%40isocpp.org</a>.<br />
------=_Part_23540_284033723.1523280837967--
------=_Part_23539_872499111.1523280837967--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 9 Apr 2018 07:06:37 -0700 (PDT)
Raw View
------=_Part_23376_1042175045.1523282797814
Content-Type: multipart/alternative;
boundary="----=_Part_23377_476128633.1523282797815"
------=_Part_23377_476128633.1523282797815
Content-Type: text/plain; charset="UTF-8"
On Monday, April 9, 2018 at 9:33:58 AM UTC-4, Marcin Jaczewski wrote:
>
>
> In p0745r0 is introduced new syntax:
>
> X f(Concept{T}&& a){ /* ... */ }
>
> But after looking on it I get feeling this could end up in new most vexing
> parse MK 2:
>
> X f(Concept{}); //forward function declaration
> X h(int{}); //new variable
>
> Is this valid concern?
>
Nope. In order for that to compile, the compiler must see the declaration
of `Concept`. And therefore, the compiler can see that `Concept` is a
concept, not a typename. And therefore, the compiler knows what that is.
Now, it may be that the *user* is confused, but never the compiler.
> Is possible that someone write code that will have opposite meaning than
> intended? Can same concept and type name exist in same scope?
>
Concepts are variables, and you can't have a typename and variable with the
same name in the same scope.
Probably one thing for sure we will loose is ability automatic visual
> distinction:
> Foo a(X()); //function, even if I wanted variable
> Foo b(Y(1)); //variable
> Foo f(Z{}); //C++11: always variable, C++20: ??, you need to know what Z
> is
>
>
And how is that any different from:
Foo f(Z); //May declare a template or non-template function; you need to
know what Z is.
If you want good terse syntax, you're going to *have* to give up some form
of visual inspection. C++ is out of good syntax for this sort of stuff, so
we have to make due with what we have.
Besides, I would say that from the surrounding context, you'll know which
is which. If its in a function, odds are good `Z` is a typename. If its in
class scope, `Z` *must* be a concept, since you can't use parenthesis on
default member initializers. If its in global scope, `Z` is probably a
concept, since you'd usually write it as `Foo f = Z{};`. Also, concept
names are not likely to be confused with typenames.
--
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/b1082776-de1a-4f25-bcc2-739dcc6897ab%40isocpp.org.
------=_Part_23377_476128633.1523282797815
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, April 9, 2018 at 9:33:58 AM UTC-4, Marc=
in Jaczewski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br>In p0745r0 is introduced new syntax:<br><br><div style=3D"backgro=
und-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid=
;border-width:1px"><code><div><span style=3D"color:#000">X f</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#606">Concept</span><span s=
tyle=3D"color:#660">{</span><span style=3D"color:#000">T</span><span style=
=3D"color:#660">}&&</span><span style=3D"color:#000"> a</span><span=
style=3D"color:#660">){</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#800">/* ... */</span><span style=3D"color:#000"> </span><span =
style=3D"color:#660">}</span><span style=3D"color:#000"><br></span></div></=
code></div><br>But after looking on it I get feeling this could end up in n=
ew most vexing parse MK 2:<br><br><div style=3D"background-color:rgb(250,25=
0,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><=
code><div><span style=3D"color:#000">X f</span><span style=3D"color:#660">(=
</span><span style=3D"color:#606">Concept</span><span style=3D"color:#660">=
{});</span><span style=3D"color:#000"> </span><span style=3D"color:#800">//=
forward function declaration</span><span style=3D"color:#000"><br>X h</span=
><span style=3D"color:#660">(</span><span style=3D"color:#008">int</span><s=
pan style=3D"color:#660">{});</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#800">//new variable</span><span style=3D"color:#000"><br>=
</span></div></code></div><br>Is this valid concern?</div></blockquote><div=
><br>Nope. In order for that to compile, the compiler must see the declarat=
ion of `Concept`. And therefore, the compiler can see that `Concept` is a c=
oncept, not a typename. And therefore, the compiler knows what that is.<br>=
<br>Now, it may be that the <i>user</i> is confused, but never the compiler=
..<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Is possible that someone write code that will have opposite meaning tha=
n intended? Can same concept and type name exist in same scope?<br></div></=
blockquote><div><br>Concepts are variables, and you can't have a typena=
me and variable with the same name in the same scope.<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Probably one thing <s=
pan lang=3D"en"><span>for sure</span></span> we will loose is ability autom=
atic visual distinction:<br><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">Foo</span><span style=3D"color:#000"> a</spa=
n><span style=3D"color:#660">(</span><span style=3D"color:#000">X</span><sp=
an style=3D"color:#660">());</span><span style=3D"color:#000"> </span><span=
style=3D"color:#800">//function, even if I wanted variable</span><span sty=
le=3D"color:#000"><br></span><span style=3D"color:#606">Foo</span><span sty=
le=3D"color:#000"> b</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">Y</span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#066">1</span><span style=3D"color:#660">));</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#800">//variable</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#606">Foo</span><span style=3D"=
color:#000"> f</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#000">Z</span><span style=3D"color:#660">{});</span><span style=3D"color:=
#000"> </span><span style=3D"color:#800">//C++11: always variable, C++20: ?=
?, you need to know what Z is</span><span style=3D"color:#000"><br></span><=
/div></code></div><br></div></blockquote><div><br>And how is that any diffe=
rent from:<br><br><div style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overfl=
ow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Foo</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">Z</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">//May declare a template or non-template=
function; you need to know what Z is.</span></div></code></div><br>If you =
want good terse syntax, you're going to <i>have</i> to give up some for=
m of visual inspection. C++ is out of good syntax for this sort of stuff, s=
o we have to make due with what we have.<br><br>Besides, I would say that f=
rom the surrounding context, you'll know which is which. If its in a fu=
nction, odds are good `Z` is a typename. If its in class scope, `Z` *must* =
be a concept, since you can't use parenthesis on default member initial=
izers. If its in global scope, `Z` is probably a concept, since you'd u=
sually write it as `Foo f =3D Z{};`. Also, concept names are not likely to =
be confused with typenames.<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b1082776-de1a-4f25-bcc2-739dcc6897ab%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b1082776-de1a-4f25-bcc2-739dcc6897ab=
%40isocpp.org</a>.<br />
------=_Part_23377_476128633.1523282797815--
------=_Part_23376_1042175045.1523282797814--
.
Author: inkwizytoryankes@gmail.com
Date: Mon, 9 Apr 2018 08:10:27 -0700 (PDT)
Raw View
------=_Part_24038_2014094700.1523286627279
Content-Type: multipart/alternative;
boundary="----=_Part_24039_1270658645.1523286627279"
------=_Part_24039_1270658645.1523286627279
Content-Type: text/plain; charset="UTF-8"
On Monday, April 9, 2018 at 4:06:37 PM UTC+2, Nicol Bolas wrote:
>
>
>
> On Monday, April 9, 2018 at 9:33:58 AM UTC-4, Marcin Jaczewski wrote:
>>
>>
>> In p0745r0 is introduced new syntax:
>>
>> X f(Concept{T}&& a){ /* ... */ }
>>
>> But after looking on it I get feeling this could end up in new most
>> vexing parse MK 2:
>>
>> X f(Concept{}); //forward function declaration
>> X h(int{}); //new variable
>>
>> Is this valid concern?
>>
>
> Nope. In order for that to compile, the compiler must see the declaration
> of `Concept`. And therefore, the compiler can see that `Concept` is a
> concept, not a typename. And therefore, the compiler knows what that is.
>
> Now, it may be that the *user* is confused, but never the compiler.
>
>
This is whole point. In most vexing parse compiler is not confused too but
user is.
> Is possible that someone write code that will have opposite meaning than
>> intended? Can same concept and type name exist in same scope?
>>
>
> Concepts are variables, and you can't have a typename and variable with
> the same name in the same scope.
>
> Probably one thing for sure we will loose is ability automatic visual
>> distinction:
>> Foo a(X()); //function, even if I wanted variable
>> Foo b(Y(1)); //variable
>> Foo f(Z{}); //C++11: always variable, C++20: ??, you need to know what Z
>> is
>>
>>
> And how is that any different from:
>
> Foo f(Z); //May declare a template or non-template function; you need to
> know what Z is.
>
>
How it could declare template in `C++17`? If `Z` is value then we have
variable `f`, if it type this will always be normal function, you will need
drop `template` before it, but then it will be different thing.
> If you want good terse syntax, you're going to *have* to give up some
> form of visual inspection. C++ is out of good syntax for this sort of
> stuff, so we have to make due with what we have.
>
> I fully understand this, my question is how big will be side effects (if
any) of this new syntax. I can easy live with examples I provide but I do
not know if there is any more serious case where syntax could clash and do
different thing that programmer wanted and excepted.
One thing I find that is similar to this is unnamed value template
parameter:
template<Concept{T}> class A{}; // A<int>, T == int
template<Concept{T} V> class B1{}; // B1<5>
template<Concept{T} /*V*/> class B2{}; //ups, now is type not value
parameter
Of corse this is minor inconveniences.
> Besides, I would say that from the surrounding context, you'll know which
> is which. If its in a function, odds are good `Z` is a typename. If its in
> class scope, `Z` *must* be a concept, since you can't use parenthesis on
> default member initializers. If its in global scope, `Z` is probably a
> concept, since you'd usually write it as `Foo f = Z{};`. Also, concept
> names are not likely to be confused with typenames.
>
>
Yes, most of this examples is comparable to `X * a;`. If this all then
there is no problem, again I'm simply interested if there was analyze of
this "side effects".
--
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/c36cef50-7f52-446b-a690-f4e10922e5d6%40isocpp.org.
------=_Part_24039_1270658645.1523286627279
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, April 9, 2018 at 4:06:37 PM UTC+2, 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"=
><br><br>On Monday, April 9, 2018 at 9:33:58 AM UTC-4, Marcin Jaczewski wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>In p0745r0 =
is introduced new syntax:<br><br><div style=3D"background-color:rgb(250,250=
,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><c=
ode><div><span style=3D"color:#000">X f</span><span style=3D"color:#660">(<=
/span><span style=3D"color:#606">Concept</span><span style=3D"color:#660">{=
</span><span style=3D"color:#000">T</span><span style=3D"color:#660">}&=
&</span><span style=3D"color:#000"> a</span><span style=3D"color:#660">=
){</span><span style=3D"color:#000"> </span><span style=3D"color:#800">/* .=
... */</span><span style=3D"color:#000"> </span><span style=3D"color:#660">}=
</span><span style=3D"color:#000"><br></span></div></code></div><br>But aft=
er looking on it I get feeling this could end up in new most vexing parse M=
K 2:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rg=
b(187,187,187);border-style:solid;border-width:1px"><code><div><span style=
=3D"color:#000">X f</span><span style=3D"color:#660">(</span><span style=3D=
"color:#606">Concept</span><span style=3D"color:#660">{});</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#800">//forward function decl=
aration</span><span style=3D"color:#000"><br>X h</span><span style=3D"color=
:#660">(</span><span style=3D"color:#008">int</span><span style=3D"color:#6=
60">{});</span><span style=3D"color:#000"> </span><span style=3D"color:#800=
">//new variable</span><span style=3D"color:#000"><br></span></div></code><=
/div><br>Is this valid concern?</div></blockquote><div><br>Nope. In order f=
or that to compile, the compiler must see the declaration of `Concept`. And=
therefore, the compiler can see that `Concept` is a concept, not a typenam=
e. And therefore, the compiler knows what that is.<br><br>Now, it may be th=
at the <i>user</i> is confused, but never the compiler.<br>=C2=A0</div></di=
v></blockquote><div><br>This is whole point. In most vexing parse compiler =
is not confused too but user is.<br>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><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">Is possible that someone write code that will have opposi=
te meaning than intended? Can same concept and type name exist in same scop=
e?<br></div></blockquote><div><br>Concepts are variables, and you can't=
have a typename and variable with the same name in the same scope.<br><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">Probably one=
thing <span lang=3D"en"><span>for sure</span></span> we will loose is abil=
ity automatic visual distinction:<br><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">Foo</span><span style=3D"color:#000=
"> a</span><span style=3D"color:#660">(</span><span style=3D"color:#000">X<=
/span><span style=3D"color:#660">());</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#800">//function, even if I wanted variable</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#606">Foo</span>=
<span style=3D"color:#000"> b</span><span style=3D"color:#660">(</span><spa=
n style=3D"color:#000">Y</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#066">1</span><span style=3D"color:#660">));</span><span style=
=3D"color:#000"> </span><span style=3D"color:#800">//variable</span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#606">Foo</span><span s=
tyle=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">Z</span><span style=3D"color:#660">{});</span><span style=
=3D"color:#000"> </span><span style=3D"color:#800">//C++11: always variable=
, C++20: ??, you need to know what Z is</span><span style=3D"color:#000"><b=
r></span></div></code></div><br></div></blockquote><div><br>And how is that=
any different from:<br><br><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">Foo</span><span style=3D"color:#000"> f</spa=
n><span style=3D"color:#660">(</span><span style=3D"color:#000">Z</span><sp=
an style=3D"color:#660">);</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#800">//May declare a template or non-template function; you =
need to know what Z is.</span></div></code></div><br></div></div></blockquo=
te><div><br>How it could declare template in `C++17`? If `Z` is value then =
we have variable `f`, if it type this will always be normal function, you w=
ill need drop `template` before it, but then it will be different thing.<br=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>If you want good terse syntax, you're going to <i>have</i> to give=
up some form of visual inspection. C++ is out of good syntax for this sort=
of stuff, so we have to make due with what we have.<br><br></div></div></b=
lockquote><div>I fully understand this, my question is how big will be side=
effects (if any) of this new syntax. I can easy live with examples I provi=
de but I do not know if there is any more serious case where syntax could c=
lash and do different thing that programmer wanted and excepted.<br><br>One=
thing I find that is similar to this is unnamed value template parameter:<=
br><br><div style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: br=
eak-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">t=
emplate</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Concept</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n 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"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> A</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{};</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// A<int>, T =3D=3D int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">template</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify"><</span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Concept</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> V</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> B1</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{};</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// B1<5></span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Concep=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;"=
class=3D"styled-by-prettify">/*V*/</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> B2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{}=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #800;" class=3D"styled-by-prettify">//ups, now is type=
not value parameter</span></div></code></div><br>Of corse this is minor in=
conveniences.<br><br>=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>Besides, I would say that from the surrounding con=
text, you'll know which is which. If its in a function, odds are good `=
Z` is a typename. If its in class scope, `Z` *must* be a concept, since you=
can't use parenthesis on default member initializers. If its in global=
scope, `Z` is probably a concept, since you'd usually write it as `Foo=
f =3D Z{};`. Also, concept names are not likely to be confused with typena=
mes.<br><br></div></div></blockquote><div><br>=C2=A0Yes, most of this examp=
les is comparable to `X * a;`. If this all then there is no problem, again =
I'm simply interested if there was analyze of this "side effects&q=
uot;.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c36cef50-7f52-446b-a690-f4e10922e5d6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c36cef50-7f52-446b-a690-f4e10922e5d6=
%40isocpp.org</a>.<br />
------=_Part_24039_1270658645.1523286627279--
------=_Part_24038_2014094700.1523286627279--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 9 Apr 2018 08:29:31 -0700 (PDT)
Raw View
------=_Part_23669_2053540233.1523287771940
Content-Type: multipart/alternative;
boundary="----=_Part_23670_2090781441.1523287771940"
------=_Part_23670_2090781441.1523287771940
Content-Type: text/plain; charset="UTF-8"
On Monday, April 9, 2018 at 11:10:27 AM UTC-4, Marcin Jaczewski wrote:
>
> On Monday, April 9, 2018 at 4:06:37 PM UTC+2, Nicol Bolas wrote:
>>
>>
>>
>> On Monday, April 9, 2018 at 9:33:58 AM UTC-4, Marcin Jaczewski wrote:
>>>
>>>
>>> In p0745r0 is introduced new syntax:
>>>
>>> X f(Concept{T}&& a){ /* ... */ }
>>>
>>> But after looking on it I get feeling this could end up in new most
>>> vexing parse MK 2:
>>>
>>> X f(Concept{}); //forward function declaration
>>> X h(int{}); //new variable
>>>
>>> Is this valid concern?
>>>
>>
>> Nope. In order for that to compile, the compiler must see the declaration
>> of `Concept`. And therefore, the compiler can see that `Concept` is a
>> concept, not a typename. And therefore, the compiler knows what that is.
>>
>> Now, it may be that the *user* is confused, but never the compiler.
>>
>>
>
> This is whole point. In most vexing parse compiler is not confused too but
> user is.
>
In the most vexing parse, the compiler is not doing what the user expected.
You wrote a typename followed by parenthesis, expecting this to mean
"default construct a prvalue of this type". The compiler sees a typename
followed by parenthesis and assumes this means "function type". The code
doesn't do what the user thought it would.
That's not the case here. You wrote a *concept name* followed by curly
braces, expecting this to mean "concept constrained parameter". The
compiler agrees with you. So there is no confusion.
The most vexing parse is about the confusion between the writer and the
compiler. That's not what's happening here. If there is confusion, it is
*only* between the *reader* and the writer/compiler. The writer's intent
and the compiler's actions are in alignment. The writer knew it was a
concept name, and the compiler agreed.
Is possible that someone write code that will have opposite meaning than
>>> intended? Can same concept and type name exist in same scope?
>>>
>>
>> Concepts are variables, and you can't have a typename and variable with
>> the same name in the same scope.
>>
>> Probably one thing for sure we will loose is ability automatic visual
>>> distinction:
>>> Foo a(X()); //function, even if I wanted variable
>>> Foo b(Y(1)); //variable
>>> Foo f(Z{}); //C++11: always variable, C++20: ??, you need to know what
>>> Z is
>>>
>>>
>> And how is that any different from:
>>
>> Foo f(Z); //May declare a template or non-template function; you need to
>> know what Z is.
>>
>>
> How it could declare template in `C++17`?
>
I didn't say anything about C++17. I was comparing Herb's terse syntax with
the Concepts TS version of terse templates, which doesn't use the `{}`
after the concept name. The point being that terse syntax will either not
be terse or will involve some ambiguity on the reader's part.
--
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/85f70090-83d6-48e7-8418-571af858fad3%40isocpp.org.
------=_Part_23670_2090781441.1523287771940
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, April 9, 2018 at 11:10:27 AM UTC-4, Marcin Jacz=
ewski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
n Monday, April 9, 2018 at 4:06:37 PM UTC+2, 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"><br><br>On Monday, April 9, 20=
18 at 9:33:58 AM UTC-4, Marcin Jaczewski wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><br>In p0745r0 is introduced new syntax:<br><b=
r><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:#=
000">X f</span><span style=3D"color:#660">(</span><span style=3D"color:#606=
">Concept</span><span style=3D"color:#660">{</span><span style=3D"color:#00=
0">T</span><span style=3D"color:#660">}&&</span><span style=3D"colo=
r:#000"> a</span><span style=3D"color:#660">){</span><span style=3D"color:#=
000"> </span><span style=3D"color:#800">/* ... */</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">}</span><span style=3D"color:#00=
0"><br></span></div></code></div><br>But after looking on it I get feeling =
this could end up in new most vexing parse MK 2:<br><br><div style=3D"backg=
round-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:sol=
id;border-width:1px"><code><div><span style=3D"color:#000">X f</span><span =
style=3D"color:#660">(</span><span style=3D"color:#606">Concept</span><span=
style=3D"color:#660">{});</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#800">//forward function declaration</span><span style=3D"col=
or:#000"><br>X h</span><span style=3D"color:#660">(</span><span style=3D"co=
lor:#008">int</span><span style=3D"color:#660">{});</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#800">//new variable</span><span sty=
le=3D"color:#000"><br></span></div></code></div><br>Is this valid concern?<=
/div></blockquote><div><br>Nope. In order for that to compile, the compiler=
must see the declaration of `Concept`. And therefore, the compiler can see=
that `Concept` is a concept, not a typename. And therefore, the compiler k=
nows what that is.<br><br>Now, it may be that the <i>user</i> is confused, =
but never the compiler.<br>=C2=A0</div></div></blockquote><div><br>This is =
whole point. In most vexing parse compiler is not confused too but user is.=
<br></div></div></blockquote><div><br>In the most vexing parse, the compile=
r is not doing what the user expected. You wrote a typename followed by par=
enthesis, expecting this to mean "default construct a prvalue of this =
type". The compiler sees a typename followed by parenthesis and assume=
s this means "function type". The code doesn't do what the us=
er thought it would.<br><br>That's not the case here. You wrote a <i>co=
ncept name</i> followed by curly braces, expecting this to mean "conce=
pt constrained parameter". The compiler agrees with you. So there is n=
o confusion.<br><br>The most vexing parse is about the confusion between th=
e writer and the compiler. That's not what's happening here. If the=
re is confusion, it is <i>only</i> between the <i>reader</i> and the writer=
/compiler. The writer's intent and the compiler's actions are in al=
ignment. The writer knew it was a concept name, and the compiler agreed.<br=
><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"><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"><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">Is possible that someone write code th=
at will have opposite meaning than intended? Can same concept and type name=
exist in same scope?<br></div></blockquote><div><br>Concepts are variables=
, and you can't have a typename and variable with the same name in the =
same scope.<br><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">Probably one thing <span lang=3D"en"><span>for sure</span></span> =
we will loose is ability automatic visual distinction:<br><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px"><code><div><span style=3D"color:#606">Foo</span><spa=
n style=3D"color:#000"> a</span><span style=3D"color:#660">(</span><span st=
yle=3D"color:#000">X</span><span style=3D"color:#660">());</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#800">//function, even if I w=
anted variable</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#606">Foo</span><span style=3D"color:#000"> b</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#000">Y</span><span style=3D"color:#6=
60">(</span><span style=3D"color:#066">1</span><span style=3D"color:#660">)=
);</span><span style=3D"color:#000"> </span><span style=3D"color:#800">//va=
riable</span><span style=3D"color:#000"><br></span><span style=3D"color:#60=
6">Foo</span><span style=3D"color:#000"> f</span><span style=3D"color:#660"=
>(</span><span style=3D"color:#000">Z</span><span style=3D"color:#660">{});=
</span><span style=3D"color:#000"> </span><span style=3D"color:#800">//C++1=
1: always variable, C++20: ??, you need to know what Z is</span><span style=
=3D"color:#000"><br></span></div></code></div><br></div></blockquote><div><=
br>And how is that any different from:<br><br><div style=3D"background-colo=
r:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-=
width:1px"><code><div><span style=3D"color:#606">Foo</span><span style=3D"c=
olor:#000"> f</span><span style=3D"color:#660">(</span><span style=3D"color=
:#000">Z</span><span style=3D"color:#660">);</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#800">//May declare a template or non-templ=
ate function; you need to know what Z is.</span></div></code></div><br></di=
v></div></blockquote><div><br>How it could declare template in `C++17`?</di=
v></div></blockquote><div><br>I didn't say anything about C++17. I was =
comparing Herb's terse syntax with the Concepts TS version of terse tem=
plates, which doesn't use the `{}` after the concept name. The point be=
ing that terse syntax will either not be terse or will involve some ambigui=
ty on the reader's part.<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" 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/85f70090-83d6-48e7-8418-571af858fad3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/85f70090-83d6-48e7-8418-571af858fad3=
%40isocpp.org</a>.<br />
------=_Part_23670_2090781441.1523287771940--
------=_Part_23669_2053540233.1523287771940--
.
Author: inkwizytoryankes@gmail.com
Date: Mon, 9 Apr 2018 12:09:59 -0700 (PDT)
Raw View
------=_Part_24720_1299927638.1523301000070
Content-Type: multipart/alternative;
boundary="----=_Part_24721_440670576.1523301000070"
------=_Part_24721_440670576.1523301000070
Content-Type: text/plain; charset="UTF-8"
On Monday, April 9, 2018 at 5:29:32 PM UTC+2, Nicol Bolas wrote:
>
> On Monday, April 9, 2018 at 11:10:27 AM UTC-4, Marcin Jaczewski wrote:
>>
>> On Monday, April 9, 2018 at 4:06:37 PM UTC+2, Nicol Bolas wrote:
>>>
>>>
>>>
>>> On Monday, April 9, 2018 at 9:33:58 AM UTC-4, Marcin Jaczewski wrote:
>>>>
>>>>
>>>> In p0745r0 is introduced new syntax:
>>>>
>>>> X f(Concept{T}&& a){ /* ... */ }
>>>>
>>>> But after looking on it I get feeling this could end up in new most
>>>> vexing parse MK 2:
>>>>
>>>> X f(Concept{}); //forward function declaration
>>>> X h(int{}); //new variable
>>>>
>>>> Is this valid concern?
>>>>
>>>
>>> Nope. In order for that to compile, the compiler must see the
>>> declaration of `Concept`. And therefore, the compiler can see that
>>> `Concept` is a concept, not a typename. And therefore, the compiler knows
>>> what that is.
>>>
>>> Now, it may be that the *user* is confused, but never the compiler.
>>>
>>>
>>
>> This is whole point. In most vexing parse compiler is not confused too
>> but user is.
>>
>
> In the most vexing parse, the compiler is not doing what the user
> expected. You wrote a typename followed by parenthesis, expecting this to
> mean "default construct a prvalue of this type". The compiler sees a
> typename followed by parenthesis and assumes this means "function type".
> The code doesn't do what the user thought it would.
>
> That's not the case here. You wrote a *concept name* followed by curly
> braces, expecting this to mean "concept constrained parameter". The
> compiler agrees with you. So there is no confusion.
>
> The most vexing parse is about the confusion between the writer and the
> compiler. That's not what's happening here. If there is confusion, it is
> *only* between the *reader* and the writer/compiler. The writer's intent
> and the compiler's actions are in alignment. The writer knew it was a
> concept name, and the compiler agreed.
>
>
I'm not arguing about this exactly situation with examples, as I said:
"Yes, most of this examples is comparable to `X * a;`. If this all then
there is no problem".
I'm not language layer to rule out that this is more different cases, this
way I ask this there.
Right now you say that:
ConceptName + `{` -> type that can be template parameter, can only be used
in declaration/definitions
TypeName + `{` -> new rvalue, can only be used in expressions
And this is enough to eliminate ANY possible overlap in syntax structure?
--
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/a926776d-e1f8-4a2b-bdd0-dc432de45992%40isocpp.org.
------=_Part_24721_440670576.1523301000070
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, April 9, 2018 at 5:29:32 PM UTC+2, 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 Monday, April 9, 2018 at 11:10:27 AM UTC-4, Marcin Jaczewski wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, April 9, 20=
18 at 4:06:37 PM UTC+2, Nicol Bolas wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><br><br>On Monday, April 9, 2018 at 9:33:58 AM UTC-=
4, Marcin Jaczewski 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>In p0745r0 is introduced new syntax:<br><br><div style=3D"back=
ground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:so=
lid;border-width:1px"><code><div><span style=3D"color:#000">X f</span><span=
style=3D"color:#660">(</span><span style=3D"color:#606">Concept</span><spa=
n style=3D"color:#660">{</span><span style=3D"color:#000">T</span><span sty=
le=3D"color:#660">}&&</span><span style=3D"color:#000"> a</span><sp=
an style=3D"color:#660">){</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#800">/* ... */</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">}</span><span style=3D"color:#000"><br></span></div>=
</code></div><br>But after looking on it I get feeling this could end up in=
new most vexing parse MK 2:<br><br><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:#000">X f</span><span style=3D"color:#660"=
>(</span><span style=3D"color:#606">Concept</span><span style=3D"color:#660=
">{});</span><span style=3D"color:#000"> </span><span style=3D"color:#800">=
//forward function declaration</span><span style=3D"color:#000"><br>X h</sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#008">int</span>=
<span style=3D"color:#660">{});</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#800">//new variable</span><span style=3D"color:#000"><b=
r></span></div></code></div><br>Is this valid concern?</div></blockquote><d=
iv><br>Nope. In order for that to compile, the compiler must see the declar=
ation of `Concept`. And therefore, the compiler can see that `Concept` is a=
concept, not a typename. And therefore, the compiler knows what that is.<b=
r><br>Now, it may be that the <i>user</i> is confused, but never the compil=
er.<br>=C2=A0</div></div></blockquote><div><br>This is whole point. In most=
vexing parse compiler is not confused too but user is.<br></div></div></bl=
ockquote><div><br>In the most vexing parse, the compiler is not doing what =
the user expected. You wrote a typename followed by parenthesis, expecting =
this to mean "default construct a prvalue of this type". The comp=
iler sees a typename followed by parenthesis and assumes this means "f=
unction type". The code doesn't do what the user thought it would.=
<br><br>That's not the case here. You wrote a <i>concept name</i> follo=
wed by curly braces, expecting this to mean "concept constrained param=
eter". The compiler agrees with you. So there is no confusion.<br><br>=
The most vexing parse is about the confusion between the writer and the com=
piler. That's not what's happening here. If there is confusion, it =
is <i>only</i> between the <i>reader</i> and the writer/compiler. The write=
r's intent and the compiler's actions are in alignment. The writer =
knew it was a concept name, and the compiler agreed.<br><br></div></div></b=
lockquote><div><br>I'm not arguing about this exactly situation with ex=
amples, as I said: "Yes, most of this examples is comparable to `X * a=
;`. If this all then there is no problem".<br>I'm not language lay=
er to rule out that this is more different cases, this way I ask this there=
..<br><br>Right now you say that:<br><br>ConceptName + `{` -> type that c=
an be template parameter, can only be used in declaration/definitions<br>T=
ypeName + `{` -> new rvalue, can only be used in expressions<br><br>And =
this is enough to eliminate ANY possible overlap in syntax structure? <br><=
/div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a926776d-e1f8-4a2b-bdd0-dc432de45992%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a926776d-e1f8-4a2b-bdd0-dc432de45992=
%40isocpp.org</a>.<br />
------=_Part_24721_440670576.1523301000070--
------=_Part_24720_1299927638.1523301000070--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 9 Apr 2018 15:30:54 -0700 (PDT)
Raw View
------=_Part_25723_1005115137.1523313054508
Content-Type: multipart/alternative;
boundary="----=_Part_25724_1188477269.1523313054508"
------=_Part_25724_1188477269.1523313054508
Content-Type: text/plain; charset="UTF-8"
On Monday, April 9, 2018 at 3:10:00 PM UTC-4, Marcin Jaczewski wrote:
>
> On Monday, April 9, 2018 at 5:29:32 PM UTC+2, Nicol Bolas wrote:
>>
>> On Monday, April 9, 2018 at 11:10:27 AM UTC-4, Marcin Jaczewski wrote:
>>>
>>> On Monday, April 9, 2018 at 4:06:37 PM UTC+2, Nicol Bolas wrote:
>>>>
>>>>
>>>>
>>>> On Monday, April 9, 2018 at 9:33:58 AM UTC-4, Marcin Jaczewski wrote:
>>>>>
>>>>>
>>>>> In p0745r0 is introduced new syntax:
>>>>>
>>>>> X f(Concept{T}&& a){ /* ... */ }
>>>>>
>>>>> But after looking on it I get feeling this could end up in new most
>>>>> vexing parse MK 2:
>>>>>
>>>>> X f(Concept{}); //forward function declaration
>>>>> X h(int{}); //new variable
>>>>>
>>>>> Is this valid concern?
>>>>>
>>>>
>>>> Nope. In order for that to compile, the compiler must see the
>>>> declaration of `Concept`. And therefore, the compiler can see that
>>>> `Concept` is a concept, not a typename. And therefore, the compiler knows
>>>> what that is.
>>>>
>>>> Now, it may be that the *user* is confused, but never the compiler.
>>>>
>>>>
>>>
>>> This is whole point. In most vexing parse compiler is not confused too
>>> but user is.
>>>
>>
>> In the most vexing parse, the compiler is not doing what the user
>> expected. You wrote a typename followed by parenthesis, expecting this to
>> mean "default construct a prvalue of this type". The compiler sees a
>> typename followed by parenthesis and assumes this means "function type".
>> The code doesn't do what the user thought it would.
>>
>> That's not the case here. You wrote a *concept name* followed by curly
>> braces, expecting this to mean "concept constrained parameter". The
>> compiler agrees with you. So there is no confusion.
>>
>> The most vexing parse is about the confusion between the writer and the
>> compiler. That's not what's happening here. If there is confusion, it is
>> *only* between the *reader* and the writer/compiler. The writer's intent
>> and the compiler's actions are in alignment. The writer knew it was a
>> concept name, and the compiler agreed.
>>
>>
> I'm not arguing about this exactly situation with examples, as I said:
> "Yes, most of this examples is comparable to `X * a;`. If this all then
> there is no problem".
> I'm not language layer to rule out that this is more different cases, this
> way I ask this there.
>
> Right now you say that:
>
> ConceptName + `{` -> type that can be template parameter, can only be used
> in declaration/definitions
> TypeName + `{` -> new rvalue, can only be used in expressions
>
> And this is enough to eliminate ANY possible overlap in syntax structure?
>
.... yes.
The Most Vexing Parse happened because of the ambiguous nature of `TypeName
+ (`. That can sometimes mean initialize a prvalue and sometimes mean a
function type. If both are viable within the context, the grammar will have
to favor one over the other. And they picked "function type".
By contrast, right now `ConceptName + {` means nothing, since concepts are
variables and `variable + {` doesn't mean anything. So it can be safely
given whatever meaning we want. `TypeName + {` means to initialize a
prvalue, and that need not change.
From a grammar standpoint, `identifier + {` will have to be able to lead to
two different outcomes, but things like that already happen in C++. You
can't really parse C++ as it is now without knowing what those identifiers
mean based on previous declarations/definitions. This would simply be one
more instance of that.
From a parsing perspective and writer/compiler agreement perspective,
`ConceptName + {` is safe and unambiguous. It's context sensitive, but not
ambiguous.
--
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/cbfd65aa-137e-492e-8662-90242ecd262b%40isocpp.org.
------=_Part_25724_1188477269.1523313054508
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, April 9, 2018 at 3:10:00 PM UTC-4, Marcin Jacze=
wski 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, April 9, 2018 at 5:29:32 PM UTC+2, Nicol Bolas wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, April 9, 2018 at 11:=
10:27 AM UTC-4, Marcin Jaczewski wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">On Monday, April 9, 2018 at 4:06:37 PM UTC+2, Nicol Bo=
las wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>=
On Monday, April 9, 2018 at 9:33:58 AM UTC-4, Marcin Jaczewski wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>In p0745r0 is introd=
uced new syntax:<br><br><div style=3D"background-color:rgb(250,250,250);bor=
der-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div>=
<span style=3D"color:#000">X f</span><span style=3D"color:#660">(</span><sp=
an style=3D"color:#606">Concept</span><span style=3D"color:#660">{</span><s=
pan style=3D"color:#000">T</span><span style=3D"color:#660">}&&</sp=
an><span style=3D"color:#000"> a</span><span style=3D"color:#660">){</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#800">/* ... */</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">}</span><s=
pan style=3D"color:#000"><br></span></div></code></div><br>But after lookin=
g on it I get feeling this could end up in new most vexing parse MK 2:<br><=
br><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:=
#000">X f</span><span style=3D"color:#660">(</span><span style=3D"color:#60=
6">Concept</span><span style=3D"color:#660">{});</span><span style=3D"color=
:#000"> </span><span style=3D"color:#800">//forward function declaration</s=
pan><span style=3D"color:#000"><br>X h</span><span style=3D"color:#660">(</=
span><span style=3D"color:#008">int</span><span style=3D"color:#660">{});</=
span><span style=3D"color:#000"> </span><span style=3D"color:#800">//new va=
riable</span><span style=3D"color:#000"><br></span></div></code></div><br>I=
s this valid concern?</div></blockquote><div><br>Nope. In order for that to=
compile, the compiler must see the declaration of `Concept`. And therefore=
, the compiler can see that `Concept` is a concept, not a typename. And the=
refore, the compiler knows what that is.<br><br>Now, it may be that the <i>=
user</i> is confused, but never the compiler.<br>=C2=A0</div></div></blockq=
uote><div><br>This is whole point. In most vexing parse compiler is not con=
fused too but user is.<br></div></div></blockquote><div><br>In the most vex=
ing parse, the compiler is not doing what the user expected. You wrote a ty=
pename followed by parenthesis, expecting this to mean "default constr=
uct a prvalue of this type". The compiler sees a typename followed by =
parenthesis and assumes this means "function type". The code does=
n't do what the user thought it would.<br><br>That's not the case h=
ere. You wrote a <i>concept name</i> followed by curly braces, expecting th=
is to mean "concept constrained parameter". The compiler agrees w=
ith you. So there is no confusion.<br><br>The most vexing parse is about th=
e confusion between the writer and the compiler. That's not what's =
happening here. If there is confusion, it is <i>only</i> between the <i>rea=
der</i> and the writer/compiler. The writer's intent and the compiler&#=
39;s actions are in alignment. The writer knew it was a concept name, and t=
he compiler agreed.<br><br></div></div></blockquote><div><br>I'm not ar=
guing about this exactly situation with examples, as I said: "Yes, mos=
t of this examples is comparable to `X * a;`. If this all then there is no =
problem".<br>I'm not language layer to rule out that this is more =
different cases, this way I ask this there.<br><br>Right now you say that:<=
br><br>ConceptName + `{` -> type that can be template parameter, can on=
ly be used in declaration/definitions<br>TypeName + `{` -> new rvalue, c=
an only be used in expressions<br><br>And this is enough to eliminate ANY p=
ossible overlap in syntax structure? <br></div></div></blockquote><div><br>=
.... yes.<br><br>The Most Vexing Parse happened because of the ambiguous nat=
ure of `TypeName + (`. That can sometimes mean initialize a prvalue and som=
etimes mean a function type. If both are viable within the context, the gra=
mmar will have to favor one over the other. And they picked "function =
type".<br><br>By contrast, right now `ConceptName + {` means nothing, =
since concepts are variables and `variable + {` doesn't mean anything. =
So it can be safely given whatever meaning we want. `TypeName + {` means to=
initialize a prvalue, and that need not change.<br><br>From a grammar stan=
dpoint, `identifier + {` will have to be able to lead to two different outc=
omes, but things like that already happen in C++. You can't really pars=
e C++ as it is now without knowing what those identifiers mean based on pre=
vious declarations/definitions. This would simply be one more instance of t=
hat.<br><br>From a parsing perspective and writer/compiler agreement perspe=
ctive, `ConceptName + {` is safe and unambiguous. It's context sensitiv=
e, but not ambiguous.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cbfd65aa-137e-492e-8662-90242ecd262b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cbfd65aa-137e-492e-8662-90242ecd262b=
%40isocpp.org</a>.<br />
------=_Part_25724_1188477269.1523313054508--
------=_Part_25723_1005115137.1523313054508--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 9 Apr 2018 16:08:47 -0700
Raw View
--000000000000304c750569727ece
Content-Type: text/plain; charset="UTF-8"
On 9 April 2018 at 07:06, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Monday, April 9, 2018 at 9:33:58 AM UTC-4, Marcin Jaczewski wrote:
>>
>>
>> In p0745r0 is introduced new syntax:
>>
>> X f(Concept{T}&& a){ /* ... */ }
>>
>> But after looking on it I get feeling this could end up in new most
>> vexing parse MK 2:
>>
>> X f(Concept{}); //forward function declaration
>> X h(int{}); //new variable
>>
>> Is this valid concern?
>>
>
> Nope. In order for that to compile, the compiler must see the declaration
> of `Concept`. And therefore, the compiler can see that `Concept` is a
> concept, not a typename. And therefore, the compiler knows what that is.
>
> Now, it may be that the *user* is confused, but never the compiler.
>
>
>> Is possible that someone write code that will have opposite meaning than
>> intended? Can same concept and type name exist in same scope?
>>
>
> Concepts are variables, and you can't have a typename and variable with
> the same name in the same scope.
>
> Probably one thing for sure we will loose is ability automatic visual
>> distinction:
>> Foo a(X()); //function, even if I wanted variable
>> Foo b(Y(1)); //variable
>> Foo f(Z{}); //C++11: always variable, C++20: ??, you need to know what Z
>> is
>>
>>
> And how is that any different from:
>
> Foo f(Z); //May declare a template or non-template function; you need to
> know what Z is.
>
> If you want good terse syntax, you're going to *have* to give up some
> form of visual inspection.
>
I don't entirely agree: I would say that if you have to give up some form
of visual inspection, you don't have a good terse syntax. Perhaps this
means that we're forced to choose between a less-good terse syntax and no
terse syntax at all, but that's an engineering tradeoff that we can and
should make, and we should keep in mind that having only one option doesn't
necessarily make that option good. (But conversely, "not good" doesn't mean
"not an improvement"...)
> C++ is out of good syntax for this sort of stuff, so we have to make due
> with what we have.
>
Besides, I would say that from the surrounding context, you'll know which
> is which. If its in a function, odds are good `Z` is a typename. If its in
> class scope, `Z` *must* be a concept, since you can't use parenthesis on
> default member initializers. If its in global scope, `Z` is probably a
> concept, since you'd usually write it as `Foo f = Z{};`. Also, concept
> names are not likely to be confused with typenames.
>
> --
> 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/b1082776-de1a-4f25-
> bcc2-739dcc6897ab%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b1082776-de1a-4f25-bcc2-739dcc6897ab%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkXEfRGVtXYMPvxgptum%2BppwXJFUY3UmTAErJ_OTtC%2Bbg%40mail.gmail.com.
--000000000000304c750569727ece
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 9=
April 2018 at 07:06, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On=
Monday, April 9, 2018 at 9:33:58 AM UTC-4, Marcin Jaczewski wrote:<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"><br>In p0745r0 is introduc=
ed new syntax:<br><br><div style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><s=
pan style=3D"color:#000">X f</span><span style=3D"color:#660">(</span><span=
style=3D"color:#606">Concept</span><span style=3D"color:#660">{</span><spa=
n style=3D"color:#000">T</span><span style=3D"color:#660">}&&</span=
><span style=3D"color:#000"> a</span><span style=3D"color:#660">){</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#800">/* ... */</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">}</span><spa=
n style=3D"color:#000"><br></span></div></code></div><br>But after looking =
on it I get feeling this could end up in new most vexing parse MK 2:<br><br=
><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,1=
87);border-style:solid;border-width:1px"><code><div><span style=3D"color:#0=
00">X f</span><span style=3D"color:#660">(</span><span style=3D"color:#606"=
>Concept</span><span style=3D"color:#660">{});</span><span style=3D"color:#=
000"> </span><span style=3D"color:#800">//forward function declaration</spa=
n><span style=3D"color:#000"><br>X h</span><span style=3D"color:#660">(</sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#660">{});</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#800">//new vari=
able</span><span style=3D"color:#000"><br></span></div></code></div><br>Is =
this valid concern?</div></blockquote></span><div><br>Nope. In order for th=
at to compile, the compiler must see the declaration of `Concept`. And ther=
efore, the compiler can see that `Concept` is a concept, not a typename. An=
d therefore, the compiler knows what that is.<br><br>Now, it may be that th=
e <i>user</i> is confused, but never the compiler.<br>=C2=A0</div><span cla=
ss=3D""><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">Is possibl=
e that someone write code that will have opposite meaning than intended? Ca=
n same concept and type name exist in same scope?<br></div></blockquote></s=
pan><div><br>Concepts are variables, and you can't have a typename and =
variable with the same name in the same scope.<br><br></div><span class=3D"=
"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Probably one thi=
ng <span lang=3D"en"><span>for sure</span></span> we will loose is ability =
automatic visual distinction:<br><div style=3D"background-color:rgb(250,250=
,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><c=
ode><div><span style=3D"color:#606">Foo</span><span style=3D"color:#000"> a=
</span><span style=3D"color:#660">(</span><span style=3D"color:#000">X</spa=
n><span style=3D"color:#660">());</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#800">//function, even if I wanted variable</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#606">Foo</span><spa=
n style=3D"color:#000"> b</span><span style=3D"color:#660">(</span><span st=
yle=3D"color:#000">Y</span><span style=3D"color:#660">(</span><span style=
=3D"color:#066">1</span><span style=3D"color:#660">));</span><span style=3D=
"color:#000"> </span><span style=3D"color:#800">//variable</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#606">Foo</span><span styl=
e=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span style=3D=
"color:#000">Z</span><span style=3D"color:#660">{});</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#800">//C++11: always variable, C++=
20: ??, you need to know what Z is</span><span style=3D"color:#000"><br></s=
pan></div></code></div><br></div></blockquote></span><div><br>And how is th=
at any different from:<br><br><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px" class=
=3D"m_8164568124480438600prettyprint"><code class=3D"m_8164568124480438600p=
rettyprint"><div class=3D"m_8164568124480438600subprettyprint"><span style=
=3D"color:#606" class=3D"m_8164568124480438600styled-by-prettify">Foo</span=
><span style=3D"color:#000" class=3D"m_8164568124480438600styled-by-prettif=
y"> f</span><span style=3D"color:#660" class=3D"m_8164568124480438600styled=
-by-prettify">(</span><span style=3D"color:#000" class=3D"m_816456812448043=
8600styled-by-prettify">Z</span><span style=3D"color:#660" class=3D"m_81645=
68124480438600styled-by-prettify">);</span><span style=3D"color:#000" class=
=3D"m_8164568124480438600styled-by-prettify"> </span><span style=3D"color:#=
800" class=3D"m_8164568124480438600styled-by-prettify">//May declare a temp=
late or non-template function; you need to know what Z is.</span></div></co=
de></div><br>If you want good terse syntax, you're going to <i>have</i>=
to give up some form of visual inspection.</div></div></blockquote><div><b=
r></div><div>I don't entirely agree: I would say that if you have to gi=
ve up some form of visual inspection, you don't have a good terse synta=
x. Perhaps this means that we're forced to choose between a less-good t=
erse syntax and no terse syntax at all, but that's an engineering trade=
off that we can and should make, and we should keep in mind that having onl=
y one option doesn't necessarily make that option good. (But conversely=
, "not good" doesn't mean "not an improvement"...)<=
/div><div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;fo=
nt-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-=
caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-ind=
ent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-=
color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:=
initial">=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"color:rgb(3=
4,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;fon=
t-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-=
spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decorat=
ion-style:initial;text-decoration-color:initial;margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v>C++ is out of good syntax for this sort of stuff, so we have to make due =
with what we have.=C2=A0</div></div></blockquote></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div>Besides, I would say that from the surroun=
ding context, you'll know which is which. If its in a function, odds ar=
e good `Z` is a typename. If its in class scope, `Z` *must* be a concept, s=
ince you can't use parenthesis on default member initializers. If its i=
n global scope, `Z` is probably a concept, since you'd usually write it=
as `Foo f =3D Z{};`. Also, concept names are not likely to be confused wit=
h typenames.<br><br></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b1082776-de1a-4f25-bcc2-739dcc6897ab%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/b108=
2776-de1a-4f25-<wbr>bcc2-739dcc6897ab%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkXEfRGVtXYMPvxgptum%2BppwXJFUY=
3UmTAErJ_OTtC%2Bbg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkXEfRG=
VtXYMPvxgptum%2BppwXJFUY3UmTAErJ_OTtC%2Bbg%40mail.gmail.com</a>.<br />
--000000000000304c750569727ece--
.