------=_Part_188_2444323.1358186781028
Content-Type: text/plain; charset=ISO-8859-1

I'm wondering if it would be entirely out of the question to have in C++

   - implicit template generation for functions
   - implicit autos for variable instantiation
   - implicit ->decltype(...) for functions that do not specify a return
   type if a return statement is specified (void other wise). Given that we
   have uniform initialisation, that wouldn't cause too many clashes?
   - and in general core language support to make previously non-compiling
   "Python-style" code compile.

For example the function:
add(x, y){
return x + y;
}

would be automatically translated into

template <typename X, typename Y>
auto add(X x, Y y) -> decltype(x + y){
return x + y;
}

Variable Instantiation:

x = 7;

Automatically translates to (if x is not already in scope and the statement
above is an assignment)

auto x = 7;

Given that consideration is being given to polymorphic lambdas, and I heard
on some video somewhere that since lambdas are being made polymorphic, why
not function arguments as well? There would be no need to break any code at
all, this would just be an optional short-hand new way of writing C++ code!

It would make C++ code a lot more elegant on the whole, which is what C++11
did for C++98.

Thanks for reading this!

Cong Lu

--




------=_Part_188_2444323.1358186781028
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<DIV>I'm wondering if it would be entirely out of the question to have in C=
++</DIV>
<UL>
<LI>implicit template generation for functions</LI>
<LI>implicit autos for variable instantiation</LI>
<LI>implicit -&gt;decltype(...) for functions that do not specify a return =
type if a return statement is specified (void other wise). Given that we ha=
ve uniform initialisation, that wouldn't cause too many clashes?</LI>
<LI>and in general core language support to make previously non-compiling "=
Python-style" code compile.</LI></UL>
<DIV>For example the function:</DIV>
<DIV>add(x, y){</DIV>
<DIV>return x + y;</DIV>
<DIV>}</DIV>
<DIV>&nbsp;</DIV>
<DIV>would be automatically translated into </DIV>
<DIV>&nbsp;</DIV>
<DIV>template &lt;typename X, typename Y&gt;</DIV>
<DIV>auto add(X x, Y y) -&gt; decltype(x + y){</DIV>
<DIV>return x + y;</DIV>
<DIV>}</DIV>
<DIV>&nbsp;</DIV>
<DIV>Variable Instantiation:</DIV>
<DIV>&nbsp;</DIV>
<DIV>x =3D 7; </DIV>
<DIV>&nbsp;</DIV>
<DIV>Automatically translates to (if x is not already in scope and the stat=
ement above is an assignment)</DIV>
<DIV>&nbsp;</DIV>
<DIV>auto x =3D 7;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Given that consideration is being given to polymorphic lambdas, and I =
heard on some video somewhere that since lambdas are being made polymorphic=
, why not function arguments as well? There would be no need to break any c=
ode at all, this would just be an optional&nbsp;short-hand new way of writi=
ng C++ code!</DIV>
<DIV>&nbsp;</DIV>
<DIV>It would make C++ code a lot more elegant on the whole, which is what =
C++11 did for C++98.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks for reading this!</DIV>
<DIV>&nbsp;</DIV>
<DIV>Cong Lu</DIV>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_188_2444323.1358186781028--

.

--0015175cfccc4600a404d343b5bb
Content-Type: text/plain; charset=ISO-8859-1

On 14 January 2013 12:06, Cong Lu <hicong5@gmail.com> wrote:

> I'm wondering if it would be entirely out of the question to have in C++
>
>    - implicit ->decltype(...) for functions that do not specify a return
>    type if a return statement is specified (void other wise).
>
> n3386 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3386.html> addresses
a lot of this particular item.


> Variable Instantiation:
>
> x = 7;
>
> Automatically translates to (if x is not already in scope and the
> statement above is an assignment)
>
> auto x = 7;
>

The problem is the mere inclusion of a header file with a global "x", or
someone adding an "x" member variable can change the meaning of your
program.  Very error prone and brittle.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




--0015175cfccc4600a404d343b5bb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 14 January 2013 12:06, Cong Lu <span dir=3D"ltr">&lt;<a href=3D"mailto:h=
icong5@gmail.com" target=3D"_blank">hicong5@gmail.com</a>&gt;</span> wrote:=
<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>I&#39;m wondering if it would be entirely out of the question to have =
in C++</div>
<ul>
<li>implicit -&gt;decltype(...) for functions that do not specify a return =
type if a return statement is specified (void other wise).</li></ul></block=
quote><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20=
12/n3386.html">n3386</a>=A0addresses a lot of this particular item.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div>Variable Instantiation:</=
div>
<div>=A0</div>
<div>x =3D 7; </div>
<div>=A0</div>
<div>Automatically translates to (if x is not already in scope and the stat=
ement above is an assignment)</div>
<div>=A0</div>
<div>auto x =3D 7;</div></blockquote><div><br></div><div>The problem is the=
 mere inclusion of a header file with a global &quot;x&quot;, or someone ad=
ding an &quot;x&quot; member variable can change the meaning of your progra=
m. =A0Very error prone and brittle.</div>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--0015175cfccc4600a404d343b5bb--

.

------=_Part_481_27931258.1358201340301
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Actually, I was wondering something similar reading the lambda extension=20
proposal.

If=20
[](auto x) -> decltype(x){ return x*x; }
allowed, then why not going for
auto calcSquare(auto x) -> decltype(x) { return x*x; }
meaning
template<typename T>
auto calcSquare(auto x) -> decltype(x) { return x*x; }
?

Regards,
Robert


2013. janu=E1r 14., h=E9tf=F5 19:06:21 UTC+1 id=F5pontban Cong Lu a k=F6vet=
kez=F5t =EDrta:
>
> I'm wondering if it would be entirely out of the question to have in C++
>
>    - implicit template generation for functions=20
>    - implicit autos for variable instantiation=20
>    - implicit ->decltype(...) for functions that do not specify a return=
=20
>    type if a return statement is specified (void other wise). Given that =
we=20
>    have uniform initialisation, that wouldn't cause too many clashes?=20
>    - and in general core language support to make previously=20
>    non-compiling "Python-style" code compile.
>
> For example the function:
> add(x, y){
> return x + y;
> }
> =20
> would be automatically translated into=20
> =20
> template <typename X, typename Y>
> auto add(X x, Y y) -> decltype(x + y){
> return x + y;
> }
> =20
> Variable Instantiation:
> =20
> x =3D 7;=20
> =20
> Automatically translates to (if x is not already in scope and the=20
> statement above is an assignment)
> =20
> auto x =3D 7;
> =20
> Given that consideration is being given to polymorphic lambdas, and I=20
> heard on some video somewhere that since lambdas are being made=20
> polymorphic, why not function arguments as well? There would be no need t=
o=20
> break any code at all, this would just be an optional short-hand new way =
of=20
> writing C++ code!
> =20
> It would make C++ code a lot more elegant on the whole, which is what=20
> C++11 did for C++98.
> =20
> Thanks for reading this!
> =20
> Cong Lu
>

--=20




------=_Part_481_27931258.1358201340301
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Actually, I was wondering something similar reading the lambda extension pr=
oposal.<br><br>If <div class=3D"prettyprint" style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">[](</span><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">decltype</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">){</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><spa=
n 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"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> allowed, then why not going=
 for<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
 250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> calcSquar=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">decltype</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </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: #008;"=
 class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></d=
iv>meaning<br><div class=3D"prettyprint" style=3D"background-color: rgb(250=
, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-=
width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> calcSquare</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> x</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=
">-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">decltype</sp=
an><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"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">x</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: #6=
60;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span></div></code></div>?<br><br>Regards,<br=
>Robert<br><br><br>2013. janu=E1r 14., h=E9tf=F5 19:06:21 UTC+1 id=F5pontba=
n Cong Lu a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div>I'm wondering if it would be entirely out of the question to hav=
e in C++</div>
<ul>
<li>implicit template generation for functions</li>
<li>implicit autos for variable instantiation</li>
<li>implicit -&gt;decltype(...) for functions that do not specify a return =
type if a return statement is specified (void other wise). Given that we ha=
ve uniform initialisation, that wouldn't cause too many clashes?</li>
<li>and in general core language support to make previously non-compiling "=
Python-style" code compile.</li></ul>
<div>For example the function:</div>
<div>add(x, y){</div>
<div>return x + y;</div>
<div>}</div>
<div>&nbsp;</div>
<div>would be automatically translated into </div>
<div>&nbsp;</div>
<div>template &lt;typename X, typename Y&gt;</div>
<div>auto add(X x, Y y) -&gt; decltype(x + y){</div>
<div>return x + y;</div>
<div>}</div>
<div>&nbsp;</div>
<div>Variable Instantiation:</div>
<div>&nbsp;</div>
<div>x =3D 7; </div>
<div>&nbsp;</div>
<div>Automatically translates to (if x is not already in scope and the stat=
ement above is an assignment)</div>
<div>&nbsp;</div>
<div>auto x =3D 7;</div>
<div>&nbsp;</div>
<div>Given that consideration is being given to polymorphic lambdas, and I =
heard on some video somewhere that since lambdas are being made polymorphic=
, why not function arguments as well? There would be no need to break any c=
ode at all, this would just be an optional&nbsp;short-hand new way of writi=
ng C++ code!</div>
<div>&nbsp;</div>
<div>It would make C++ code a lot more elegant on the whole, which is what =
C++11 did for C++98.</div>
<div>&nbsp;</div>
<div>Thanks for reading this!</div>
<div>&nbsp;</div>
<div>Cong Lu</div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_481_27931258.1358201340301--

.

------=_Part_761_7455157.1358201726684
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Actually, I was wondering something similar reading the lambda extension=20
proposal.

If=20
[](auto x) -> decltype(x){ return x*x; }
is allowed, then why not going for
auto calcSquare(auto x) -> decltype(x) { return x*x; }
meaning
template<typename T>
auto calcSquare(T x) -> decltype(x) { return x*x; }
?

Regards,
Robert

2013. janu=E1r 14., h=E9tf=F5 19:06:21 UTC+1 id=F5pontban Cong Lu a k=F6vet=
kez=F5t =EDrta:
>
> I'm wondering if it would be entirely out of the question to have in C++
>
>    - implicit template generation for functions=20
>    - implicit autos for variable instantiation=20
>    - implicit ->decltype(...) for functions that do not specify a return=
=20
>    type if a return statement is specified (void other wise). Given that =
we=20
>    have uniform initialisation, that wouldn't cause too many clashes?=20
>    - and in general core language support to make previously=20
>    non-compiling "Python-style" code compile.
>
> For example the function:
> add(x, y){
> return x + y;
> }
> =20
> would be automatically translated into=20
> =20
> template <typename X, typename Y>
> auto add(X x, Y y) -> decltype(x + y){
> return x + y;
> }
> =20
> Variable Instantiation:
> =20
> x =3D 7;=20
> =20
> Automatically translates to (if x is not already in scope and the=20
> statement above is an assignment)
> =20
> auto x =3D 7;
> =20
> Given that consideration is being given to polymorphic lambdas, and I=20
> heard on some video somewhere that since lambdas are being made=20
> polymorphic, why not function arguments as well? There would be no need t=
o=20
> break any code at all, this would just be an optional short-hand new way =
of=20
> writing C++ code!
> =20
> It would make C++ code a lot more elegant on the whole, which is what=20
> C++11 did for C++98.
> =20
> Thanks for reading this!
> =20
> Cong Lu
>

--=20




------=_Part_761_7455157.1358201726684
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Actually, I was wondering something similar reading the lambda extension pr=
oposal.<br><br>If <div style=3D"background-color:rgb(250,250,250);border-co=
lor:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-wo=
rd"><code><div><span style=3D"color:#660">[](</span><span style=3D"color:#0=
08">auto</span><span style=3D"color:#000"> x</span><span style=3D"color:#66=
0">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">-&=
gt;</span><span style=3D"color:#000"> </span><span style=3D"color:#008">dec=
ltype</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"> </sp=
an><span style=3D"color:#008">return</span><span style=3D"color:#000"> x</s=
pan><span style=3D"color:#660">*</span><span style=3D"color:#000">x</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span =
style=3D"color:#660">}</span></div></code></div> is allowed, then why not g=
oing for<br><div style=3D"background-color:rgb(250,250,250);border-color:rg=
b(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><c=
ode><div><span style=3D"color:#008">auto</span><span style=3D"color:#000"> =
calcSquare</span><span style=3D"color:#660">(</span><span style=3D"color:#0=
08">auto</span><span style=3D"color:#000"> x</span><span style=3D"color:#66=
0">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">-&=
gt;</span><span style=3D"color:#000"> </span><span style=3D"color:#008">dec=
ltype</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"> </spa=
n><span style=3D"color:#660">{</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#008">return</span><span style=3D"color:#000"> x</span><s=
pan style=3D"color:#660">*</span><span style=3D"color:#000">x</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">}</span><span style=3D"color:#000"><br></span></div></code>=
</div>meaning<br><div style=3D"background-color:rgb(250,250,250);border-col=
or:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-wor=
d"><code><div><span style=3D"color:#008">template</span><span style=3D"colo=
r:#660">&lt;</span><span style=3D"color:#008">typename</span><span style=3D=
"color:#000"> T</span><span style=3D"color:#660">&gt;</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#008">auto</span><span style=3D=
"color:#000"> calcSquare</span><span style=3D"color:#660">(T </span><span s=
tyle=3D"color:#000">x</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">-&gt;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">decltype</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#000">x</span><span style=3D=
"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">return</span><span style=3D"color:#000"> x</span><span style=3D"color:#6=
60">*</span><span style=3D"color:#000">x</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">}</spa=
n><span style=3D"color:#000"><br></span></div></code></div>?<br><br>Regards=
,<br>Robert<br><br>2013. janu=E1r 14., h=E9tf=F5 19:06:21 UTC+1 id=F5pontba=
n Cong Lu a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div>I'm wondering if it would be entirely out of the question to hav=
e in C++</div>
<ul>
<li>implicit template generation for functions</li>
<li>implicit autos for variable instantiation</li>
<li>implicit -&gt;decltype(...) for functions that do not specify a return =
type if a return statement is specified (void other wise). Given that we ha=
ve uniform initialisation, that wouldn't cause too many clashes?</li>
<li>and in general core language support to make previously non-compiling "=
Python-style" code compile.</li></ul>
<div>For example the function:</div>
<div>add(x, y){</div>
<div>return x + y;</div>
<div>}</div>
<div>&nbsp;</div>
<div>would be automatically translated into </div>
<div>&nbsp;</div>
<div>template &lt;typename X, typename Y&gt;</div>
<div>auto add(X x, Y y) -&gt; decltype(x + y){</div>
<div>return x + y;</div>
<div>}</div>
<div>&nbsp;</div>
<div>Variable Instantiation:</div>
<div>&nbsp;</div>
<div>x =3D 7; </div>
<div>&nbsp;</div>
<div>Automatically translates to (if x is not already in scope and the stat=
ement above is an assignment)</div>
<div>&nbsp;</div>
<div>auto x =3D 7;</div>
<div>&nbsp;</div>
<div>Given that consideration is being given to polymorphic lambdas, and I =
heard on some video somewhere that since lambdas are being made polymorphic=
, why not function arguments as well? There would be no need to break any c=
ode at all, this would just be an optional&nbsp;short-hand new way of writi=
ng C++ code!</div>
<div>&nbsp;</div>
<div>It would make C++ code a lot more elegant on the whole, which is what =
C++11 did for C++98.</div>
<div>&nbsp;</div>
<div>Thanks for reading this!</div>
<div>&nbsp;</div>
<div>Cong Lu</div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_761_7455157.1358201726684--

.

On Mon, Jan 14, 2013 at 4:15 PM, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:
> auto calcSquare(auto x) -> decltype(x) { return x*x; }

That is why I don't like the `auto` keyword used in the "generic
lambda" proposal.  In C++11, `auto` means "deducible", but the
proposal want to overload its meaning as "implicit template".

Please, consider my suggestion on the syntax, use

  =3Da, &a, and, probably, &&a,

instead of

  auto a, auto& a, auto&& a

in a generic lambda's parameter list.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=20




.

------=_Part_1450_15179477.1358204333528
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

I didn't care about the syntax here. The point was that there is a proposal=
=20
for a feature that works for lambdas, but does not for equivalent functions=
..

Robert

2013. janu=E1r 14., h=E9tf=F5 23:55:36 UTC+1 id=F5pontban Zhihao Yuan a k=
=F6vetkez=F5t=20
=EDrta:
>
> On Mon, Jan 14, 2013 at 4:15 PM, R=F3bert D=E1vid <lrd...@gmail.com<javas=
cript:>>=20
> wrote:=20
> > auto calcSquare(auto x) -> decltype(x) { return x*x; }=20
>
> That is why I don't like the `auto` keyword used in the "generic=20
> lambda" proposal.  In C++11, `auto` means "deducible", but the=20
> proposal want to overload its meaning as "implicit template".=20
>
> Please, consider my suggestion on the syntax, use=20
>
>   =3Da, &a, and, probably, &&a,=20
>
> instead of=20
>
>   auto a, auto& a, auto&& a=20
>
> in a generic lambda's parameter list.=20
>
>
> --=20
> Zhihao Yuan, ID lichray=20
> The best way to predict the future is to invent it.=20
> ___________________________________________________=20
> 4BSD -- http://4bsd.biz/=20
>

--=20




------=_Part_1450_15179477.1358204333528
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

I didn't care about the syntax here. The point was that there is a proposal=
 for a feature that works for lambdas, but does not for equivalent function=
s.<br><br>Robert<br><br>2013. janu=E1r 14., h=E9tf=F5 23:55:36 UTC+1 id=F5p=
ontban Zhihao Yuan a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">On Mon, Jan 14, 2013 at 4:15 PM, R=F3bert D=E1vid &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"-UGFkm-pARwJ">l=
rd...@gmail.com</a>&gt; wrote:
<br>&gt; auto calcSquare(auto x) -&gt; decltype(x) { return x*x; }
<br>
<br>That is why I don't like the `auto` keyword used in the "generic
<br>lambda" proposal. &nbsp;In C++11, `auto` means "deducible", but the
<br>proposal want to overload its meaning as "implicit template".
<br>
<br>Please, consider my suggestion on the syntax, use
<br>
<br>&nbsp; =3Da, &amp;a, and, probably, &amp;&amp;a,
<br>
<br>instead of
<br>
<br>&nbsp; auto a, auto&amp; a, auto&amp;&amp; a
<br>
<br>in a generic lambda's parameter list.
<br>
<br>
<br>--
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1450_15179477.1358204333528--

.

------=_Part_352_10311220.1358242782936
Content-Type: text/plain; charset=ISO-8859-1

On Monday, January 14, 2013 7:06:21 PM UTC+1, Cong Lu wrote:

> add(x, y){
> return x + y;
> }
>

That might be a bit too short. add and x might be types (already).

auto add(auto x, auto y) { return x + y; }

> Automatically translates to (if x is not already in scope and the
statement above is an assignment)

That's way too dangerous.

--




------=_Part_352_10311220.1358242782936
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, January 14, 2013 7:06:21 PM UTC+1, Cong Lu wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div>add(x, y){<br></div>
<div>return x + y;</div>
<div>}</div></blockquote><div><br></div><div>That might be a bit too short.=
 add and x might be types (already).</div><div><br></div><div>auto add(auto=
 x, auto y) { return x + y; }&nbsp;</div><div><br></div><div>&gt;&nbsp;Auto=
matically translates to (if x is not already in scope and the statement abo=
ve is an assignment)</div><div><br></div><div>That's way too dangerous.</di=
v>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_352_10311220.1358242782936--

.

------=_Part_405_11046303.1358271527896
Content-Type: text/plain; charset=ISO-8859-1

I seems to me that in all these proposals for polymorphic lambdas etc, the
keyword autos gets sprinkled all over the place, I realize that it is
essential to prevent clashes and a whole host of errors but it seems
extremely verbose for something that should by its very own nature let the
compiler do the work for you.

--




------=_Part_405_11046303.1358271527896
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I seems to me that in all these proposals for polymorphic lambdas etc, the =
keyword autos gets sprinkled all over the place, I realize that it is essen=
tial to prevent clashes and a whole host of errors but it seems extremely v=
erbose for something that should by its very own nature let the compiler do=
 the work for you.

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_405_11046303.1358271527896--

.

------=_Part_1545_22252534.1358291067741
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

This topic is a matter of personal taste, so this is not an argument, just=
=20
an expression of opinion.

I actually like the auto version of the lambda better because I find it=20
more readable:
[&a](&b){a&b;}
makes my eyes bleed due to lack of structure, but
[&a](auto& b){a&b;}
shows perfectly where new (parameter) declarations are. Also tells they are=
=20
"automatically deduced" (ok, implicit template, but from a practical point=
=20
of view it is deduced on usage), so I don't agree with Yuan. I would even=
=20
keep return to make it show where the "code" is.

You rarely have a type name that has less character than "auto" (let's see:=
=20
int, and.. nothing else), so it is still hundred times better than anything=
=20
you have now. I say having to type 3 or 4 more characters (what will be=20
automatic after a time, if you allow me this pun) worth ending up with a=20
code that is better readable and does not scare new users right away.

2013. janu=E1r 15., kedd 18:38:47 UTC+1 id=F5pontban Cong Lu a k=F6vetkez=
=F5t =EDrta:
>
> I seems to me that in all these proposals for polymorphic lambdas etc, th=
e=20
> keyword autos gets sprinkled all over the place, I realize that it is=20
> essential to prevent clashes and a whole host of errors but it seems=20
> extremely verbose for something that should by its very own nature let th=
e=20
> compiler do the work for you.

--=20




------=_Part_1545_22252534.1358291067741
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

This topic is a matter of personal taste, so this is not an argument, just =
an expression of opinion.<br><br>I actually like the auto version of the la=
mbda better because I find it more readable:<br><div class=3D"prettyprint" =
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, =
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><code=
 class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: =
#660;" class=3D"styled-by-prettify">[&amp;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">](&amp;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">b</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">){</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;}</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></d=
iv>makes my eyes bleed due to lack of structure, but<br><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #660;" class=3D"styled-by-prettify">[&amp;</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: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">){</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">b</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div>show=
s perfectly where new (parameter) declarations are. Also tells they are "au=
tomatically deduced" (ok, implicit template, but from a practical point of =
view it is deduced on usage), so I don't agree with Yuan. I would even keep=
 <span style=3D"font-family: courier new,monospace;">return</span> to make =
it show where the "code" is.<br><br>You rarely have a type name that has le=
ss character than "<span style=3D"font-family: courier new,monospace;">auto=
</span>"=20
(let's see: <span style=3D"font-family: courier new,monospace;">int</span>,=
 and.. nothing else), so it is still hundred times better than
anything you have now. I say having to type 3 or 4 more characters (what wi=
ll be automatic after a time, if you allow me this pun) worth ending up wit=
h a code that is better readable and does not scare new users right away.<b=
r><br>2013. janu=E1r 15., kedd 18:38:47 UTC+1 id=F5pontban Cong Lu a k=F6ve=
tkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I seems to me =
that in all these proposals for polymorphic lambdas etc, the keyword autos =
gets sprinkled all over the place, I realize that it is essential to preven=
t clashes and a whole host of errors but it seems extremely verbose for som=
ething that should by its very own nature let the compiler do the work for =
you.</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1545_22252534.1358291067741--

.

On Tue, Jan 15, 2013 at 5:04 PM, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:
> [&a](auto& b){a&b;}
> shows perfectly where new (parameter) declarations are.

The C++11 `auto` type-specifier can not be used in a declaration.  For
example,

  auto a;  // storage-class-specifier
  a =3D make_shared(...); // won't work

The syntax

  auto a =3D expr;

is a special rule to trigger deduction, which is meaningless to a
function parameter.  Overloading its meaning is misleading.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=20




.

--0015175d07827fdba504d35c25db
Content-Type: text/plain; charset=ISO-8859-1

On 15 January 2013 17:20, Zhihao Yuan <lichray@gmail.com> wrote:

> The C++11 `auto` type-specifier can not be used in a declaration.  For
> example,
>
>   auto a;  // storage-class-specifier
>

Not in C++11.  See n3485 C1.6 section 7.1.6.4.


> The syntax
>
>   auto a = expr;
>
> is a special rule to trigger deduction, which is meaningless to a
> function parameter.  Overloading its meaning is misleading.
>

Well, it is already overloaded for trailing return types:

auto foo() -> int;

This is for the future; (the collective) we can do whatever we think is
right for the language.  The choices seem to be some combination of
nothing, keyword, non-identifier character, or funky syntax.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




--0015175d07827fdba504d35c25db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 15 January 2013 17:20, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"mail=
to:lichray@gmail.com" target=3D"_blank">lichray@gmail.com</a>&gt;</span> wr=
ote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">The C++11 `auto` type-specifier can not be used in a decl=
aration. =A0For</div>
example,<br>
<br>
=A0 auto a; =A0// storage-class-specifier<br></blockquote><div><br></div><d=
iv>Not in C++11. =A0See n3485 C1.6 section 7.1.6.4.</div><div>=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">

The syntax<br>
<br>
=A0 auto a =3D expr;<br>
<br>
is a special rule to trigger deduction, which is meaningless to a<br>
function parameter. =A0Overloading its meaning is misleading.<br></blockquo=
te><div><br></div><div>Well, it is already overloaded for trailing return t=
ypes:</div><div><br></div><div>auto foo() -&gt; int;</div><div><br></div>

<div>This is for the future; (the collective) we can do whatever we think i=
s right for the language. =A0The choices seem to be some combination of not=
hing, keyword, non-identifier character, or funky syntax.</div></div>-- <br=
>

=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1=
404

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--0015175d07827fdba504d35c25db--

.

------=_Part_606_24777029.1358292792291
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Tuesday, January 15, 2013 3:04:27 PM UTC-8, R=F3bert D=E1vid wrote:
>
> This topic is a matter of personal taste, so this is not an argument, jus=
t=20
> an expression of opinion.
>

Not really. Name another (statically typed) language that offers=20
polymorphic lambdas that require a specific typename/keyword/etc to mean "I=
=20
take anything".

If C++ goes this route, I'm fairly sure that it will be the only language=
=20
to do so. C# lambdas don't, even though it's a statically typed language=20
like C++.

The *primary* argument for needing `auto` here is the syntactic needs of=20
the parser, not personal preference. And some have suggested alternate=20
syntax that is equally as effective parser-wise. I personally like the idea=
=20
of simply detecting `&a`, `const&a`, `&&a`, `const &&a`, with `=3Da` for=20
value types.

--=20




------=_Part_606_24777029.1358292792291
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, January 15, 2013 3:04:27 PM UTC-8, R=F3bert D=E1vid wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">This topic is a matter of p=
ersonal taste, so this is not an argument, just an expression of opinion.<b=
r></blockquote><div><br>Not really. Name another (statically typed) languag=
e that offers polymorphic lambdas that require a specific typename/keyword/=
etc to mean "I take anything".<br><br>If C++ goes this route, I'm fairly su=
re that it will be the only language to do so. C# lambdas don't, even thoug=
h it's a statically typed language like C++.</div><br>The <i>primary</i> ar=
gument for needing `auto` here is the syntactic needs of the parser, not pe=
rsonal preference. And some have suggested alternate syntax that is equally=
 as effective parser-wise. I personally like the idea of simply detecting `=
&amp;a`, `const&amp;a`, `&amp;&amp;a`, `const &amp;&amp;a`, with `=3Da` for=
 value types.<br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_606_24777029.1358292792291--

.

On Tue, Jan 15, 2013 at 5:29 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> auto foo() -> int;

So should I also include `if (auto a = expr)`,
`while (auto a = expr)`, etc.?  My point is simple:  All of these are
based on deduction, so please don't not add something completely
irrelevant just for convenience, and it's not convenient actually,
compared with =a, &a, etc.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--




.

------=_Part_383_28216447.1358301041760
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

2013. janu=E1r 16., szerda 0:33:12 UTC+1 id=F5pontban Nicol Bolas a k=F6vet=
kez=F5t=20
=EDrta:
>
>
>
> On Tuesday, January 15, 2013 3:04:27 PM UTC-8, R=F3bert D=E1vid wrote:
>>
>> This topic is a matter of personal taste, so this is not an argument,=20
>> just an expression of opinion.
>>
>
> Not really. Name another (statically typed) language that offers=20
> polymorphic lambdas that require a specific typename/keyword/etc to mean =
"I=20
> take anything".
>
> If C++ goes this route, I'm fairly sure that it will be the only language=
=20
> to do so. C# lambdas don't, even though it's a statically typed language=
=20
> like C++.
>

C++ is the only language (at least from the big ones) with move semantics.=
=20
Does this make move semantics bad?
=20

>
> The *primary* argument for needing `auto` here is the syntactic needs of=
=20
> the parser, not personal preference. And some have suggested alternate=20
> syntax that is equally as effective parser-wise. I personally like the id=
ea=20
> of simply detecting `&a`, `const&a`, `&&a`, `const &&a`, with `=3Da` for=
=20
> value types.
>

Of course one needs *some* syntax for it. The "personal taste" in my=20
previous point goes to whether "auto& a" or "&a" (or anything else) is=20
preferred, and expressed my thoughts why the first. I'm yet to see an=20
argument for the second, apart from "I like it more".

Regards, Robert

--=20




------=_Part_383_28216447.1358301041760
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

2013. janu=E1r 16., szerda 0:33:12 UTC+1 id=F5pontban Nicol Bolas a k=F6vet=
kez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Tues=
day, January 15, 2013 3:04:27 PM UTC-8, R=F3bert D=E1vid wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">This topic is a matter of personal taste, so th=
is is not an argument, just an expression of opinion.<br></blockquote><div>=
<br>Not really. Name another (statically typed) language that offers polymo=
rphic lambdas that require a specific typename/keyword/etc to mean "I take =
anything".<br><br>If C++ goes this route, I'm fairly sure that it will be t=
he only language to do so. C# lambdas don't, even though it's a statically =
typed language like C++.</div></blockquote><div><br>C++ is the only languag=
e (at least from the big ones) with move semantics. Does this make move sem=
antics bad?<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br=
>The <i>primary</i> argument for needing `auto` here is the syntactic needs=
 of the parser, not personal preference. And some have suggested alternate =
syntax that is equally as effective parser-wise. I personally like the idea=
 of simply detecting `&amp;a`, `const&amp;a`, `&amp;&amp;a`, `const &amp;&a=
mp;a`, with `=3Da` for value types.<br></blockquote><div><br>Of course one =
needs <i>some</i> syntax for it. The "personal taste" in my previous point =
goes to whether "auto&amp; a" or "&amp;a" (or anything else) is preferred, =
and expressed my thoughts why the first. I'm yet to see an argument for the=
 second, apart from "I like it more".<br><br>Regards, Robert<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_383_28216447.1358301041760--

.

------=_Part_1592_31659087.1358301056844
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

2013. janu=E1r 16., szerda 0:39:46 UTC+1 id=F5pontban Zhihao Yuan a k=F6vet=
kez=F5t=20
=EDrta:
>
> On Tue, Jan 15, 2013 at 5:29 PM, Nevin Liber <ne...@eviloverlord.com<java=
script:>>=20
> wrote:=20
> > auto foo() -> int;=20
>
> So should I also include `if (auto a =3D expr)`,=20
> `while (auto a =3D expr)`, etc.?  My point is simple:  All of these are=
=20
> based on deduction, so please don't not add something completely=20
> irrelevant just for convenience, and it's not convenient actually,=20
> compared with =3Da, &a, etc.=20
>

It is more convenient *to you*. For me, having auto is the more convenient=
=20
(as it ease readability, and every code is written once but read multiple=
=20
times). And that's why I said this is borderline of personal taste.

Regards,
Robert

--=20




------=_Part_1592_31659087.1358301056844
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

2013. janu=E1r 16., szerda 0:39:46 UTC+1 id=F5pontban Zhihao Yuan a k=F6vet=
kez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Jan 15,=
 2013 at 5:29 PM, Nevin Liber &lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"k1L7o4-0l1cJ">ne...@eviloverlord.com</a>&gt; wrot=
e:
<br>&gt; auto foo() -&gt; int;
<br>
<br>So should I also include `if (auto a =3D expr)`,
<br>`while (auto a =3D expr)`, etc.? &nbsp;My point is simple: &nbsp;All of=
 these are
<br>based on deduction, so please don't not add something completely
<br>irrelevant just for convenience, and it's not convenient actually,
<br>compared with =3Da, &amp;a, etc.
<br></blockquote><div><br>It is more convenient <u><b>to you</b></u>. For m=
e, having auto is the=20
more convenient (as it ease readability, and every code is written once=20
but read multiple times). And that's why I said this is borderline of=20
personal taste.<br><br>Regards,<br>Robert</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1592_31659087.1358301056844--

.

------=_Part_889_12747761.1358305850084
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



On Tuesday, January 15, 2013 5:50:41 PM UTC-8, R=F3bert D=E1vid wrote:
>
> 2013. janu=E1r 16., szerda 0:33:12 UTC+1 id=F5pontban Nicol Bolas a k=F6v=
etkez=F5t=20
> =EDrta:
>>
>>
>>
>> On Tuesday, January 15, 2013 3:04:27 PM UTC-8, R=F3bert D=E1vid wrote:
>>>
>>> This topic is a matter of personal taste, so this is not an argument,=
=20
>>> just an expression of opinion.
>>>
>>
>> Not really. Name another (statically typed) language that offers=20
>> polymorphic lambdas that require a specific typename/keyword/etc to mean=
 "I=20
>> take anything".
>>
>> If C++ goes this route, I'm fairly sure that it will be the only languag=
e=20
>> to do so. C# lambdas don't, even though it's a statically typed language=
=20
>> like C++.
>>
>
> C++ is the only language (at least from the big ones) with move semantics=
..=20
> Does this make move semantics bad?
>

C++ has move semantics because C++ has *value* semantics (which most other=
=20
languages don't), so it's a false analogy. C++ has typenames for arguments=
=20
because C++ is statically typed. C# has typenames for arguments because=20
it's statically typed too. Thus, it's reasonable to compare them, and=20
reasonable to make inferences based on how they handle typeless lambda=20
arguments.

The *primary* argument for needing `auto` here is the syntactic needs of=20
>> the parser, not personal preference. And some have suggested alternate=
=20
>> syntax that is equally as effective parser-wise. I personally like the i=
dea=20
>> of simply detecting `&a`, `const&a`, `&&a`, `const &&a`, with `=3Da` for=
=20
>> value types.
>>
>
> Of course one needs *some* syntax for it. The "personal taste" in my=20
> previous point goes to whether "auto& a" or "&a" (or anything else) is=20
> preferred, and expressed my thoughts why the first. I'm yet to see an=20
> argument for the second, apart from "I like it more".
>

And the argument I made above: every other language does it that way. And=
=20
the fact that it's more compact.

The syntax being compact is true. The `auto` syntax being something that=20
even other statically typed languages don't do is a fact. That you find one=
=20
more "readable" is ultimately an opinion, and one primarily based on how=20
used you are to reading "(Typename Decorator ArgumentName, Typename=20
Decorator ArgumentName)". As someone who has both dynamic and static=20
languages in his background, neither is *a priori* more "readable" than the=
=20
other to me.

That the syntax should be as compact as possible or that it should conform=
=20
to established norms is an opinion, yes. But at the end of the day, it's a=
=20
very reasonable opinion: if C++ is going to take the untraveled in terms of=
=20
having `auto` here, then it should do so for well-defined reasons (like=20
syntactic issues and so forth). Not because some C++ users find it more=20
"readable".

--=20




------=_Part_889_12747761.1358305850084
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, January 15, 2013 5:50:41 PM UTC-8, R=F3bert D=E1vid wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">2013. janu=E1r 16., szerda =
0:33:12 UTC+1 id=F5pontban Nicol Bolas a k=F6vetkez=F5t =EDrta:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><br><br>On Tuesday, January 15, 2013 3:04:27 PM=
 UTC-8, R=F3bert D=E1vid wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">This=
 topic is a matter of personal taste, so this is not an argument, just an e=
xpression of opinion.<br></blockquote><div><br>Not really. Name another (st=
atically typed) language that offers polymorphic lambdas that require a spe=
cific typename/keyword/etc to mean "I take anything".<br><br>If C++ goes th=
is route, I'm fairly sure that it will be the only language to do so. C# la=
mbdas don't, even though it's a statically typed language like C++.</div></=
blockquote><div><br>C++ is the only language (at least from the big ones) w=
ith move semantics. Does this make move semantics bad?<br></div></blockquot=
e><div><br>C++ has move semantics because C++ has <i>value</i> semantics (w=
hich most other languages don't), so it's a false analogy. C++ has typename=
s for arguments because C++ is statically typed. C# has typenames for argum=
ents because it's statically typed too. Thus, it's reasonable to compare th=
em, and reasonable to make inferences based on how they handle typeless lam=
bda arguments.<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">The <i>primary</i> argumen=
t for needing `auto` here is the syntactic needs of the parser, not persona=
l preference. And some have suggested alternate syntax that is equally as e=
ffective parser-wise. I personally like the idea of simply detecting `&amp;=
a`, `const&amp;a`, `&amp;&amp;a`, `const &amp;&amp;a`, with `=3Da` for valu=
e types.<br></blockquote><div><br>Of course one needs <i>some</i> syntax fo=
r it. The "personal taste" in my previous point goes to whether "auto&amp; =
a" or "&amp;a" (or anything else) is preferred, and expressed my thoughts w=
hy the first. I'm yet to see an argument for the second, apart from "I like=
 it more".<br></div></blockquote><div><br>And the argument I made above: ev=
ery other language does it that way. And the fact that it's more compact.<b=
r><br>The syntax being compact is true. The `auto` syntax being something t=
hat even other statically typed languages don't do is a fact. That you find=
 one more "readable" is ultimately an opinion, and one primarily based on h=
ow used you are to reading "(Typename Decorator ArgumentName, Typename Deco=
rator ArgumentName)". As someone who has both dynamic and static languages =
in his background, neither is <i>a priori</i> more "readable" than the othe=
r to me.<br><br>That the syntax should be as compact as possible or that it=
 should conform to established norms is an opinion, yes. But at the end of =
the day, it's a very reasonable opinion: if C++ is going to take the untrav=
eled in terms of having `auto` here, then it should do so for well-defined =
reasons (like syntactic issues and so forth). Not because some C++ users fi=
nd it more "readable".<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_889_12747761.1358305850084--

.

------=_Part_214_8535131.1358343875865
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Tuesday, January 15, 2013 11:33:12 PM UTC, Nicol Bolas wrote:
>
>
>
> On Tuesday, January 15, 2013 3:04:27 PM UTC-8, R=F3bert D=E1vid wrote:
>>
>> This topic is a matter of personal taste, so this is not an argument,=20
>> just an expression of opinion.
>>
>
> Not really. Name another (statically typed) language that offers=20
> polymorphic lambdas that require a specific typename/keyword/etc to mean =
"I=20
> take anything".
>
> If C++ goes this route, I'm fairly sure that it will be the only language=
=20
> to do so. C# lambdas don't, even though it's a statically typed language=
=20
> like C++.
>

GHC Haskell supports higher-rank polymorphism, it supports N-rank types:

http://en.wikibooks.org/wiki/Haskell/Polymorphism#Higher_rank_types

--=20




------=_Part_214_8535131.1358343875865
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, January 15, 2013 11:33:12 PM UTC, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Tuesday, January 15, 2=
013 3:04:27 PM UTC-8, R=F3bert D=E1vid wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">This topic is a matter of personal taste, so this is not an argum=
ent, just an expression of opinion.<br></blockquote><div><br>Not really. Na=
me another (statically typed) language that offers polymorphic lambdas that=
 require a specific typename/keyword/etc to mean "I take anything".<br><br>=
If C++ goes this route, I'm fairly sure that it will be the only language t=
o do so. C# lambdas don't, even though it's a statically typed language lik=
e C++.</div></blockquote><div><br>GHC Haskell supports higher-rank polymorp=
hism, it supports N-rank types:<br><br>http://en.wikibooks.org/wiki/Haskell=
/Polymorphism#Higher_rank_types<br><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_214_8535131.1358343875865--

.

------=_Part_123_17830950.1358345821768
Content-Type: text/plain; charset=ISO-8859-1



> C++ is the only language (at least from the big ones) with move semantics.
>> Does this make move semantics bad?
>>
>
> C++ has move semantics because C++ has *value* semantics (which most
> other languages don't), so it's a false analogy. C++ has typenames for
> arguments because C++ is statically typed. C# has typenames for arguments
> because it's statically typed too. Thus, it's reasonable to compare them,
> and reasonable to make inferences based on how they handle typeless lambda
> arguments.
>

Point is, "if a proposal makes something that is done only by C++ then it
is probably bad" is not a good argument, because C++ already does something
others don't: value and move semantics. If we do this "one only thing"
right, we just added another strength.

But again, this is personal taste. I like version a, better, you like b, .
Also, can't we explore the case to have both? That way, typename being
optional, and meaning "auto" if missing.

Regards, Robert

--




------=_Part_123_17830950.1358345821768
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div>C++ is the only language (at least from the big ones) wi=
th move semantics. Does this make move semantics bad?<br></div></blockquote=
><div><br>C++ has move semantics because C++ has <i>value</i> semantics (wh=
ich most other languages don't), so it's a false analogy. C++ has typenames=
 for arguments because C++ is statically typed. C# has typenames for argume=
nts because it's statically typed too. Thus, it's reasonable to compare the=
m, and reasonable to make inferences based on how they handle typeless lamb=
da arguments.<br></div></blockquote><div><br>Point is, "if a proposal makes=
 something that is done only by C++ then it is probably bad" is not a good =
argument, because C++ already does something others don't: value and move s=
emantics. If we do this "one only thing" right, we just added another stren=
gth.<br><br>But again, this is personal taste. I like version a, better, yo=
u like b, . Also, can't we explore the case to have both? That way, typenam=
e being optional, and meaning "auto" if missing.<br><br>Regards, Robert<br>=
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_123_17830950.1358345821768--

.

------=_Part_67_30213469.1358364074105
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wednesday, January 16, 2013 6:17:01 AM UTC-8, R=F3bert D=E1vid wrote:
>
>
> C++ is the only language (at least from the big ones) with move semantics=
..=20
>>> Does this make move semantics bad?
>>>
>>
>> C++ has move semantics because C++ has *value* semantics (which most=20
>> other languages don't), so it's a false analogy. C++ has typenames for=
=20
>> arguments because C++ is statically typed. C# has typenames for argument=
s=20
>> because it's statically typed too. Thus, it's reasonable to compare them=
,=20
>> and reasonable to make inferences based on how they handle typeless lamb=
da=20
>> arguments.
>>
>
> Point is, "if a proposal makes something that is done only by C++ then it=
=20
> is probably bad" is not a good argument, because C++ already does somethi=
ng=20
> others don't: value and move semantics. If we do this "one only thing"=20
> right, we just added another strength.
>

That wasn't my argument. My argument was "other languages with similar=20
characteristics to C++ do not need filler for the typename, so C++ should=
=20
not either." C++ needs move semantics because C++ uses value semantics (and=
=20
lacks GC), and thus C++ needs to have a way to express transfer of=20
ownership.

If you're going to make your argument, then you should be able to point to=
=20
some specific difference between C++ and (for example) C# that makes having=
=20
typename filler *necessary*. Not merely "I like it better that way," but=20
essential to implementing the feature.

Because the default state should be to do things the way other languages do=
=20
them, as this is existing standard practice. That argument has nothing to=
=20
do with personal preference; it's simply the principle of least surprise.

--=20




------=_Part_67_30213469.1358364074105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, January 16, 2013 6:17:01 AM UTC-8, R=F3bert D=E1vid w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><br><blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>C++ is the =
only language (at least from the big ones) with move semantics. Does this m=
ake move semantics bad?<br></div></blockquote><div><br>C++ has move semanti=
cs because C++ has <i>value</i> semantics (which most other languages don't=
), so it's a false analogy. C++ has typenames for arguments because C++ is =
statically typed. C# has typenames for arguments because it's statically ty=
ped too. Thus, it's reasonable to compare them, and reasonable to make infe=
rences based on how they handle typeless lambda arguments.<br></div></block=
quote><div><br>Point is, "if a proposal makes something that is done only b=
y C++ then it is probably bad" is not a good argument, because C++ already =
does something others don't: value and move semantics. If we do this "one o=
nly thing" right, we just added another strength.<br></div></blockquote><di=
v><br>That wasn't my argument. My argument was "other languages with simila=
r characteristics to C++ do not need filler for the typename, so C++ should=
 not either." C++ needs move semantics because C++ uses value semantics (an=
d lacks GC), and thus C++ needs to have a way to express transfer of owners=
hip.<br><br>If you're going to make your argument, then you should be able =
to point to some specific difference between C++ and (for example) C# that =
makes having typename filler <i>necessary</i>. Not merely "I like it better=
 that way," but essential to implementing the feature.<br><br>Because the d=
efault state should be to do things the way other languages do them, as thi=
s is existing standard practice. That argument has nothing to do with perso=
nal preference; it's simply the principle of least surprise.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_67_30213469.1358364074105--

.

On 01/16/2013 08:21 PM, Nicol Bolas wrote:
> Because the default state should be to do things the way other
> languages do them, as this is existing standard practice.

Regardless of the perceived need for some filler keyword in C++
or other languages, I get worried when reading a sentence like that.

There are a bunch of languages that could be described as
"extensions of C", among them C++, Java, C#.  All of them have
made some decisions to deviate from the C syntax, sometimes to
support new features, sometimes to ease the syntax a little,
sometimes to restrict the feature set for various reasons.
For example, array declarations in Java can be "int x[5]" or
"int[5] x", if I remember correctly.  Also, Java does not have
a syntax such as "int *p".

Therefore, I think other languages can give us ideas which
semantics might be useful, or even an idea about the syntax,
but it is nonetheless a valid argument to say that the syntax
should be different in C++ compared to that other language,
simply due to the inherent differences in overall language
design decisions in those languages.  It's the totality of
syntax and semantics that needs to fit together, and that
goal might be in conflict with taking over specific syntax
from some other language.

Specifically, C++ doesn't do "implicit int".  Any time a
variable is declared (i.e. a name for an object is introduced),
there is at least some syntax to indicate the type.  Occasionally,
it's "auto" or some template parameter, but there is always more
than nothing.   That feels at least like some precedence relative
to which a deviation for the lambda case needs to be carefully
considered.  I agree there are good arguments on both sides,
but referring to "existing standard practice" is just one of them,
not a slam dunk.

And btw, which ISO standard are we talking about when referring to
"existing standard practice"?

Jens

--




.

On Wed, Jan 16, 2013 at 3:53 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> On 01/16/2013 08:21 PM, Nicol Bolas wrote:
>> Because the default state should be to do things the way other
>> languages do them, as this is existing standard practice.
>
> Regardless of the perceived need for some filler keyword in C++
> or other languages, I get worried when reading a sentence like that.
>
> There are a bunch of languages that could be described as
> "extensions of C", among them C++, Java, C#.  All of them have
> made some decisions to deviate from the C syntax, sometimes to
> support new features, sometimes to ease the syntax a little,
> sometimes to restrict the feature set for various reasons.

And I think the biggest lesson from them is that even if the
extensions are "compatible" with C/C++, they often end up limiting
other (better?) extensions in the future.

So not only do we need to weigh how it fits into existing practice,
but how it will fit into future practice.  Sounds impossible (predict
the future...), but we do know that the more you veer from existing
practice, the more likely you are to close doors that were not
otherwise closed.

(see, for example, how Objective-C's named-parameters are affecting
our choices for string-literal suffixes and other seemingly unrelated
things)

Tony

--




.