------=_Part_2655_2091532379.1448129833688
Content-Type: multipart/alternative;
 boundary="----=_Part_2656_1410255179.1448129833688"

------=_Part_2656_1410255179.1448129833688
Content-Type: text/plain; charset=UTF-8

This is just an idea (and quickly searching the mailing list I didn't find
something similar). It's probably best illustrated with an example:

void print(variant<SomeTypes...> const& v)
{
    v.visit(
        [&] struct {
            void operator ()(int x) { ... }
            void operator ()(string const& x) { ... }
        }
    );
}

i.e. extending the lambda-syntax to create unnamed structs with multiple
member
functions which all have access to the variables specified in the
capture-list.

Something like this is already possible using helper functions like
make_visitor(lambda1, lambda2, ...), but it would also make working with
multiple callbacks packed into a single struct (like Boost Graph Library
does)
much easier:

struct default_callbacks
{
    void discover_vertex(int u) {}
    void discover_edge(int u, int v) {}
    void finish_vertex(int u) {}

    // probably many more like:
    // http://www.boost.org/doc/libs/1_59_0/libs/graph/doc/DFSVisitor.html
};

vector<int> postorder(Graph const& graph, int start)
{
    vector<int> result;

    auto callbacks = [&] struct : default_callbacks
    {
        void finish_vertex(int u) { result.push_back(u); }
    };

    depth_first_search(graph, start, callbacks);

    return result;
}

I must admit that I haven't thought about this more closely. Maybe others
can
tell me if a construct like this does (or does not) make sense, or if there
is
something I'm missing, or ... . Any feedback appreciated.

Thanks,
Alex

--

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

------=_Part_2656_1410255179.1448129833688
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>This is just an idea (and quickly searching the maili=
ng list I didn&#39;t find</div><div>something similar). It&#39;s probably b=
est illustrated with an example:</div><div><br></div><div><font face=3D"cou=
rier new, monospace">void print(variant&lt;SomeTypes...&gt; const&amp; v)</=
font></div><div><font face=3D"courier new, monospace">{</font></div><div><f=
ont face=3D"courier new, monospace">=C2=A0 =C2=A0 v.visit(</font></div><div=
><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 [&amp;] =
struct {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator ()(int x) { ... }</font></div=
><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 void operator ()(string const&amp; x) { ... }</font></div><div><=
font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 );</font></div=
><div><font face=3D"courier new, monospace">}</font></div><div><br></div><d=
iv>i.e. extending the lambda-syntax to create unnamed structs with multiple=
 member</div><div>functions which all have access to the variables specifie=
d in the capture-list.</div><div><br></div><div>Something like this is alre=
ady possible using helper functions like</div><div><font face=3D"courier ne=
w, monospace">make_visitor(lambda1, lambda2, ...)</font>, but it would also=
 make working with</div><div>multiple callbacks packed into a single struct=
 (like Boost Graph Library does)</div><div>much easier:</div><div><br></div=
><div><font face=3D"courier new, monospace">struct default_callbacks</font>=
</div><div><font face=3D"courier new, monospace">{</font></div><div><font f=
ace=3D"courier new, monospace">=C2=A0 =C2=A0 void discover_vertex(int u) {}=
</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 void =
discover_edge(int u, int v) {}</font></div><div><font face=3D"courier new, =
monospace">=C2=A0 =C2=A0 void finish_vertex(int u) {}</font></div><div><fon=
t face=3D"courier new, monospace"><br></font></div><div><font face=3D"couri=
er new, monospace">=C2=A0 =C2=A0 // probably many more like:</font></div><d=
iv><font face=3D"courier new, monospace">=C2=A0 =C2=A0 // http://www.boost.=
org/doc/libs/1_59_0/libs/graph/doc/DFSVisitor.html</font></div><div><font f=
ace=3D"courier new, monospace">};</font></div><div><font face=3D"courier ne=
w, monospace"><br></font></div><div><font face=3D"courier new, monospace">v=
ector&lt;int&gt; postorder(Graph const&amp; graph, int start)</font></div><=
div><font face=3D"courier new, monospace">{</font></div><div><font face=3D"=
courier new, monospace">=C2=A0 =C2=A0 vector&lt;int&gt; result;</font></div=
><div><font face=3D"courier new, monospace"><br></font></div><div><font fac=
e=3D"courier new, monospace">=C2=A0 =C2=A0 auto callbacks =3D [&amp;] struc=
t : default_callbacks</font></div><div><font face=3D"courier new, monospace=
">=C2=A0 =C2=A0 {</font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 void finish_vertex(int u) { result.push_back(u)=
; }</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 };=
</font></div><div><font face=3D"courier new, monospace"><br></font></div><d=
iv><font face=3D"courier new, monospace">=C2=A0 =C2=A0 depth_first_search(g=
raph, start, callbacks);</font></div><div><font face=3D"courier new, monosp=
ace"><br></font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 return result;</font></div><div><font face=3D"courier new, monospace">}=
</font></div><div><br></div><div><div>I must admit that I haven&#39;t thoug=
ht about this more closely. Maybe others can</div><div>tell me if a constru=
ct like this does (or does not) make sense, or if there is</div><div>someth=
ing I&#39;m missing, or ... . Any feedback appreciated.</div></div><div><br=
></div><div>Thanks,</div><div>Alex</div><div><br></div></div>

<p></p>

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

------=_Part_2656_1410255179.1448129833688--
------=_Part_2655_2091532379.1448129833688--

.

ISn't Gaunard's overload class enough ?

https://gist.github.com/dabrahams/3779345



On 21/11/2015 19:17, Alexander Bolz wrote:
> This is just an idea (and quickly searching the mailing list I didn't find
> something similar). It's probably best illustrated with an example:
>
> void print(variant<SomeTypes...> const& v)
> {
>      v.visit(
>          [&] struct {
>              void operator ()(int x) { ... }
>              void operator ()(string const& x) { ... }
>          }
>      );
> }
>
> i.e. extending the lambda-syntax to create unnamed structs with multiple
> member
> functions which all have access to the variables specified in the
> capture-list.
>
> Something like this is already possible using helper functions like
> make_visitor(lambda1, lambda2, ...), but it would also make working with
> multiple callbacks packed into a single struct (like Boost Graph Library
> does)
> much easier:
>
> struct default_callbacks
> {
>      void discover_vertex(int u) {}
>      void discover_edge(int u, int v) {}
>      void finish_vertex(int u) {}
>
>      // probably many more like:
>      // http://www.boost.org/doc/libs/1_59_0/libs/graph/doc/DFSVisitor.html
> };
>
> vector<int> postorder(Graph const& graph, int start)
> {
>      vector<int> result;
>
>      auto callbacks = [&] struct : default_callbacks
>      {
>          void finish_vertex(int u) { result.push_back(u); }
>      };
>
>      depth_first_search(graph, start, callbacks);
>
>      return result;
> }
>
> I must admit that I haven't thought about this more closely. Maybe
> others can
> tell me if a construct like this does (or does not) make sense, or if
> there is
> something I'm missing, or ... . Any feedback appreciated.
>
> Thanks,
> Alex
>
> --
>
> ---
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

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

.

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

2015-11-21 19:27 GMT+01:00 Joel FALCOU <joel.falcou@gmail.com>:

> ISn't Gaunard's overload class enough ?
>
> https://gist.github.com/dabrahams/3779345
>
>
>
=E2=80=8BFor the first example, yes. But not for the second. Sorry, I shoul=
d have
made this more clear.=E2=80=8B
=E2=80=8BA lambda like

[capture-list] (params) { body }

is currently roughly equivalent to

struct {
    [capture-list] // captured variables stored here...

    void operator ()(params) const { body }
}=E2=80=8B

The idea is basically instead of being restricted to specify only "params"
and "body"
of the function call operator, specify the contents of the resulting
function object:

[capture-list] struct {
    // add anything here
    // e.g.
    void func1() { ... }
    void func2(int x) { ... }
}

would be equivalent to

struct {
    [capture-list] // captured variables stored here...

    void func1()      { /* can use captured variables here */ }
    void func2(int x) { /* can use captured variables here */ }
}

I think that would working with visitors like the ones required by
variant<T...> (which uses
operator () and function overloading) or like the ones required by BGL
(which uses named
member functions) much more easy.


>
> On 21/11/2015 19:17, Alexander Bolz wrote:
>
>> This is just an idea (and quickly searching the mailing list I didn't fi=
nd
>> something similar). It's probably best illustrated with an example:
>>
>> void print(variant<SomeTypes...> const& v)
>> {
>>      v.visit(
>>          [&] struct {
>>              void operator ()(int x) { ... }
>>              void operator ()(string const& x) { ... }
>>          }
>>      );
>> }
>>
>> i.e. extending the lambda-syntax to create unnamed structs with multiple
>> member
>> functions which all have access to the variables specified in the
>> capture-list.
>>
>> Something like this is already possible using helper functions like
>> make_visitor(lambda1, lambda2, ...), but it would also make working with
>> multiple callbacks packed into a single struct (like Boost Graph Library
>> does)
>> much easier:
>>
>> struct default_callbacks
>> {
>>      void discover_vertex(int u) {}
>>      void discover_edge(int u, int v) {}
>>      void finish_vertex(int u) {}
>>
>>      // probably many more like:
>>      //
>> http://www.boost.org/doc/libs/1_59_0/libs/graph/doc/DFSVisitor.html
>> };
>>
>> vector<int> postorder(Graph const& graph, int start)
>> {
>>      vector<int> result;
>>
>>      auto callbacks =3D [&] struct : default_callbacks
>>      {
>>          void finish_vertex(int u) { result.push_back(u); }
>>      };
>>
>>      depth_first_search(graph, start, callbacks);
>>
>>      return result;
>> }
>>
>> I must admit that I haven't thought about this more closely. Maybe
>> others can
>> tell me if a construct like this does (or does not) make sense, or if
>> there is
>> something I'm missing, or ... . Any feedback appreciated.
>>
>> Thanks,
>> Alex
>>
>> --
>>
>> ---
>> 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
>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto:std-proposals@isocpp.org>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>



--=20
Alex

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

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif"><br></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">2015-11-21 19:27 GMT+01:00 Joel FALCOU <span dir=3D"ltr">&lt;<=
a href=3D"mailto:joel.falcou@gmail.com" target=3D"_blank">joel.falcou@gmail=
..com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex">ISn&#39;t Gaunard&#39;s overload c=
lass enough ?<br>
<br>
<a href=3D"https://gist.github.com/dabrahams/3779345" rel=3D"noreferrer" ta=
rget=3D"_blank">https://gist.github.com/dabrahams/3779345</a><div><div clas=
s=3D"h5"><br>
<br></div></div></blockquote><div><br></div><div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif">=E2=80=8BFor the first =
example, yes. But not for the second. Sorry, I should have made this more c=
lear.=E2=80=8B</div></div><div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif">=E2=80=8BA lambda like</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif"><br></div>=
<div class=3D"gmail_default"><font face=3D"monospace, monospace">[capture-l=
ist] (params) { body }</font></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif">is currently roughly equ=
ivalent to</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif"><br></div><div class=3D"gmail_default"><font face=3D"mon=
ospace, monospace">struct {</font></div><div class=3D"gmail_default"><font =
face=3D"monospace, monospace">=C2=A0 =C2=A0 [capture-list] // captured vari=
ables stored here...</font></div><div class=3D"gmail_default"><font face=3D=
"monospace, monospace"><br></font></div><div class=3D"gmail_default"><font =
face=3D"monospace, monospace">=C2=A0 =C2=A0 void operator ()(params) const =
{ body }</font></div><div class=3D"gmail_default"><font face=3D"monospace, =
monospace">}=E2=80=8B</font></div></div><div class=3D"gmail_default"><br></=
div><div class=3D"gmail_default">The idea is basically instead of being res=
tricted to specify only &quot;params&quot; and &quot;body&quot;</div><div c=
lass=3D"gmail_default">of the function call operator, specify the contents =
of the resulting function object:</div><div class=3D"gmail_default"><br></d=
iv><div class=3D"gmail_default"><font face=3D"monospace, monospace">[captur=
e-list] struct {</font></div><div class=3D"gmail_default"><font face=3D"mon=
ospace, monospace">=C2=A0 =C2=A0 // add anything here</font></div><div clas=
s=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 =C2=A0 // e.=
g.</font></div><div class=3D"gmail_default"><font face=3D"monospace, monosp=
ace">=C2=A0 =C2=A0 void func1() { ... }</font></div><div class=3D"gmail_def=
ault"><font face=3D"monospace, monospace">=C2=A0 =C2=A0 void func2(int x) {=
 ... }</font></div><div class=3D"gmail_default"><span style=3D"font-family:=
monospace,monospace">}</span><br></div><div class=3D"gmail_default"><br></d=
iv><div class=3D"gmail_default">would be equivalent to</div><div class=3D"g=
mail_default"><br></div><div class=3D"gmail_default"><div class=3D"gmail_de=
fault"><font face=3D"monospace, monospace">struct {</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 =C2=A0=C2=A0<=
/font><span style=3D"font-family:monospace,monospace">[capture-list] // cap=
tured variables stored here...</span></div><div class=3D"gmail_default"><sp=
an style=3D"font-family:monospace,monospace"><br></span></div><div class=3D=
"gmail_default"><span style=3D"font-family:monospace,monospace">=C2=A0 =C2=
=A0 void func1() =C2=A0 =C2=A0 =C2=A0{ /* can use captured variables here *=
/ }</span></div><div class=3D"gmail_default"><span style=3D"font-family:mon=
ospace,monospace">=C2=A0 =C2=A0 void func2(int x) { /* can use captured var=
iables here */ }</span></div><div class=3D"gmail_default"><span style=3D"fo=
nt-family:monospace,monospace">}</span><br></div><div><br></div></div><div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f">I think that would working with visitors like the ones required by varia=
nt&lt;T...&gt; (which uses</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif">operator () and function overloading) or=
 like the ones required by BGL (which uses named</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif">member functions) =
much more easy.</div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div><div class=3D"h5">
<br>
<br>
On 21/11/2015 19:17, Alexander Bolz wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div><div class=3D"h5">
This is just an idea (and quickly searching the mailing list I didn&#39;t f=
ind<br>
something similar). It&#39;s probably best illustrated with an example:<br>
<br>
void print(variant&lt;SomeTypes...&gt; const&amp; v)<br>
{<br>
=C2=A0 =C2=A0 =C2=A0v.visit(<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[&amp;] struct {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void operator ()(int x) { .=
... }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void operator ()(string con=
st&amp; x) { ... }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0);<br>
}<br>
<br>
i.e. extending the lambda-syntax to create unnamed structs with multiple<br=
>
member<br>
functions which all have access to the variables specified in the<br>
capture-list.<br>
<br>
Something like this is already possible using helper functions like<br>
make_visitor(lambda1, lambda2, ...), but it would also make working with<br=
>
multiple callbacks packed into a single struct (like Boost Graph Library<br=
>
does)<br>
much easier:<br>
<br>
struct default_callbacks<br>
{<br>
=C2=A0 =C2=A0 =C2=A0void discover_vertex(int u) {}<br>
=C2=A0 =C2=A0 =C2=A0void discover_edge(int u, int v) {}<br>
=C2=A0 =C2=A0 =C2=A0void finish_vertex(int u) {}<br>
<br>
=C2=A0 =C2=A0 =C2=A0// probably many more like:<br>
=C2=A0 =C2=A0 =C2=A0// <a href=3D"http://www.boost.org/doc/libs/1_59_0/libs=
/graph/doc/DFSVisitor.html" rel=3D"noreferrer" target=3D"_blank">http://www=
..boost.org/doc/libs/1_59_0/libs/graph/doc/DFSVisitor.html</a><br>
};<br>
<br>
vector&lt;int&gt; postorder(Graph const&amp; graph, int start)<br>
{<br>
=C2=A0 =C2=A0 =C2=A0vector&lt;int&gt; result;<br>
<br>
=C2=A0 =C2=A0 =C2=A0auto callbacks =3D [&amp;] struct : default_callbacks<b=
r>
=C2=A0 =C2=A0 =C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void finish_vertex(int u) { result.push_b=
ack(u); }<br>
=C2=A0 =C2=A0 =C2=A0};<br>
<br>
=C2=A0 =C2=A0 =C2=A0depth_first_search(graph, start, callbacks);<br>
<br>
=C2=A0 =C2=A0 =C2=A0return result;<br>
}<br>
<br>
I must admit that I haven&#39;t thought about this more closely. Maybe<br>
others can<br>
tell me if a construct like this does (or does not) make sense, or if<br>
there is<br>
something I&#39;m missing, or ... . Any feedback appreciated.<br>
<br>
Thanks,<br>
Alex<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google<br>
Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send<br>
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" targe=
t=3D"_blank">std-proposals+unsubscribe@isocpp.org</a><br></div></div>
&lt;mailto:<a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=
=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>&gt;.<span class=3D""><=
br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a><br></span>
&lt;mailto:<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">st=
d-proposals@isocpp.org</a>&gt;.<span class=3D""><br>
Visit this group at<br>
<a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/" rel=
=3D"noreferrer" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</span></blockquote><div class=3D""><div class=3D"h5">
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr">Alex</div></div>
</div></div>

<p></p>

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

--001a1141324458f66e052511f3d4--

.

------=_Part_5367_1749752112.1448226272248
Content-Type: multipart/alternative;
 boundary="----=_Part_5368_755171152.1448226272248"

------=_Part_5368_755171152.1448226272248
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, November 21, 2015 at 10:17:14 AM UTC-8, Alexander Bolz wrote:
>
> This is just an idea (and quickly searching the mailing list I didn't fin=
d
> something similar). It's probably best illustrated with an example:
>
> void print(variant<SomeTypes...> const& v)
> {
>     v.visit(
>         [&] struct {
>             void operator ()(int x) { ... }
>             void operator ()(string const& x) { ... }
>         }
>     );
> }
>
> i.e. extending the lambda-syntax to create unnamed structs with multiple=
=20
> member
> functions which all have access to the variables specified in the=20
> capture-list.
>

As opposed to simply creating a local type:

void print(variant<SomeTypes...> const& v)
{
    struct Local {
        variant<SomeTypes...> const *v;
        Local(variant<SomeTypes...> const& v) : v(&v) {}
        void operator ()(int x) { ... }
        void operator ()(string const& x) { ... }
    };
    Local loc(v);
    v.visit(loc);
}

I'll admit that your "lambda struct" syntax looks nicer in this example,=20
but is it so *much* nicer that we need a syntax for it?
Also, does your syntax allow me to construct two or more objects of type=20
Local? or is the type necessarily unnamed?

I suppose you could extend your syntax a little further to allow giving a=
=20
name to the struct:

auto x =3D [&] struct Local {
    void operator ()(int x) { ... }
    void operator ()(string const& x) { ... }
};

although I don't really understand what it would mean then to say Local y;=
=20
or decltype(x) y; in the same scope, or in an inner scope. C++11/14 lambdas=
=20
aren't generally default-constructible, not even ones that have no=20
captures. (This is a pet peeve of mine that I'd love to see fixed, by the=
=20
way. With that and lambdas-in-unevaluated-contexts, it would make it so=20
much easier to provide a deleter for a unique_ptr:
using Ptr =3D std::unique_ptr<void *, decltype([](void *p){ free(p); })>;)

I like the idea of bringing lambdas and structs/classes closer together=20
somehow, but I don't think that this particular addition is worth the=20
syntax =E2=80=94 yet. That is, the limited proposal here doesn't seem to be=
 a full=20
step forward in itself, and I don't *immediately* see how to incrementally=
=20
extend it to get all the way to anywhere I'd want to go. Which is not to=20
say that such an incremental extension couldn't possibly exist.

my $.02,
=E2=80=93Arthur

P.S. =E2=80=94 In the print-visitor example, did you mean for those operato=
r()s to=20
be non-const? In other words, I wonder whether the proposed syntax would=20
encourage people to write subtly incorrect code. The "default constness" of=
=20
lambdas' call operators is currently training programmers that they don't=
=20
need to write "const"; you'll have to either copy what lambdas have done,=
=20
or else un-train everyone.

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

------=_Part_5368_755171152.1448226272248
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, November 21, 2015 at 10:17:14 AM UTC-8, Alexander Bolz wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>This is j=
ust an idea (and quickly searching the mailing list I didn&#39;t find</div>=
<div>something similar). It&#39;s probably best illustrated with an example=
:</div><div><br></div><div><font face=3D"courier new, monospace">void print=
(variant&lt;SomeTypes...&gt; const&amp; v)</font></div><div><font face=3D"c=
ourier new, monospace">{</font></div><div><font face=3D"courier new, monosp=
ace">=C2=A0 =C2=A0 v.visit(</font></div><div><font face=3D"courier new, mon=
ospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 [&amp;] struct {</font></div><div><font=
 face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
void operator ()(int x) { ... }</font></div><div><font face=3D"courier new,=
 monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator ()(stri=
ng const&amp; x) { ... }</font></div><div><font face=3D"courier new, monosp=
ace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font></div><div><font face=3D"courier n=
ew, monospace">=C2=A0 =C2=A0 );</font></div><div><font face=3D"courier new,=
 monospace">}</font></div><div><br></div><div>i.e. extending the lambda-syn=
tax to create unnamed structs with multiple member</div><div>functions whic=
h all have access to the variables specified in the capture-list.</div></di=
v></blockquote><div><br></div><div>As opposed to simply creating a local ty=
pe:</div><div><br></div><div><div><font face=3D"courier new, monospace">voi=
d print(variant&lt;SomeTypes...&gt; const&amp; v)</font></div><div><font fa=
ce=3D"courier new, monospace">{</font></div><div><font face=3D"courier new,=
 monospace">=C2=A0 =C2=A0 struct Local {</font></div><div><font face=3D"cou=
rier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 variant&lt;SomeTypes...&gt=
; const *v;</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 Local(</font><span style=3D"font-family: &#39;courier =
new&#39;, monospace;">variant&lt;SomeTypes...&gt; const&amp;=C2=A0</span><s=
pan style=3D"font-family: &#39;courier new&#39;, monospace;">v) : v(&amp;v)=
 {}</span></div><div><span style=3D"font-family: &#39;courier new&#39;, mon=
ospace;">=C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator ()(int x) { ... }</span>=
<br></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 void operator ()(string const&amp; x) { ... }</font></div><div><span=
 style=3D"font-family: &#39;courier new&#39;, monospace;">=C2=A0 =C2=A0 };<=
/span><br></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 Lo=
cal loc(v);</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 v.visit(loc);</font></div><div><span style=3D"font-family: &#39;cour=
ier new&#39;, monospace;">}</span></div><div><br></div><div>I&#39;ll admit =
that your &quot;lambda struct&quot; syntax looks nicer in this example, but=
 is it so <i>much</i> nicer that we need a syntax for it?</div></div><div>A=
lso, does your syntax allow me to construct two or more objects of type Loc=
al? or is the type necessarily unnamed?</div><div><br></div><div>I suppose =
you could extend your syntax a little further to allow giving a name to the=
 struct:</div><div><br></div><div><div><font face=3D"courier new, monospace=
">auto x =3D [&amp;] struct Local {</font></div><div><font face=3D"courier =
new, monospace">=C2=A0 =C2=A0 void operator ()(int x) { ... }</font></div><=
div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 void operator ()(st=
ring const&amp; x) { ... }</font></div><div><font face=3D"courier new, mono=
space">};</font></div></div><br>although I don&#39;t really understand what=
 it would mean then to say=C2=A0<font face=3D"courier new, monospace">Local=
 y;</font> or <font face=3D"courier new, monospace">decltype(x) y;</font> i=
n the same scope, or in an inner scope. C++11/14 lambdas aren&#39;t general=
ly default-constructible, not even ones that have no captures. (This is a p=
et peeve of mine that I&#39;d love to see fixed, by the way. With that and =
lambdas-in-unevaluated-contexts, it would make it so much easier to provide=
 a deleter for a unique_ptr:<div><font face=3D"courier new, monospace">usin=
g Ptr =3D std::unique_ptr&lt;void *, decltype([](void *p){ free(p); })&gt;;=
</font>)<div><br>I like the idea of bringing lambdas and structs/classes cl=
oser together somehow, but I don&#39;t think that this particular addition =
is worth the syntax =E2=80=94 yet. That is, the limited proposal here doesn=
&#39;t seem to be a full step forward in itself, and I don&#39;t <i>immedia=
tely</i> see how to incrementally extend it to get all the way to anywhere =
I&#39;d want to go. Which is not to say that such an incremental extension =
couldn&#39;t possibly exist.</div></div><div><br></div><div>my $.02,</div><=
div>=E2=80=93Arthur</div><div><br></div><div>P.S. =E2=80=94 In the print-vi=
sitor example, did you mean for those operator()s to be non-const? In other=
 words, I wonder whether the proposed syntax would encourage people to writ=
e subtly incorrect code. The &quot;default constness&quot; of lambdas&#39; =
call operators is currently training programmers that they don&#39;t need t=
o write &quot;const&quot;; you&#39;ll have to either copy what lambdas have=
 done, or else un-train everyone.</div>

<p></p>

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

------=_Part_5368_755171152.1448226272248--
------=_Part_5367_1749752112.1448226272248--

.

On Sunday 22 November 2015 13:04:32 Arthur O'Dwyer wrote:
> Also, does your syntax allow me to construct two or more objects of type
> Local? or is the type necessarily unnamed?

You can use decltype on the first.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_3532_1357566759.1448232026606
Content-Type: multipart/alternative;
 boundary="----=_Part_3533_1804461268.1448232026607"

------=_Part_3533_1804461268.1448232026607
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Out of curiosity, does anyone know why the following code is invalid?

    void print(variant<SomeTypes...> const& v) {
        struct Local {
            variant<SomeTypes...> const *v_ =3D &v;
            void operator ()(int x) { ... }
            void operator ()(string const& x) { ... }
        };
        Local loc;
        v.visit(loc);
    }

Notice how I'm "capturing" `v` by using inline in-class initialization so=
=20
that you don't need to write a constructor. I'm not saying this is a good=
=20
idea or anything, but it seems to me like this should work, since it works=
=20
for variables declared at namespace scope:

    int global =3D 0;
    void f() {
        struct Local { int const* i =3D &global; };
        Local loc;
    }

Regards,
Louis

On Sunday, 22 November 2015 16:04:32 UTC-5, Arthur O'Dwyer wrote:
>
> On Saturday, November 21, 2015 at 10:17:14 AM UTC-8, Alexander Bolz wrote=
:
>>
>> This is just an idea (and quickly searching the mailing list I didn't fi=
nd
>> something similar). It's probably best illustrated with an example:
>>
>> void print(variant<SomeTypes...> const& v)
>> {
>>     v.visit(
>>         [&] struct {
>>             void operator ()(int x) { ... }
>>             void operator ()(string const& x) { ... }
>>         }
>>     );
>> }
>>
>> i.e. extending the lambda-syntax to create unnamed structs with multiple=
=20
>> member
>> functions which all have access to the variables specified in the=20
>> capture-list.
>>
>
> As opposed to simply creating a local type:
>
> void print(variant<SomeTypes...> const& v)
> {
>     struct Local {
>         variant<SomeTypes...> const *v;
>         Local(variant<SomeTypes...> const& v) : v(&v) {}
>         void operator ()(int x) { ... }
>         void operator ()(string const& x) { ... }
>     };
>     Local loc(v);
>     v.visit(loc);
> }
>
> I'll admit that your "lambda struct" syntax looks nicer in this example,=
=20
> but is it so *much* nicer that we need a syntax for it?
> Also, does your syntax allow me to construct two or more objects of type=
=20
> Local? or is the type necessarily unnamed?
>
> I suppose you could extend your syntax a little further to allow giving a=
=20
> name to the struct:
>
> auto x =3D [&] struct Local {
>     void operator ()(int x) { ... }
>     void operator ()(string const& x) { ... }
> };
>
> although I don't really understand what it would mean then to say Local y=
;=20
> or decltype(x) y; in the same scope, or in an inner scope. C++11/14=20
> lambdas aren't generally default-constructible, not even ones that have n=
o=20
> captures. (This is a pet peeve of mine that I'd love to see fixed, by the=
=20
> way. With that and lambdas-in-unevaluated-contexts, it would make it so=
=20
> much easier to provide a deleter for a unique_ptr:
> using Ptr =3D std::unique_ptr<void *, decltype([](void *p){ free(p); })>;=
)
>
> I like the idea of bringing lambdas and structs/classes closer together=
=20
> somehow, but I don't think that this particular addition is worth the=20
> syntax =E2=80=94 yet. That is, the limited proposal here doesn't seem to =
be a full=20
> step forward in itself, and I don't *immediately* see how to=20
> incrementally extend it to get all the way to anywhere I'd want to go.=20
> Which is not to say that such an incremental extension couldn't possibly=
=20
> exist.
>
> my $.02,
> =E2=80=93Arthur
>
> P.S. =E2=80=94 In the print-visitor example, did you mean for those opera=
tor()s to=20
> be non-const? In other words, I wonder whether the proposed syntax would=
=20
> encourage people to write subtly incorrect code. The "default constness" =
of=20
> lambdas' call operators is currently training programmers that they don't=
=20
> need to write "const"; you'll have to either copy what lambdas have done,=
=20
> or else un-train everyone.
>

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

------=_Part_3533_1804461268.1448232026607
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Out of curiosity, does anyone know why the following =
code is invalid?</div><div><br></div><div>=C2=A0 =C2=A0 void print(variant&=
lt;SomeTypes...&gt; const&amp; v) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 s=
truct Local {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 variant&l=
t;SomeTypes...&gt; const *v_ =3D &amp;v;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 void operator ()(int x) { ... }</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator ()(string const&amp; x) { ... }</=
div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 };</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 Local loc;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 v.visit(loc);</div><di=
v>=C2=A0 =C2=A0 }</div><div><br></div><div>Notice how I&#39;m &quot;capturi=
ng&quot; `v` by using inline in-class initialization so=C2=A0</div><div>tha=
t you don&#39;t need to write a constructor. I&#39;m not saying this is a g=
ood=C2=A0</div><div>idea or anything, but it seems to me like this should w=
ork, since it works=C2=A0</div><div>for variables declared at namespace sco=
pe:</div><div><br></div><div>=C2=A0 =C2=A0 int global =3D 0;</div><div>=C2=
=A0 =C2=A0 void f() {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct Local { =
int const* i =3D &amp;global; };</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Loca=
l loc;</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>Regards,</div><di=
v>Louis</div><br>On Sunday, 22 November 2015 16:04:32 UTC-5, Arthur O&#39;D=
wyer  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, Novem=
ber 21, 2015 at 10:17:14 AM UTC-8, Alexander Bolz wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>This is just an idea (and quic=
kly searching the mailing list I didn&#39;t find</div><div>something simila=
r). It&#39;s probably best illustrated with an example:</div><div><br></div=
><div><font face=3D"courier new, monospace">void print(variant&lt;SomeTypes=
....&gt; const&amp; v)</font></div><div><font face=3D"courier new, monospace=
">{</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 v.=
visit(</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 [&amp;] struct {</font></div><div><font face=3D"courier new,=
 monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator ()(int =
x) { ... }</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator ()(string const&amp; x) { =
.... }</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 }</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 );</font></div><div><font face=3D"courier new, monospace">}</fon=
t></div><div><br></div><div>i.e. extending the lambda-syntax to create unna=
med structs with multiple member</div><div>functions which all have access =
to the variables specified in the capture-list.</div></div></blockquote><di=
v><br></div><div>As opposed to simply creating a local type:</div><div><br>=
</div><div><div><font face=3D"courier new, monospace">void print(variant&lt=
;SomeTypes...&gt; const&amp; v)</font></div><div><font face=3D"courier new,=
 monospace">{</font></div><div><font face=3D"courier new, monospace">=C2=A0=
 =C2=A0 struct Local {</font></div><div><font face=3D"courier new, monospac=
e">=C2=A0 =C2=A0 =C2=A0 =C2=A0 variant&lt;SomeTypes...&gt; const *v;</font>=
</div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 Local(</font><span style=3D"font-family:&#39;courier new&#39;,monospace=
">variant&lt;SomeTypes...&gt; const&amp;=C2=A0</span><span style=3D"font-fa=
mily:&#39;courier new&#39;,monospace">v) : v(&amp;v) {}</span></div><div><s=
pan style=3D"font-family:&#39;courier new&#39;,monospace">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 void operator ()(int x) { ... }</span><br></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator ()(st=
ring const&amp; x) { ... }</font></div><div><span style=3D"font-family:&#39=
;courier new&#39;,monospace">=C2=A0 =C2=A0 };</span><br></div><div><font fa=
ce=3D"courier new, monospace">=C2=A0 =C2=A0 Local loc(v);</font></div><div>=
<font face=3D"courier new, monospace">=C2=A0 =C2=A0 v.visit(loc);</font></d=
iv><div><span style=3D"font-family:&#39;courier new&#39;,monospace">}</span=
></div><div><br></div><div>I&#39;ll admit that your &quot;lambda struct&quo=
t; syntax looks nicer in this example, but is it so <i>much</i> nicer that =
we need a syntax for it?</div></div><div>Also, does your syntax allow me to=
 construct two or more objects of type Local? or is the type necessarily un=
named?</div><div><br></div><div>I suppose you could extend your syntax a li=
ttle further to allow giving a name to the struct:</div><div><br></div><div=
><div><font face=3D"courier new, monospace">auto x =3D [&amp;] struct Local=
 {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 voi=
d operator ()(int x) { ... }</font></div><div><font face=3D"courier new, mo=
nospace">=C2=A0 =C2=A0 void operator ()(string const&amp; x) { ... }</font>=
</div><div><font face=3D"courier new, monospace">};</font></div></div><br>a=
lthough I don&#39;t really understand what it would mean then to say=C2=A0<=
font face=3D"courier new, monospace">Local y;</font> or <font face=3D"couri=
er new, monospace">decltype(x) y;</font> in the same scope, or in an inner =
scope. C++11/14 lambdas aren&#39;t generally default-constructible, not eve=
n ones that have no captures. (This is a pet peeve of mine that I&#39;d lov=
e to see fixed, by the way. With that and lambdas-in-unevaluated-<wbr>conte=
xts, it would make it so much easier to provide a deleter for a unique_ptr:=
<div><font face=3D"courier new, monospace">using Ptr =3D std::unique_ptr&lt=
;void *, decltype([](void *p){ free(p); })&gt;;</font>)<div><br>I like the =
idea of bringing lambdas and structs/classes closer together somehow, but I=
 don&#39;t think that this particular addition is worth the syntax =E2=80=
=94 yet. That is, the limited proposal here doesn&#39;t seem to be a full s=
tep forward in itself, and I don&#39;t <i>immediately</i> see how to increm=
entally extend it to get all the way to anywhere I&#39;d want to go. Which =
is not to say that such an incremental extension couldn&#39;t possibly exis=
t.</div></div><div><br></div><div>my $.02,</div><div>=E2=80=93Arthur</div><=
div><br></div><div>P.S. =E2=80=94 In the print-visitor example, did you mea=
n for those operator()s to be non-const? In other words, I wonder whether t=
he proposed syntax would encourage people to write subtly incorrect code. T=
he &quot;default constness&quot; of lambdas&#39; call operators is currentl=
y training programmers that they don&#39;t need to write &quot;const&quot;;=
 you&#39;ll have to either copy what lambdas have done, or else un-train ev=
eryone.</div></blockquote></div>

<p></p>

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

------=_Part_3533_1804461268.1448232026607--
------=_Part_3532_1357566759.1448232026606--

.

Louis Dionne <ldionne.2@gmail.com> writes:

> Out of curiosity, does anyone know why the following code is invalid?
>
>     void print(variant<SomeTypes...> const& v) {
>         struct Local {
>             variant<SomeTypes...> const *v_ = &v;
>             void operator ()(int x) { ... }
>             void operator ()(string const& x) { ... }
>         };
>         Local loc;
>         v.visit(loc);
>     }
>
> Notice how I'm "capturing" `v` by using inline in-class initialization
> so that you don't need to write a constructor. I'm not saying this is
> a good idea or anything, but it seems to me like this should work,
> since it works for variables declared at namespace scope:
>
>     int global = 0;
>     void f() {
>         struct Local { int const* i = &global; };
>         Local loc;
>     }

That `struct Local` would now be default-constructible but its *type* is
not limited to the scope it was declared in.  You could pass it (the
type) around as `template` parameter or recover it using `decltype`.  If
now somebody in an other scope (potentially after `v` has been
destroyed) were to default-construct a `Local` what should the `v_`
member be initialized to?  Note that this problem does not occur with
global variables because they are always accessible from any scope.

--

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

.

------=_Part_3690_1179459973.1448236236053
Content-Type: multipart/alternative;
 boundary="----=_Part_3691_192046504.1448236236053"

------=_Part_3691_192046504.1448236236053
Content-Type: text/plain; charset=UTF-8

Yes, of course. And the difference between this definition of `Local` and
using a lambda is that the lambda type is not default-constructible.

Thanks!
Louis

On Sunday, 22 November 2015 18:17:57 UTC-5, Moritz Klammler wrote:
>
> Louis Dionne <ldio...@gmail.com <javascript:>> writes:
>
> > Out of curiosity, does anyone know why the following code is invalid?
> >
> >     void print(variant<SomeTypes...> const& v) {
> >         struct Local {
> >             variant<SomeTypes...> const *v_ = &v;
> >             void operator ()(int x) { ... }
> >             void operator ()(string const& x) { ... }
> >         };
> >         Local loc;
> >         v.visit(loc);
> >     }
> >
> > Notice how I'm "capturing" `v` by using inline in-class initialization
> > so that you don't need to write a constructor. I'm not saying this is
> > a good idea or anything, but it seems to me like this should work,
> > since it works for variables declared at namespace scope:
> >
> >     int global = 0;
> >     void f() {
> >         struct Local { int const* i = &global; };
> >         Local loc;
> >     }
>
> That `struct Local` would now be default-constructible but its *type* is
> not limited to the scope it was declared in.  You could pass it (the
> type) around as `template` parameter or recover it using `decltype`.  If
> now somebody in an other scope (potentially after `v` has been
> destroyed) were to default-construct a `Local` what should the `v_`
> member be initialized to?  Note that this problem does not occur with
> global variables because they are always accessible from any scope.
>

--

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

------=_Part_3691_192046504.1448236236053
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Yes, of course. And the difference between this defin=
ition of `Local` and</div><div>using a lambda is that the lambda type is no=
t default-constructible.=C2=A0</div><div><br></div><div>Thanks!</div><div>L=
ouis</div><br>On Sunday, 22 November 2015 18:17:57 UTC-5, Moritz Klammler  =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">Louis Dionne &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"sXovGW77BQAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">ldio...@gmai=
l.com</a>&gt; writes:
<br>
<br>&gt; Out of curiosity, does anyone know why the following code is inval=
id?
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 void print(variant&lt;SomeTypes...&gt; const&amp; v)=
 {
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct Local {
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 variant&lt;SomeTypes...&=
gt; const *v_ =3D &amp;v;
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator ()(int x) =
{ ... }
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator ()(string =
const&amp; x) { ... }
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 };
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Local loc;
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 v.visit(loc);
<br>&gt; =C2=A0 =C2=A0 }
<br>&gt;
<br>&gt; Notice how I&#39;m &quot;capturing&quot; `v` by using inline in-cl=
ass initialization
<br>&gt; so that you don&#39;t need to write a constructor. I&#39;m not say=
ing this is
<br>&gt; a good idea or anything, but it seems to me like this should work,
<br>&gt; since it works for variables declared at namespace scope:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 int global =3D 0;
<br>&gt; =C2=A0 =C2=A0 void f() {
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct Local { int const* i =3D &amp;g=
lobal; };
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Local loc;
<br>&gt; =C2=A0 =C2=A0 }
<br>
<br>That `struct Local` would now be default-constructible but its *type* i=
s
<br>not limited to the scope it was declared in. =C2=A0You could pass it (t=
he
<br>type) around as `template` parameter or recover it using `decltype`. =
=C2=A0If
<br>now somebody in an other scope (potentially after `v` has been
<br>destroyed) were to default-construct a `Local` what should the `v_`
<br>member be initialized to? =C2=A0Note that this problem does not occur w=
ith
<br>global variables because they are always accessible from any scope.
<br></blockquote></div>

<p></p>

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

------=_Part_3691_192046504.1448236236053--
------=_Part_3690_1179459973.1448236236053--

.

--001a11c240005a5d16052533169d
Content-Type: text/plain; charset=UTF-8

On Sat, Nov 21, 2015 at 6:27 PM, Joel FALCOU <joel.falcou@gmail.com> wrote:

> ISn't Gaunard's overload class enough ?
>
> https://gist.github.com/dabrahams/3779345
>
>
I didn't know anyone was using my name to talk about that kind of thing
before, funny.
Vicente J Botet Escriba built a proposal for this otherwise, P0051R1.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Nov 21, 2015 at 6:27 PM, Joel FALCOU <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:joel.falcou@gmail.com" target=3D"_blank">joel.falcou@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex">ISn&#39;t Gaunard&#39;s overload class =
enough ?<br>
<br>
<a href=3D"https://gist.github.com/dabrahams/3779345" rel=3D"noreferrer" ta=
rget=3D"_blank">https://gist.github.com/dabrahams/3779345</a><div><div clas=
s=3D"h5"><br></div></div></blockquote></div><br></div><div class=3D"gmail_e=
xtra">I didn&#39;t know anyone was using my name to talk about that kind of=
 thing before, funny.<br>Vicente J Botet Escriba built a proposal for this =
otherwise, P0051R1.</div></div>

<p></p>

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

--001a11c240005a5d16052533169d--

.

On 11/23/2015 04:57 AM, Mathias Gaunard wrote:
> On Sat, Nov 21, 2015 at 6:27 PM, Joel FALCOU <joel.falcou@gmail.com
> <mailto:joel.falcou@gmail.com>> wrote:
>
>     ISn't Gaunard's overload class enough ?
>
>     https://gist.github.com/dabrahams/3779345
>
>
> I didn't know anyone was using my name to talk about that kind of thing
> before, funny.
> Vicente J Botet Escriba built a proposal for this otherwise, P0051R1.
>
Did you mean D0051R1?  I ask because I remember Vicente mentioning it
in this newgroup:


https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/D0051|sort:relevance/std-proposals/LfFYY5zCPFw/2DuEYWf6AwAJ

which had headers:

From: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: D0051- C++ generic overload function
Date: Tue, 15 Sep 2015 21:52:59 +0200
Lines: 23
Approved: news@gmane.org
Message-ID: <55F8771B.1090108@wanadoo.fr>

That post contained a link to a pdf; however, googling for
P0051R1 failed to find anything for me.

-regards,
Larry


--

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

.

On 11/23/2015 06:07 AM, Larry Evans wrote:
> On 11/23/2015 04:57 AM, Mathias Gaunard wrote:
>> On Sat, Nov 21, 2015 at 6:27 PM, Joel FALCOU <joel.falcou@gmail.com
>> <mailto:joel.falcou@gmail.com>> wrote:
>>
>>     ISn't Gaunard's overload class enough ?
>>
>>     https://gist.github.com/dabrahams/3779345
>>
>>
>> I didn't know anyone was using my name to talk about that kind of thing
>> before, funny.
>> Vicente J Botet Escriba built a proposal for this otherwise, P0051R1.
>>
> Did you mean D0051R1?  I ask because I remember Vicente mentioning it
> in this newgroup:
>
>
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/D0051|sort:relevance/std-proposals/LfFYY5zCPFw/2DuEYWf6AwAJ
>
OOPS.  Should have looked further:

http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0051r1.pdf

-regards,
Larry



--

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

.

On Mon, Nov 23, 2015 at 4:57 AM, Mathias Gaunard <mathias@gaunard.com> wrote:
> On Sat, Nov 21, 2015 at 6:27 PM, Joel FALCOU <joel.falcou@gmail.com> wrote:
>>
>> ISn't Gaunard's overload class enough ?
>>
>> https://gist.github.com/dabrahams/3779345
>>
>
> I didn't know anyone was using my name to talk about that kind of thing
> before, funny.
> Vicente J Botet Escriba built a proposal for this otherwise, P0051R1.

When we (Dave, Herb and myself) were writing up the generic lambda
proposal back in 2012, if I recall correctly, I thought you were the
first one to bring this technique to anyone's attention (and were
credited as so in our paper) - was it ever 'published' before that?

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

--

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

.

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

2015-11-22 22:04 GMT+01:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:

> On Saturday, November 21, 2015 at 10:17:14 AM UTC-8, Alexander Bolz wrote=
:
>>
>> This is just an idea (and quickly searching the mailing list I didn't fi=
nd
>> something similar). It's probably best illustrated with an example:
>>
>> void print(variant<SomeTypes...> const& v)
>> {
>>     v.visit(
>>         [&] struct {
>>             void operator ()(int x) { ... }
>>             void operator ()(string const& x) { ... }
>>         }
>>     );
>> }
>>
>> i.e. extending the lambda-syntax to create unnamed structs with multiple
>> member
>> functions which all have access to the variables specified in the
>> capture-list.
>>
>
> As opposed to simply creating a local type:
>
> void print(variant<SomeTypes...> const& v)
> {
>     struct Local {
>         variant<SomeTypes...> const *v;
>         Local(variant<SomeTypes...> const& v) : v(&v) {}
>         void operator ()(int x) { ... }
>         void operator ()(string const& x) { ... }
>     };
>     Local loc(v);
>     v.visit(loc);
> }
>

=E2=80=8BYes... as Joel pointed out (and I mentioned in the first message) =
this is
possible using a helper function like overload().=E2=80=8B
So this is probably not the best example...


> I'll admit that your "lambda struct" syntax looks nicer in this example,
> but is it so *much* nicer that we need a syntax for it?
> Also, does your syntax allow me to construct two or more objects of type
> Local? or is the type necessarily unnamed?
>

=E2=80=8BYes. Just like with "ordinary" lambdas right now.=E2=80=8B

I didn't intend to give these structs a name. The struct keyword is just
there so that it's possible to distinguish
a "lambda struct" from "auto x =3D []{};" (Although giving the struct a nam=
e
would probably make it
possible to add "bool operator =3D=3D(Local rhs) {...}" or something like t=
hat
to the resulting function object.)


> I suppose you could extend your syntax a little further to allow giving a
> name to the struct:
>
> auto x =3D [&] struct Local {
>     void operator ()(int x) { ... }
>     void operator ()(string const& x) { ... }
> };
>
> although I don't really understand what it would mean then to say Local y=
;
> or decltype(x) y; in the same scope, or in an inner scope.


=E2=80=8BIt wouldn't be possible. Copying would be ok: Local y =3D f or dec=
ltype(f) y
=3D f.

Ignoring for a moment that it might be possible to add members or specify a
base class, a "lambda struct" wouldn't be too much different from an
ordinary lambda=E2=80=8B.
But it would allow me add additional operator()s and - more important - to
have named member functions:

auto x =3D [&] struct {
    void func1() { ... }
    void func2() { ... }
};

=E2=80=8BI first thought that it would be sufficient to extend the lambda
syntax to [capture-list]
<function-name> (params) { body } (assuming that such
syntax would be possible) but I couldn't image a way to write a
generic overload(lambda1,
lambda2, ...) in this case which would make all overloads
visible in the following case:

auto x =3D make_overload(
    [&] func1(int) {...},
    [&] func1(double) {...}
);

since func1 is a completey arbitrary name.

=E2=80=8BNow that there is return type deduction for normal functions, the =
only
thing unique to lambdas is the [capture-list]. This is the feature I would
like to use
to create custom local structs.=E2=80=8B Currently I can create local struc=
ts with
a single member function operator() only (or I write the capture-list stuff
myself...)



> C++11/14 lambdas aren't generally default-constructible, not even ones
> that have no captures. (This is a pet peeve of mine that I'd love to see
> fixed, by the way. With that and lambdas-in-unevaluated-contexts, it woul=
d
> make it so much easier to provide a deleter for a unique_ptr:
> using Ptr =3D std::unique_ptr<void *, decltype([](void *p){ free(p); })>;=
)
>
> I like the idea of bringing lambdas and structs/classes closer together
> somehow, but I don't think that this particular addition is worth the
> syntax =E2=80=94 yet. That is, the limited proposal here doesn't seem to =
be a full
> step forward in itself, and I don't *immediately* see how to
> incrementally extend it to get all the way to anywhere I'd want to go.
> Which is not to say that such an incremental extension couldn't possibly
> exist.
>
> my $.02,
> =E2=80=93Arthur
>
> P.S. =E2=80=94 In the print-visitor example, did you mean for those opera=
tor()s to
> be non-const? In other words, I wonder whether the proposed syntax would
> encourage people to write subtly incorrect code. The "default constness" =
of
> lambdas' call operators is currently training programmers that they don't
> need to write "const";
> =E2=80=8B =E2=80=8B
> you'll have to either copy what lambdas have done, or else un-train
> everyone.
>

=E2=80=8BYes=E2=80=8B and no... (The struct in the print-visitor example or=
iginally had a
member which was modifed by operator()(int)...)

=E2=80=8B(I dont't know why exactly the call operators are const by default=
.. But I
guess it is because of something like this:

int x =3D 0;
auto f =3D [=3D]{ x =3D 1; }

? Or just that in 99% of the cases a "operator()(...) const" is intended
and this saves a few characters?)

Well the new syntax would very much look like an ordinary struct definition
and it would be quite confusing that in a "lambda struct" member functions
are const by default and in an ordinary struct member functions are mutable
by default... On the other hand it's weird that it is not just not needed
to write "const" but
actually invalid... Good question... Don't know.



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



--=20
Alex

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

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif"><span style=3D"font-family:arial,sans-serif">2015-11-22=
 22:04 GMT+01:00 Arthur O&#39;Dwyer </span><span dir=3D"ltr" style=3D"font-=
family:arial,sans-serif">&lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" t=
arget=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt;</span><span style=3D"fon=
t-family:arial,sans-serif">:</span><br></div><div class=3D"gmail_extra"><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"><span class=3D"">On =
Saturday, November 21, 2015 at 10:17:14 AM UTC-8, Alexander Bolz wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>This is just an i=
dea (and quickly searching the mailing list I didn&#39;t find</div><div>som=
ething similar). It&#39;s probably best illustrated with an example:</div><=
div><br></div><div><font face=3D"courier new, monospace">void print(variant=
&lt;SomeTypes...&gt; const&amp; v)</font></div><div><font face=3D"courier n=
ew, monospace">{</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 v.visit(</font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [&amp;] struct {</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void ope=
rator ()(int x) { ... }</font></div><div><font face=3D"courier new, monospa=
ce">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator ()(string const=
&amp; x) { ... }</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 }</font></div><div><font face=3D"courier new, mono=
space">=C2=A0 =C2=A0 );</font></div><div><font face=3D"courier new, monospa=
ce">}</font></div><div><br></div><div>i.e. extending the lambda-syntax to c=
reate unnamed structs with multiple member</div><div>functions which all ha=
ve access to the variables specified in the capture-list.</div></div></bloc=
kquote><div><br></div></span><div>As opposed to simply creating a local typ=
e:</div><div><br></div><div><span class=3D""><div><font face=3D"courier new=
, monospace">void print(variant&lt;SomeTypes...&gt; const&amp; v)</font></d=
iv><div><font face=3D"courier new, monospace">{</font></div></span><div><fo=
nt face=3D"courier new, monospace">=C2=A0 =C2=A0 struct Local {</font></div=
><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 var=
iant&lt;SomeTypes...&gt; const *v;</font></div><div><font face=3D"courier n=
ew, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 Local(</font><span style=3D"font=
-family:&#39;courier new&#39;,monospace">variant&lt;SomeTypes...&gt; const&=
amp;=C2=A0</span><span style=3D"font-family:&#39;courier new&#39;,monospace=
">v) : v(&amp;v) {}</span></div><span class=3D""><div><span style=3D"font-f=
amily:&#39;courier new&#39;,monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 void ope=
rator ()(int x) { ... }</span><br></div><div><font face=3D"courier new, mon=
ospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator ()(string const&amp; x) {=
 ... }</font></div></span><div><span style=3D"font-family:&#39;courier new&=
#39;,monospace">=C2=A0 =C2=A0 };</span><br></div><div><font face=3D"courier=
 new, monospace">=C2=A0 =C2=A0 Local loc(v);</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 v.visit(loc);</font></div><div><span=
 style=3D"font-family:&#39;courier new&#39;,monospace">}</span></div></div>=
</blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;display:inline">=E2=80=8BYes... as Joel =
pointed out (and I mentioned in the first message) this is possible using a=
 helper function like overload().=E2=80=8B</div></div><div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;display:inline=
">So this is probably not the best example...</div></div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div><div><br></div><div>I&#39;ll admit that yo=
ur &quot;lambda struct&quot; syntax looks nicer in this example, but is it =
so <i>much</i> nicer that we need a syntax for it?</div></div><div>Also, do=
es your syntax allow me to construct two or more objects of type Local? or =
is the type necessarily unnamed?</div></blockquote><div><br></div><div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">=
=E2=80=8BYes. Just like with &quot;ordinary&quot; lambdas right now.=E2=80=
=8B=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif">I didn&#39;t intend to give these structs a =
name. The struct keyword is just there so that it&#39;s possible to disting=
uish</div><div class=3D"gmail_default"><span style=3D"font-family:arial,hel=
vetica,sans-serif">a &quot;lambda struct&quot; from &quot;</span><font face=
=3D"monospace, monospace">auto x =3D []{};</font><font face=3D"arial, helve=
tica, sans-serif">&quot; (Although giving the struct a name would probably =
make it</font></div><div class=3D"gmail_default"><span style=3D"font-family=
:arial,helvetica,sans-serif">possible to add &quot;</span><font face=3D"mon=
ospace, monospace">bool operator =3D=3D(Local rhs) {...}</font><font face=
=3D"arial, helvetica, sans-serif">&quot; or something like that to the resu=
lting function object.)</font></div></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><br></div><div>I suppose you could extend your syntax a =
little further to allow giving a name to the struct:</div><div><br></div><d=
iv><div><font face=3D"courier new, monospace">auto x =3D [&amp;] struct Loc=
al {</font></div><span class=3D""><div><font face=3D"courier new, monospace=
">=C2=A0 =C2=A0 void operator ()(int x) { ... }</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 void operator ()(string const&amp=
; x) { ... }</font></div></span><div><font face=3D"courier new, monospace">=
};</font></div></div><br>although I don&#39;t really understand what it wou=
ld mean then to say=C2=A0<font face=3D"courier new, monospace">Local y;</fo=
nt> or <font face=3D"courier new, monospace">decltype(x) y;</font> in the s=
ame scope, or in an inner scope. </blockquote><div><br></div><div><div clas=
s=3D"gmail_default"><span style=3D"font-family:arial,helvetica,sans-serif">=
=E2=80=8BIt wouldn&#39;t be possible. Copying would be ok: </span><font fac=
e=3D"monospace, monospace">Local y =3D f</font><span style=3D"font-family:a=
rial,helvetica,sans-serif"> or </span><font face=3D"monospace, monospace">d=
ecltype(f) y =3D f</font><font face=3D"arial, helvetica, sans-serif">.</fon=
t></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif">Ignoring for a moment that it might be possible to =
add members or specify a base class, a &quot;lambda struct&quot; wouldn&#39=
;t be too much different from an ordinary lambda=E2=80=8B.</div><div class=
=3D"gmail_default"><span style=3D"font-family:arial,helvetica,sans-serif">B=
ut it would allow me add additional </span><font face=3D"monospace, monospa=
ce">operator()</font><font face=3D"arial, helvetica, sans-serif">s and - mo=
re important - to have named member functions:</font></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif"><br></div><di=
v class=3D"gmail_default"><font face=3D"monospace, monospace">auto x =3D [&=
amp;] struct {</font></div><div class=3D"gmail_default"><font face=3D"monos=
pace, monospace">=C2=A0 =C2=A0 void func1() { ... }</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 =C2=A0 void f=
unc2() { ... }</font></div><div class=3D"gmail_default"><font face=3D"monos=
pace, monospace">};</font></div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default"><=
span style=3D"font-family:arial,helvetica,sans-serif">=E2=80=8BI first thou=
ght that it would be sufficient to extend the lambda syntax to </span><font=
 face=3D"monospace, monospace">[capture-list] &lt;function-name&gt; (params=
) { body }</font><font face=3D"arial, helvetica, sans-serif">=C2=A0(assumin=
g that such</font></div><div class=3D"gmail_default"><font face=3D"arial, h=
elvetica, sans-serif">syntax would be possible) but I couldn&#39;t image a =
way=C2=A0</font><span style=3D"font-family:arial,helvetica,sans-serif">to w=
rite a generic </span><font face=3D"monospace, monospace">overload(lambda1,=
 lambda2, ...)</font><font face=3D"arial, helvetica, sans-serif"> in this c=
ase which would make all overloads</font></div><div class=3D"gmail_default"=
><font face=3D"arial, helvetica, sans-serif">visible in the following case:=
</font></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif"><br></div><div class=3D"gmail_default"><font face=3D"monosp=
ace, monospace">auto x =3D make_overload(</font></div><div class=3D"gmail_d=
efault"><font face=3D"monospace, monospace">=C2=A0 =C2=A0 [&amp;] func1(int=
) {...},</font></div><div class=3D"gmail_default"><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 [&amp;] func1(double) {...}</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">);</font></div></div=
><div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif"><br></div><div class=3D"gmail_default"><span style=3D"font-family:=
arial,helvetica,sans-serif">since </span><font face=3D"monospace, monospace=
">func1 </font><font face=3D"arial, helvetica, sans-serif">is a completey a=
rbitrary name.</font></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif">=E2=80=8BNow that there is retu=
rn type deduction for normal functions, the only thing unique to lambdas is=
 the [capture-list]. This is the feature I would like to use</div><div clas=
s=3D"gmail_default"><span style=3D"font-family:arial,helvetica,sans-serif">=
to create custom local structs.=E2=80=8B Currently I can create local struc=
ts with a single member function </span><font face=3D"monospace, monospace"=
>operator()</font><font face=3D"arial, helvetica, sans-serif">=C2=A0only (o=
r I write the capture-list stuff myself...)</font></div><br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">C++11/14 lambdas aren&#39;t general=
ly default-constructible, not even ones that have no captures. (This is a p=
et peeve of mine that I&#39;d love to see fixed, by the way. With that and =
lambdas-in-unevaluated-contexts, it would make it so much easier to provide=
 a deleter for a unique_ptr:<div><font face=3D"courier new, monospace">usin=
g Ptr =3D std::unique_ptr&lt;void *, decltype([](void *p){ free(p); })&gt;;=
</font>)<div><br>I like the idea of bringing lambdas and structs/classes cl=
oser together somehow, but I don&#39;t think that this particular addition =
is worth the syntax =E2=80=94 yet. That is, the limited proposal here doesn=
&#39;t seem to be a full step forward in itself, and I don&#39;t <i>immedia=
tely</i> see how to incrementally extend it to get all the way to anywhere =
I&#39;d want to go. Which is not to say that such an incremental extension =
couldn&#39;t possibly exist.</div></div><div><br></div><div>my $.02,</div><=
div>=E2=80=93Arthur</div><div><br></div><div>P.S. =E2=80=94 In the print-vi=
sitor example, did you mean for those operator()s to be non-const? In other=
 words, I wonder whether the proposed syntax would encourage people to writ=
e subtly incorrect code. The &quot;default constness&quot; of lambdas&#39; =
call operators is currently training programmers that they don&#39;t need t=
o write &quot;const&quot;;<div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;display:inline">=E2=80=8B =E2=80=8B</div>you&#3=
9;ll have to either copy what lambdas have done, or else un-train everyone.=
</div></blockquote><div><br></div><div><div class=3D"gmail_default"><span s=
tyle=3D"font-family:arial,helvetica,sans-serif">=E2=80=8BYes=E2=80=8B and n=
o... (The struct in the print-visitor example originally had a member which=
 was modifed by </span><font face=3D"monospace, monospace">operator()(int)<=
/font><font face=3D"arial, helvetica, sans-serif">...)</font></div></div><d=
iv><br></div><div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif">=E2=80=8B(I dont&#39;t know why exactly the call opera=
tors are const by default. But I guess it is because of something like this=
:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif"><br></div><div class=3D"gmail_default"><font face=3D"monospace, m=
onospace">int x =3D 0;</font></div><div class=3D"gmail_default"><font face=
=3D"monospace, monospace">auto f =3D [=3D]{ x =3D 1; }</font></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif">? Or just that in 99% of the cases a &quot;operator()(...) const&qu=
ot; is intended and this saves a few characters?)</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">Well=
 the new syntax would very much look like an ordinary struct definition and=
 it would be quite confusing that in a &quot;lambda struct&quot; member fun=
ctions</div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif">are const by default and in an ordinary struct member functi=
ons are mutable by default... On the other hand it&#39;s weird that it is n=
ot just not needed to write &quot;const&quot; but</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif">actually invalid.=
... Good question... Don&#39;t know.</div><br></div><div>=C2=A0</div><blockq=
uote 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">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr">Alex</div></div>
</div></div>

<p></p>

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

--001a114d3a1a81875d0525369bac--

.

Le 23/11/2015 14:02, Faisal Vali a =C3=A9crit :
> On Mon, Nov 23, 2015 at 4:57 AM, Mathias Gaunard <mathias@gaunard.com> wr=
ote:
>> On Sat, Nov 21, 2015 at 6:27 PM, Joel FALCOU <joel.falcou@gmail.com> wro=
te:
>>> ISn't Gaunard's overload class enough ?
>>>
>>> https://gist.github.com/dabrahams/3779345
>>>
>> I didn't know anyone was using my name to talk about that kind of thing
>> before, funny.
>> Vicente J Botet Escriba built a proposal for this otherwise, P0051R1.
> When we (Dave, Herb and myself) were writing up the generic lambda
> proposal back in 2012, if I recall correctly, I thought you were the
> first one to bring this technique to anyone's attention (and were
> credited as so in our paper) - was it ever 'published' before that?
>
>>
The first reference I have found is from the boost svn sandbox overload=20
library

     Copyright (c) 2007-2012 Marco Cecchetti

Vicente

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

.

--089e013cb782feac2d0525877b3a
Content-Type: text/plain; charset=UTF-8

Somewhat off-topic: I know that the original general lambda proposal was
far more radical than the one eventually incorporated into the language.
One of its proposals, later reiterated in n3560, was that a lambda body
could be an expression (clause 2.2 in n3560). Is there any information on
why that particular proposal did not pass?

Cheers,
V.

On Mon, Nov 23, 2015 at 2:02 PM, Faisal Vali <faisalv@gmail.com> wrote:

> On Mon, Nov 23, 2015 at 4:57 AM, Mathias Gaunard <mathias@gaunard.com>
> wrote:
> > On Sat, Nov 21, 2015 at 6:27 PM, Joel FALCOU <joel.falcou@gmail.com>
> wrote:
> >>
> >> ISn't Gaunard's overload class enough ?
> >>
> >> https://gist.github.com/dabrahams/3779345
> >>
> >
> > I didn't know anyone was using my name to talk about that kind of thing
> > before, funny.
> > Vicente J Botet Escriba built a proposal for this otherwise, P0051R1.
>
> When we (Dave, Herb and myself) were writing up the generic lambda
> proposal back in 2012, if I recall correctly, I thought you were the
> first one to bring this technique to anyone's attention (and were
> credited as so in our paper) - was it ever 'published' before that?
>
> >
> > --
> >
> > ---
> > 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/.
>
> --
>
> ---
> 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/.
>

--

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

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

<div dir=3D"ltr">Somewhat off-topic: I know that the original general lambd=
a proposal was far more radical than the one eventually incorporated into t=
he language. One of its proposals, later reiterated in n3560, was that a la=
mbda body could be an expression (clause 2.2 in n3560). Is there any inform=
ation on why that particular proposal did not pass?<div><br></div><div>Chee=
rs,</div><div>V.</div></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On Mon, Nov 23, 2015 at 2:02 PM, 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:1px #ccc solid;padding-left:1ex">On Mon, Nov 23, 20=
15 at 4:57 AM, Mathias Gaunard &lt;<a href=3D"mailto:mathias@gaunard.com">m=
athias@gaunard.com</a>&gt; wrote:<br>
&gt; On Sat, Nov 21, 2015 at 6:27 PM, Joel FALCOU &lt;<a href=3D"mailto:joe=
l.falcou@gmail.com">joel.falcou@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; ISn&#39;t Gaunard&#39;s overload class enough ?<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"https://gist.github.com/dabrahams/3779345" rel=3D"noref=
errer" target=3D"_blank">https://gist.github.com/dabrahams/3779345</a><br>
&gt;&gt;<br>
&gt;<br>
&gt; I didn&#39;t know anyone was using my name to talk about that kind of =
thing<br>
&gt; before, funny.<br>
&gt; Vicente J Botet Escriba built a proposal for this otherwise, P0051R1.<=
br>
<br>
When we (Dave, Herb and myself) were writing up the generic lambda<br>
proposal back in 2012, if I recall correctly, I thought you were the<br>
first one to bring this technique to anyone&#39;s attention (and were<br>
credited as so in our paper) - was it ever &#39;published&#39; before that?=
<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 rel=3D"noreferrer" target=3D"_blank">http://groups.google.com/a/isocpp.org=
/group/std-proposals/</a>.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--089e013cb782feac2d0525877b3a--

.

On Fri, Nov 27, 2015 at 9:38 AM, Viacheslav Usov <via.usov@gmail.com> wrote:
> Somewhat off-topic: I know that the original general lambda proposal was far
> more radical than the one eventually incorporated into the language. One of
> its proposals, later reiterated in n3560, was that a lambda body could be an
> expression (clause 2.2 in n3560). Is there any information on why that
> particular proposal did not pass?
>

Unfortunately, I missed being in EWG when that paper was discussed -
but I got the sense from others who were there that the general
feeling in the room was that this syntax had been summarily dismissed
at the time of initial presentation (in portland) as having the wrong
balance of expressiveness, terseness and obfuscatability - and given
that there were probably no strong champions for the contrary position
present in the room at the time of the second discussion (n3560) - and
since no one has been motivated to write a paper on it since (to try
and reattempt a discussion on a subjective topic with seasoned
opinions) - we are where we are today.

My apologies to EWG if I have misrepresented events.



> Cheers,
> V.
>
> On Mon, Nov 23, 2015 at 2:02 PM, Faisal Vali <faisalv@gmail.com> wrote:
>>
>> On Mon, Nov 23, 2015 at 4:57 AM, Mathias Gaunard <mathias@gaunard.com>
>> wrote:
>> > On Sat, Nov 21, 2015 at 6:27 PM, Joel FALCOU <joel.falcou@gmail.com>
>> > wrote:
>> >>
>> >> ISn't Gaunard's overload class enough ?
>> >>
>> >> https://gist.github.com/dabrahams/3779345
>> >>
>> >
>> > I didn't know anyone was using my name to talk about that kind of thing
>> > before, funny.
>> > Vicente J Botet Escriba built a proposal for this otherwise, P0051R1.
>>
>> When we (Dave, Herb and myself) were writing up the generic lambda
>> proposal back in 2012, if I recall correctly, I thought you were the
>> first one to bring this technique to anyone's attention (and were
>> credited as so in our paper) - was it ever 'published' before that?
>>
>> >
>> > --
>> >
>> > ---
>> > 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/.
>>
>> --
>>
>> ---
>> 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/.
>
>

--

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

.