Topic: Request for feedback - default constructed lambda


Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Fri, 15 Mar 2013 10:44:08 -0700 (PDT)
Raw View
------=_Part_302_24242190.1363369448167
Content-Type: multipart/alternative;
 boundary="----=_Part_303_26379951.1363369448168"

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

Hello,

I have written the issue document to the default constructed lambda=20
closures floated up back in December at=20
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/1NFQeAP1=
wJA/discussion.

A small change requires a small document, please check the attachment.

Comments are more than welcome.

Regards, R=F3bert

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

Hello,<br><br>I have written the issue document to the default constructed =
lambda closures floated up back in December at <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/forum/#!topic/std-proposals/1NFQeAP1wJA/discussion">h=
ttps://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/1NFQeAP1w=
JA/discussion</a> .<br><br>A small change requires a small document, please=
 check the attachment.<br><br>Comments are more than welcome.<br><br>Regard=
s, R=F3bert<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_303_26379951.1363369448168--
------=_Part_302_24242190.1363369448167
Content-Type: text/html; charset=US-ASCII;
 name="Default constructed closure types.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Default constructed closure types.html"
X-Attachment-Id: 922d2910-a2a7-4eac-8776-6345cdb45330
Content-ID: <922d2910-a2a7-4eac-8776-6345cdb45330>

<html>
<head>
<title>Default constructed closure types</title>

<style type="text/css">
  ins { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  del { text-decoration:line-through; background-color:#FFA0A0 }
  strong { font-weight: inherit; color: #2020ff }
</style>

</head>

<body>
Nxxxx<br/>
Robert David<br/>
2013-03-15

<h1>Default constructed closure types</h1>

<h2>Motivation</h2>

<p>
One of the primary benefits of introducing lambdas, closure types into C++ was the simplified usage of algorithms that expect a function object for one of its parameters: the function object can be implemented locally as a lambda. They are however not applicable for containers, due to the deleted default constructor of such objects, what in some cases could be useful. For example:
</p>

<pre>
#include &lt;set&gt;
template&lt;typename T&gt
using absset = std::set&lt;T, decltype([](T a, T b) { return std::abs(a) &lt; std::abs(b); })&gt;;

absset&lt;double&gt; f() {
   absset&lt;double&gt; res; // ill-formed C++11
   res.insert(-1.0);
   res.insert( 2.0);
   res.insert(-3.0);
   return res;
}
</pre>

<h2>Scope</h2>

<p>
This paper proposes to add a default constructor to the closure type for lambda expressions with no lambda-capture.
</p>

<p>
Examples:

<pre>
void f()
{
  int a = 42;

  auto x = [](){ return 42; };
  decltype(x) x2;

  auto y = [a](){ return a; };
  decltype(y) y2;                         // ill-formed

  auto z = [=](){ return a; };
  decltype(z) z2;                         // ill-formed
}
</pre>
</p>

<p>
Closure types for lambda expressions with no lambda-captures are already treated differently in regards of available member functions. Such closures have a conversion operator to a pointer-to-function (defined in 5.1.2 paragraph 6), while closures with captures do not have that operator. The proposal adds the default constructor to the conditionally defined functions, using the same condition.
</p>

<h2>Proposed changes to the Working Draft</h2>

<p>Wording change is proposed against N3376</p>

<p>
Change in 5.1.2 expr.prim.lambda paragraph 19:
<blockquote>
The closure type associated with a lambda-expression has a deleted (8.4.3)<del> default constructor and a deleted</del> copy assignment operator.</p>
</blockquote>

Add a new paragraph to 5.1.2 expr.prim.lambda:
<blockquote>
<ins>If the closure type is associated with a lambda-expression with no lambda-capture, then it has a public implicitly-declared (12.8) default constructor, else it has a deleted (8.4.3) default constructor.</ins>
</p>
</blockquote>
</body>
</html>
------=_Part_302_24242190.1363369448167--

.


Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 15 Mar 2013 13:05:15 -0500
Raw View
--047d7bdc0b2497bd9804d7fa7db6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 15 March 2013 12:44, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:

Hello,
>
> I have written the issue document to the default constructed lambda
> closures floated up back in December at
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/1NFQeA=
P1wJA/discussion.
>
> A small change requires a small document, please check the attachment.
>

Editorial:  fix

template<typename T&gt

(at least that is how it looks with FireFox).


Possible issue:

// a.h:

#include <set>
template<typename T>
using absset =3D std::set<T, decltype([](T a, T b) { return std::abs(a)
< std::abs(b); })>;

Given that every lambda creates a new type, is decltype(absset<double>) the
same type across all translation units that include a.h?  The case I am
worried about is using absset<T> to declare a member variable in another
class in a header.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

On 15 March 2013 12:44, R=F3bert D=E1vid <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:lrdxgm@gmail.com" target=3D"_blank">lrdxgm@gmail.com</a>&gt;</span> w=
rote:<br><div class=3D"gmail_quote"><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hello,<br><br>I have written the issue document to the default constructed =
lambda closures floated up back in December at <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/forum/#!topic/std-proposals/1NFQeAP1wJA/discussion" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/forum/#!topic/std-p=
roposals/1NFQeAP1wJA/discussion</a> .<br>

<br>A small change requires a small document, please check the attachment.<=
br></blockquote><div><br>Editorial:=A0 fix <br><pre>template&lt;typename T&=
amp;gt</pre> </div></div>(at least that is how it looks with FireFox).<br c=
lear=3D"all">

<br><br>Possible issue:<br><br>// a.h:<br><pre>#include &lt;set&gt;
template&lt;typename T&gt;
using absset =3D std::set&lt;T, decltype([](T a, T b) { return std::abs(a) =
&lt; std::abs(b); })&gt;;<br><br></pre>Given that every lambda creates a ne=
w type, is decltype(absset&lt;double&gt;) the same type across all translat=
ion units that include a.h?=A0 The case I am worried about is using absset&=
lt;T&gt; to declare a member variable in another class in a header.<br>

-- <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 />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bdc0b2497bd9804d7fa7db6--

.


Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Fri, 15 Mar 2013 12:06:22 -0700 (PDT)
Raw View
------=_Part_689_12767464.1363374382904
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



2013. m=E1rcius 15., p=E9ntek 19:05:15 UTC+1 id=F5pontban Nevin ":-)" Liber=
 a=20
k=F6vetkez=F5t =EDrta:
>
> Possible issue:
>
> // a.h:
>
> #include <set>
> template<typename T>
> using absset =3D std::set<T, decltype([](T a, T b) { return std::abs(a) <=
 std::abs(b); })>;
>
> Given that every lambda creates a new type, is decltype(absset<double>)=
=20
> the same type across all translation units that include a.h?  The case I =
am=20
> worried about is using absset<T> to declare a member variable in another=
=20
> class in a header.
>
>
Possible issue:
>
> // a.h:
>
> #include <set>
> template<typename T>
> using absset =3D std::set<T, decltype([](T a, T b) { return std::abs(a) <=
 std::abs(b); })>;
>
> Given that every lambda creates a new type, is decltype(absset<double>)=
=20
> the same type across all translation units that include a.h?  The case I =
am=20
> worried about is using absset<T> to declare a member variable in another=
=20
> class in a header.
>

That is a nice catch, Nevin. If this goes to a header, we arguably loose=20
the code locality that lambdas give us, and I would recommend to use an old=
=20
boring function object instead.

I.. don't really know a solution to this issue. Isn't there a similar=20
problem when one stores a lambda as member variable within a class?

// a.h:
#include <cmath>
static auto absComp =3D [](float a, float b) { return std::abs(a) < std::ab=
s(b
); };
struct Foo {
  decltype(absComp) comp;
  Foo(decltype(absComp) x =3D absComp) : comp(x) {}
};

Is using Foo in two compilation units violating ODR? It has different=20
implementation, as the comp member variable has different type.. VC11=20
compiles it without any complaints, same when I change the lambda to be=20
non-static, but inside an anonymous lambda (so we don't have two globals=20
with the same mangled name).

I have fixed the editorial error for the next version.

Regards, Robert

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

<br><br>2013. m=E1rcius 15., p=E9ntek 19:05:15 UTC+1 id=F5pontban Nevin ":-=
)" Liber a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">Possible issue:<br><br>// a.h:<br><pre>#include &lt;set&gt;
template&lt;typename T&gt;
using absset =3D std::set&lt;T, decltype([](T a, T b) { return std::abs(a) =
&lt; std::abs(b); })&gt;;<br><br></pre>Given that every lambda creates a ne=
w type, is decltype(absset&lt;double&gt;) the same type across all translat=
ion units that include a.h?&nbsp; The case I am worried about is using abss=
et&lt;T&gt; to declare a member variable in another class in a header.<br><=
br></blockquote><div><br><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Possi=
ble issue:<br><br>// a.h:<br><pre>#include &lt;set&gt;
template&lt;typename T&gt;
using absset =3D std::set&lt;T, decltype([](T a, T b) { return std::abs(a) =
&lt; std::abs(b); })&gt;;<br><br></pre>Given
 that every lambda creates a new type, is decltype(absset&lt;double&gt;)
 the same type across all translation units that include a.h?&nbsp; The cas=
e I
 am worried about is using absset&lt;T&gt; to declare a member variable=20
in another class in a header.<br>

</blockquote><div><br>That is a nice catch, Nevin. If this goes to a header=
, we=20
arguably loose the code locality that lambdas give us, and I would=20
recommend to use an old boring function object instead.<br><br>I.. don't re=
ally know
 a solution to this issue. Isn't there a similar problem when one stores a =
lambda as member variable within a class?<br><br><div class=3D"prettyprint"=
 style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
 #800;" class=3D"styled-by-prettify">// a.h:</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" c=
lass=3D"styled-by-prettify">#include</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"sty=
led-by-prettify">&lt;cmath&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">static</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"> absC=
omp </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><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">float</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">float</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">abs</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">abs</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">b</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Foo</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">decltype</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">absComp</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> comp=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">decltype</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">absComp</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> absComp</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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> comp</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 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-prettif=
y"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
</div></code></div><br>Is using Foo in two compilation units violating ODR?=
 It has different implementation, as the comp member variable has different=
 type.. VC11 compiles it without any complaints, same when I change the lam=
bda to be non-static, but inside an anonymous lambda (so we don't have two =
globals with the same mangled name).<br><br>I have fixed the editorial erro=
r for the next version.<br><br>Regards, Robert<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_689_12767464.1363374382904--

.


Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Fri, 15 Mar 2013 12:23:36 -0700 (PDT)
Raw View
------=_Part_847_30293418.1363375416188
Content-Type: text/plain; charset=ISO-8859-1

In the meanwhile, I have uploaded this to GitHub:

https://github.com/lrdxgm/Nxxx

Regards, Robert

--

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



------=_Part_847_30293418.1363375416188
Content-Type: text/html; charset=ISO-8859-1

In the meanwhile, I have uploaded this to GitHub:<br><br>https://github.com/lrdxgm/Nxxx<br><br>Regards, Robert<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_847_30293418.1363375416188--

.


Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 15 Mar 2013 15:41:57 -0500
Raw View
--047d7bea328212423804d7fcae5e
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On 15 March 2013 14:06, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:

>
>
> 2013. m=E1rcius 15., p=E9ntek 19:05:15 UTC+1 id=F5pontban Nevin ":-)" Lib=
er a
> k=F6vetkez=F5t =EDrta:
>
>> template<typename T> using absset =3D std::set<T, decltype([](T a, T b) =
{
>> return std::abs(a) < std::abs(b); })>;
>>
>>
>> Given that every lambda creates a new type, is decltype(absset<double>)
>> the same type across all translation units that include a.h?  The case I=
 am
>> worried about is using absset<T> to declare a member variable in another
>> class in a header.
>>
> That is a nice catch, Nevin. If this goes to a header, we arguably loose
> the code locality that lambdas give us, and I would recommend to use an o=
ld
> boring function object instead.
>
> I.. don't really know a solution to this issue. Isn't there a similar
> problem when one stores a lambda as member variable within a class?
>
> // a.h:
> #include <cmath>
> static auto absComp =3D [](float a, float b) { return std::abs(a) < std::=
abs
> (b); };
> struct Foo {
>   decltype(absComp) comp;
>   Foo(decltype(absComp) x =3D absComp) : comp(x) {}
> };
>
>
Sure, but the above isn't something users are going to accidentally stumble
upon.  The primary use case for default constructed lambdas is as a
comparator in a container, which we are now saying isn't legal if the
container is in a header file.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

On 15 March 2013 14:06, R=F3bert D=E1vid <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:lrdxgm@gmail.com" target=3D"_blank">lrdxgm@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">

<br><br>2013. m=E1rcius 15., p=E9ntek 19:05:15 UTC+1 id=F5pontban Nevin &qu=
ot;:-)&quot; Liber a k=F6vetkez=F5t =EDrta:<div class=3D"im"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">


template&lt;typename T&gt;
using absset =3D std::set&lt;T, decltype([](T a, T b) { return std::abs(a) =
&lt; std::abs(b); })&gt;;<br><pre><br></pre>Given that every lambda creates=
 a new type, is decltype(absset&lt;double&gt;) the same type across all tra=
nslation units that include a.h?=A0 The case I am worried about is using ab=
sset&lt;T&gt; to declare a member variable in another class in a header.<br=
>

</blockquote></div><div><div>That is a nice catch, Nevin. If this goes to a=
 header, we=20
arguably loose the code locality that lambdas give us, and I would=20
recommend to use an old boring function object instead.<br><br>I.. don&#39;=
t really know
 a solution to this issue. Isn&#39;t there a similar problem when one store=
s a lambda as member variable within a class?<br><br><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px;word-wrap:break-word">

<code><div><span style=3D"color:#800">// a.h:</span><span style><br></span>=
<span style=3D"color:#800">#include</span><span style> </span><span style=
=3D"color:#080">&lt;cmath&gt;</span><span style><br></span><span style=3D"c=
olor:#008">static</span><span style> </span><span style=3D"color:#008">auto=
</span><span style> absComp </span><span style=3D"color:#660">=3D</span><sp=
an style> </span><span style=3D"color:#660">[](</span><span style=3D"color:=
#008">float</span><span style> a</span><span style=3D"color:#660">,</span><=
span style> </span><span style=3D"color:#008">float</span><span style> b</s=
pan><span style=3D"color:#660">)</span><span style> </span><span style=3D"c=
olor:#660">{</span><span style> </span><span style=3D"color:#008">return</s=
pan><span style> std</span><span style=3D"color:#660">::</span><span style>=
abs</span><span style=3D"color:#660">(</span><span style>a</span><span styl=
e=3D"color:#660">)</span><span style> </span><span style=3D"color:#660">&lt=
;</span><span style> std</span><span style=3D"color:#660">::</span><span st=
yle>abs</span><span style=3D"color:#660">(</span><span style>b</span><span =
style=3D"color:#660">);</span><span style> </span><span style=3D"color:#660=
">};</span><span style><br>

</span><span style=3D"color:#008">struct</span><span style> </span><span st=
yle=3D"color:#606">Foo</span><span style> </span><span style=3D"color:#660"=
>{</span><span style><br>=A0 </span><span style=3D"color:#008">decltype</sp=
an><span style=3D"color:#660">(</span><span style>absComp</span><span style=
=3D"color:#660">)</span><span style> comp</span><span style=3D"color:#660">=
;</span><span style><br>

=A0 </span><span style=3D"color:#606">Foo</span><span style=3D"color:#660">=
(</span><span style=3D"color:#008">decltype</span><span style=3D"color:#660=
">(</span><span style>absComp</span><span style=3D"color:#660">)</span><spa=
n style> x </span><span style=3D"color:#660">=3D</span><span style> absComp=
</span><span style=3D"color:#660">)</span><span style> </span><span style=
=3D"color:#660">:</span><span style> comp</span><span style=3D"color:#660">=
(</span><span style>x</span><span style=3D"color:#660">)</span><span style>=
 </span><span style=3D"color:#660">{}</span><span style><br>

</span><span style=3D"color:#660">};</span><span style><br></span></div></c=
ode></div><br></div></div></blockquote><div><br>Sure, but the above isn&#39=
;t something users are going to accidentally stumble upon.=A0 The primary u=
se case for default constructed lambdas is as a comparator in a container, =
which we are now saying isn&#39;t legal if the container is in a header fil=
e.<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

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bea328212423804d7fcae5e--

.


Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Fri, 15 Mar 2013 14:18:05 -0700 (PDT)
Raw View
------=_Part_703_21806669.1363382285257
Content-Type: text/plain; charset=ISO-8859-1



> Sure, but the above isn't something users are going to accidentally
> stumble upon.  The primary use case for default constructed lambdas is as a
> comparator in a container, which we are now saying isn't legal if the
> container is in a header file.
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404


I didn't say it's illegal, I just said I don't yet know any solution.
Currently VC11 is happy to "copy construct" one instance of the lambda into
another, witch make this problem non-existant (no ODR violation), but it
also tells me there is something fishy how Microsoft implemented lambdas..
Oh well, the effective size of the closure is zero (sizeof is 1, but you
know what I mean), how wrong can this "copy" be? :-)

I'd say this is a defect in the language, as it already exists without my
proposal, and it just makes the defect more visible.

Regards, Robert

--

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



------=_Part_703_21806669.1363382285257
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 class=3D"gmail_quote"=
><div>Sure, but the above isn't something users are going to accidentally s=
tumble upon.&nbsp; The primary use case for default constructed lambdas is =
as a comparator in a container, which we are now saying isn't legal if the =
container is in a header file.<br clear=3D"all">

</div></div>-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"OiNLOEPgjSMJ">ne...@evi=
loverlord.com</a><wbr>&gt;&nbsp; (847) 691-1404
</blockquote><div><br>I didn't say it's illegal, I just said I don't yet kn=
ow any solution. Currently VC11 is happy to "copy construct" one instance o=
f the lambda into another, witch make this problem non-existant (no ODR vio=
lation), but it also tells me there is something fishy how Microsoft implem=
ented lambdas.. Oh well, the effective size of the closure is zero (sizeof =
is 1, but you know what I mean), how wrong can this "copy" be? :-)<br><br>I=
'd say this is a defect in the language, as it already exists without my pr=
oposal, and it just makes the defect more visible.<br><br>Regards, Robert<b=
r></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_703_21806669.1363382285257--

.


Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 15 Mar 2013 16:27:52 -0500
Raw View
--14dae93995a92f1d7a04d7fd52dd
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 15 March 2013 16:18, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:

> I'd say this is a defect in the language, as it already exists without my
> proposal, and it just makes the defect more visible.
>

While it may not work the way you want it to, I don't see a language defect
here.  What is the defect?
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

On 15 March 2013 16:18, R=F3bert D=E1vid <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:lrdxgm@gmail.com" target=3D"_blank">lrdxgm@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">

I&#39;d say this is a defect in the language, as it already exists without =
my proposal, and it just makes the defect more visible.<br></blockquote><di=
v><br>While it may not work the way you want it to, I don&#39;t see a langu=
age defect here.=A0 What is the defect?<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 />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--14dae93995a92f1d7a04d7fd52dd--

.


Author: Jonathan Wakely <cxx@kayari.org>
Date: Mon, 18 Mar 2013 04:47:07 -0700 (PDT)
Raw View
------=_Part_1218_26072622.1363607227045
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Friday, March 15, 2013 5:44:08 PM UTC, R=F3bert D=E1vid wrote:
>
> Hello,
>
> I have written the issue document to the default constructed lambda=20
> closures floated up back in December at=20
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/1NFQeA=
P1wJA/discussion.
>
> A small change requires a small document, please check the attachment.
>
> Comments are more than welcome.
>


A small point, but as documented at=20
https://github.com/cplusplus/draft/wiki/Specification-Style-Guidelines the=
=20
new paragraph should say "otherwise" not "else".


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

<br><br>On Friday, March 15, 2013 5:44:08 PM UTC, R=F3bert D=E1vid wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">Hello,<br><br>I have written the=
 issue document to the default constructed lambda closures floated up back =
in December at <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!to=
pic/std-proposals/1NFQeAP1wJA/discussion" target=3D"_blank">https://groups.=
google.com/a/<wbr>isocpp.org/forum/#!topic/std-<wbr>proposals/1NFQeAP1wJA/<=
wbr>discussion</a> .<br><br>A small change requires a small document, pleas=
e check the attachment.<br><br>Comments are more than welcome.<br></blockqu=
ote><div><br><br>A small point, but as documented at https://github.com/cpl=
usplus/draft/wiki/Specification-Style-Guidelines the new paragraph should s=
ay "otherwise" not "else".<br><br><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1218_26072622.1363607227045--

.


Author: Jonathan Wakely <cxx@kayari.org>
Date: Mon, 18 Mar 2013 04:58:48 -0700 (PDT)
Raw View
------=_Part_47_6970026.1363607928433
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Friday, March 15, 2013 9:27:52 PM UTC, Nevin ":-)" Liber wrote:
>
> On 15 March 2013 16:18, R=F3bert D=E1vid <lrd...@gmail.com <javascript:>>=
wrote:
>
>> I'd say this is a defect in the language, as it already exists without m=
y=20
>> proposal, and it just makes the defect more visible.
>>
>
> While it may not work the way you want it to, I don't see a language=20
> defect here.  What is the defect?
>

I don't think this is a defect here either. Closures are unnamed types, so=
=20
the fact they can cause ODR violations when used in headers is nothing new,=
=20
we have the same for unnamed enumerations, classes and namespaces.

Consider a header containing these definitions:

enum { A };
struct { } B;
namespace { struct C { }; }

struct D
{
    decltype(A) a;
    decltype(B) b;
    C c;
};

Each of D's members has a different type in every translation unit.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

<br><br>On Friday, March 15, 2013 9:27:52 PM UTC, Nevin ":-)" Liber wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On 15 March 2013 16:18, R=F3ber=
t D=E1vid <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"giNl3zQDjZIJ">lrd...@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">

I'd say this is a defect in the language, as it already exists without my p=
roposal, and it just makes the defect more visible.<br></blockquote><div><b=
r>While it may not work the way you want it to, I don't see a language defe=
ct here.&nbsp; What is the defect?<br></div></div></blockquote><div><br>I d=
on't think this is a defect here either. Closures are unnamed types, so the=
 fact they can cause ODR violations when used in headers is nothing new, we=
 have the same for unnamed enumerations, classes and namespaces.<br><br>Con=
sider a header containing these definitions:<br><br>enum { A };<br>struct {=
 } B;<br>namespace { struct C { }; }<br><br>struct D<br>{<br>&nbsp;&nbsp;&n=
bsp; decltype(A) a;<br>&nbsp;&nbsp;&nbsp; decltype(B) b;<br>&nbsp;&nbsp;&nb=
sp; C c;<br>};<br><br>Each of D's members has a different type in every tra=
nslation unit.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_47_6970026.1363607928433--

.


Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Wed, 20 Mar 2013 18:17:35 -0700 (PDT)
Raw View
------=_Part_996_28455545.1363828655471
Content-Type: text/plain; charset=ISO-8859-1

Hello,

(sorry for the slooow reply, I got some snow-problems the weekend....)

What I have found, that lambda expressions cannot appear in an unevaluated
operand (5.1.2/2), so decltype([](){}) is disallowed.. While this does not
conflict with this proposal, without that this change is.. one-armed. I
have tried to check what needs to be changed there and found more
paragraphs needing change than I'd be happy with, so I think we need a
different way than decltype() to use lambdas as template arguments (to be
used as e.g. comparators in containers).

Well, things are never that easy how they look like.

Robert

--

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



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

Hello,<br><br>(sorry for the slooow reply, I got some snow-problems the wee=
kend....)<br><br>What I have found, that lambda expressions cannot appear i=
n an unevaluated operand (5.1.2/2), so decltype([](){}) is disallowed.. Whi=
le this does not conflict with this proposal, without that this change is..=
 one-armed. I have tried to check what needs to be changed there and found =
more paragraphs needing change than I'd be happy with, so I think we need a=
 different way than decltype() to use lambdas as template arguments (to be =
used as e.g. comparators in containers).<br><br>Well, things are never that=
 easy how they look like.<br><br>Robert<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_996_28455545.1363828655471--

.


Author: Xeo <hivemaster@hotmail.de>
Date: Wed, 20 Mar 2013 18:32:37 -0700 (PDT)
Raw View
------=_Part_406_7511835.1363829558026
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, March 21, 2013 2:17:35 AM UTC+1, R=F3bert D=E1vid wrote:

> What I have found, that lambda expressions cannot appear in an unevaluate=
d=20
> operand (5.1.2/2), so decltype([](){}) is disallowed..=20
>

Reason being that if a lambda was allowed in an unevaluated context,=20
implementations would be required to encode arbitary statements in the=20
mangled name of a function.=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



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

On Thursday, March 21, 2013 2:17:35 AM UTC+1, R=F3bert D=E1vid wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">What I have found, that lambda e=
xpressions cannot appear in an unevaluated operand (5.1.2/2), so decltype([=
](){}) is disallowed.. <br></blockquote><div><br>Reason being that if a lam=
bda was allowed in an unevaluated context, implementations would be require=
d to encode arbitary statements in the mangled name of a function. <br></di=
v>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_406_7511835.1363829558026--

.