------=_Part_333_27856979.1355807910580
Content-Type: text/plain; charset=ISO-8859-1

That looks great!  What is the status of the proposal?

As soon as time permits I plan to test out the implementation.

Thanks,
Andrew Sandoval

--




------=_Part_333_27856979.1355807910580
Content-Type: text/html; charset=ISO-8859-1

That looks great!&nbsp; What is the status of the proposal?<br><br>As soon as time permits I plan to test out the implementation.<br><br>Thanks,<br>Andrew Sandoval<br>

<p></p>

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

------=_Part_333_27856979.1355807910580--

.

------=_Part_46_3391498.1355845851035
Content-Type: text/plain; charset=ISO-8859-1

The `auto` is required is disambiguate this:

[] (a) {}

Is `a` an automatically-typed variable or an unnamed argument with the type
`a`?

On Monday, December 17, 2012 3:38:25 PM UTC-7, dain...@gmail.com wrote:
>
> Cool :)
>
>  Why is "auto" required though? It seems like it would work fine without
> the keyword..?
>
>
>

--




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

The `auto` is required is disambiguate this:<br><br>[] (a) {}<br><br>Is `a`=
 an automatically-typed variable or an unnamed argument with the type `a`?<=
br><br>On Monday, December 17, 2012 3:38:25 PM UTC-7, dain...@gmail.com wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">Cool :)<div><br></div><div>=
&nbsp;Why is "auto" required though? It seems like it would work fine witho=
ut the keyword..?</div><div><br></div><div><br></div></blockquote>

<p></p>

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

------=_Part_46_3391498.1355845851035--

.

On Tue, Dec 18, 2012 at 12:50 PM,  <travis@solidfire.com> wrote:
> The `auto` is required is disambiguate this:
>
> [] (a) {}
>
> Is `a` an automatically-typed variable or an unnamed argument with the type
> `a`?
>
Really?

Not according to the relevant paper:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf

Where it specifically says that auto is NOT allowed (not just not
required), which necessarily disallows unnamed parameters precisely to
avoid the ambiguity.

Has this changed? I like it better without auto FWIW

Best

--




.

------=_Part_253_13334830.1356021341786
Content-Type: text/plain; charset=ISO-8859-1

Not according to the relevant paper:

>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf
>
> Where it specifically says that auto is NOT allowed (not just not
> required), which necessarily disallows unnamed parameters precisely to
> avoid the ambiguity.
>
> Has this changed? I like it better without auto FWIW
>

Hasn't changed, just didn't realize that caveat: "A consequence of this
decision is that generic lambdas do not support unnamed parameters."

--




------=_Part_253_13334830.1356021341786
Content-Type: text/html; charset=ISO-8859-1

Not according to the relevant paper:&nbsp;<br><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf" target="_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2012/<wbr>n3418.pdf</a>
<br>
<br>Where it specifically says that auto is NOT allowed (not just not
<br>required), which necessarily disallows unnamed parameters precisely to
<br>avoid the ambiguity.
<br>
<br>Has this changed? I like it better without auto FWIW
<br></blockquote><div><br></div><div>Hasn't changed, just didn't realize that caveat:&nbsp;"A consequence of this decision is that generic lambdas do not support unnamed&nbsp;parameters."&nbsp;</div>

<p></p>

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

------=_Part_253_13334830.1356021341786--

.

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

Note that this proposal is still in progress, and is changing based on EWG =
input.

In particular, in Portland there was considerable concern from Bjarne in pa=
rticular about the "overly terse" form, such as []( &a ) as a synonym for [=
]( auto& a ), mainly on the grounds that:

*         If we adopt concept-like template constraints in the future we wa=
nt to write things like []( iterator a ) and allowing dropping the 'auto' n=
ow potentially could make people lazy and disincentivized to insert the con=
cept/constraint name in the future.

*         As noted, it means we can't have unnamed parameters for lambdas, =
which for better or worse are allowed everywhere else and so would be incon=
sistent with the rest of the language.

I still think there's real demand for the terse form that doesn't require '=
auto', but there is a design tension here that we're still working out.

Herb


From: Travis Gockel [mailto:travis@gockelhut.com]
Sent: Thursday, December 20, 2012 8:36 AM
To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: An implementation of Generic lambdas (Requ=
est for feedback)

Not according to the relevant paper:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf

Where it specifically says that auto is NOT allowed (not just not
required), which necessarily disallows unnamed parameters precisely to
avoid the ambiguity.

Has this changed? I like it better without auto FWIW

Hasn't changed, just didn't realize that caveat: "A consequence of this dec=
ision is that generic lambdas do not support unnamed parameters."
--



--=20




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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
 {font-family:Wingdings;
 panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
 {font-family:Wingdings;
 panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
 {font-family:Calibri;
 panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
 {font-family:Tahoma;
 panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
 {margin:0in;
 margin-bottom:.0001pt;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
 {mso-style-priority:99;
 color:blue;
 text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
 {mso-style-priority:99;
 color:purple;
 text-decoration:underline;}
p
 {mso-style-priority:99;
 mso-margin-top-alt:auto;
 margin-right:0in;
 mso-margin-bottom-alt:auto;
 margin-left:0in;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
 {mso-style-priority:34;
 margin-top:0in;
 margin-right:0in;
 margin-bottom:0in;
 margin-left:.5in;
 margin-bottom:.0001pt;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
span.EmailStyle18
 {mso-style-type:personal-reply;
 font-family:"Calibri","sans-serif";
 color:#1F497D;}
..MsoChpDefault
 {mso-style-type:export-only;
 font-family:"Calibri","sans-serif";}
@page WordSection1
 {size:8.5in 11.0in;
 margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
 {page:WordSection1;}
/* List Definitions */
@list l0
 {mso-list-id:1020740573;
 mso-list-type:hybrid;
 mso-list-template-ids:1502095464 67698689 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l0:level1
 {mso-level-number-format:bullet;
 mso-level-text:\F0B7;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Symbol;}
@list l0:level2
 {mso-level-number-format:bullet;
 mso-level-text:o;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:"Courier New";}
@list l0:level3
 {mso-level-number-format:bullet;
 mso-level-text:\F0A7;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Wingdings;}
@list l0:level4
 {mso-level-number-format:bullet;
 mso-level-text:\F0B7;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Symbol;}
@list l0:level5
 {mso-level-number-format:bullet;
 mso-level-text:o;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:"Courier New";}
@list l0:level6
 {mso-level-number-format:bullet;
 mso-level-text:\F0A7;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Wingdings;}
@list l0:level7
 {mso-level-number-format:bullet;
 mso-level-text:\F0B7;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Symbol;}
@list l0:level8
 {mso-level-number-format:bullet;
 mso-level-text:o;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:"Courier New";}
@list l0:level9
 {mso-level-number-format:bullet;
 mso-level-text:\F0A7;
 mso-level-tab-stop:none;
 mso-level-number-position:left;
 text-indent:-.25in;
 font-family:Wingdings;}
ol
 {margin-bottom:0in;}
ul
 {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Note that this proposal i=
s still in progress, and is changing based on EWG input.<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In particular, in Portlan=
d there was considerable concern from Bjarne in particular about the &#8220=
;overly terse&#8221; form, such as []( &amp;a ) as a synonym for []( auto&a=
mp;
 a ), mainly on the grounds that:<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:Sy=
mbol;color:#1F497D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"=
font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">If we adopt conce=
pt-like template constraints in the future we want to write things like [](=
 iterator a ) and allowing dropping the &#8216;auto&#8217; now potentially
 could make people lazy and disincentivized to insert the concept/constrain=
t name in the future.<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:Sy=
mbol;color:#1F497D"><span style=3D"mso-list:Ignore">&middot;<span style=3D"=
font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">As noted, it mean=
s we can&#8217;t have unnamed parameters for lambdas, which for better or w=
orse are allowed everywhere else and so would be inconsistent
 with the rest of the language.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I still think there&#8217=
;s real demand for the terse form that doesn&#8217;t require &#8216;auto&#8=
217;, but there is a design tension here that we&#8217;re still working out=
..<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Herb<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Travis G=
ockel [mailto:travis@gockelhut.com]
<br>
<b>Sent:</b> Thursday, December 20, 2012 8:36 AM<br>
<b>To:</b> std-proposals@isocpp.org<br>
<b>Subject:</b> Re: [std-proposals] Re: An implementation of Generic lambda=
s (Request for feedback)<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Not according to the relevant paper:&nbsp;<o:p></o:p=
></p>
<p class=3D"MsoNormal"><br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pd=
f" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
2/n3418.pdf</a>
<br>
<br>
Where it specifically says that auto is NOT allowed (not just not <br>
required), which necessarily disallows unnamed parameters precisely to <br>
avoid the ambiguity. <br>
<br>
Has this changed? I like it better without auto FWIW <o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Hasn't changed, just didn't realize that caveat:&nbs=
p;&quot;A consequence of this decision is that generic lambdas do not suppo=
rt unnamed&nbsp;parameters.&quot;&nbsp;<o:p></o:p></p>
</div>
<p class=3D"MsoNormal">-- <br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<o:p></o:p></p>
</div>
</div>
</body>
</html>

<p></p>

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

--_000_fcf0c5a9c44b44978db008de5142d0b7BN1PR03MB086namprd03pro_--

.

------=_Part_214_28441934.1356027378884
Content-Type: text/plain; charset=ISO-8859-1

Absolutely fantastic! A few things on interest:

I had not realized this syntax supports nesting:

auto compose = []( auto f, auto g )
    [=]( auto x ) f( g(x) );

auto curry3 =
   []( auto f )
       [=](auto x) [=](auto y) [=](auto z)
           f(x,y,z);


And variadic lambdas, too! Very nice.
But I wonder why we couldn't...

auto f = []( auto _f ) [](auto ...x) _f(x...);

I wrote some tests. A few lines caused the compiler to crash so I commented them out and labelled them "Crash!".

https://gist.github.com/4347130



On Monday, December 17, 2012 2:05:37 PM UTC-5, faisalv wrote:
>
> Motivated by the positive feedback we received regarding Generic
> Lambdas (during the October 2012 ISO C++ Standards Meeting in
> Portland), I have implemented a reasonably complete (unless I am
> missing something obvious) implementation
> (http://faisalv.github.com/clang-glambda/) of most of the proposal
> (named lambda syntax for functions has not been attempted) using a
> fork of clang.
>
> We would like to encourage developers who are interested in this
> feature, to either compile the code or download the binaries (sorry,
> only windows for now) and play with the implementation and provide us
> with feedback so that we can incorporate it within our next revision
> of the document.
>
> The following link: http://faisalv.github.com/clang-glambda/, has some
> instructions (towards the bottom) on how to compile the code or use
> the binaries for windows.
>
> Any and all constructive feedback will be greatly appreciated.
>
> The current version (12/2012) implements subproposals 2.1, 2.2, 2.3 and
> 2.5.
>
> 2.1 Allow the type-specifier within a parameter declaration of a
> lambda to be auto (i.e. auto is mandatory)
>
> auto Sum = [](auto a, decltype(a) b) { return a + b; };
> int i = Sum(3, 4);
> double d = Sum(3.14, 2.77);
>
> 2.2 Allow the use of familiar template syntax in lambda expressions
>
> auto NumElements = []<int N>(auto (&a)[N]) { return N; };
> int arri[]{1, 2, 3};
> double arrd[]{3.14, 2.77, 6.626};
> auto total = NumElements(arri) + NumElements(arrd);
>
> 2.3 Permit a lambda body to be an expression
>
> int local = 10;
> auto L = [&](auto a) a + ++local;
>
> 2.5 Autogenerate a conversion to function pointer in captureless generic
> lambdas
>
> auto L = [](auto a, decltype(a) b) { return a + b; };
> int (*fp)(int, int) = L;
>
>
> Thank you and looking forward to the feedback!
>

--




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

Absolutely fantastic! A few things on interest:<br><br>I had not realized t=
his syntax supports nesting:<br><br><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> compose </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>[](</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><spa=
n style=3D"color: #000;" class=3D"styled-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"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> g </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">[=3D](</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> g</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-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> curry3 </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span><spa=
n 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=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> f </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp;</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">[=3D](</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>[=3D](</span><span style=3D"color: #008;" class=3D"styled-by-prettify">aut=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">[=3D](</span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">auto</span><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"style=
d-by-prettify"> <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;f</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: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">y</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">z</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
></div></code></div><pre><div class=3D"line" id=3D"file-generic-lambda-test=
s-cpp-LC13"><pre><div class=3D"line" id=3D"file-generic-lambda-tests-cpp-LC=
24"><span class=3D"p"><br>And variadic lambdas, too! Very nice. <br>But I w=
onder why we couldn't...<br><br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"=
styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> f </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[](</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-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"> </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: #000;" class=3D"styled-by-pre=
ttify"> </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"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> _f</span><span style=3D"co=
lor: #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></div></code></div><br>I wrote some tes=
ts. A few lines caused the compiler to crash so I commented them out and la=
belled them "Crash!".<br><br>https://gist.github.com/4347130<br></span></di=
v></pre></div></pre><br><br>On Monday, December 17, 2012 2:05:37 PM UTC-5, =
faisalv wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Motivated by the=
 positive feedback we received regarding Generic
<br>Lambdas (during the October 2012 ISO C++ Standards Meeting in
<br>Portland), I have implemented a reasonably complete (unless I am
<br>missing something obvious) implementation
<br>(<a href=3D"http://faisalv.github.com/clang-glambda/" target=3D"_blank"=
>http://faisalv.github.com/<wbr>clang-glambda/</a>) of most of the proposal
<br>(named lambda syntax for functions has not been attempted) using a
<br>fork of clang.
<br>
<br>We would like to encourage developers who are interested in this
<br>feature, to either compile the code or download the binaries (sorry,
<br>only windows for now) and play with the implementation and provide us
<br>with feedback so that we can incorporate it within our next revision
<br>of the document.
<br>
<br>The following link: <a href=3D"http://faisalv.github.com/clang-glambda/=
" target=3D"_blank">http://faisalv.github.com/<wbr>clang-glambda/</a>, has =
some
<br>instructions (towards the bottom) on how to compile the code or use
<br>the binaries for windows.
<br>
<br>Any and all constructive feedback will be greatly appreciated.
<br>
<br>The current version (12/2012) implements subproposals 2.1, 2.2, 2.3 and=
 2.5.
<br>
<br>2.1 Allow the type-specifier within a parameter declaration of a
<br>lambda to be auto (i.e. auto is mandatory)
<br>
<br>auto Sum =3D [](auto a, decltype(a) b) { return a + b; };
<br>int i =3D Sum(3, 4);
<br>double d =3D Sum(3.14, 2.77);
<br>
<br>2.2 Allow the use of familiar template syntax in lambda expressions
<br>
<br>auto NumElements =3D []&lt;int N&gt;(auto (&amp;a)[N]) { return N; };
<br>int arri[]{1, 2, 3};
<br>double arrd[]{3.14, 2.77, 6.626};
<br>auto total =3D NumElements(arri) + NumElements(arrd);
<br>
<br>2.3 Permit a lambda body to be an expression
<br>
<br>int local =3D 10;
<br>auto L =3D [&amp;](auto a) a + ++local;
<br>
<br>2.5 Autogenerate a conversion to function pointer in captureless generi=
c lambdas
<br>
<br>auto L =3D [](auto a, decltype(a) b) { return a + b; };
<br>int (*fp)(int, int) =3D L;
<br>
<br>
<br>Thank you and looking forward to the feedback!
<br></blockquote>

<p></p>

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

------=_Part_214_28441934.1356027378884--

.

On Thu, Dec 20, 2012 at 2:59 PM, Herb Sutter <hsutter@microsoft.com> wrote:
> Note that this proposal is still in progress, and is changing based on EW=
G
> input.
>
>
>
> In particular, in Portland there was considerable concern from Bjarne in
> particular about the =93overly terse=94 form, such as []( &a ) as a synon=
ym for
> []( auto& a ), mainly on the grounds that:
>
> =B7         If we adopt concept-like template constraints in the future w=
e
> want to write things like []( iterator a ) and allowing dropping the =91a=
uto=92
> now potentially could make people lazy and disincentivized to insert the
> concept/constraint name in the future.
>
I see.

When auto was being initially discussed in c.l.cpp.m, I mentioned that

f( auto a, auto b, auto c, auto d )

was lexically the same as

f(a, b, c, d)

i.e., the auto keyword doesn't really add any information, and that I
preferred something like

f( T a, T b, U c, X d );

instead.

My reason was that even though the parameters are fully typed, the
types are lexically lost, which might be a problem, specially when
maintaining f().

In my own example, 'a' and 'b' are declared to be of the same type
which would not necessarily be the case in the "unconstrained" case of
(auto a, auto b,....), so it was clear that I might want to give the
type a name, but I might also want to explicitly not do so. Hence I
realized that 'auto' as a "whatever type specifier" serves it's
purpose, and let go of the idea.

Now I see that some of that is still in the air. Sometimes you want to
explicitely indicate that any type is just fine, sometimes you want to
explicitly name it so you can express things that relate to the type.
For instance, that a group of parameters shall be of the same type: X
a, X b, Y c, or that the actual type is a derivation: shared_ptr<T>,
or as in your example, that the type must satisfy certain requirements
(i.e. be a concept)

I believe that (a) we sometimes want to name the type, while (b)
sometimes we don't, being that a deliberate design decision. The
current state of the proposal addresses that by allowing you to omit
the type-specifier (case a) or naming the type via the familiar
template syntax (case b)

IMO, requiring, or even allowing auto is like having case (a)  but
looking like case (b), which IMHO would be a mistake and would add
nothing. What I think we need is to support both cases cleanly and
consistently (and the current paper does that)

(FWIW, I would prefer a simpler syntax where you can say (T a) instead
of <class T>(T a), but that's a lot more difficult given the current
language definition)

Best














--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=20




.

On Thu, Dec 20, 2012 at 3:59 PM, Herb Sutter <hsutter@microsoft.com> wrote:

> In particular, in Portland there was considerable concern from Bjarne in
> particular

I realize now that it might be be clear from my last response how that
addresses the specific concerns mentioned.

> about the =93overly terse=94 form, such as []( &a ) as a synonym for
> []( auto& a ), mainly on the grounds that:
>
> =B7         If we adopt concept-like template constraints in the future w=
e
> want to write things like []( iterator a )

From my POV:

You would type  [](& a) when you *explicitly* express that there are
no requirement on the type of a. Which is what you do if you use auto.

And you would type [](iterator a) (or [](T a, T b as another example),
when express the requirements.

So IMO both are separate design choices, hence I wouldn't consider
using auto for the first one just to be "lexically closer" to the
second one.
In the long term, it would much more annoy everyone for having to
write auto for no real purpose than it would help lazy programmers
(who better don't work in C++) do the right thing.

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=20




.

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

On 20 December 2012 12:38, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:

>
> f(a, b, c, d)
>
> i.e., the auto keyword doesn't really add any information, and that I
> preferred something like
>
> f( T a, T b, U c, X d );
>

But if any of those types T, U or X happen to exist and come into view
(say, by including a header), you've changed the meaning.  That seems very
error prone to me.

I once had to debug a template problem caused by a 3rd party doing

#define U8 unsigned char

so it does happen, even with short names.

IMO, requiring, or even allowing auto is like having case (a)  but
> looking like case (b), which IMHO would be a mistake and would add
> nothing.


Not putting auto in *already* has a meaning; it is perfectly legal to write:

[](string){}

Changing string to mean "parameter" instead of "type" is a breaking change
from C++11 and inconsistent with the rest of the language.


> (FWIW, I would prefer a simpler syntax where you can say (T a) instead
> of <class T>(T a), but that's a lot more difficult given the current
> language definition)
>

Again, I think that is incredibly error prone, because its meaning changes
based on whether or not T is a lexically available type.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




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

On 20 December 2012 12:38, Fernando Cacciola <span dir=3D"ltr">&lt;<a href=
=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciola=
@gmail.com</a>&gt;</span> wrote:<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">

<br>
f(a, b, c, d)<br>
<br>
i.e., the auto keyword doesn&#39;t really add any information, and that I<b=
r>
preferred something like<br>
<br>
f( T a, T b, U c, X d );<br></blockquote><div><br>But if any of those types=
 T, U or X happen to exist and come into view (say, by including a header),=
 you&#39;ve changed the meaning.=A0 That seems very error prone to me.<br>

<br>I once had to debug a template problem caused by a 3rd party doing<br><=
br>#define U8 unsigned char<br><br>so it does happen, even with short names=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">

IMO, requiring, or even allowing auto is like having case (a) =A0but<br>
looking like case (b), which IMHO would be a mistake and would add<br>
nothing.</blockquote><div><br>Not putting auto in *already* has a meaning; =
it is perfectly legal to write:<br><br>[](string){}<br><br>Changing string =
to mean &quot;parameter&quot; instead of &quot;type&quot; is a breaking cha=
nge from C++11 and inconsistent with the rest of the language.<br>

=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">(FWIW, I would prefer a simpler syn=
tax where you can say (T a) instead<br>
of &lt;class T&gt;(T a), but that&#39;s a lot more difficult given the curr=
ent<br>
language definition)<br clear=3D"all"></blockquote></div><br>Again, I think=
 that is incredibly error prone, because its meaning changes based on wheth=
er or not T is a lexically available type.<br>-- <br>=A0Nevin &quot;:-)&quo=
t; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"=
_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404<br>


<p></p>

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

--bcaec550b3366a914904d14dd331--

.

On Thu, Dec 20, 2012 at 5:34 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 20 December 2012 12:38, Fernando Cacciola <fernando.cacciola@gmail.com>
> wrote:
>>
>>
>> f(a, b, c, d)
>>
>> i.e., the auto keyword doesn't really add any information, and that I
>> preferred something like
>>
>> f( T a, T b, U c, X d );
>
>
> But if any of those types T, U or X happen to exist and come into view (say,
> by including a header), you've changed the meaning.  That seems very error
> prone to me.
>
> I once had to debug a template problem caused by a 3rd party doing
>
> #define U8 unsigned char
>
> so it does happen, even with short names.
>
Right.
I didn't consider that too much back then, but now in the context of
the proposal the first think I noticed is that they propose to use the
familiar template syntax.

You'd type   <class T>[]( T& a) instead of just [](T& a)

so that shouldn't be a problem

(and regarding what I said about dropping <class T>, you are right and
I did think of it, that's why I just mentioned that I liked that but
it's not currently possible)


>> IMO, requiring, or even allowing auto is like having case (a)  but
>> looking like case (b), which IMHO would be a mistake and would add
>> nothing.
>
>
> Not putting auto in *already* has a meaning; it is perfectly legal to write:
>
> [](string){}
>
> Changing string to mean "parameter" instead of "type" is a breaking change
> from C++11 and inconsistent with the rest of the language.
>

OK.
Now this is a different argument. You have a point, but, I would say
that the solution is simple: disallow unnamed parameters (like they do
in the proposal)

>>
>> (FWIW, I would prefer a simpler syntax where you can say (T a) instead
>> of <class T>(T a), but that's a lot more difficult given the current
>> language definition)
>
>
> Again, I think that is incredibly error prone, because its meaning changes
> based on whether or not T is a lexically available type.

Are you referring to the case when you'd use <class T>?

If so, why? It's the exact same thing as with an ordinary function
template and that's never been a problem.

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




.

--001517475cb0e4793404d14e48d8
Content-Type: text/plain; charset=ISO-8859-1

On 20 December 2012 13:44, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:

>
> > Not putting auto in *already* has a meaning; it is perfectly legal to
> write:
> >
> > [](string){}
> >
> > Changing string to mean "parameter" instead of "type" is a breaking
> change
> > from C++11 and inconsistent with the rest of the language.
> >
>
> OK.
> Now this is a different argument. You have a point, but, I would say
> that the solution is simple: disallow unnamed parameters (like they do
> in the proposal)
>

I don't see how this fixes the problem; it is still a breaking change,
making it far less likely to pass for C++14.  Take the following example:

struct Missiles
{
    Missiles(int numberToCreate) { /*... */ }
    Missiles& operator()(int numberToLaunch) { /* ... */ }
};

[](Missiles){ return Missiles(1); }

This behavior has changed silently under the proposal.


> >> (FWIW, I would prefer a simpler syntax where you can say (T a) instead
> >> of <class T>(T a), but that's a lot more difficult given the current
> >> language definition)
> >
> >
> > Again, I think that is incredibly error prone, because its meaning
> changes
> > based on whether or not T is a lexically available type.
>
> Are you referring to the case when you'd use <class T>?
>

No, omitting the <class T> is the error prone case.  You need something to
say what 'T' is.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




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

On 20 December 2012 13:44, Fernando Cacciola <span dir=3D"ltr">&lt;<a href=
=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciola=
@gmail.com</a>&gt;</span> wrote:<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">

<br><div class=3D"im">
&gt; Not putting auto in *already* has a meaning; it is perfectly legal to =
write:<br>
&gt;<br>
&gt; [](string){}<br>
&gt;<br>
&gt; Changing string to mean &quot;parameter&quot; instead of &quot;type&qu=
ot; is a breaking change<br>
&gt; from C++11 and inconsistent with the rest of the language.<br>
&gt;<br>
<br>
</div>OK.<br>
Now this is a different argument. You have a point, but, I would say<br>
that the solution is simple: disallow unnamed parameters (like they do<br>
in the proposal)<br></blockquote><div><br>I don&#39;t see how this fixes th=
e problem; it is still a breaking change, making it far less likely to pass=
 for C++14.=A0 Take the following example:<br><br>struct Missiles<br>{<br>

=A0=A0=A0 Missiles(int numberToCreate) { /*... */ }<br>=A0=A0=A0 Missiles&a=
mp; operator()(int numberToLaunch) { /* ... */ }<br>};<br><br>[](Missiles){=
 return Missiles(1); }<br><br>This behavior has changed silently under the =
proposal.<br>

=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">&gt;&gt; (FWIW, I would prefer a si=
mpler syntax where you can say (T a) instead<br><div class=3D"im">
&gt;&gt; of &lt;class T&gt;(T a), but that&#39;s a lot more difficult given=
 the current<br>
&gt;&gt; language definition)<br>
&gt;<br>
&gt;<br>
&gt; Again, I think that is incredibly error prone, because its meaning cha=
nges<br>
&gt; based on whether or not T is a lexically available type.<br>
<br>
</div>Are you referring to the case when you&#39;d use &lt;class T&gt;?<br>=
</blockquote><div><br>No, omitting the &lt;class T&gt; is the error prone c=
ase.=A0 You need something to say what &#39;T&#39; is.<br></div></div>-- <b=
r>

=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<br>

<p></p>

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

--001517475cb0e4793404d14e48d8--

.

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

Composition and currying are cool.



Those who don't like the terse syntax may object that it's only slightly worse with the current syntax, though, right?



auto compose = []( auto f, auto g ) { return

    [=]( auto x ) f( g(x) ); };



auto curry3 =

   []( auto f ) { return

       [=](auto x) { return [=](auto y) { return [=](auto z) { return

           f(x,y,z); }; }; }; };



Though you do have to be a little careful to balance the {'s and };'s.



Herb


From: Scott Prager [mailto:splinterofchaos@gmail.com]
Sent: Thursday, December 20, 2012 10:16 AM
To: std-proposals@isocpp.org
Cc: std-discussion@isocpp.org; faisalv@gmail.com
Subject: [std-proposals] Re: An implementation of Generic lambdas (Request for feedback)

Absolutely fantastic! A few things on interest:

I had not realized this syntax supports nesting:
auto compose = []( auto f, auto g )
    [=]( auto x ) f( g(x) );

auto curry3 =
   []( auto f )
       [=](auto x) [=](auto y) [=](auto z)
           f(x,y,z);

And variadic lambdas, too! Very nice.
But I wonder why we couldn't...

auto f = []( auto _f ) [](auto ...x) _f(x...);

I wrote some tests. A few lines caused the compiler to crash so I commented them out and labelled them "Crash!".

https://gist.github.com/4347130


On Monday, December 17, 2012 2:05:37 PM UTC-5, faisalv wrote:
Motivated by the positive feedback we received regarding Generic
Lambdas (during the October 2012 ISO C++ Standards Meeting in
Portland), I have implemented a reasonably complete (unless I am
missing something obvious) implementation
(http://faisalv.github.com/clang-glambda/) of most of the proposal
(named lambda syntax for functions has not been attempted) using a
fork of clang.

We would like to encourage developers who are interested in this
feature, to either compile the code or download the binaries (sorry,
only windows for now) and play with the implementation and provide us
with feedback so that we can incorporate it within our next revision
of the document.

The following link: http://faisalv.github.com/clang-glambda/, has some
instructions (towards the bottom) on how to compile the code or use
the binaries for windows.

Any and all constructive feedback will be greatly appreciated.

The current version (12/2012) implements subproposals 2.1, 2.2, 2.3 and 2.5.

2.1 Allow the type-specifier within a parameter declaration of a
lambda to be auto (i.e. auto is mandatory)

auto Sum = [](auto a, decltype(a) b) { return a + b; };
int i = Sum(3, 4);
double d = Sum(3.14, 2.77);

2.2 Allow the use of familiar template syntax in lambda expressions

auto NumElements = []<int N>(auto (&a)[N]) { return N; };
int arri[]{1, 2, 3};
double arrd[]{3.14, 2.77, 6.626};
auto total = NumElements(arri) + NumElements(arrd);

2.3 Permit a lambda body to be an expression

int local = 10;
auto L = [&](auto a) a + ++local;

2.5 Autogenerate a conversion to function pointer in captureless generic lambdas

auto L = [](auto a, decltype(a) b) { return a + b; };
int (*fp)(int, int) = L;


Thank you and looking forward to the feedback!
--



--




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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
 {font-family:Calibri;
 panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
 {font-family:Tahoma;
 panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
 {font-family:Consolas;
 panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
 {margin:0in;
 margin-bottom:.0001pt;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
 {mso-style-priority:99;
 color:blue;
 text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
 {mso-style-priority:99;
 color:purple;
 text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
 {mso-style-priority:99;
 mso-style-link:"Plain Text Char";
 margin:0in;
 margin-bottom:.0001pt;
 font-size:11.0pt;
 font-family:"Calibri","sans-serif";}
p
 {mso-style-priority:99;
 mso-margin-top-alt:auto;
 margin-right:0in;
 mso-margin-bottom-alt:auto;
 margin-left:0in;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
code
 {mso-style-priority:99;
 font-family:"Courier New";}
pre
 {mso-style-priority:99;
 mso-style-link:"HTML Preformatted Char";
 margin:0in;
 margin-bottom:.0001pt;
 font-size:10.0pt;
 font-family:"Courier New";}
span.styled-by-prettify
 {mso-style-name:styled-by-prettify;}
span.HTMLPreformattedChar
 {mso-style-name:"HTML Preformatted Char";
 mso-style-priority:99;
 mso-style-link:"HTML Preformatted";
 font-family:Consolas;}
span.p
 {mso-style-name:p;}
span.EmailStyle23
 {mso-style-type:personal-reply;
 font-family:"Calibri","sans-serif";
 color:#1F497D;}
span.PlainTextChar
 {mso-style-name:"Plain Text Char";
 mso-style-priority:99;
 mso-style-link:"Plain Text";
 font-family:"Calibri","sans-serif";}
..MsoChpDefault
 {mso-style-type:export-only;
 font-family:"Calibri","sans-serif";}
@page WordSection1
 {size:8.5in 11.0in;
 margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
 {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Composition and currying are cool.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Those who don&#8217;t like the terse syntax may o=
bject that it&#8217;s only slightly worse with the current syntax, though, =
right?<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">auto compose =3D []( auto f, auto g ) { return<o:=
p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; [=3D]( auto x ) f( g(x) ); };<=
o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">auto curry3 =3D<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp; []( auto f ) { return<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=3D](auto x=
) { return [=3D](auto y) { return [=3D](auto z) { return<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; f(x,y,z); }; }; }; };<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Though you do have to be a little careful to bala=
nce the {&#8216;s and };&#8217;s.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Herb<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Scott Pr=
ager [mailto:splinterofchaos@gmail.com]
<br>
<b>Sent:</b> Thursday, December 20, 2012 10:16 AM<br>
<b>To:</b> std-proposals@isocpp.org<br>
<b>Cc:</b> std-discussion@isocpp.org; faisalv@gmail.com<br>
<b>Subject:</b> [std-proposals] Re: An implementation of Generic lambdas (R=
equest for feedback)<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Absolutely fantastic!=
 A few things on interest:<br>
<br>
I had not realized this syntax supports nesting:<o:p></o:p></p>
<div style=3D"border:solid #BBBBBB 1.0pt;padding:0in 0in 0in 0in;word-wrap:=
 break-word">
<div>
<p class=3D"MsoNormal" style=3D"background:#FAFAFA"><span class=3D"styled-b=
y-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&q=
uot;;color:#000088">auto</span></span><span class=3D"styled-by-prettify"><s=
pan style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:bla=
ck">
 compose </span></span><span class=3D"styled-by-prettify"><span style=3D"fo=
nt-size:10.0pt;font-family:&quot;Courier New&quot;;color:#666600">=3D</span=
></span><span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;=
font-family:&quot;Courier New&quot;;color:black">
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#666600">[](</span></span><=
span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-fami=
ly:&quot;Courier New&quot;;color:black">
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#000088">auto</span></span>=
<span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-fam=
ily:&quot;Courier New&quot;;color:black"> f</span></span><span class=3D"sty=
led-by-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;Courier =
New&quot;;color:#666600">,</span></span><span class=3D"styled-by-prettify">=
<span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:b=
lack">
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#000088">auto</span></span>=
<span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-fam=
ily:&quot;Courier New&quot;;color:black"> g
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#666600">)</span></span><sp=
an style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:blac=
k"><br>
<span class=3D"styled-by-prettify">&nbsp; &nbsp; </span></span><span class=
=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;C=
ourier New&quot;;color:#666600">[=3D](</span></span><span class=3D"styled-b=
y-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&q=
uot;;color:black">
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#000088">auto</span></span>=
<span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-fam=
ily:&quot;Courier New&quot;;color:black"> x
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#666600">)</span></span><sp=
an class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-family=
:&quot;Courier New&quot;;color:black"> f</span></span><span class=3D"styled=
-by-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;Courier New=
&quot;;color:#666600">(</span></span><span class=3D"styled-by-prettify"><sp=
an style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:blac=
k">
 g</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size=
:10.0pt;font-family:&quot;Courier New&quot;;color:#666600">(</span></span><=
span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-fami=
ly:&quot;Courier New&quot;;color:black">x</span></span><span class=3D"style=
d-by-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;Courier Ne=
w&quot;;color:#666600">)</span></span><span class=3D"styled-by-prettify"><s=
pan style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:bla=
ck">
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#666600">);</span></span><s=
pan style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:bla=
ck"><br>
<br>
</span><span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;f=
ont-family:&quot;Courier New&quot;;color:#000088">auto</span></span><span c=
lass=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-family:&qu=
ot;Courier New&quot;;color:black"> curry3
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#666600">=3D</span></span><=
span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:bl=
ack"><br>
<span class=3D"styled-by-prettify">&nbsp; &nbsp;</span></span><span class=
=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;C=
ourier New&quot;;color:#666600">[](</span></span><span class=3D"styled-by-p=
rettify"><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot=
;;color:black">
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#000088">auto</span></span>=
<span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-fam=
ily:&quot;Courier New&quot;;color:black"> f
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#666600">)</span></span><sp=
an style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:blac=
k"><br>
<span class=3D"styled-by-prettify">&nbsp; &nbsp; &nbsp; &nbsp;</span></span=
><span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-fa=
mily:&quot;Courier New&quot;;color:#666600">[=3D](</span></span><span class=
=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;C=
ourier New&quot;;color:#000088">auto</span></span><span class=3D"styled-by-=
prettify"><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quo=
t;;color:black">
 x</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size=
:10.0pt;font-family:&quot;Courier New&quot;;color:#666600">)</span></span><=
span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-fami=
ly:&quot;Courier New&quot;;color:black">
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#666600">[=3D](</span></spa=
n><span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-f=
amily:&quot;Courier New&quot;;color:#000088">auto</span></span><span class=
=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;C=
ourier New&quot;;color:black">
 y</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size=
:10.0pt;font-family:&quot;Courier New&quot;;color:#666600">)</span></span><=
span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-fami=
ly:&quot;Courier New&quot;;color:black">
</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;;color:#666600">[=3D](</span></spa=
n><span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-f=
amily:&quot;Courier New&quot;;color:#000088">auto</span></span><span class=
=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;C=
ourier New&quot;;color:black">
 z</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size=
:10.0pt;font-family:&quot;Courier New&quot;;color:#666600">)</span></span><=
span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-fami=
ly:&quot;Courier New&quot;;color:black">
</span></span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New=
&quot;;color:black"><br>
<span class=3D"styled-by-prettify">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;f</span></span><span class=3D"styled-by-prettify"><span style=3D"font-size=
:10.0pt;font-family:&quot;Courier New&quot;;color:#666600">(</span></span><=
span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-fami=
ly:&quot;Courier New&quot;;color:black">x</span></span><span class=3D"style=
d-by-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;Courier Ne=
w&quot;;color:#666600">,</span></span><span class=3D"styled-by-prettify"><s=
pan style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:bla=
ck">y</span></span><span class=3D"styled-by-prettify"><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Courier New&quot;;color:#666600">,</span></spa=
n><span class=3D"styled-by-prettify"><span style=3D"font-size:10.0pt;font-f=
amily:&quot;Courier New&quot;;color:black">z</span></span><span class=3D"st=
yled-by-prettify"><span style=3D"font-size:10.0pt;font-family:&quot;Courier=
 New&quot;;color:#666600">);</span></span><span style=3D"font-size:10.0pt;f=
ont-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
</div>
<div id=3D"file-generic-lambda-tests-cpp-LC13">
<div id=3D"file-generic-lambda-tests-cpp-LC24">
<pre style=3D"margin-bottom:12.0pt"><br><span class=3D"p">And variadic lamb=
das, too! Very nice. </span><br><span class=3D"p">But I wonder why we could=
n't...<o:p></o:p></span></pre>
<div style=3D"border:solid #BBBBBB 1.0pt;padding:0in 0in 0in 0in;word-wrap:=
 break-word">
<div>
<pre style=3D"background:#FAFAFA"><span class=3D"styled-by-prettify"><span =
style=3D"color:#000088">auto</span><span style=3D"color:black"> f </span><s=
pan style=3D"color:#666600">=3D</span><span style=3D"color:black"> </span><=
span style=3D"color:#666600">[](</span><span style=3D"color:black"> </span>=
<span style=3D"color:#000088">auto</span><span style=3D"color:black"> _f </=
span><span style=3D"color:#666600">)</span><span style=3D"color:black"> </s=
pan><span style=3D"color:#666600">[](</span><span style=3D"color:#000088">a=
uto</span><span style=3D"color:black"> </span><span style=3D"color:#666600"=
>...</span><span style=3D"color:black">x</span><span style=3D"color:#666600=
">)</span><span style=3D"color:black"> _f</span><span style=3D"color:#66660=
0">(</span><span style=3D"color:black">x</span><span style=3D"color:#666600=
">...);</span></span><o:p></o:p></pre>
</div>
</div>
<pre><br><span class=3D"p">I wrote some tests. A few lines caused the compi=
ler to crash so I commented them out and labelled them &quot;Crash!&quot;.<=
/span><br><br><span class=3D"p"><a href=3D"https://gist.github.com/4347130"=
>https://gist.github.com/4347130</a></span><o:p></o:p></pre>
</div>
</div>
<p class=3D"MsoNormal"><br>
<br>
On Monday, December 17, 2012 2:05:37 PM UTC-5, faisalv wrote:<o:p></o:p></p=
>
<p class=3D"MsoNormal">Motivated by the positive feedback we received regar=
ding Generic
<br>
Lambdas (during the October 2012 ISO C&#43;&#43; Standards Meeting in <br>
Portland), I have implemented a reasonably complete (unless I am <br>
missing something obvious) implementation <br>
(<a href=3D"http://faisalv.github.com/clang-glambda/" target=3D"_blank">htt=
p://faisalv.github.com/clang-glambda/</a>) of most of the proposal
<br>
(named lambda syntax for functions has not been attempted) using a <br>
fork of clang. <br>
<br>
We would like to encourage developers who are interested in this <br>
feature, to either compile the code or download the binaries (sorry, <br>
only windows for now) and play with the implementation and provide us <br>
with feedback so that we can incorporate it within our next revision <br>
of the document. <br>
<br>
The following link: <a href=3D"http://faisalv.github.com/clang-glambda/" ta=
rget=3D"_blank">
http://faisalv.github.com/clang-glambda/</a>, has some <br>
instructions (towards the bottom) on how to compile the code or use <br>
the binaries for windows. <br>
<br>
Any and all constructive feedback will be greatly appreciated. <br>
<br>
The current version (12/2012) implements subproposals 2.1, 2.2, 2.3 and 2.5=
.. <br>
<br>
2.1 Allow the type-specifier within a parameter declaration of a <br>
lambda to be auto (i.e. auto is mandatory) <br>
<br>
auto Sum =3D [](auto a, decltype(a) b) { return a &#43; b; }; <br>
int i =3D Sum(3, 4); <br>
double d =3D Sum(3.14, 2.77); <br>
<br>
2.2 Allow the use of familiar template syntax in lambda expressions <br>
<br>
auto NumElements =3D []&lt;int N&gt;(auto (&amp;a)[N]) { return N; }; <br>
int arri[]{1, 2, 3}; <br>
double arrd[]{3.14, 2.77, 6.626}; <br>
auto total =3D NumElements(arri) &#43; NumElements(arrd); <br>
<br>
2.3 Permit a lambda body to be an expression <br>
<br>
int local =3D 10; <br>
auto L =3D [&amp;](auto a) a &#43; &#43;&#43;local; <br>
<br>
2.5 Autogenerate a conversion to function pointer in captureless generic la=
mbdas <br>
<br>
auto L =3D [](auto a, decltype(a) b) { return a &#43; b; }; <br>
int (*fp)(int, int) =3D L; <br>
<br>
<br>
Thank you and looking forward to the feedback! <o:p></o:p></p>
<p class=3D"MsoNormal">-- <br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<o:p></o:p></p>
</div>
</div>
</body>
</html>

<p></p>

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

--_000_daa02f6ff5514e7a94116571302de769BN1PR03MB086namprd03pro_--

.

On Thu, Dec 20, 2012 at 6:07 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 20 December 2012 13:44, Fernando Cacciola <fernando.cacciola@gmail.com>
> wrote:
>>
>>
>> > Not putting auto in *already* has a meaning; it is perfectly legal to
>> > write:
>> >
>> > [](string){}
>> >
>> > Changing string to mean "parameter" instead of "type" is a breaking
>> > change
>> > from C++11 and inconsistent with the rest of the language.
>> >
>>
>> OK.
>> Now this is a different argument. You have a point, but, I would say
>> that the solution is simple: disallow unnamed parameters (like they do
>> in the proposal)
>
>
> I don't see how this fixes the problem; it is still a breaking change,
> making it far less likely to pass for C++14.  Take the following example:
>
> struct Missiles
> {
>     Missiles(int numberToCreate) { /*... */ }
>     Missiles& operator()(int numberToLaunch) { /* ... */ }
> };
>
> [](Missiles){ return Missiles(1); }
>
> This behavior has changed silently under the proposal.
>
Hmm, I see.
And right now I don't see how could the conclusion not be that we do
need the placeholder auto to disambiguate (and with it default
argument would be back)


>>
>> >> (FWIW, I would prefer a simpler syntax where you can say (T a) instead
>> >> of <class T>(T a), but that's a lot more difficult given the current
>> >> language definition)
>> >
>> >
>> > Again, I think that is incredibly error prone, because its meaning
>> > changes
>> > based on whether or not T is a lexically available type.
>>
>> Are you referring to the case when you'd use <class T>?
>
>
> No, omitting the <class T> is the error prone case.  You need something to
> say what 'T' is.

OK, so the part of the proposal where template syntax is used to name
types is not debated, only the omission of auto.

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




.

--047d7b15a1ef81af9d04d14ead6f
Content-Type: text/plain; charset=ISO-8859-1

Would it help having a terse-but-with-auto syntax by keeping the auto based
syntax but allowing a ..."shortcut" symbol that would be an alias for auto?
Like @ or $?

Example:

auto f = []( auto a, auto b) a x b;
or
auto f = []( auto a, auto b) { return a x b; }

could be written something like

auto f = []( $ a, $ b) a x b;
or
auto f = []( $ a, $ b) { return a x b; }
or even
auto f = [] $a x $b; // just got the idea while writing this, didn't think
about the implications yet...
and allow
auto f = []( $, $ b) { return b; } // first argument is anonymous

OR

auto f = []( @ a, @ b) a x b;
or
auto f = []( @ a, @ b) { return a x b; }
or even
auto f = [] @a x @b; // just got the idea while writing this, didn't think
about the implications yet...
and allow
auto f = []( @, @ b) { return b; } // first argument is anonymous

The point being that we just need to know that something is an object of
arbitrary type, am I correct?

Auto diagnostic:

 1. it would reserve a new symbol, which makes one less symbol for a new
(future) feature
 2. it might require that any possible place where you can use auto, you
can use @ (for example), to generalize
 3. ...?

For the example
auto f = [] @a x @b; // maximum tersity

the idea would be to have the expression directly, with just markers to the
names which are arguments objects, letting the compiler do the rest.


This is a wild idea coming from reading this discussion so it might be
stupid...
What do you think?

Joel Lamotte

--




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

<div dir=3D"ltr">Would it help having a terse-but-with-auto syntax by keepi=
ng the auto based syntax but allowing a ...&quot;shortcut&quot; symbol that=
 would be an alias for auto?<br>Like @ or $?<br><br>Example:<br><br>auto f =
=3D []( auto a, auto b) a x b;<br>
or<br>auto f =3D []( auto a, auto b) { return a x b; }<br><br>could be writ=
ten something like<br><br>auto f =3D []( $ a, $ b) a x b;<br>or<br>auto f =
=3D []( $ a, $ b) { return a x b; }<br>or even<br>auto f =3D [] $a x $b; //=
 just got the idea while writing this, didn&#39;t think about the implicati=
ons yet...<div>
and allow<br>auto f =3D []( $, $ b) { return b; }=A0// first argument is an=
onymous<br><br>OR<br><br>auto f =3D []( @ a, @ b) a x b;<br>or<br>auto f =
=3D []( @ a, @ b) { return a x b; }<br>or even<br>auto f =3D [] @a x @b; //=
 just got the idea while writing this, didn&#39;t think about the implicati=
ons yet...</div>
<div>and allow<br>auto f =3D []( @, @ b) { return b; } // first argument is=
 anonymous<br><br>The point being that we just need to know that something =
is an object of arbitrary type, am I correct?<br><br>Auto diagnostic:<br>
<br>=A01. it would reserve a new symbol, which makes one less symbol for a =
new (future) feature<br>=A02. it might require that any possible place wher=
e you can use auto, you can use @ (for example), to generalize<br>=A03. ...=
?<br>
<br>For the example<br>auto f =3D [] @a x @b; // maximum tersity<br><br>the=
 idea would be to have the expression directly, with just markers to the na=
mes which are arguments objects, letting the compiler do the rest.<br><br>
<br>This is a wild idea coming from reading this discussion so it might be =
stupid...<br>What do you think?<br><br>Joel Lamotte<br><br></div></div>

<p></p>

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

--047d7b15a1ef81af9d04d14ead6f--

.

On 20 December 2012 22:35, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrote=
:
> Would it help having a terse-but-with-auto syntax by keeping the auto bas=
ed
> syntax but allowing a ..."shortcut" symbol that would be an alias for aut=
o?
> Like @ or $?
> This is a wild idea coming from reading this discussion so it might be
> stupid...
> What do you think?

I think I strongly prefer auto to such line noise.

--=20




.

>
> For the example
> auto f = [] @a x @b; // maximum tersity
>
Just off the top of my head, I really like that :)

The generalization would be that, in (the body of) a lambda
expression, identifiers of a certain form are implicitly arguments of
the lambda. Each such argument would be of an automatic type as if it
appeared in the parameter list in the form "auto a". If all lamda
parameters are implicit the parameter list can be omitted altogether.

Whether the proper form is @a or has to be something else would be a
separate issue.

I like the direction this is going because I would like lambdas to be
a "second level meta programming tool": they are put in source code to
generate source code, which is itself template code generating the
final concrete source code.

If the above where to be sound and potentially accepted, then one
would think that it might be possible to go further and say that: if
there is a lambda with all implicit lamda arguments, the lambda
introducer [] can also be omitted, which we leads us to:

find_if(range(r), @e == 2 ) ;


Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




.

On 20 December 2012 22:51, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
>>
>> For the example
>> auto f = [] @a x @b; // maximum tersity
> Just off the top of my head, I really like that :)

Some further points: I would also prefer

1) not adding $ or @ for just lambda uses
2) not adding yet-another-meaning-in-yet-another-language for $ or @

The second point is for those of us unfortunate enough to get
occasional exposure to
shell scripts, perl, and ruby. Replacing auto with @ is utterly
unconvincing to me,
and is just a foolish hack that has negative value. I don't think
maximum tersity
is a valuable goal, I prefer having a short but readable syntax, and
that's at odds
with maximum tersity.

--




.

--047d7b15a1ef8a4ea404d14f3570
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Dec 20, 2012 at 10:01 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> The second point is for those of us unfortunate enough to get
> occasional exposure to
> shell scripts, perl, and ruby. Replacing auto with @ is utterly
> unconvincing to me,
>

It was an example, you could use any symbol that doesn't already mean
something in the given context (maybe : )
but I suppose any other symbol wouldn't please you anyway?


> and is just a foolish hack that has negative value. I don't think
> maximum tersity
> is a valuable goal, I prefer having a short but readable syntax, and
> that's at odds
> with maximum tersity.
>

I don't know if maximum tersity have negative value, I was just suggesting
that it could solve the two points Herb stated, which assume we go the way
of having a terse way to express lambdas.
If a very terse way to express lambdas isn't acceptable, sure it's a hack.

Joel Lamotte

--




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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te">On Thu, Dec 20, 2012 at 10:01 PM, Ville Voutilainen <span dir=3D"ltr">&=
lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.v=
outilainen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div id=3D":1u0">The second point is for tho=
se of us unfortunate enough to get<br>
occasional exposure to<br>
shell scripts, perl, and ruby. Replacing auto with @ is utterly<br>
unconvincing to me,<br></div></blockquote><div><br></div><div style>It was =
an example, you could use any symbol that doesn&#39;t already mean somethin=
g in the given context (maybe : )<br>but I suppose any other symbol wouldn&=
#39;t please you anyway?<br>
</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 id=3D":1u0">
and is just a foolish hack that has negative value. I don&#39;t think<br>
maximum tersity<br>
is a valuable goal, I prefer having a short but readable syntax, and<br>
that&#39;s at odds<br>
with maximum tersity.</div></blockquote></div><br></div><div class=3D"gmail=
_extra" style>I don&#39;t know if maximum tersity have negative value, I wa=
s just suggesting that it could solve the two points Herb stated, which ass=
ume we go the way of having a terse way to express lambdas.<br>
If a very terse way to express lambdas isn&#39;t acceptable, sure it&#39;s =
a hack.<br><br>Joel Lamotte<br><br></div><div class=3D"gmail_extra"><br></d=
iv></div>

<p></p>

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

--047d7b15a1ef8a4ea404d14f3570--

.

On 20 December 2012 23:13, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrote=
:
> It was an example, you could use any symbol that doesn't already mean
> something in the given context (maybe : )
> but I suppose any other symbol wouldn't please you anyway?

All ideas I've seen so far look worse than auto to me.

> I don't know if maximum tersity have negative value, I was just suggestin=
g
> that it could solve the two points Herb stated, which assume we go the wa=
y
> of having a terse way to express lambdas.

That's a funny assumption because EWG indicated the opposite in Portland,
as far as I recall.

--=20




.

On Thu, Dec 20, 2012 at 6:01 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 20 December 2012 22:51, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
>>>
>>> For the example
>>> auto f = [] @a x @b; // maximum tersity
>> Just off the top of my head, I really like that :)
>
> Some further points: I would also prefer
>
> 1) not adding $ or @ for just lambda uses
> 2) not adding yet-another-meaning-in-yet-another-language for $ or @
>
> The second point is for those of us unfortunate enough to get
> occasional exposure to
> shell scripts, perl, and ruby.

At the risk of digressing, can you tell us why? I use those languages
every once in a while and from all the complaints I have, their markup
for variable names has never been one.

> Replacing auto with @ is utterly
> unconvincing to me,

Ah, but that's not really what Joel did, even if he presented it as such.

He proposed a syntax in which lambda arguments are implicit. So it not
just (or "not really" to be precise) that auto is replaced by another
symbol: the entire parameter list (where you would put auto) is gone!!
That's a whole new level of tersity, one which IMO pushes lambdas into
the direction I think they should go.

> and is just a foolish hack that has negative value. I don't think
> maximum tersity
> is a valuable goal, I prefer having a short but readable syntax, and
> that's at odds
> with maximum tersity.
>

I agree with the general principle of what you said.

However, I believe lambdas should be the exception.
The reason is that a lambda expression is, IMO, all about tersity. I
don't need a lambda at all. I can write the function object myself.
In fact, to be honest, that's what I do, and because I still don't
find the syntax convenient enough.

Like I said before, IMO a lambda is nothing but a metaprogramming
construct to help me generate a function object easily. The more
simple than writing the function object it is, the more valuable.

In that sense, being able to just write the lambda expression *itself*
and nothing else, as in:

apply(e, @e + 2 );

instead of

apply(e,  [](auto e) { return e + 2 ; } ) ;

which is itself instead of:

struct plustwo {
template<class T> T operator() ( T e ) { return e + 2 ; }
} ;

apply(e, plustwo() );


makes the feature really really, really, useful.

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




.

> However, I believe lambdas should be the exception.
Considering the apply case below, I think so too.

> apply(e, @e + 2 );
This is very nice, I am just afraid of the consequences of it though.
Also I dislike @ but that is besides the point.



Mikael

--




.

On Thu, Dec 20, 2012 at 8:02 PM, Mikael Kilpel=E4inen
<mikael.kilpelainen@gmail.com> wrote:
>> However, I believe lambdas should be the exception.
>
> Considering the apply case below, I think so too.
>
>
>> apply(e, @e + 2 );
>
> This is very nice, I am just afraid of the consequences of it though. Als=
o I
> dislike @ but that is besides the point.
>
As I would. So let's discuss that.

Off the top of my head, here's what I think of it (disclaimer: I'm
anything but a compiler writer)

(from my user POV) when the compiler correctly identifies a lambda
expression, it generates the corresponding closure type. Further, when
it sees an application of such lambda, it generates the expression
that creates the closure object, binds the corresponding objects that
are captured, and calls the generated function object with lambda
parameters.

So, the very first consideration would be if the proposed syntax would
allow the compiler to correctly identify the lambda expression.
With the current grammar of [](){} this is clearly possible. I would
imagine that the lambda-introducer (the []) is the token that makes
such identification possible in the current syntax.
I might leave with it if necessary but the whole point of the proposed
simplification is to avoid all unnecessary tokens. Thus, we need a
grammar that also provides a unique token (or token sequence). Off the
top of my head, I would say that @ or $ could function as a token to
identify a lambda expression.

If that is correct, then next step would be if such a grammar, based
on such tokens, would suffice to identify the full lambda expression.
I can't tell so let's just say yes.

Then, would the elements of such a correctly identified lambda be
enough to generate the closure type? here I'm sure it is because we
need:

(1) the captures. If there is lambda-introducer that is as it is now,
and if there is not introducer the simple rule is that there are no
captures.

(2) the parameter-list. If the full lambda expression is correctly
identified, then all implicit arguments are found and generating the
parameter list is trivial:

   @a + @b * @c  -> ( auto a, auto b, auto c)

(3) the operator() body. This would be the fully-indentified
expression, possibly put inside "{ return (expr) ; }", with implicit
arguments transformed by stripping the special @ token.


I'm sure there would be much more details, but this is to get it started.

Notice that this is compatible and coexistent with actual and
"as-proposed" polymorphic lambdas, since it is really about
automatically generating, or adding into, auto parameters in the
parameter list.


Best





--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=20




.

> As I would. So let's discuss that.
Lets do.

> (from my user POV) when the compiler correctly identifies a lambda
> expression, it generates the corresponding closure type. Further, when
> it sees an application of such lambda, it generates the expression
> that creates the closure object, binds the corresponding objects that
> are captured, and calls the generated function object with lambda
> parameters.
Indeed, so here that is based on the @, which is part of the
identifier?.. how about clauses
with parenthesis, for example to use comma operator in lambda expressions.
Is (@a + 2) still a lambda expression? Naturally that extends to
arbitrary long expressions.

> If that is correct, then next step would be if such a grammar, based
> on such tokens, would suffice to identify the full lambda expression.
> I can't tell so let's just say yes.
Besides the above issue, I don't see any major problems.

> Then, would the elements of such a correctly identified lambda be
> enough to generate the closure type? here I'm sure it is because we
> need:
I am sure they would be. This, of course, puts some restrictions to this
form of lambdas but
I think that was obvious, and works well to be just "extension" to the
normal syntax.

> I'm sure there would be much more details, but this is to get it started.
Indeed, thank you for that.



Mikael

--




.

On Thu, Dec 20, 2012 at 9:19 PM, Mikael Kilpel=E4inen
<mikael.kilpelainen@gmail.com> wrote:
>> As I would. So let's discuss that.
>
> Lets do.
>
>
>> (from my user POV) when the compiler correctly identifies a lambda
>> expression, it generates the corresponding closure type. Further, when
>> it sees an application of such lambda, it generates the expression
>> that creates the closure object, binds the corresponding objects that
>> are captured, and calls the generated function object with lambda
>> parameters.
>
> Indeed, so here that is based on the @, which is part of the identifier?.=
..
> how about clauses
> with parenthesis, for example to use comma operator in lambda expressions=
..
> Is (@a + 2) still a lambda expression? Naturally that extends to arbitrar=
y
> long expressions.
>
IMO, it must be for this to be truly useful.
Now I'm not an expert in C++ parsing but I would think that it would
be possible to "grow out" the enclosing full expression containing the
implicit lambda parameter. At least to a reasonably useful extent.

>
>> If that is correct, then next step would be if such a grammar, based
>> on such tokens, would suffice to identify the full lambda expression.
>> I can't tell so let's just say yes.
>
> Besides the above issue, I don't see any major problems.
>
>
>> Then, would the elements of such a correctly identified lambda be
>> enough to generate the closure type? here I'm sure it is because we
>> need:
>
> I am sure they would be. This, of course, puts some restrictions to this
> form of lambdas but
> I think that was obvious, and works well to be just "extension" to the
> normal syntax.
>
Right.
The idea is to make it enviously straightforward to create the really
simple polymorphic lambdas, while still possible to write the rest.

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=20




.

> IMO, it must be for this to be truly useful.
> Now I'm not an expert in C++ parsing but I would think that it would
> be possible to "grow out" the enclosing full expression containing the
> implicit lambda parameter. At least to a reasonably useful extent.
Certainly, but it makes the parsing more complex. That said, I don't
think it is really a problem (maybe it is for some generated parsers?).


Mikael

--




.

On 20/12/12 16:43, Fernando Cacciola wrote:
> In that sense, being able to just write the lambda expression *itself*
> and nothing else, as in:
>
> apply(e, @e + 2 );

<snip>

> makes the feature really really, really, useful.

Note that this is very close to what is already offered by libraries
such as Boost.Phoenix.  In that case the line would be:

apply(e, _1 + 2 );

(provided you first bring the _1 into scope from the library namespace)

So, there is already a widely-used proof of concept for such a syntax.

John Bytheway

--




.

--047d7b5d480848858704d154dc0e
Content-Type: text/plain; charset=ISO-8859-1

> Certainly, but it makes the parsing more complex.

This is very true...I'm not even sure it is possible to unambiguously
determine if a in `[] (a)` is a type or the name of an argument, especially
since the behavior of C++11 is in the wild (`a` is always a type...contrast
this with D, where `a` is always a value). Even if it is possible, it
unquestionably makes the parsing more context-sensitive. The only benefit I
see is the ability to drop the N characters of whatever token serves as the
placeholder for the type name ("auto", "$", "@" or otherwise). I'm not sure
the benefit is worth the cost of the increased grammar complexity.

As far as sigil placeholders go...in my opinion, they contrast the rest of
the language. Furthermore, [] ($*&) { } looks funny to me.

--




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

&gt; Certainly, but it makes the parsing more complex.<br><br>This is very =
true...I&#39;m not even sure it is possible to unambiguously determine if a=
 in `[] (a)` is a type or the name of an argument, especially since the beh=
avior of C++11 is in the wild (`a` is always a type...contrast this with D,=
 where `a` is always a value). Even if it is possible, it unquestionably ma=
kes the parsing more context-sensitive. The only benefit I see is the abili=
ty to drop the N characters of whatever token serves as the placeholder for=
 the type name (&quot;auto&quot;, &quot;$&quot;, &quot;@&quot; or otherwise=
). I&#39;m not sure the benefit is worth the cost of the increased grammar =
complexity.<br>
<br>As far as sigil placeholders go...in my opinion, they contrast the rest=
 of the language. Furthermore, [] ($*&amp;) { } looks funny to me.<br>

<p></p>

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

--047d7b5d480848858704d154dc0e--

.

--089e0122f58ebe241504d1550b1e
Content-Type: text/plain; charset=ISO-8859-1

Worth mentioning a potential workaround for disambiguating between C++11
and the N3418 proposed single-token lambda function arguments is to have
something like `[]<>` be a template-lambda-introducer, which says that its
lambda-declarator should treat single-token arguments as values. That
syntax might play poorly with the changes to allow the compound-statement
in a lambda to be an expression, but I haven't fully thought it through.

--




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

Worth mentioning a potential workaround for disambiguating between C++11 an=
d the N3418 proposed single-token lambda function arguments is to have some=
thing like `[]&lt;&gt;` be a template-lambda-introducer, which says that it=
s lambda-declarator should treat single-token arguments as values. That syn=
tax might play poorly with the changes to allow the compound-statement in a=
 lambda to be an expression, but I haven&#39;t fully thought it through.<br=
>

<p></p>

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

--089e0122f58ebe241504d1550b1e--

.

Il giorno 20/dic/2012, alle ore 22:01, Ville Voutilainen <ville.voutilainen=
@gmail.com> ha scritto:

> On 20 December 2012 22:51, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
>>>=20
>>> For the example
>>> auto f =3D [] @a x @b; // maximum tersity
>> Just off the top of my head, I really like that :)
>=20
> Some further points: I would also prefer
>=20
> 1) not adding $ or @ for just lambda uses
> 2) not adding yet-another-meaning-in-yet-another-language for $ or @
>=20
> The second point is for those of us unfortunate enough to get
> occasional exposure to
> shell scripts, perl, and ruby. Replacing auto with @ is utterly
> unconvincing to me,
> and is just a foolish hack that has negative value. I don't think
> maximum tersity
> is a valuable goal, I prefer having a short but readable syntax, and
> that's at odds
> with maximum tersity.

I definitely agree. Let me point out that using @ would be disastrous for O=
bjective-C/C++ interoperability and that $ is already being used by some ot=
her specific dialect/platform, which I don't recall now. Of course, whether=
 we want to keep compatibility with such uses is debatable, but we have to =
be aware that the lexical space is more crowded than it seems and every dec=
ision comes at a cost.

Ganesh

--=20




.

Il giorno 21/dic/2012, alle ore 13:39, stackmachine@hotmail.com ha scritto:

> What about =A7?
>=20

It has to be in the "basic source character set" (see 2.3/2). =A7 is not pa=
rt of it.

Ganesh

--=20




.

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

Am Freitag, 21. Dezember 2012 13:47:36 UTC+1 schrieb Alberto Ganesh Barbati=
:
>
>
> Il giorno 21/dic/2012, alle ore 13:39, stackm...@hotmail.com <javascript:=
>ha scritto:=20
>
> > What about =A7?=20
> >=20
>
> It has to be in the "basic source character set" (see 2.3/2). =A7 is not=
=20
> part of it.=20
>
> Ganesh=20
>
> Neither are @ or $.=20

--=20




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

Am Freitag, 21. Dezember 2012 13:47:36 UTC+1 schrieb Alberto Ganesh Barbati=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">
<br>Il giorno 21/dic/2012, alle ore 13:39, <a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"r6ghmkgWwz0J">stackm...@hotmail.com</a=
> ha scritto:
<br>
<br>&gt; What about =A7?
<br>&gt;=20
<br>
<br>It has to be in the "basic source character set" (see 2.3/2). =A7 is no=
t part of it.
<br>
<br>Ganesh
<br>
<br></blockquote><div>Neither are @ or $. <br></div>

<p></p>

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

------=_Part_215_29235320.1356094242462--

.

On Fri, Dec 21, 2012 at 12:38 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Thu, Dec 20, 2012 at 8:02 PM, Mikael Kilpel=E4inen
> (2) the parameter-list. If the full lambda expression is correctly
> identified, then all implicit arguments are found and generating the
> parameter list is trivial:
>
>    @a + @b * @c  -> ( auto a, auto b, auto c)
>

Before we go any further into bikeshedding territory about which weird
looking symbol is better, let us first note the fact that this syntax
does not really cut it in general. What if I want `(auto c, auto b,
auto a)` instead?

Mit freundlichen Gr=FC=DFen,

Martinho

--=20




.

On Fri, Dec 21, 2012 at 9:58 AM, Martinho Fernandes
<martinho.fernandes@gmail.com> wrote:

> What if I want `(auto c, auto b, auto a)` instead?
>

OK. I thought I should address that but figured it might not be
necessary. But it is, so:

There is *absolutely no difference in the observed behavior* between

(auto a, auto b, auto c) and (auto a, auto c, auto b)

or any other permutation for that matter.

This is specially true because the order of evaluation to function
arguments is undefined (there is something about parameter order and
default arguments but that is irrelevant here)

The only difference is lexical (what the source code is expressing
about the parameters), and is an important difference but only if you
are indeed expressing a parameter list. In the case in hand we are
specifically not doing that so there is effectively no difference at
all. The corresponding closure type would be defined to have a
parameter list whose parameters  are listed in the order they first
appear in the expression, from left to right.

Best


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




.

On 21/12/12 13:39, Fernando Cacciola wrote:
> On Fri, Dec 21, 2012 at 9:58 AM, Martinho Fernandes
> <martinho.fernandes@gmail.com> wrote:
>
>> What if I want `(auto c, auto b, auto a)` instead?
>>
> OK. I thought I should address that but figured it might not be
> necessary. But it is, so:
>
> There is *absolutely no difference in the observed behavior* between
>
> (auto a, auto b, auto c) and (auto a, auto c, auto b)
>
> or any other permutation for that matter.
>
> This is specially true because the order of evaluation to function
> arguments is undefined (there is something about parameter order and
> default arguments but that is irrelevant here)
>
> The only difference is lexical (what the source code is expressing
> about the parameters), and is an important difference but only if you
> are indeed expressing a parameter list. In the case in hand we are
> specifically not doing that so there is effectively no difference at
> all. The corresponding closure type would be defined to have a
> parameter list whose parameters  are listed in the order they first
> appear in the expression, from left to right.

I think the point was, often function's arguments are not in the same
order as they appear.

For example, I often use lambdas for things like rearranging the
arguments to functions, and filling some values in. Consider for example
wanting to sort largest to smallest, so using [](auto a, auto b) {
return b < a; }.

Now, I could assume in this case that > exists, so I can use @a > @b,
but what if the existing argument was a function f, how I can switch
around the arguments to a function?

Chris

--




.

On Fri, Dec 21, 2012 at 10:45 AM, Chris Jefferson <chris@bubblescope.net> wrote:
>
> Now, I could assume in this case that > exists, so I can use @a > @b, but
> what if the existing argument was a function f, how I can switch around the
> arguments to a function?
>
Ah, OK. I did miss it.

It is a good point indeed, though I think it servers to refine the
proposal more than it would serve to discourage it.

It is certainly important to correlate the implicit parameters to the
actual function arguments. The left to right rule I mentioned could it
but for the sake of the ultimate goal, which is the ability to express
simple lambdas as directly as possible, the proven placeholder syntax
would do just fine.

So, we would have implicit lambda arguments which are of a numerical
form, such as @1 + @2 * 3

It's only natural to ask why not just _1, _2 etc directly since they
are in use already? That would be very nice but I don't think is
possible.


--
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--




.

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

I think the "overly terse" syntax discussion should happen in another
thread as it goes beyond the initial purpose of this one that was feedback
about Faisal's implementation.

Joel Lamotte

--




--f46d042de8070f137304d15d773c
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">I think the &quot;overly terse&quot; syntax discussion should happen in another thread as it goes beyond the initial purpose of this one that was feedback about Faisal&#39;s implementation.<br><br>Joel Lamotte<div>
<br></div></div>

<p></p>

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

--f46d042de8070f137304d15d773c--

.

On Thu, Dec 20, 2012 at 12:16 PM, Scott Prager
<splinterofchaos@gmail.com> wrote:
>
> I wrote some tests. A few lines caused the compiler to crash so I commented
> them out and labelled them "Crash!".
>
> https://gist.github.com/4347130
>

Ok the latest snapshot contains fixes for all the crashes except for
one which I have been unable to replicate (but am still trying a few
things):
// Crash!
auto singleton2 = []( auto x ) Singleton <typename
std::decay<decltype(x)>::type> ( std::move(x) );

Also, iostreams on linux and mac (in reference to our discussion on
reddit) should now work too.

Once again - thanks for all your feedback and help!

--




.

On Wed, Dec 19, 2012 at 8:41 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Tue, Dec 18, 2012 at 12:50 PM,  <travis@solidfire.com> wrote:
>> The `auto` is required is disambiguate this:
>>
>> [] (a) {}
>>
>> Is `a` an automatically-typed variable or an unnamed argument with the type
>> `a`?
>>
> Really?
>
> Not according to the relevant paper:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf
>
> Where it specifically says that auto is NOT allowed (not just not
> required), which necessarily disallows unnamed parameters precisely to
> avoid the ambiguity.
>
> Has this changed? I like it better without auto FWIW
>

There was a very strong preference in the Evolution Room of the
Portland Meeting for auto to be mandatory.  I believe either option
can be reasonably implemented.

--




.

On 20 December 2012 23:43, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
>> Some further points: I would also prefer
>> 1) not adding $ or @ for just lambda uses
>> 2) not adding yet-another-meaning-in-yet-another-language for $ or @
>> The second point is for those of us unfortunate enough to get
>> occasional exposure to
>> shell scripts, perl, and ruby.
> At the risk of digressing, can you tell us why? I use those languages
> every once in a while and from all the complaints I have, their markup
> for variable names has never been one.

I don't hugely mind their markup for variable names. I do mind if c++ suddenly
gains a different markup for variables using $ or @. That's my beef with those,
more meanings to symbols commonly found in other languages.

> However, I believe lambdas should be the exception.
> The reason is that a lambda expression is, IMO, all about tersity. I
> don't need a lambda at all. I can write the function object myself.
> In fact, to be honest, that's what I do, and because I still don't
> find the syntax convenient enough.
> Like I said before, IMO a lambda is nothing but a metaprogramming
> construct to help me generate a function object easily. The more
> simple than writing the function object it is, the more valuable.

I daresay I disagree - maximizing the ease of writing the function at all costs
is not what I'm after, because I have to read the resulting code many more
times than I have to write it. That is why I prefer using auto, and not trying
to make the syntax as terse as possible.

--




.

--0015174c12cec7de8804d13fd030
Content-Type: text/plain; charset=ISO-8859-1

On 19 December 2012 20:41, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:

> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf
>
> Where it specifically says that auto is NOT allowed (not just not
> required), which necessarily disallows unnamed parameters precisely to
> avoid the ambiguity.
>

Wouldn't that be a breaking change from C++11 lambdas?


> Has this changed?


The paper cited is pre-Portland.  According to n3488:  "Reviewed by EWG in
Portland, proceeding with a follow-up paper."
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




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

On 19 December 2012 20:41, Fernando Cacciola <span dir=3D"ltr">&lt;<a href=
=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciola=
@gmail.com</a>&gt;</span> wrote:<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"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pa=
pers/2012/n3418.pdf" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2012/n3418.pdf</a></div>
<br>
Where it specifically says that auto is NOT allowed (not just not<br>
required), which necessarily disallows unnamed parameters precisely to<br>
avoid the ambiguity.<br></blockquote><div><br></div><div>Wouldn&#39;t that =
be a breaking change from C++11 lambdas?</div><div>=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">

Has this changed?</blockquote><div><br></div><div>The paper cited is pre-Po=
rtland. =A0According to n3488: =A0&quot;<span class=3D"Apple-style-span" st=
yle=3D"font-family:Times;font-size:medium">Reviewed by EWG in Portland, pro=
ceeding with a follow-up paper.&quot;</span></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 />

--0015174c12cec7de8804d13fd030--

.

--f46d040168dd1a891304d14ccd7c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 20 December 2012 11:59, Herb Sutter <hsutter@microsoft.com> wrote:

>
> I still think there=92s real demand for the terse form that doesn=92t req=
uire
> =91auto=92, but there is a design tension here that we=92re still working=
 out.
>

Could you use a different operator to mean auto in this context?  Something
like:

[](+a, +b){}

Note:  I'm not necessarily endorsing this kind of thing; I'm just throwing
it into the design space.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20




--f46d040168dd1a891304d14ccd7c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 20 December 2012 11:59, Herb Sutter <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:hsutter@microsoft.com" target=3D"_blank">hsutter@microsoft.com</a>&gt;<=
/span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">







<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US">
<div><br><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family=
:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I still think th=
ere=92s real demand for the terse form that doesn=92t require =91auto=92, b=
ut there is a design tension here that we=92re still working out.</span></p=
>

</div></div></blockquote><div><br>Could you use a different operator to mea=
n auto in this context?=A0 Something like:<br><br>[](+a, +b){}<br><br>Note:=
=A0 I&#39;m not necessarily endorsing this kind of thing; I&#39;m just thro=
wing it into the design space.<br clear=3D"all">

</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<br>

<p></p>

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

--f46d040168dd1a891304d14ccd7c--

.

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

On 19 December 2012 22:49, Faisal Vali <faisalv@gmail.com> wrote:

>
> There was a very strong preference in the Evolution Room of the
> Portland Meeting for auto to be mandatory.  I believe either option
> can be reasonably implemented.
>

I believe something has to be there (for the reasons I've stated earlier in
this thread), but I don't remember discussing if it has to be spelled
"auto" and/or another, one-character token could work as well.

And terseness for short expressions is growing on me...
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




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

On 19 December 2012 22:49, Faisal Vali <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:faisalv@gmail.com" target=3D"_blank">faisalv@gmail.com</a>&gt;</span> w=
rote:<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"HOEnZb"><div class=3D"h5"><br>
</div></div>There was a very strong preference in the Evolution Room of the=
<br>
Portland Meeting for auto to be mandatory. =A0I believe either option<br>
can be reasonably implemented.<br clear=3D"all"></blockquote></div><br>I be=
lieve something has to be there (for the reasons I&#39;ve stated earlier in=
 this thread), but I don&#39;t remember discussing if it has to be spelled =
&quot;auto&quot; and/or another, one-character token could work as well.<br=
>

<br>And terseness for short expressions is growing on me...<br>-- <br>=A0Ne=
vin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlor=
d.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404<b=
r>

<p></p>

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

--f46d0401fe6f9f357604d165bd40--

.

------=_Part_115_4866483.1356793280678
Content-Type: text/plain; charset=ISO-8859-1

so, maybe it'd make sense to introduce some special keyword to disambiguate
these cases?

On Tuesday, December 18, 2012 5:50:50 PM UTC+2, tra...@solidfire.com wrote:
>
> The `auto` is required is disambiguate this:
>
> [] (a) {}
>
> Is `a` an automatically-typed variable or an unnamed argument with the
> type `a`?
>
> On Monday, December 17, 2012 3:38:25 PM UTC-7, dain...@gmail.com wrote:
>>
>> Cool :)
>>
>>  Why is "auto" required though? It seems like it would work fine without
>> the keyword..?
>>
>>
>>

--




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

so, maybe it'd make sense to introduce some special keyword to disambiguate=
 these cases?<br><br>On Tuesday, December 18, 2012 5:50:50 PM UTC+2, tra...=
@solidfire.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The `auto=
` is required is disambiguate this:<br><br>[] (a) {}<br><br>Is `a` an autom=
atically-typed variable or an unnamed argument with the type `a`?<br><br>On=
 Monday, December 17, 2012 3:38:25 PM UTC-7, <a>dain...@gmail.com</a> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">Cool :)<div><br></div><div>&nbsp;W=
hy is "auto" required though? It seems like it would work fine without the =
keyword..?</div><div><br></div><div><br></div></blockquote></blockquote>

<p></p>

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

------=_Part_115_4866483.1356793280678--

.

------=_Part_15_9116852.1357934648284
Content-Type: text/plain; charset=ISO-8859-1

I find the current proposal extremely disappointing. If you use lambda's in
C#, you can see how elegant they _can_ be. Requiring a type specification
for each parameter is cumbersome and ugly. I don't see any reason why each
argument to a lambda can't have an implicit template type assigned to it,
that can then be inferred by the call context. It doesn't make semantic
difference, it is just syntactic sugar. Trying to infer a single token in
the parameter list of a lambda as a typename is silly, since it doesn't
make any sense to do so.

In addition, I understand that Bjarne wants concepts, and many other people
do too. However, I don't think _anything_ should be predicated on concepts
ever happening. I for one am not confident they ever will, and I find it
frustrating that using lambdas has to be desecrated because concepts
"might" happen in our lifetime.


On Friday, December 21, 2012 7:06:10 PM UTC-5, Nevin ":-)" Liber wrote:
>
> On 19 December 2012 22:49, Faisal Vali <fai...@gmail.com <javascript:>>wrote:
>
>>
>> There was a very strong preference in the Evolution Room of the
>> Portland Meeting for auto to be mandatory.  I believe either option
>> can be reasonably implemented.
>>
>
> I believe something has to be there (for the reasons I've stated earlier
> in this thread), but I don't remember discussing if it has to be spelled
> "auto" and/or another, one-character token could work as well.
>
> And terseness for short expressions is growing on me...
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

--




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

I find the current proposal extremely disappointing. If you use lambda's in=
 C#, you can see how elegant they _can_ be. Requiring a type specification =
for each parameter is cumbersome and ugly. I don't see any reason why each =
argument to a lambda can't have an implicit template type assigned to it, t=
hat can then be inferred by the call context. It doesn't make semantic diff=
erence, it is just syntactic sugar. Trying to infer a single token in the p=
arameter list of a lambda as a typename is silly, since it doesn't make any=
 sense to do so.<div><br></div><div>In addition, I understand that Bjarne w=
ants concepts, and many other people do too. However, I don't think _anythi=
ng_ should be predicated on concepts ever happening. I for one am not confi=
dent they ever will, and I find it frustrating that using lambdas has to be=
 desecrated because concepts "might" happen in our lifetime.</div><div><br>=
</div><div><br>On Friday, December 21, 2012 7:06:10 PM UTC-5, Nevin ":-)" L=
iber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 19 December 2012=
 22:49, Faisal Vali <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"KkRvDXKggyoJ">fai...@gmail.com</a>&gt;</s=
pan> wrote:<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><div><br>
</div></div>There was a very strong preference in the Evolution Room of the=
<br>
Portland Meeting for auto to be mandatory. &nbsp;I believe either option<br=
>
can be reasonably implemented.<br clear=3D"all"></blockquote></div><br>I be=
lieve something has to be there (for the reasons I've stated earlier in thi=
s thread), but I don't remember discussing if it has to be spelled "auto" a=
nd/or another, one-character token could work as well.<br>

<br>And terseness for short expressions is growing on me...<br>-- <br>&nbsp=
;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"KkRvDXKggyoJ">ne...@eviloverlord.com</a><wbr>&g=
t;&nbsp; (847) 691-1404<br>
</blockquote></div>

<p></p>

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

------=_Part_15_9116852.1357934648284--

.

------=_Part_249_30012442.1357934889944
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, December 29, 2012 10:01:20 AM UTC-5, innoc...@gmail.com wrote:
>
> so, maybe it'd make sense to introduce some special keyword to
> disambiguate these cases?
>
> On Tuesday, December 18, 2012 5:50:50 PM UTC+2, tra...@solidfire.comwrote:
>>
>> The `auto` is required is disambiguate this:
>>
>> [] (a) {}
>>
>> Is `a` an automatically-typed variable or an unnamed argument with the
>> type `a`?
>>
>
It's an automatically-typed variable. Having an unnamed argument in a
lambda in senseless. You can't overload it, so using it to force the
compiler to choose some version of a function isn't possible. You can't
refer to it. It is therefore silly to create problem which does not, in
practice, exist.



--




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

<br><br>On Saturday, December 29, 2012 10:01:20 AM UTC-5, innoc...@gmail.co=
m wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">so, maybe it'd make se=
nse to introduce some special keyword to disambiguate these cases?<br><br>O=
n Tuesday, December 18, 2012 5:50:50 PM UTC+2, <a>tra...@solidfire.com</a> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">The `auto` is required is dis=
ambiguate this:<br><br>[] (a) {}<br><br>Is `a` an automatically-typed varia=
ble or an unnamed argument with the type `a`?<br></blockquote></blockquote>=
<div><br></div><div>It's an automatically-typed variable. Having an unnamed=
 argument in a lambda in senseless. You can't overload it, so using it to f=
orce the compiler to choose some version of a function isn't possible. You =
can't refer to it. It is therefore silly to create problem which does not, =
in practice, exist.</div><div><br></div><div>&nbsp;</div>

<p></p>

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

------=_Part_249_30012442.1357934889944--

.

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

On 11 January 2013 14:08, <nadiasvertex@gmail.com> wrote:

>
>
> On Tuesday, December 18, 2012 5:50:50 PM UTC+2, tra...@solidfire.comwrote:
>>>
>>> The `auto` is required is disambiguate this:
>>>
>>> [] (a) {}
>>>
>>> Is `a` an automatically-typed variable or an unnamed argument with the
>>> type `a`?
>>>
>>
> It's an automatically-typed variable. Having an unnamed argument in a
> lambda in senseless. You can't overload it, so using it to force the
> compiler to choose some version of a function isn't possible. You can't
> refer to it. It is therefore silly to create problem which does not, in
> practice, exist.
>

The reasons for not doing so have already been discussed at length in this
thread; it may be worth reviewing the whole discussion.  I'm not seeing any
new information here.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




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

On 11 January 2013 14:08,  <span dir=3D"ltr">&lt;<a href=3D"mailto:nadiasve=
rtex@gmail.com" target=3D"_blank">nadiasvertex@gmail.com</a>&gt;</span> wro=
te:<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"><br><br><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Tuesda=
y, December 18, 2012 5:50:50 PM UTC+2, <a>tra...@solidfire.com</a> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">

The `auto` is required is disambiguate this:<br><br>[] (a) {}<br><br>Is `a`=
 an automatically-typed variable or an unnamed argument with the type `a`?<=
br></blockquote></blockquote><div><br></div></div><div>It&#39;s an automati=
cally-typed variable. Having an unnamed argument in a lambda in senseless. =
You can&#39;t overload it, so using it to force the compiler to choose some=
 version of a function isn&#39;t possible. You can&#39;t refer to it. It is=
 therefore silly to create problem which does not, in practice, exist.</div=
>

</blockquote><div><br></div><div>The reasons for not doing so have already =
been discussed at length in this thread; it may be worth reviewing the whol=
e discussion. =A0I&#39;m not seeing any new information here.</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 />

--f46d043bd988549b3204d3090391--

.

On 11 January 2013 22:08,  <nadiasvertex@gmail.com> wrote:
>>> [] (a) {}
>>> Is `a` an automatically-typed variable or an unnamed argument with the
>>> type `a`?
> It's an automatically-typed variable. Having an unnamed argument in a lambda
> in senseless. You can't overload it, so using it to force the compiler to
> choose some version of a function isn't possible. You can't refer to it. It
> is therefore silly to create problem which does not, in practice, exist.

How is an unnamed argument more senseless in a lambda than in a function,
where I use it for ignoring a parameter without polluting the function body with
a superfluous name?

--




.

--047d7b5d480804837e04d30910d9
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 11, 2013 at 1:08 PM, <nadiasvertex@gmail.com> wrote:

>
>
> It's an automatically-typed variable. Having an unnamed argument in a
> lambda in senseless. You can't overload it, so using it to force the
> compiler to choose some version of a function isn't possible. You can't
> refer to it. It is therefore silly to create problem which does not, in
> practice, exist.
>
>

I agree that's how I would have written the rule if I was starting from
scratch -- the issue is that there is already a C++11 standard which
unambiguously *requires* [] (a) {} to be parsed as an unnamed argument. It
will be a very tough fight to get the committee to approve a breaking
change.

Besides, there are legitimate use cases for unnamed arguments in lambda
functions:

void foo(void (*)(Info, Extra));
foo([] (Info x, Extra) { ... });

--=20
Travis Gockel
=EB Combinator

--=20




--047d7b5d480804837e04d30910d9
Content-Type: text/html; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 11, 2013 at 1:08 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:n=
adiasvertex@gmail.com" target=3D"_blank">nadiasvertex@gmail.com</a>&gt;</sp=
an> wrote:<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"><br><br></div><div>It&#39;s an automatically-typed variab=
le. Having an unnamed argument in a lambda in senseless. You can&#39;t over=
load it, so using it to force the compiler to choose some version of a func=
tion isn&#39;t possible. You can&#39;t refer to it. It is therefore silly t=
o create problem which does not, in practice, exist.</div>
<span class=3D"HOEnZb"><font color=3D"#888888"><div>=A0</div>
</font></span></blockquote></div><br>I agree that&#39;s how I would have wr=
itten the rule if I was starting from scratch -- the issue is that there is=
 already a C++11 standard which unambiguously <i>requires</i>=A0[] (a) {} t=
o be parsed as an unnamed argument. It will be a very tough fight to get th=
e committee to approve a breaking change.<div>
<br></div><div>Besides, there are legitimate use cases for unnamed argument=
s in lambda functions:<br><div><br></div><div>void foo(void (*)(Info, Extra=
));</div><div>foo([] (Info x, Extra) { ... });</div><div><div><br></div>
<div>--=A0</div>Travis Gockel<div>=EB Combinator<br><div><br></div></div>
</div></div>

<p></p>

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

--047d7b5d480804837e04d30910d9--

.

------=_Part_551_16652956.1357936582937
Content-Type: text/plain; charset=ISO-8859-1



On Friday, January 11, 2013 12:19:42 PM UTC-8, Ville Voutilainen wrote:
>
> On 11 January 2013 22:08,  <nadias...@gmail.com <javascript:>> wrote:
> >>> [] (a) {}
> >>> Is `a` an automatically-typed variable or an unnamed argument with the
> >>> type `a`?
> > It's an automatically-typed variable. Having an unnamed argument in a
> lambda
> > in senseless. You can't overload it, so using it to force the compiler
> to
> > choose some version of a function isn't possible. You can't refer to it.
> It
> > is therefore silly to create problem which does not, in practice, exist.
>
> How is an unnamed argument more senseless in a lambda than in a function,
> where I use it for ignoring a parameter without polluting the function
> body with
> a superfluous name?
>

A name is more "pollution" than always having to take up precious space for
short functions with a completely pointless type? I mean, it's only
pollution when you don't need it, right? Whereas a typename is *always*pollution when it's just `auto`. So if you're getting "environment
friendly", you should be supporting the one that removes the pollution in
more cases.

The problem is that this is a breaking change. So we need a solution to
that problem. Has anyone considered special lambda declaration syntax that
changes the grammar to mean "just an identifier means `auto <identifier>`,
not `type`"? Something like this maybe (I am not well-versed enough in C++
grammar to know if this would work. It's just an example):

[]a(var1, var2, var3) {...}

Where `a` is one of those "special identifier" type things that isn't a
keyword. Or maybe you can use double parenthesis: (( )). There has to be *
some* grammar that's reasonably short that can take out the pointless word
cruft of `auto` from the declaration.

--




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

<br><br>On Friday, January 11, 2013 12:19:42 PM UTC-8, Ville Voutilainen wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">On 11 January 2013 22:08, =
&nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"LAVtGfdHx3YJ">nadias...@gmail.com</a>&gt; wrote:
<br>&gt;&gt;&gt; [] (a) {}
<br>&gt;&gt;&gt; Is `a` an automatically-typed variable or an unnamed argum=
ent with the
<br>&gt;&gt;&gt; type `a`?
<br>&gt; It's an automatically-typed variable. Having an unnamed argument i=
n a lambda
<br>&gt; in senseless. You can't overload it, so using it to force the comp=
iler to
<br>&gt; choose some version of a function isn't possible. You can't refer =
to it. It
<br>&gt; is therefore silly to create problem which does not, in practice, =
exist.
<br>
<br>How is an unnamed argument more senseless in a lambda than in a functio=
n,
<br>where I use it for ignoring a parameter without polluting the function =
body with
<br>a superfluous name?
<br></blockquote><div><br>A name is more "pollution" than always having to =
take up precious space for short functions with a completely pointless type=
? I mean, it's only pollution when you don't need it, right? Whereas a type=
name is <i>always</i> pollution when it's just `auto`. So if you're getting=
 "environment friendly", you should be supporting the one that removes the =
pollution in more cases.<br><br>The problem is that this is a breaking chan=
ge. So we need a solution to that problem. Has anyone considered special la=
mbda declaration syntax that changes the grammar to mean "just an identifie=
r means `auto &lt;identifier&gt;`, not `type`"? Something like this maybe (=
I am not well-versed enough in C++ grammar to know if this would work. It's=
 just an example):<br><br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; 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">[]</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">var1</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> var2</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> var3</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 style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span></div></code></div><br>Where `a` is one of those "special =
identifier" type things that isn't a keyword. Or maybe you can use double p=
arenthesis: (( )). There has to be <i>some</i> grammar that's reasonably sh=
ort that can take out the pointless word cruft of `auto` from the declarati=
on.<br></div>

<p></p>

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

------=_Part_551_16652956.1357936582937--

.

On 11 January 2013 22:36, Nicol Bolas <jmckesson@gmail.com> wrote:
> A name is more "pollution" than always having to take up precious space for
> short functions with a completely pointless type? I mean, it's only
> pollution when you don't need it, right? Whereas a typename is always
> pollution when it's just `auto`. So if you're getting "environment
> friendly", you should be supporting the one that removes the pollution in
> more cases.

I consider the proposed inconsistencies between lambdas and functions
unfortunate, and
I'm not convinced that the "precious" space is that precious when I'm
reading code.

--




.

On Fri, Jan 11, 2013 at 2:23 PM, Travis Gockel <travis@gockelhut.com> wrote:
> Besides, there are legitimate use cases for unnamed arguments in lambda
> functions:
>
> void foo(void (*)(Info, Extra));
> foo([] (Info x, Extra) { ... });

A single name is ambiguous here, however, I noticed that a reference
without a type-specifier is not, like

    [] (&a) { ... }

So, how about enforce a special prefix to non-reference parameters? Like:

    [] (=a) { ... }

Thus, the two grammars above are two generic lambda parameters.

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

--




.

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

On 11 January 2013 14:36, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> []a(var1, var2, var3) {...}
>
> Ultimately, people are going to want to mix concrete types and templated
types, as they do with templated functions now.

Part of the charter of EWG is to look at the language "as a whole".  Making
the declarations work in a way that is inconsistent with the rest of the
language goes against this, IMHO.

Also, the more complicated this proposal gets, the less likely it'll make
it into C++14 (whose charter is to "Complete C++11", not invent a whole
bunch of new things).  Are polymorphic lambdas a feature you'd rather see
sooner than later?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




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

On 11 January 2013 14:36, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mail=
to:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span=
> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code=
><div><span style=3D"color:#660">[]</span><span style>a</span><span style=
=3D"color:#660">(</span><span style>var1</span><span style=3D"color:#660">,=
</span><span style> var2</span><span style=3D"color:#660">,</span><span sty=
le> var3</span><span style=3D"color:#660">)</span><span style> </span><span=
 style=3D"color:#660">{...}</span><span style><br>

</span></div></code></div><br></div></blockquote><div>Ultimately, people ar=
e going to want to mix concrete types and templated types, as they do with =
templated functions now.<br><br>Part of the charter of EWG is to look at th=
e language &quot;as a whole&quot;.=A0 Making the declarations work in a way=
 that is inconsistent with the rest of the language goes against this, IMHO=
..<br>

<br>Also, the more complicated this proposal gets, the less likely it&#39;l=
l make it into C++14 (whose charter is to &quot;Complete C++11&quot;, not i=
nvent a whole bunch of new things).=A0 Are polymorphic lambdas a feature yo=
u&#39;d rather see sooner than later?</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 />

--bcaec554d29a13c32204d309a581--

.

------=_Part_452_26629095.1357938661777
Content-Type: text/plain; charset=ISO-8859-1



> Besides, there are legitimate use cases for unnamed arguments in lambda
> functions:
>
> void foo(void (*)(Info, Extra));
> foo([] (Info x, Extra) { ... });
>
>
I don't see that as so compelling a reason as to _require_ a typename. The
fact that it might occasionally be convenient to do that is outweighed by
the fact that it is nearly always more convenient (and clear) to omit the
type names from a lambda parameter list.

--




------=_Part_452_26629095.1357938661777
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;"><div>Besides, there are le=
gitimate use cases for unnamed arguments in lambda functions:<br><div><br><=
/div><div>void foo(void (*)(Info, Extra));</div><div>foo([] (Info x, Extra)=
 { ... });</div><div><div><br></div></div></div></blockquote><div><br></div=
><div>I don't see that as so compelling a reason as to _require_ a typename=
.. The fact that it might occasionally be convenient to do that is outweighe=
d by the fact that it is nearly always more convenient (and clear) to omit =
the type names from a lambda parameter list.&nbsp;</div>

<p></p>

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

------=_Part_452_26629095.1357938661777--

.

------=_Part_319_15629774.1357938864947
Content-Type: text/plain; charset=ISO-8859-1


On Friday, January 11, 2013 3:23:03 PM UTC-5, Travis Gockel wrote:
>
> On Fri, Jan 11, 2013 at 1:08 PM, <nadias...@gmail.com <javascript:>>wrote:
>
>>
>>
>> It's an automatically-typed variable. Having an unnamed argument in a
>> lambda in senseless. You can't overload it, so using it to force the
>> compiler to choose some version of a function isn't possible. You can't
>> refer to it. It is therefore silly to create problem which does not, in
>> practice, exist.
>>
>>
>
> I agree that's how I would have written the rule if I was starting from
> scratch -- the issue is that there is already a C++11 standard which
> unambiguously *requires* [] (a) {} to be parsed as an unnamed argument.
> It will be a very tough fight to get the committee to approve a breaking
> change.


That may be social reason for the sad "auto" requirement rule, but it is
not a satisfying one. Users will gasp in horror, as I did, when they view
the mess that has been made of something that can be elegant and readable.
As demonstrated by many modern programming languages that support a
non-desecrated syntax for lambdas.

--




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

<br>On Friday, January 11, 2013 3:23:03 PM UTC-5, Travis Gockel wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On Fri, Jan 11, 2013 at 1:08 PM,  <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"q3r6OTzyfAkJ">nadias...@gmail.com</a>&gt;</span> wrote:<br><di=
v 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><br><br></div><div>It's an automatically-typed variable. Having an unn=
amed argument in a lambda in senseless. You can't overload it, so using it =
to force the compiler to choose some version of a function isn't possible. =
You can't refer to it. It is therefore silly to create problem which does n=
ot, in practice, exist.</div>
<span><font color=3D"#888888"><div>&nbsp;</div>
</font></span></blockquote></div><br>I agree that's how I would have writte=
n the rule if I was starting from scratch -- the issue is that there is alr=
eady a C++11 standard which unambiguously <i>requires</i>&nbsp;[] (a) {} to=
 be parsed as an unnamed argument. It will be a very tough fight to get the=
 committee to approve a breaking change.</blockquote><div>&nbsp;</div><div>=
That may be social reason for the sad "auto" requirement rule, but it is no=
t a satisfying one. Users will gasp in horror, as I did, when they view the=
 mess that has been made of something that can be elegant and readable. As =
demonstrated by many modern programming languages that support a non-desecr=
ated syntax for lambdas.</div><div><br></div>

<p></p>

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

------=_Part_319_15629774.1357938864947--

.

------=_Part_409_20674713.1357938959688
Content-Type: text/plain; charset=ISO-8859-1



On Friday, January 11, 2013 4:04:04 PM UTC-5, Nevin ":-)" Liber wrote:
>
> On 11 January 2013 14:36, Nicol Bolas <jmck...@gmail.com <javascript:>>wrote:
>
>>
>> []a(var1, var2, var3) {...}
>>
>> Ultimately, people are going to want to mix concrete types and templated
> types, as they do with templated functions now.
>
> Part of the charter of EWG is to look at the language "as a whole".
> Making the declarations work in a way that is inconsistent with the rest of
> the language goes against this, IMHO.
>
> Also, the more complicated this proposal gets, the less likely it'll make
> it into C++14 (whose charter is to "Complete C++11", not invent a whole
> bunch of new things).  Are polymorphic lambdas a feature you'd rather see
> sooner than later?
>

This is not a new invention. According to the footnote in the proposal, the
auto-less syntax was the intended direction:

1 Lawrence Crowl: "Yes. The intent was to expand lambda in just this
direction after 2012."

Taken from page 2 of N3418=12-0108.

--




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

<br><br>On Friday, January 11, 2013 4:04:04 PM UTC-5, Nevin ":-)" Liber wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On 11 January 2013 14:36, N=
icol Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"j5-CjX84rLIJ">jmck...@gmail.com</a>&gt;</span> wro=
te:<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">

<br><div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code=
><div><span style=3D"color:#660">[]</span><span>a</span><span style=3D"colo=
r:#660">(</span><span>var1</span><span style=3D"color:#660">,</span><span> =
var2</span><span style=3D"color:#660">,</span><span> var3</span><span style=
=3D"color:#660">)</span><span> </span><span style=3D"color:#660">{...}</spa=
n><span><br>

</span></div></code></div><br></div></blockquote><div>Ultimately, people ar=
e going to want to mix concrete types and templated types, as they do with =
templated functions now.<br><br>Part of the charter of EWG is to look at th=
e language "as a whole".&nbsp; Making the declarations work in a way that i=
s inconsistent with the rest of the language goes against this, IMHO.<br>

<br>Also, the more complicated this proposal gets, the less likely it'll ma=
ke it into C++14 (whose charter is to "Complete C++11", not invent a whole =
bunch of new things).&nbsp; Are polymorphic lambdas a feature you'd rather =
see sooner than later?</div></div></blockquote><div><br></div><div>This is =
not a new invention. According to the footnote in the proposal, the auto-le=
ss syntax was the intended direction:&nbsp;</div><div><br></div><div>1 Lawr=
ence Crowl: "Yes. The intent was to expand lambda in just this direction af=
ter 2012."</div><div><br></div><div>Taken from page 2 of N3418=3D12-0108.&n=
bsp;</div>

<p></p>

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

------=_Part_409_20674713.1357938959688--

.

On Fri, Jan 11, 2013 at 12:23 PM, Travis Gockel <travis@gockelhut.com> wrote:
> On Fri, Jan 11, 2013 at 1:08 PM, <nadiasvertex@gmail.com> wrote:
>>
>>
>>
>> It's an automatically-typed variable. Having an unnamed argument in a
>> lambda in senseless. You can't overload it, so using it to force the
>> compiler to choose some version of a function isn't possible. You can't
>> refer to it. It is therefore silly to create problem which does not, in
>> practice, exist.
>>
>
>
> I agree that's how I would have written the rule if I was starting from
> scratch -- the issue is that there is already a C++11 standard which
> unambiguously requires [] (a) {} to be parsed as an unnamed argument. It
> will be a very tough fight to get the committee to approve a breaking
> change.

I'm not sure that's the case, and it seems worthwhile to put it to the
committee rather than assuming they would oppose it. I would support
such a breaking change, and several other members of the committee
whom I've spoken to were surprised to learn that the parameter name
for a lambda had become optional (in earlier drafts of the lambda
proposal, it was mandatory, in order to allow this extension at a
later date).

--




.

------=_Part_715_27386109.1357940448545
Content-Type: text/plain; charset=ISO-8859-1



On Friday, January 11, 2013 1:04:04 PM UTC-8, Nevin ":-)" Liber wrote:
>
> On 11 January 2013 14:36, Nicol Bolas <jmck...@gmail.com <javascript:>>wrote:
>
>>
>> []a(var1, var2, var3) {...}
>>
>> Ultimately, people are going to want to mix concrete types and templated
> types, as they do with templated functions now.
>

The different rule would only come into play with arguments that are just
an identifier. It says that with identifier-only arguments, the identifier
specifies a argument who's type is automatically deduced and who's name is
given.

Part of the charter of EWG is to look at the language "as a whole".  Making
> the declarations work in a way that is inconsistent with the rest of the
> language goes against this, IMHO.
>

This will be neither the first nor the last time that changes enter the
standard that are "inconsistent with the rest of the language".

Also, the more complicated this proposal gets, the less likely it'll make
> it into C++14 (whose charter is to "Complete C++11", not invent a whole
> bunch of new things).  Are polymorphic lambdas a feature you'd rather see
> sooner than later?
>

No. I would much rather have to wait until C++17 to get polymorphic lambdas
*correctly* than to have a long-winded, broken version *forever in the
language*, with no possibilities of ever correcting the syntax. I would
rather have to write the class by hand than to have horrible syntax like
what is being proposed.

However, it would be a strong demonstration of the *failure* of the
standardization process and the committee if we can't get something that so
effectively describes what the user wants into C++14.

--




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

<br><br>On Friday, January 11, 2013 1:04:04 PM UTC-8, Nevin ":-)" Liber wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On 11 January 2013 14:36, N=
icol Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"j5-CjX84rLIJ">jmck...@gmail.com</a>&gt;</span> wro=
te:<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">

<br><div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code=
><div><span style=3D"color:#660">[]</span><span>a</span><span style=3D"colo=
r:#660">(</span><span>var1</span><span style=3D"color:#660">,</span><span> =
var2</span><span style=3D"color:#660">,</span><span> var3</span><span style=
=3D"color:#660">)</span><span> </span><span style=3D"color:#660">{...}</spa=
n><span><br>

</span></div></code></div><br></div></blockquote><div>Ultimately, people ar=
e going to want to mix concrete types and templated types, as they do with =
templated functions now.<br></div></div></blockquote><div><br>The different=
 rule would only come into play with arguments that are just an identifier.=
 It says that with identifier-only arguments, the identifier specifies a ar=
gument who's type is automatically deduced and who's name is given.<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quot=
e"><div>Part of the charter of EWG is to look at the language "as a whole".=
&nbsp; Making the declarations work in a way that is inconsistent with the =
rest of the language goes against this, IMHO.<br></div></div></blockquote><=
div><br>This will be neither the first nor the last time that changes enter=
 the standard that are "inconsistent with the rest of the language".<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 class=3D"gmail_quo=
te"><div>

Also, the more complicated this proposal gets, the less likely it'll make i=
t into C++14 (whose charter is to "Complete C++11", not invent a whole bunc=
h of new things).&nbsp; Are polymorphic lambdas a feature you'd rather see =
sooner than later?</div></div></blockquote><div><br>No. I would much rather=
 have to wait until C++17 to get polymorphic lambdas <i>correctly</i> than =
to have a long-winded, broken version <i>forever in the language</i>, with =
no possibilities of ever correcting the syntax. I would rather have to writ=
e the class by hand than to have horrible syntax like what is being propose=
d.<br><br>However, it would be a strong demonstration of the <i>failure</i>=
 of the standardization process and the committee if we can't get something=
 that so effectively describes what the user wants into C++14.</div>

<p></p>

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

------=_Part_715_27386109.1357940448545--

.

------=_Part_427_10071574.1357940512683
Content-Type: text/plain; charset=ISO-8859-1



On Friday, January 11, 2013 1:01:43 PM UTC-8, Zhihao Yuan wrote:
>
> On Fri, Jan 11, 2013 at 2:23 PM, Travis Gockel <tra...@gockelhut.com<javascript:>>
> wrote:
> > Besides, there are legitimate use cases for unnamed arguments in lambda
> > functions:
> >
> > void foo(void (*)(Info, Extra));
> > foo([] (Info x, Extra) { ... });
>
> A single name is ambiguous here, however, I noticed that a reference
> without a type-specifier is not, like
>
>     [] (&a) { ... }
>
> So, how about enforce a special prefix to non-reference parameters? Like:
>
>     [] (=a) { ... }
>
> Thus, the two grammars above are two generic lambda parameters.
>

That works for me. I don't know if the grammar is doable in terms of C++
conflicts and such, but it looks similar to how [] syntax works, so it has
consistency working for it.

--




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

<br><br>On Friday, January 11, 2013 1:01:43 PM UTC-8, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Jan 11, 2013 at 2:23 PM, =
Travis Gockel &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"Xsp2pYfe3-YJ">tra...@gockelhut.com</a>&gt; wrote:
<br>&gt; Besides, there are legitimate use cases for unnamed arguments in l=
ambda
<br>&gt; functions:
<br>&gt;
<br>&gt; void foo(void (*)(Info, Extra));
<br>&gt; foo([] (Info x, Extra) { ... });
<br>
<br>A single name is ambiguous here, however, I noticed that a reference
<br>without a type-specifier is not, like
<br>
<br>&nbsp; &nbsp; [] (&amp;a) { ... }
<br>
<br>So, how about enforce a special prefix to non-reference parameters? Lik=
e:
<br>
<br>&nbsp; &nbsp; [] (=3Da) { ... }
<br>
<br>Thus, the two grammars above are two generic lambda parameters.<br></bl=
ockquote><div><br>That works for me. I don't know if the grammar is doable =
in terms of C++ conflicts and such, but it looks similar to how [] syntax w=
orks, so it has consistency working for it. <br></div>

<p></p>

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

------=_Part_427_10071574.1357940512683--

.

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

On 11 January 2013 15:20, Richard Smith <richard@metafoo.co.uk> wrote:

>
> > I agree that's how I would have written the rule if I was starting from
> > scratch -- the issue is that there is already a C++11 standard which
> > unambiguously requires [] (a) {} to be parsed as an unnamed argument. It
> > will be a very tough fight to get the committee to approve a breaking
> > change.
>
> I'm not sure that's the case, and it seems worthwhile to put it to the
> committee rather than assuming they would oppose it.


A.  It was already brought to the committee in Portland, and the auto-less
syntax was discouraged by EWG.
B.  Some of the people opposing it in this discussion are on that committee.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




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

On 11 January 2013 15:20, Richard Smith <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&gt;=
</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>

<br>
&gt; I agree that&#39;s how I would have written the rule if I was starting=
 from<br>
&gt; scratch -- the issue is that there is already a C++11 standard which<b=
r>
&gt; unambiguously requires [] (a) {} to be parsed as an unnamed argument. =
It<br>
&gt; will be a very tough fight to get the committee to approve a breaking<=
br>
&gt; change.<br>
<br>
I&#39;m not sure that&#39;s the case, and it seems worthwhile to put it to =
the<br>
committee rather than assuming they would oppose it.</blockquote><div><br>A=
..=A0 It was already brought to the committee in Portland, and the auto-less=
 syntax was discouraged by EWG.<br>B.=A0 Some of the people opposing it in =
this discussion are on that committee.<br>

</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 />

--0015175ce0080fef6f04d30a9ee3--

.

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

On 11 January 2013 15:40, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> Part of the charter of EWG is to look at the language "as a whole".
>> Making the declarations work in a way that is inconsistent with the rest of
>> the language goes against this, IMHO.
>>
>
> This will be neither the first nor the last time that changes enter the
> standard that are "inconsistent with the rest of the language".
>

That doesn't mean we should do it gratuitously.  Consistency is hard,
because you cannot be consistent with everything; that doesn't mean you
shouldn't be consistent with anything.


>
>  Also, the more complicated this proposal gets, the less likely it'll make
>> it into C++14 (whose charter is to "Complete C++11", not invent a whole
>> bunch of new things).  Are polymorphic lambdas a feature you'd rather see
>> sooner than later?
>>
>
> No. I would much rather have to wait until C++17 to get polymorphic
> lambdas *correctly* than to have a long-winded, broken version *forever
> in the language*, with no possibilities of ever correcting the syntax.
>


That isn't the choice; if we put it off, who knows what form it will take?
Do you want it in C++14, or are you willing chance waiting until some point
in the future?  5+ years is a long time to wait for a feature people want
now.

Assuming you can convince the committee to reverse its Portland guidance,
one option would be to write and present in Bristol a proposal to deprecate
optional parameter names in lambdas, as that at least paves the way.

IMO, a better (as in a little more likely to succeed) proposal is to come
up with a general terse syntax that is a replacement for

template<typename T>
U foo(T t);
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




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

On 11 January 2013 15:40, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mail=
to:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span=
> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D=
"gmail_quote"><div>Part of the charter of EWG is to look at the language &q=
uot;as a whole&quot;.=A0 Making the declarations work in a way that is inco=
nsistent with the rest of the language goes against this, IMHO.<br>

</div></div></blockquote></div><div><br>This will be neither the first nor =
the last time that changes enter the standard that are &quot;inconsistent w=
ith the rest of the language&quot;.<br></div></blockquote><div><br>That doe=
sn&#39;t mean we should do it gratuitously.=A0 Consistency is hard, because=
 you cannot be consistent with everything; that doesn&#39;t mean you should=
n&#39;t be consistent with anything.<br>

=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div><br></div><div class=3D"im"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">

<div class=3D"gmail_quote"><div>

Also, the more complicated this proposal gets, the less likely it&#39;ll ma=
ke it into C++14 (whose charter is to &quot;Complete C++11&quot;, not inven=
t a whole bunch of new things).=A0 Are polymorphic lambdas a feature you&#3=
9;d rather see sooner than later?</div>

</div></blockquote></div><div><br>No. I would much rather have to wait unti=
l C++17 to get polymorphic lambdas <i>correctly</i> than to have a long-win=
ded, broken version <i>forever in the language</i>, with no possibilities o=
f ever correcting the syntax.</div>

</blockquote><div><br><br>That isn&#39;t the choice; if we put it off, who =
knows what form it will take?=A0 Do you want it in C++14, or are you willin=
g chance waiting until some point in the future?=A0 5+ years is a long time=
 to wait for a feature people want now.<br>

<br>Assuming you can convince the committee to reverse its Portland guidanc=
e, one option would be to write and present in Bristol a proposal to deprec=
ate optional parameter names in lambdas, as that at least paves the way.<br=
>

<br>IMO, a better (as in a little more likely to succeed) proposal is to co=
me up with a general terse syntax that is a replacement for<br><br>template=
&lt;typename T&gt;<br>U foo(T t);<br></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 />

--0015175cfccc210ba704d30ac6a5--

.

--001517475cb08cffca04d30af776
Content-Type: text/plain; charset=ISO-8859-1

On 11 January 2013 15:14, <nadiasvertex@gmail.com> wrote:

>
> On Friday, January 11, 2013 3:23:03 PM UTC-5, Travis Gockel wrote:
>
>>
>> I agree that's how I would have written the rule if I was starting from
>> scratch -- the issue is that there is already a C++11 standard which
>> unambiguously *requires* [] (a) {} to be parsed as an unnamed argument.
>> It will be a very tough fight to get the committee to approve a breaking
>> change.
>
>
> That may be social reason for the sad "auto" requirement rule, but it is
> not a satisfying one.
>

Breakage has a cost and slows adoption.  While some breakage is inevitable,
the bar is high for C++.  Other languages have different constraints.


> Users will gasp in horror,
>

Some users will "gasp in horror" no matter what we do.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--




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

On 11 January 2013 15:14,  <span dir=3D"ltr">&lt;<a href=3D"mailto:nadiasve=
rtex@gmail.com" target=3D"_blank">nadiasvertex@gmail.com</a>&gt;</span> wro=
te:<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">

<br>On Friday, January 11, 2013 3:23:03 PM UTC-5, Travis Gockel wrote:<div =
class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>I agree that&#39;s=
 how I would have written the rule if I was starting from scratch -- the is=
sue is that there is already a C++11 standard which unambiguously <i>requir=
es</i>=A0[] (a) {} to be parsed as an unnamed argument. It will be a very t=
ough fight to get the committee to approve a breaking change.</blockquote>

<div>=A0</div></div><div>That may be social reason for the sad &quot;auto&q=
uot; requirement rule, but it is not a satisfying one.</div></blockquote><d=
iv><br>Breakage has a cost and slows adoption.=A0 While some breakage is in=
evitable, the bar is high for C++.=A0 Other languages have different constr=
aints.<br>

=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div> Users will gasp in horror,</d=
iv></blockquote><div><br>Some users will &quot;gasp in horror&quot; no matt=
er what we do.<br>

</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 />

--001517475cb08cffca04d30af776--

.

------=_Part_349_7766474.1357956736633
Content-Type: text/plain; charset=ISO-8859-1

I have a quick question concerning the standardization of generic lambdas.
I am not sure if this is the place where to ask, so I apologize in advance
if that is not the case.

The current standard forbids declaring local types which contain template
member functions. Clearly, generic lambdas will have to be an exception to
this rule.
My question is: will this restriction be lifted completely, or will generic
lambdas be the only exception allowed?

Thank you for your consideration,

Andy

--




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

I have a quick question concerning the standardization of generic lambdas. =
I am not sure if this is the place where to ask, so I apologize in advance =
if that is not the case.<br><br>The current standard forbids declaring loca=
l types which contain template member functions. Clearly, generic lambdas w=
ill have to be an exception to this rule.<br>My question is: will this rest=
riction be lifted completely, or will generic lambdas be the only exception=
 allowed?<br><br>Thank you for your consideration,<br><br>Andy<br>

<p></p>

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

------=_Part_349_7766474.1357956736633--

.

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

On Friday, December 21, 2012 12:35:55 AM UTC+4, Klaim - Jo=EBl Lamotte wrot=
e:
>
>
> For the example
> auto f =3D [] @a x @b; // maximum tersity
>
> the idea would be to have the expression directly, with just markers to=
=20
> the names which are arguments objects, letting the compiler do the rest.
>
>
> This is a wild idea coming from reading this discussion so it might be=20
> stupid...
> What do you think?
>

Personally, I would prefer to use a short notation like this:

    [][%1 + %2]

rather than

    [](auto &&_1, auto &&_2) { return FORWARD(_1) + FORWARD(_2); }

where FORWARD is defined as

    #define FORWARD(x) static_cast<decltype(x) &&>(x)

The general form with explicit declarations of parameters could still be=20
used when the desirable semantics cannot be expressed via the reduced form.

--=20




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

On Friday, December 21, 2012 12:35:55 AM UTC+4, Klaim - Jo=EBl Lamotte wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>
<br>For the example<br>auto f =3D [] @a x @b; // maximum tersity<br><br>the=
 idea would be to have the expression directly, with just markers to the na=
mes which are arguments objects, letting the compiler do the rest.<br><br>
<br>This is a wild idea coming from reading this discussion so it might be =
stupid...<br>What do you think?<br></div></div></blockquote><div><br>Person=
ally, I would prefer to use a short notation like this:<br><br>&nbsp; &nbsp=
; [][%1 + %2]<br><br>rather than<br><br>&nbsp;&nbsp;&nbsp; [](auto &amp;&am=
p;_1, auto &amp;&amp;_2) { return FORWARD(_1) + FORWARD(_2); }<br><br>where=
 FORWARD is defined as<br><br>&nbsp;&nbsp;&nbsp; #define FORWARD(x) static_=
cast&lt;decltype(x) &amp;&amp;&gt;(x)<br><br>The general form with explicit=
 declarations of parameters could still be used when the desirable semantic=
s cannot be expressed via the reduced form.<br></div>

<p></p>

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

------=_Part_1457_2698121.1357978855888--

.

--047d7bacb360ec727504d315cef0
Content-Type: text/plain; charset=ISO-8859-1

Thank you for your answer.

I was used to think of lambdas as syntactic sugar, but *generic* lambdas
are not: the generated closure breaks the rule from paragraph 14/2:

"A template-declaration can appear only as a namespace scope or class scope
declaration".

I am unaware of the reasons why this restriction exists in the first place
(I did some research but with no success), so I cannot write a proposal on
lifting it. However, if good reasons exist, I am curious whether the fact
that generic lambdas break it will create troubles.

Kind regards,

Andy


 On Sat, Jan 12, 2013 at 5:11 AM, Faisal Vali <faisalv@gmail.com> wrote:

> On Fri, Jan 11, 2013 at 8:12 PM,  <andy.prowl@gmail.com> wrote:
> > I have a quick question concerning the standardization of generic
> lambdas. I
> > am not sure if this is the place where to ask, so I apologize in advance
> if
> > that is not the case.
> >
> > The current standard forbids declaring local types which contain template
> > member functions. Clearly, generic lambdas will have to be an exception
> to
> > this rule.
> > My question is: will this restriction be lifted completely, or will
> generic
> > lambdas be the only exception allowed?
> >
>
> It is my personal opinion that if the restriction on local class
> templates or local member templates is to be lifted, a separate
> proposal would be required (and I really hope someone writes one).  As
> far as I know, the EWG has not had any official discussion so far
> about lifting this restriction (or enabling this feature); but, a
> formal and well thought out proposal could make all the difference...
>

--




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

Thank you for your answer. <br><br>I was used to think of lambdas as syntac=
tic sugar, but *generic* lambdas are not: the generated closure breaks the =
rule from paragraph 14/2: <br><br>&quot;A template-declaration can appear o=
nly as a namespace scope or class scope declaration&quot;. <br>
<br>I am unaware of the reasons why this restriction exists in the first pl=
ace (I did some research but with no success), so I cannot write a proposal=
 on lifting it. However, if good reasons exist, I am curious whether the fa=
ct that generic lambdas break it will create troubles.<br>
<br>Kind regards,<br><br>Andy=A0<br><br><br><div class=3D"gmail_quote">=A0O=
n Sat, Jan 12, 2013 at 5:11 AM, Faisal Vali <span dir=3D"ltr">&lt;<a href=
=3D"mailto:faisalv@gmail.com" target=3D"_blank">faisalv@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Fri, Jan 11, 2013 at 8:=
12 PM, =A0&lt;<a href=3D"mailto:andy.prowl@gmail.com">andy.prowl@gmail.com<=
/a>&gt; wrote:<br>

&gt; I have a quick question concerning the standardization of generic lamb=
das. I<br>
&gt; am not sure if this is the place where to ask, so I apologize in advan=
ce if<br>
&gt; that is not the case.<br>
&gt;<br>
&gt; The current standard forbids declaring local types which contain templ=
ate<br>
&gt; member functions. Clearly, generic lambdas will have to be an exceptio=
n to<br>
&gt; this rule.<br>
&gt; My question is: will this restriction be lifted completely, or will ge=
neric<br>
&gt; lambdas be the only exception allowed?<br>
&gt;<br>
<br>
</div>It is my personal opinion that if the restriction on local class<br>
templates or local member templates is to be lifted, a separate<br>
proposal would be required (and I really hope someone writes one). =A0As<br=
>
far as I know, the EWG has not had any official discussion so far<br>
about lifting this restriction (or enabling this feature); but, a<br>
formal and well thought out proposal could make all the difference...<br>
</blockquote></div><br>

<p></p>

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

--047d7bacb360ec727504d315cef0--

.

------=_Part_648_30492330.1359122112915
Content-Type: text/plain; charset=ISO-8859-1

I disagree. I think it should be resolved the other way, because that's way
more likely to be what's useful. Unused arguments still have the old
C-style void(param) kind of thing. The problem of "Whoops, I can't use
unnamed parameters" is a lot less than "Whoops, every other thing in my
program is the "auto" keyword."

On Wednesday, December 19, 2012 9:45:36 PM UTC, iba...@gmail.com wrote:
>
>
> [] (a) {}
>>
>> Is `a` an automatically-typed variable or an unnamed argument with the
>> type `a`?
>>
>
> Isn't this another case of - if it can be a typename it is a typename?
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To post to this group, send email to std-discussion@isocpp.org.
To unsubscribe from this group, send email to std-discussion+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/?hl=en.



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

I disagree. I think it should be resolved the other way, because that's way=
 more likely to be what's useful. Unused arguments still have the old C-sty=
le void(param) kind of thing. The problem of "Whoops, I can't use unnamed p=
arameters" is a lot less than "Whoops, every other thing in my program is t=
he "auto" keyword."<br><br>On Wednesday, December 19, 2012 9:45:36 PM UTC, =
iba...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">[] (a) {}<br><br>Is `a` an automatical=
ly-typed variable or an unnamed argument with the type `a`?<br></blockquote=
><div><br></div><div>Isn't this another case of - if it can be a typename i=
t is a typename?&nbsp;</div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Discussion&quot; group.<br />
To post to this group, send email to std-discussion@isocpp.org.<br />
To unsubscribe from this group, send email to std-discussion+unsubscribe@is=
ocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-discussion/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-di=
scussion/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_648_30492330.1359122112915--

.