Topic: Structured bindings and polymorphic lambdas


Author: Curious <rmn100@gmail.com>
Date: Mon, 7 Aug 2017 00:47:04 -0700 (PDT)
Raw View
------=_Part_1379_1212384230.1502092024611
Content-Type: multipart/alternative;
 boundary="----=_Part_1380_1450183236.1502092024611"

------=_Part_1380_1450183236.1502092024611
Content-Type: text/plain; charset="UTF-8"

Structured bindings are awesome, range based for loops like the following
provide a good readable way to iterate through say a map of key value pairs
for (auto [key, value] : map) {
    cout << key << " " << value << endl;
}

This would be even better if it could work with polymorphic lambdas, like
the following
std::for_each(map.begin(), map.end(), [](auto [key, value]) {
    cout << key << " " << value << endl;    cout << key << " " << value <<
endl;
});

Since the lambda (essentially a templated functor) will only be
instantiated when called, it is possible to work through the structured
bindings' "unbinding algorithm" during instantiation.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/63eeb70c-0ff6-4826-aa90-559c28111954%40isocpp.org.

------=_Part_1380_1450183236.1502092024611
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Structured bindings are awesome, range based for loops lik=
e the following provide a good readable way to iterate through say a map of=
 key value pairs<div><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
key</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> value</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">]</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> map</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 cout </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> key </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">&quot; &=
quot;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> value </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> endl</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span></div></code></div><div><br>This would =
be even better if it could work with polymorphic lambdas, like the followin=
g</div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">for_each</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">map</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>.</span><span style=3D"color: #008;" class=3D"styled-by-prettify">begin</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(),</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> map</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">end</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">[](</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">key</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> value</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">])</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 cout </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> key </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">&quot; &quot;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> value </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> endl</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=
=A0cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> key=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify">&quot; &quot;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> value </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> endl</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">});</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></div></code></div><div><br>Since the lambda (e=
ssentially a templated functor) will only be instantiated when called, it i=
s possible to work through the structured bindings&#39; &quot;unbinding alg=
orithm&quot; during instantiation. =C2=A0<br></div><div><br></div><div><br>=
</div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/63eeb70c-0ff6-4826-aa90-559c28111954%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/63eeb70c-0ff6-4826-aa90-559c28111954=
%40isocpp.org</a>.<br />

------=_Part_1380_1450183236.1502092024611--

------=_Part_1379_1212384230.1502092024611--

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 7 Aug 2017 11:50:03 +0300
Raw View
On 7 August 2017 at 10:47, Curious <rmn100@gmail.com> wrote:
> Structured bindings are awesome, range based for loops like the following
> provide a good readable way to iterate through say a map of key value pairs
> for (auto [key, value] : map) {
>     cout << key << " " << value << endl;
> }
>
> This would be even better if it could work with polymorphic lambdas, like
> the following
> std::for_each(map.begin(), map.end(), [](auto [key, value]) {
>     cout << key << " " << value << endl;    cout << key << " " << value <<
> endl;
> });
>
> Since the lambda (essentially a templated functor) will only be instantiated
> when called, it is possible to work through the structured bindings'
> "unbinding algorithm" during instantiation.

So if you just write

std::for_each(map.begin(), map.end(), [](auto elem) {
    auto [key, value] = elem;
    cout << key << " " << value << endl;    cout << key << " " << value << endl;
});

you'll get what you want today without language extensions.

If you want parameters that automatically do structured binding, you
need to provide them for function templates
as well as lambdas.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYv8zE2ysVVvd7LvZm9eAeSC7mJ7nDZZLkBoL8x-4-v_A%40mail.gmail.com.

.


Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 7 Aug 2017 04:00:04 -0500
Raw View
On Mon, Aug 7, 2017 at 3:50 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> So if you just write
>
> std::for_each(map.begin(), map.end(), [](auto elem) {
>     auto [key, value] = elem;
>     cout << key << " " << value << endl;    cout << key << " " << value << endl;
> });
>
> you'll get what you want today without language extensions.
>
> If you want parameters that automatically do structured binding, you
> need to provide them for function templates
> as well as lambdas.
>

My guess is that OP feels that structured bindings
should be available to any places where `auto`
serves as a declarator.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuAGt1rJgniPc6OMBbbHiCKg6dKQqSOqQpzN2CfXOhmz8A%40mail.gmail.com.

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 7 Aug 2017 07:32:19 -0700 (PDT)
Raw View
------=_Part_3180_1031903290.1502116339330
Content-Type: multipart/alternative;
 boundary="----=_Part_3181_1108637118.1502116339331"

------=_Part_3181_1108637118.1502116339331
Content-Type: text/plain; charset="UTF-8"



On Monday, August 7, 2017 at 5:00:09 AM UTC-4, Zhihao Yuan wrote:
>
> On Mon, Aug 7, 2017 at 3:50 AM, Ville Voutilainen
> <ville.vo...@gmail.com <javascript:>> wrote:
> > So if you just write
> >
> > std::for_each(map.begin(), map.end(), [](auto elem) {
> >     auto [key, value] = elem;
> >     cout << key << " " << value << endl;    cout << key << " " << value
> << endl;
> > });
> >
> > you'll get what you want today without language extensions.
> >
> > If you want parameters that automatically do structured binding, you
> > need to provide them for function templates
> > as well as lambdas.
> >
>
> My guess is that OP feels that structured bindings
> should be available to any places where `auto`
> serves as a declarator.
>

But the meaning of `auto` in a variable declaration is *very different*
from the meaning of `auto` in a parameter list. They deduce types
differently, they result in different syntactic constructs.

Basically, the only reason we use `auto` in parameter lists at all is that
we didn't want to make a new keyword.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/11dfbefc-71e3-4a10-b833-a9f2dad55992%40isocpp.org.

------=_Part_3181_1108637118.1502116339331
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, August 7, 2017 at 5:00:09 AM UTC-4, Zhi=
hao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Aug 7, =
2017 at 3:50 AM, Ville Voutilainen
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
S_x1VEFCBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">ville.vo...@gmail.com</a>&gt; wrote:
<br>&gt; So if you just write
<br>&gt;
<br>&gt; std::for_each(map.begin(), map.end(), [](auto elem) {
<br>&gt; =C2=A0 =C2=A0 auto [key, value] =3D elem;
<br>&gt; =C2=A0 =C2=A0 cout &lt;&lt; key &lt;&lt; &quot; &quot; &lt;&lt; va=
lue &lt;&lt; endl; =C2=A0 =C2=A0cout &lt;&lt; key &lt;&lt; &quot; &quot; &l=
t;&lt; value &lt;&lt; endl;
<br>&gt; });
<br>&gt;
<br>&gt; you&#39;ll get what you want today without language extensions.
<br>&gt;
<br>&gt; If you want parameters that automatically do structured binding, y=
ou
<br>&gt; need to provide them for function templates
<br>&gt; as well as lambdas.
<br>&gt;
<br>
<br>My guess is that OP feels that structured bindings
<br>should be available to any places where `auto`
<br>serves as a declarator.
<br></blockquote><div><br>But the meaning of `auto` in a variable declarati=
on is <i>very different</i> from the meaning of `auto` in a parameter list.=
 They deduce types differently, they result in different syntactic construc=
ts.<br><br>Basically, the only reason we use `auto` in parameter lists at a=
ll is that we didn&#39;t want to make a new keyword.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/11dfbefc-71e3-4a10-b833-a9f2dad55992%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/11dfbefc-71e3-4a10-b833-a9f2dad55992=
%40isocpp.org</a>.<br />

------=_Part_3181_1108637118.1502116339331--

------=_Part_3180_1031903290.1502116339330--

.


Author: Tom Honermann <tom@honermann.net>
Date: Mon, 7 Aug 2017 11:42:32 -0400
Raw View
This is a multi-part message in MIME format.
--------------8613E92C8334A1F6256C9553
Content-Type: text/plain; charset="UTF-8"; format=flowed

On 08/07/2017 10:32 AM, Nicol Bolas wrote:
>
>
> On Monday, August 7, 2017 at 5:00:09 AM UTC-4, Zhihao Yuan wrote:
>
>     On Mon, Aug 7, 2017 at 3:50 AM, Ville Voutilainen
>     <ville.vo...@gmail.com <javascript:>> wrote:
>     > So if you just write
>     >
>     > std::for_each(map.begin(), map.end(), [](auto elem) {
>     >     auto [key, value] = elem;
>     >     cout << key << " " << value << endl;    cout << key << " "
>     << value << endl;
>     > });
>     >
>     > you'll get what you want today without language extensions.
>     >
>     > If you want parameters that automatically do structured binding,
>     you
>     > need to provide them for function templates
>     > as well as lambdas.
>     >
>
>     My guess is that OP feels that structured bindings
>     should be available to any places where `auto`
>     serves as a declarator.
>
>
> But the meaning of `auto` in a variable declaration is /very
> different/ from the meaning of `auto` in a parameter list. They deduce
> types differently, they result in different syntactic constructs.

That doesn't match my understanding.  The standard defines type
deduction for use of 'auto' in declaring a variable in terms of template
argument deduction (with a tweak for std::initializer_list) in
10.1.7.4.1p4 [1].  This matches the function call operator generated by
a generic lambda as described in 8.1.5.1p3 [2].

>
> Basically, the only reason we use `auto` in parameter lists at all is
> that we didn't want to make a new keyword.

That also doesn't match my understanding.

Tom.

[1]: http://eel.is/c++draft/dcl.spec.auto#dcl.type.auto.deduct-4
[2]: http://eel.is/c++draft/expr.prim.lambda#closure-3

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e4031ecc-2aaa-b7e8-8fef-a9a18e0d0e3b%40honermann.net.

--------------8613E92C8334A1F6256C9553
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 08/07/2017 10:32 AM, Nicol Bolas
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:11dfbefc-71e3-4a10-b833-a9f2dad55992@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        On Monday, August 7, 2017 at 5:00:09 AM UTC-4, Zhihao Yuan
        wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon,
          Aug 7, 2017 at 3:50 AM, Ville Voutilainen
          <br>
          &lt;<a moz-do-not-send=3D"true" href=3D"javascript:"
            target=3D"_blank" gdf-obfuscated-mailto=3D"S_x1VEFCBwAJ"
            rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retur=
n
            true;" onclick=3D"this.href=3D'javascript:';return true;">ville=
..vo...@gmail.com</a>&gt;
          wrote:
          <br>
          &gt; So if you just write
          <br>
          &gt;
          <br>
          &gt; std::for_each(map.begin(), map.end(), [](auto elem) {
          <br>
          &gt; =C2=A0 =C2=A0 auto [key, value] =3D elem;
          <br>
          &gt; =C2=A0 =C2=A0 cout &lt;&lt; key &lt;&lt; " " &lt;&lt; value
          &lt;&lt; endl; =C2=A0 =C2=A0cout &lt;&lt; key &lt;&lt; " " &lt;&l=
t;
          value &lt;&lt; endl;
          <br>
          &gt; });
          <br>
          &gt;
          <br>
          &gt; you'll get what you want today without language
          extensions.
          <br>
          &gt;
          <br>
          &gt; If you want parameters that automatically do structured
          binding, you
          <br>
          &gt; need to provide them for function templates
          <br>
          &gt; as well as lambdas.
          <br>
          &gt;
          <br>
          <br>
          My guess is that OP feels that structured bindings
          <br>
          should be available to any places where `auto`
          <br>
          serves as a declarator.
          <br>
        </blockquote>
        <div><br>
          But the meaning of `auto` in a variable declaration is <i>very
            different</i> from the meaning of `auto` in a parameter
          list. They deduce types differently, they result in different
          syntactic constructs.<br>
        </div>
      </div>
    </blockquote>
    <br>
    That doesn't match my understanding.=C2=A0 The standard defines type
    deduction for use of 'auto' in declaring a variable in terms of
    template argument deduction (with a tweak for std::initializer_list)
    in 10.1.7.4.1p4 [1].=C2=A0 This matches the function call operator
    generated by a generic lambda as described in 8.1.5.1p3 [2].<br>
    <br>
    <blockquote
      cite=3D"mid:11dfbefc-71e3-4a10-b833-a9f2dad55992@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          Basically, the only reason we use `auto` in parameter lists at
          all is that we didn't want to make a new keyword.</div>
      </div>
    </blockquote>
    <br>
    That also doesn't match my understanding.<br>
    <br>
    Tom.<br>
    <br>
    [1]: <a class=3D"moz-txt-link-freetext" href=3D"http://eel.is/c++draft/=
dcl.spec.auto#dcl.type.auto.deduct-4">http://eel.is/c++draft/dcl.spec.auto#=
dcl.type.auto.deduct-4</a><br>
    [2]: <a class=3D"moz-txt-link-freetext" href=3D"http://eel.is/c++draft/=
expr.prim.lambda#closure-3">http://eel.is/c++draft/expr.prim.lambda#closure=
-3</a><br>
  </body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e4031ecc-2aaa-b7e8-8fef-a9a18e0d0e3b%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/e4031ecc-2aaa-b7e8-8fef-a9a18e0d0=
e3b%40honermann.net</a>.<br />

--------------8613E92C8334A1F6256C9553--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 7 Aug 2017 08:59:48 -0700 (PDT)
Raw View
------=_Part_3327_1698409525.1502121588608
Content-Type: multipart/alternative;
 boundary="----=_Part_3328_1294957982.1502121588609"

------=_Part_3328_1294957982.1502121588609
Content-Type: text/plain; charset="UTF-8"



On Monday, August 7, 2017 at 11:42:35 AM UTC-4, Tom Honermann wrote:
>
> On 08/07/2017 10:32 AM, Nicol Bolas wrote:
>
>
>
> On Monday, August 7, 2017 at 5:00:09 AM UTC-4, Zhihao Yuan wrote:
>>
>> On Mon, Aug 7, 2017 at 3:50 AM, Ville Voutilainen
>> <ville.vo...@gmail.com> wrote:
>> > So if you just write
>> >
>> > std::for_each(map.begin(), map.end(), [](auto elem) {
>> >     auto [key, value] = elem;
>> >     cout << key << " " << value << endl;    cout << key << " " << value
>> << endl;
>> > });
>> >
>> > you'll get what you want today without language extensions.
>> >
>> > If you want parameters that automatically do structured binding, you
>> > need to provide them for function templates
>> > as well as lambdas.
>> >
>>
>> My guess is that OP feels that structured bindings
>> should be available to any places where `auto`
>> serves as a declarator.
>>
>
> But the meaning of `auto` in a variable declaration is *very different*
> from the meaning of `auto` in a parameter list. They deduce types
> differently, they result in different syntactic constructs.
>
>
> That doesn't match my understanding.  The standard defines type deduction
> for use of 'auto' in declaring a variable in terms of template argument
> deduction (with a tweak for std::initializer_list) in 10.1.7.4.1p4 [1].
> This matches the function call operator generated by a generic lambda as
> described in 8.1.5.1p3 [2].
>

.... Huh. Apparently, I've gotten *so used* to typing `auto&&` in generic
lambdas that I'd forgotten the `&&` was even there.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/db548e44-044d-47d4-9435-4a7c1d91947b%40isocpp.org.

------=_Part_3328_1294957982.1502121588609
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, August 7, 2017 at 11:42:35 AM UTC-4, To=
m Honermann wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>On 08/07/2017 10:32 AM, Nicol Bolas
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        On Monday, August 7, 2017 at 5:00:09 AM UTC-4, Zhihao Yuan
        wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">On Mon,
          Aug 7, 2017 at 3:50 AM, Ville Voutilainen
          <br>
          &lt;<a rel=3D"nofollow">ville.vo...@gmail.com</a>&gt;
          wrote:
          <br>
          &gt; So if you just write
          <br>
          &gt;
          <br>
          &gt; std::for_each(map.begin(), map.end(), [](auto elem) {
          <br>
          &gt; =C2=A0 =C2=A0 auto [key, value] =3D elem;
          <br>
          &gt; =C2=A0 =C2=A0 cout &lt;&lt; key &lt;&lt; &quot; &quot; &lt;&=
lt; value
          &lt;&lt; endl; =C2=A0 =C2=A0cout &lt;&lt; key &lt;&lt; &quot; &qu=
ot; &lt;&lt;
          value &lt;&lt; endl;
          <br>
          &gt; });
          <br>
          &gt;
          <br>
          &gt; you&#39;ll get what you want today without language
          extensions.
          <br>
          &gt;
          <br>
          &gt; If you want parameters that automatically do structured
          binding, you
          <br>
          &gt; need to provide them for function templates
          <br>
          &gt; as well as lambdas.
          <br>
          &gt;
          <br>
          <br>
          My guess is that OP feels that structured bindings
          <br>
          should be available to any places where `auto`
          <br>
          serves as a declarator.
          <br>
        </blockquote>
        <div><br>
          But the meaning of `auto` in a variable declaration is <i>very
            different</i> from the meaning of `auto` in a parameter
          list. They deduce types differently, they result in different
          syntactic constructs.<br>
        </div>
      </div>
    </blockquote>
    <br>
    That doesn&#39;t match my understanding.=C2=A0 The standard defines typ=
e
    deduction for use of &#39;auto&#39; in declaring a variable in terms of
    template argument deduction (with a tweak for std::initializer_list)
    in 10.1.7.4.1p4 [1].=C2=A0 This matches the function call operator
    generated by a generic lambda as described in 8.1.5.1p3 [2].<br></div><=
/blockquote><div><br>... Huh. Apparently, I&#39;ve gotten <i>so used</i> to=
 typing `auto&amp;&amp;` in generic lambdas that I&#39;d forgotten the `&am=
p;&amp;` was even there.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/db548e44-044d-47d4-9435-4a7c1d91947b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/db548e44-044d-47d4-9435-4a7c1d91947b=
%40isocpp.org</a>.<br />

------=_Part_3328_1294957982.1502121588609--

------=_Part_3327_1698409525.1502121588608--

.


Author: rmn100@gmail.com
Date: Mon, 7 Aug 2017 11:10:13 -0700 (PDT)
Raw View
------=_Part_3458_522171900.1502129413631
Content-Type: multipart/alternative;
 boundary="----=_Part_3459_595904837.1502129413632"

------=_Part_3459_595904837.1502129413632
Content-Type: text/plain; charset="UTF-8"

True, but then you could also do everything that you do with (polymorphic)
lambdas with (templated) functors.  And structured bindings were never
really needed in the first place, they are just a convenience to have.

Similarly it would be convenient to extend this to be applicable to
polymorphic lambdas because that is a very common use case for auto.  And
as far as I can see there isn't any syntactic ambiguity in doing so.

On Monday, 7 August 2017 01:50:06 UTC-7, Ville Voutilainen wrote:
>
> On 7 August 2017 at 10:47, Curious <rmn...@gmail.com <javascript:>>
> wrote:
> > Structured bindings are awesome, range based for loops like the
> following
> > provide a good readable way to iterate through say a map of key value
> pairs
> > for (auto [key, value] : map) {
> >     cout << key << " " << value << endl;
> > }
> >
> > This would be even better if it could work with polymorphic lambdas,
> like
> > the following
> > std::for_each(map.begin(), map.end(), [](auto [key, value]) {
> >     cout << key << " " << value << endl;    cout << key << " " << value
> <<
> > endl;
> > });
> >
> > Since the lambda (essentially a templated functor) will only be
> instantiated
> > when called, it is possible to work through the structured bindings'
> > "unbinding algorithm" during instantiation.
>
> So if you just write
>
> std::for_each(map.begin(), map.end(), [](auto elem) {
>     auto [key, value] = elem;
>     cout << key << " " << value << endl;    cout << key << " " << value <<
> endl;
> });
>
> you'll get what you want today without language extensions.
>
> If you want parameters that automatically do structured binding, you
> need to provide them for function templates
> as well as lambdas.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3f3c2c90-131a-4c04-b8f1-36f779863e47%40isocpp.org.

------=_Part_3459_595904837.1502129413632
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">True, but then you could also do everything that you do wi=
th (polymorphic) lambdas with (templated) functors. =C2=A0And structured bi=
ndings were never really needed in the first place, they are just a conveni=
ence to have. =C2=A0<div><br></div><div>Similarly it would be convenient to=
 extend this to be applicable to polymorphic lambdas because that is a very=
 common use case for <font face=3D"courier new, monospace">auto</font><font=
 face=3D"arial, sans-serif">. =C2=A0And as far as I can see there isn&#39;t=
 any syntactic ambiguity in doing so.</font><br><br>On Monday, 7 August 201=
7 01:50:06 UTC-7, Ville Voutilainen  wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">On 7 August 2017 at 10:47, Curious &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"zonszbRBBwAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;">rmn...@gmail.com</a>&gt; wro=
te:
<br>&gt; Structured bindings are awesome, range based for loops like the fo=
llowing
<br>&gt; provide a good readable way to iterate through say a map of key va=
lue pairs
<br>&gt; for (auto [key, value] : map) {
<br>&gt; =C2=A0 =C2=A0 cout &lt;&lt; key &lt;&lt; &quot; &quot; &lt;&lt; va=
lue &lt;&lt; endl;
<br>&gt; }
<br>&gt;
<br>&gt; This would be even better if it could work with polymorphic lambda=
s, like
<br>&gt; the following
<br>&gt; std::for_each(map.begin(), map.end(), [](auto [key, value]) {
<br>&gt; =C2=A0 =C2=A0 cout &lt;&lt; key &lt;&lt; &quot; &quot; &lt;&lt; va=
lue &lt;&lt; endl; =C2=A0 =C2=A0cout &lt;&lt; key &lt;&lt; &quot; &quot; &l=
t;&lt; value &lt;&lt;
<br>&gt; endl;
<br>&gt; });
<br>&gt;
<br>&gt; Since the lambda (essentially a templated functor) will only be in=
stantiated
<br>&gt; when called, it is possible to work through the structured binding=
s&#39;
<br>&gt; &quot;unbinding algorithm&quot; during instantiation.
<br>
<br>So if you just write
<br>
<br>std::for_each(map.begin(), map.end(), [](auto elem) {
<br>=C2=A0 =C2=A0 auto [key, value] =3D elem;
<br>=C2=A0 =C2=A0 cout &lt;&lt; key &lt;&lt; &quot; &quot; &lt;&lt; value &=
lt;&lt; endl; =C2=A0 =C2=A0cout &lt;&lt; key &lt;&lt; &quot; &quot; &lt;&lt=
; value &lt;&lt; endl;
<br>});
<br>
<br>you&#39;ll get what you want today without language extensions.
<br>
<br>If you want parameters that automatically do structured binding, you
<br>need to provide them for function templates
<br>as well as lambdas.
<br></blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3f3c2c90-131a-4c04-b8f1-36f779863e47%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3f3c2c90-131a-4c04-b8f1-36f779863e47=
%40isocpp.org</a>.<br />

------=_Part_3459_595904837.1502129413632--

------=_Part_3458_522171900.1502129413631--

.


Author: rmn100@gmail.com
Date: Mon, 7 Aug 2017 11:18:05 -0700 (PDT)
Raw View
------=_Part_2108_1515589917.1502129885374
Content-Type: multipart/alternative;
 boundary="----=_Part_2109_1679566550.1502129885375"

------=_Part_2109_1679566550.1502129885375
Content-Type: text/plain; charset="UTF-8"

Also, I personally don't see the need to extend this to work with template
functions (that are not lambdas).  Structured bindings do template type
deduction similar to auto (not the same of course) but that is not extended
to templates currently either.

But you are right, maybe the structured bindings syntax should be added to
templates.  Structured bindings with polymorphic lambdas seems very
natural.  Structured bindings with template functions on the other hand
might not seem as natural.

On Monday, 7 August 2017 01:50:06 UTC-7, Ville Voutilainen wrote:
>
> On 7 August 2017 at 10:47, Curious <rmn...@gmail.com <javascript:>>
> wrote:
> > Structured bindings are awesome, range based for loops like the
> following
> > provide a good readable way to iterate through say a map of key value
> pairs
> > for (auto [key, value] : map) {
> >     cout << key << " " << value << endl;
> > }
> >
> > This would be even better if it could work with polymorphic lambdas,
> like
> > the following
> > std::for_each(map.begin(), map.end(), [](auto [key, value]) {
> >     cout << key << " " << value << endl;    cout << key << " " << value
> <<
> > endl;
> > });
> >
> > Since the lambda (essentially a templated functor) will only be
> instantiated
> > when called, it is possible to work through the structured bindings'
> > "unbinding algorithm" during instantiation.
>
> So if you just write
>
> std::for_each(map.begin(), map.end(), [](auto elem) {
>     auto [key, value] = elem;
>     cout << key << " " << value << endl;    cout << key << " " << value <<
> endl;
> });
>
> you'll get what you want today without language extensions.
>
> If you want parameters that automatically do structured binding, you
> need to provide them for function templates
> as well as lambdas.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5330f5d6-0a90-4417-a16d-d8d400d3294a%40isocpp.org.

------=_Part_2109_1679566550.1502129885375
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Also, I personally don&#39;t see the need to extend t=
his to work with template functions (that are not lambdas). =C2=A0Structure=
d bindings do template type deduction similar to <font face=3D"courier new,=
 monospace">auto</font>=C2=A0(not the same of course) but that is not exten=
ded to templates currently either.=C2=A0<br></div><div><br></div><div>But y=
ou are right, maybe the structured bindings syntax should be added to templ=
ates. =C2=A0Structured bindings with polymorphic lambdas seems very natural=
.. =C2=A0Structured bindings with template functions on the other hand might=
 not seem as natural. =C2=A0</div><div><br>On Monday, 7 August 2017 01:50:0=
6 UTC-7, Ville Voutilainen  wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">On 7 August 2017 at 10:47, Curious &lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"zonszbRBBwAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">rmn...@gmail.com</a>&gt; wrote:
<br>&gt; Structured bindings are awesome, range based for loops like the fo=
llowing
<br>&gt; provide a good readable way to iterate through say a map of key va=
lue pairs
<br>&gt; for (auto [key, value] : map) {
<br>&gt; =C2=A0 =C2=A0 cout &lt;&lt; key &lt;&lt; &quot; &quot; &lt;&lt; va=
lue &lt;&lt; endl;
<br>&gt; }
<br>&gt;
<br>&gt; This would be even better if it could work with polymorphic lambda=
s, like
<br>&gt; the following
<br>&gt; std::for_each(map.begin(), map.end(), [](auto [key, value]) {
<br>&gt; =C2=A0 =C2=A0 cout &lt;&lt; key &lt;&lt; &quot; &quot; &lt;&lt; va=
lue &lt;&lt; endl; =C2=A0 =C2=A0cout &lt;&lt; key &lt;&lt; &quot; &quot; &l=
t;&lt; value &lt;&lt;
<br>&gt; endl;
<br>&gt; });
<br>&gt;
<br>&gt; Since the lambda (essentially a templated functor) will only be in=
stantiated
<br>&gt; when called, it is possible to work through the structured binding=
s&#39;
<br>&gt; &quot;unbinding algorithm&quot; during instantiation.
<br>
<br>So if you just write
<br>
<br>std::for_each(map.begin(), map.end(), [](auto elem) {
<br>=C2=A0 =C2=A0 auto [key, value] =3D elem;
<br>=C2=A0 =C2=A0 cout &lt;&lt; key &lt;&lt; &quot; &quot; &lt;&lt; value &=
lt;&lt; endl; =C2=A0 =C2=A0cout &lt;&lt; key &lt;&lt; &quot; &quot; &lt;&lt=
; value &lt;&lt; endl;
<br>});
<br>
<br>you&#39;ll get what you want today without language extensions.
<br>
<br>If you want parameters that automatically do structured binding, you
<br>need to provide them for function templates
<br>as well as lambdas.
<br></blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5330f5d6-0a90-4417-a16d-d8d400d3294a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5330f5d6-0a90-4417-a16d-d8d400d3294a=
%40isocpp.org</a>.<br />

------=_Part_2109_1679566550.1502129885375--

------=_Part_2108_1515589917.1502129885374--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 7 Aug 2017 11:24:03 -0700 (PDT)
Raw View
------=_Part_3521_1623852238.1502130243740
Content-Type: multipart/alternative;
 boundary="----=_Part_3522_12962615.1502130243741"

------=_Part_3522_12962615.1502130243741
Content-Type: text/plain; charset="UTF-8"

On Monday, August 7, 2017 at 3:47:04 AM UTC-4, Curious wrote:
>
> Structured bindings are awesome, range based for loops like the following
> provide a good readable way to iterate through say a map of key value pairs
> for (auto [key, value] : map) {
>     cout << key << " " << value << endl;
> }
>
> This would be even better if it could work with polymorphic lambdas, like
> the following
> std::for_each(map.begin(), map.end(), [](auto [key, value]) {
>     cout << key << " " << value << endl;    cout << key << " " << value <<
> endl;
> });
>
> Since the lambda (essentially a templated functor) will only be
> instantiated when called, it is possible to work through the structured
> bindings' "unbinding algorithm" during instantiation.
>

From a standardization point of view, one of the really big questions is
this: what is the *actual* signature of the function? Does that lambda take
two variables, with the unpacking done implicitly by the caller during
argument-to-parameter processing? Or does that function take one parameter
which gets unpacked before the first statement of the function body?

This matters a lot for exception handling. If `get` throws an exception, we
need to know who's responsible for catching it. In case #1, the only one
who could catch it is the person doing the function call expression. In
case #2, I would assume a function-level try-block would be able to catch
it.

This also matters for knowing what the function actually looks like. Can
you stick an `[](auto [x, y])` into a `std::function<void(int, int)>`, or
does it go into a `std::function<void(tuple<int, int>)>`? I suspect it's
the latter, since you can't call the lambda with two parameters.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4e076114-0f5f-4637-b9ba-70fdb163e51a%40isocpp.org.

------=_Part_3522_12962615.1502130243741
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, August 7, 2017 at 3:47:04 AM UTC-4, Curious wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Structured=
 bindings are awesome, range based for loops like the following provide a g=
ood readable way to iterate through say a map of key value pairs<div><div s=
tyle=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187)=
;word-wrap:break-word"><code><div><span style=3D"color:#008">for</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#008">auto</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">[</span><span style=3D"color:#000">key</span><span style=3D=
"color:#660">,</span><span style=3D"color:#000"> value</span><span style=3D=
"color:#660">]</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">:</span><span style=3D"color:#000"> map</span><span style=3D"color:=
#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 cout </span><span sty=
le=3D"color:#660">&lt;&lt;</span><span style=3D"color:#000"> key </span><sp=
an style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#000"> </span><=
span style=3D"color:#080">&quot; &quot;</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#000">=
 value </span><span style=3D"color:#660">&lt;&lt;</span><span style=3D"colo=
r:#000"> endl</span><span style=3D"color:#660">;</span><span style=3D"color=
:#000"><br></span><span style=3D"color:#660">}</span><span style=3D"color:#=
000"><br></span></div></code></div><div><br>This would be even better if it=
 could work with polymorphic lambdas, like the following</div><div style=3D=
"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-w=
rap:break-word"><code><div><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">for_each</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">map</span><span style=
=3D"color:#660">.</span><span style=3D"color:#008">begin</span><span style=
=3D"color:#660">(),</span><span style=3D"color:#000"> map</span><span style=
=3D"color:#660">.</span><span style=3D"color:#008">end</span><span style=3D=
"color:#660">(),</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">[](</span><span style=3D"color:#008">auto</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">[</span><span style=3D"color:#=
000">key</span><span style=3D"color:#660">,</span><span style=3D"color:#000=
"> value</span><span style=3D"color:#660">])</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"><b=
r>=C2=A0 =C2=A0 cout </span><span style=3D"color:#660">&lt;&lt;</span><span=
 style=3D"color:#000"> key </span><span style=3D"color:#660">&lt;&lt;</span=
><span style=3D"color:#000"> </span><span style=3D"color:#080">&quot; &quot=
;</span><span style=3D"color:#000"> </span><span style=3D"color:#660">&lt;&=
lt;</span><span style=3D"color:#000"> value </span><span style=3D"color:#66=
0">&lt;&lt;</span><span style=3D"color:#000"> endl</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0cout </span><span=
 style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#000"> key </span=
><span style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#080">&quot; &quot;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#0=
00"> value </span><span style=3D"color:#660">&lt;&lt;</span><span style=3D"=
color:#000"> endl</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"><br></span><span style=3D"color:#660">});</span><span style=3D"c=
olor:#000"><br></span></div></code></div><div><br>Since the lambda (essenti=
ally a templated functor) will only be instantiated when called, it is poss=
ible to work through the structured bindings&#39; &quot;unbinding algorithm=
&quot; during instantiation.=C2=A0 <br></div></div></div></blockquote><div>=
<br>From a standardization point of view, one of the really big questions i=
s this: what is the <i>actual</i> signature of the function? Does that lamb=
da take two variables, with the unpacking done implicitly by the caller dur=
ing argument-to-parameter processing? Or does that function take one parame=
ter which gets unpacked before the first statement of the function body?<br=
><br>This matters a lot for exception handling. If `get` throws an exceptio=
n, we need to know who&#39;s responsible for catching it. In case #1, the o=
nly one who could catch it is the person doing the function call expression=
.. In case #2, I would assume a function-level try-block would be able to ca=
tch it.<br><br>This also matters for knowing what the function actually loo=
ks like. Can you stick an `[](auto [x, y])` into a `std::function&lt;void(i=
nt, int)&gt;`, or does it go into a `std::function&lt;void(tuple&lt;int, in=
t&gt;)&gt;`? I suspect it&#39;s the latter, since you can&#39;t call the la=
mbda with two parameters.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4e076114-0f5f-4637-b9ba-70fdb163e51a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4e076114-0f5f-4637-b9ba-70fdb163e51a=
%40isocpp.org</a>.<br />

------=_Part_3522_12962615.1502130243741--

------=_Part_3521_1623852238.1502130243740--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 7 Aug 2017 11:25:59 -0700 (PDT)
Raw View
------=_Part_3568_515859155.1502130359707
Content-Type: multipart/alternative;
 boundary="----=_Part_3569_1616791707.1502130359707"

------=_Part_3569_1616791707.1502130359707
Content-Type: text/plain; charset="UTF-8"

On Monday, August 7, 2017 at 2:18:05 PM UTC-4, rmn...@gmail.com wrote:
>
> Also, I personally don't see the need to extend this to work with template
> functions (that are not lambdas).  Structured bindings do template type
> deduction similar to auto (not the same of course) but that is not
> extended to templates currently either.
>
> But you are right, maybe the structured bindings syntax should be added to
> templates.  Structured bindings with polymorphic lambdas seems very
> natural.  Structured bindings with template functions on the other hand
> might not seem as natural.
>

The thing is, lambdas benefit greatly from being terse. While terseness is
nice for regular functions, it's *really* important for short, one-off
lambdas. So it's reasonable to restrict a feature like this to just lambdas.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a77dfd74-f263-4dec-b948-8e88354915ac%40isocpp.org.

------=_Part_3569_1616791707.1502130359707
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, August 7, 2017 at 2:18:05 PM UTC-4, rmn...@gmai=
l.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>Also, I personally don&#39;t see the need to extend this to work with t=
emplate functions (that are not lambdas). =C2=A0Structured bindings do temp=
late type deduction similar to <font face=3D"courier new, monospace">auto</=
font>=C2=A0(not the same of course) but that is not extended to templates c=
urrently either.=C2=A0<br></div><div><br></div><div>But you are right, mayb=
e the structured bindings syntax should be added to templates. =C2=A0Struct=
ured bindings with polymorphic lambdas seems very natural. =C2=A0Structured=
 bindings with template functions on the other hand might not seem as natur=
al. =C2=A0</div></div></blockquote><div><br>The thing is, lambdas benefit g=
reatly from being terse. While terseness is nice for regular functions, it&=
#39;s <i>really</i> important for short, one-off lambdas. So it&#39;s reaso=
nable to restrict a feature like this to just lambdas.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a77dfd74-f263-4dec-b948-8e88354915ac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a77dfd74-f263-4dec-b948-8e88354915ac=
%40isocpp.org</a>.<br />

------=_Part_3569_1616791707.1502130359707--

------=_Part_3568_515859155.1502130359707--

.


Author: rmn100@gmail.com
Date: Mon, 7 Aug 2017 11:42:40 -0700 (PDT)
Raw View
------=_Part_3717_1882231634.1502131360615
Content-Type: multipart/alternative;
 boundary="----=_Part_3718_1023804360.1502131360615"

------=_Part_3718_1023804360.1502131360615
Content-Type: text/plain; charset="UTF-8"



From a standardization point of view, one of the really big questions is
> this: what is the *actual* signature of the function? Does that lambda
> take two variables, with the unpacking done implicitly by the caller during
> argument-to-parameter processing? Or does that function take one parameter
> which gets unpacked before the first statement of the function body?
>

The lambda should take one variable, this would make it easy to pass
polymorphic lambdas to algorithms/functions that pass more than one
parameter to the lambda.  And if the user had specified one of the
arguments to be a structured binding, they would be "unwrapped" only for
that specific lambda.  For example, if there was a version of
`std::for_each` that passed the element along with the index to the passed
functor, then the following could be done (skipping the iterators for
readability)

std::for_each(map, [](auto [key, value], auto index) { ... });
std::for_each(vector, [](auto ele, auto index) { ... ));


> This matters a lot for exception handling. If `get` throws an exception,
> we need to know who's responsible for catching it. In case #1, the only one
> who could catch it is the person doing the function call expression. In
> case #2, I would assume a function-level try-block would be able to catch
> it.
>

I feel like having the caller handle the exception would be the natural
thing to do here.


> This also matters for knowing what the function actually looks like. Can
> you stick an `[](auto [x, y])` into a `std::function<void(int, int)>`, or
> does it go into a `std::function<void(tuple<int, int>)>`? I suspect it's
> the latter, since you can't call the lambda with two parameters.
>

The latter, yeah, just like an [](auto){} lamdba with a std::function<void(tuple<int,
int>)>

If you think anything works better than what I have in mind let me 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5b1eb9e3-2b61-4006-b79f-e34d0c41fa88%40isocpp.org.

------=_Part_3718_1023804360.1502131360615
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div>From a standardization point of view, one of the really bi=
g questions is this: what is the <i>actual</i> signature of the function? D=
oes that lambda take two variables, with the unpacking done implicitly by t=
he caller during argument-to-parameter processing? Or does that function ta=
ke one parameter which gets unpacked before the first statement of the func=
tion body?=C2=A0</div></div></blockquote><div><br></div><div>The lambda sho=
uld take one variable, this would make it easy to pass polymorphic lambdas =
to algorithms/functions that pass more than one parameter to the lambda. =
=C2=A0And if the user had specified one of the arguments to be a structured=
 binding, they would be &quot;unwrapped&quot; only for that specific lambda=
.. =C2=A0For example, if there was a version of `std::for_each` that passed =
the element along with the index to the passed functor, then the following =
could be done (skipping the iterators for readability)</div><div><br></div>=
<div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 25=
0); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">for_each</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">map</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">key</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> value</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">],</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> index</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>});</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">for_each</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">[](</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> ele</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> index</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><font color=3D"#666600"><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">));</span></font></div></code></div></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>This matters a lot for exception handling. If `get` throws an exception, w=
e need to know who&#39;s responsible for catching it. In case #1, the only =
one who could catch it is the person doing the function call expression. In=
 case #2, I would assume a function-level try-block would be able to catch =
it.<br></div></div></blockquote><div><br></div><div>I feel like having the =
caller handle the exception would be the natural thing to do here.</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>This also matters for knowing what the function actually looks like. =
Can you stick an `[](auto [x, y])` into a `std::function&lt;void(int, int)&=
gt;`, or does it go into a `std::function&lt;void(tuple&lt;int, int&gt;)&gt=
;`? I suspect it&#39;s the latter, since you can&#39;t call the lambda with=
 two parameters.<br></div></div></blockquote><div><br></div><div>The latter=
, yeah, just like an <font face=3D"courier new, monospace">[](auto){}</font=
>=C2=A0<font face=3D"arial, sans-serif">lamdba with a </font><font face=3D"=
courier new, monospace">std::function&lt;void(tuple&lt;int, int&gt;)&gt;</f=
ont></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font=
 face=3D"arial, sans-serif">If you think anything works better than what I =
have in mind let me know!</font></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5b1eb9e3-2b61-4006-b79f-e34d0c41fa88%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5b1eb9e3-2b61-4006-b79f-e34d0c41fa88=
%40isocpp.org</a>.<br />

------=_Part_3718_1023804360.1502131360615--

------=_Part_3717_1882231634.1502131360615--

.


Author: Curious <rmn100@gmail.com>
Date: Mon, 7 Aug 2017 11:44:12 -0700 (PDT)
Raw View
------=_Part_3484_2013320781.1502131452175
Content-Type: multipart/alternative;
 boundary="----=_Part_3485_25870498.1502131452175"

------=_Part_3485_25870498.1502131452175
Content-Type: text/plain; charset="UTF-8"



> The thing is, lambdas benefit greatly from being terse. While terseness is
> nice for regular functions, it's *really* important for short, one-off
> lambdas. So it's reasonable to restrict a feature like this to just lambdas.
>

I agree!  This would work really nicely with some usecases of polymorphic
lambdas IMO

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0e885206-2d3e-4528-a815-46faaea07859%40isocpp.org.

------=_Part_3485_25870498.1502131452175
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>The thing is, lambdas benefit greatly from being terse. While=
 terseness is nice for regular functions, it&#39;s <i>really</i> important =
for short, one-off lambdas. So it&#39;s reasonable to restrict a feature li=
ke this to just lambdas.<br></div></div></blockquote><div><br></div><div>I =
agree! =C2=A0This would work really nicely with some usecases of polymorphi=
c lambdas IMO=C2=A0</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0e885206-2d3e-4528-a815-46faaea07859%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0e885206-2d3e-4528-a815-46faaea07859=
%40isocpp.org</a>.<br />

------=_Part_3485_25870498.1502131452175--

------=_Part_3484_2013320781.1502131452175--

.


Author: Tom Honermann <tom@honermann.net>
Date: Mon, 7 Aug 2017 15:34:33 -0400
Raw View
This is a multi-part message in MIME format.
--------------6F94F585A23D6B387866AE04
Content-Type: text/plain; charset="UTF-8"; format=flowed

On 08/07/2017 02:42 PM, rmn100@gmail.com wrote:
>
>     This also matters for knowing what the function actually looks
>     like. Can you stick an `[](auto [x, y])` into a
>     `std::function<void(int, int)>`, or does it go into a
>     `std::function<void(tuple<int, int>)>`? I suspect it's the latter,
>     since you can't call the lambda with two parameters.
>
>
> The latter, yeah, just like an [](auto){} lamdba with a
> std::function<void(tuple<int, int>)>
>
> If you think anything works better than what I have in mind let me know!

I would prefer that this be treated as syntactic sugar such that this:
   [](auto [x,y]){}

result in a closure type with a function call operator like this:
   struct closure_type {
     template<typename T>
     auto operator()(T unnamed_param) {
       auto& [x,y] = unnamed_param;
     }
   };

With Concepts, a decomposable constraint could conceivably be added:
   struct closure_type {
     template<typename T>
     requires is_decomposable<T,2>
     auto operator()(T unnamed_param) {
       auto& [x,y] = unnamed_param;
     }
   };

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/63fba5eb-fbdd-abc7-1e0d-1c2aac0e248f%40honermann.net.

--------------6F94F585A23D6B387866AE04
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 08/07/2017 02:42 PM,
      <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:rmn100@gmail.com=
">rmn100@gmail.com</a> wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:5b1eb9e3-2b61-4006-b79f-e34d0c41fa88@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">=C2=A0
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div dir=3D"ltr">
            <div>This also matters for knowing what the function
              actually looks like. Can you stick an `[](auto [x, y])`
              into a `std::function&lt;void(int, int)&gt;`, or does it
              go into a `std::function&lt;void(tuple&lt;int,
              int&gt;)&gt;`? I suspect it's the latter, since you can't
              call the lambda with two parameters.<br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>The latter, yeah, just like an <font face=3D"courier new,
            monospace">[](auto){}</font>=C2=A0<font face=3D"arial, sans-ser=
if">lamdba
            with a </font><font face=3D"courier new, monospace">std::functi=
on&lt;void(tuple&lt;int,
            int&gt;)&gt;</font></div>
        <div><font face=3D"arial, sans-serif"><br>
          </font></div>
        <div><font face=3D"arial, sans-serif">If you think anything works
            better than what I have in mind let me know!</font></div>
      </div>
    </blockquote>
    <br>
    I would prefer that this be treated as syntactic sugar such that
    this:<br>
    =C2=A0 [](auto [x,y]){}<br>
    <br>
    result in a closure type with a function call operator like this:<br>
    =C2=A0 struct closure_type {<br>
    =C2=A0=C2=A0=C2=A0 template&lt;typename T&gt;<br>
    =C2=A0=C2=A0=C2=A0 auto operator()(T unnamed_param) {<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto&amp; [x,y] =3D unnamed_param;<br>
    =C2=A0=C2=A0=C2=A0 }<br>
    =C2=A0 };<br>
    <br>
    With Concepts, a decomposable constraint could conceivably be added:<br=
>
    =C2=A0 struct closure_type {<br>
    =C2=A0=C2=A0=C2=A0 template&lt;typename T&gt;<br>
    =C2=A0=C2=A0=C2=A0 requires is_decomposable&lt;T,2&gt;<br>
    =C2=A0=C2=A0=C2=A0 auto operator()(T unnamed_param) {<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto&amp; [x,y] =3D unnamed_param;<br>
    =C2=A0=C2=A0=C2=A0 }<br>
    =C2=A0 };<br>
    <br>
    Tom.<br>
  </body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/63fba5eb-fbdd-abc7-1e0d-1c2aac0e248f%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/63fba5eb-fbdd-abc7-1e0d-1c2aac0e2=
48f%40honermann.net</a>.<br />

--------------6F94F585A23D6B387866AE04--

.


Author: Curious <rmn100@gmail.com>
Date: Mon, 7 Aug 2017 13:09:56 -0700 (PDT)
Raw View
------=_Part_3401_1609198742.1502136596759
Content-Type: multipart/alternative;
 boundary="----=_Part_3402_1573948862.1502136596759"

------=_Part_3402_1573948862.1502136596759
Content-Type: text/plain; charset="UTF-8"



> I would prefer that this be treated as syntactic sugar such that this:
>   [](auto [x,y]){}
>
> result in a closure type with a function call operator like this:
>   struct closure_type {
>     template<typename T>
>     auto operator()(T unnamed_param) {
>       auto& [x,y] = unnamed_param;
>     }
>   };
>

This works and seems intuitive to me.

With Concepts, a decomposable constraint could conceivably be added:
>   struct closure_type {
>     template<typename T>
>     requires is_decomposable<T,2>
>     auto operator()(T unnamed_param) {
>       auto& [x,y] = unnamed_param;
>     }
>   };
>

This would be great as well.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6b74ea6-51cf-48c1-843b-b5d66404ee3a%40isocpp.org.

------=_Part_3402_1573948862.1502136596759
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgco=
lor=3D"#FFFFFF" text=3D"#000000"><div>I would prefer that this be treated a=
s syntactic sugar such that
    this:<br></div>
    =C2=A0 [](auto [x,y]){}<br>
    <br>
    result in a closure type with a function call operator like this:<br>
    =C2=A0 struct closure_type {<br>
    =C2=A0=C2=A0=C2=A0 template&lt;typename T&gt;<br>
    =C2=A0=C2=A0=C2=A0 auto operator()(T unnamed_param) {<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto&amp; [x,y] =3D unnamed_param;<br>
    =C2=A0=C2=A0=C2=A0 }<br>
    =C2=A0 };<br></div></blockquote><div><br></div><div>This works and seem=
s intuitive to me.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
    With Concepts, a decomposable constraint could conceivably be added:<br=
>
    =C2=A0 struct closure_type {<br>
    =C2=A0=C2=A0=C2=A0 template&lt;typename T&gt;<br>
    =C2=A0=C2=A0=C2=A0 requires is_decomposable&lt;T,2&gt;<br>
    =C2=A0=C2=A0=C2=A0 auto operator()(T unnamed_param) {<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto&amp; [x,y] =3D unnamed_param;<br>
    =C2=A0=C2=A0=C2=A0 }<br>
    =C2=A0 };<br></div></blockquote><div><br></div><div>This would be great=
 as well. =C2=A0</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b6b74ea6-51cf-48c1-843b-b5d66404ee3a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b6b74ea6-51cf-48c1-843b-b5d66404ee3a=
%40isocpp.org</a>.<br />

------=_Part_3402_1573948862.1502136596759--

------=_Part_3401_1609198742.1502136596759--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 7 Aug 2017 13:25:27 -0700 (PDT)
Raw View
------=_Part_3827_1993053810.1502137527970
Content-Type: multipart/alternative;
 boundary="----=_Part_3828_1672541198.1502137527970"

------=_Part_3828_1672541198.1502137527970
Content-Type: text/plain; charset="UTF-8"

On Monday, August 7, 2017 at 3:34:36 PM UTC-4, Tom Honermann wrote:
>
> On 08/07/2017 02:42 PM, rmn...@gmail.com <javascript:> wrote:
>
>
>>
>> This also matters for knowing what the function actually looks like. Can
>> you stick an `[](auto [x, y])` into a `std::function<void(int, int)>`, or
>> does it go into a `std::function<void(tuple<int, int>)>`? I suspect it's
>> the latter, since you can't call the lambda with two parameters.
>>
>
> The latter, yeah, just like an [](auto){} lamdba with a std::function<void(tuple<int,
> int>)>
>
> If you think anything works better than what I have in mind let me know!
>
>
> I would prefer that this be treated as syntactic sugar such that this:
>

I did not mean `std::tuple` *specifically*; only that it would be a type
decomposable into 2 integers.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4dc30398-bfa1-4b90-b7c2-8cf6374ed711%40isocpp.org.

------=_Part_3828_1672541198.1502137527970
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, August 7, 2017 at 3:34:36 PM UTC-4, Tom Honerma=
nn wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>On 08/07/2017 02:42 PM,
      <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Ac=
eTW-BkBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#3=
9;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;"=
>rmn...@gmail.com</a> wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">=C2=A0
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div dir=3D"ltr">
            <div>This also matters for knowing what the function
              actually looks like. Can you stick an `[](auto [x, y])`
              into a `std::function&lt;void(int, int)&gt;`, or does it
              go into a `std::function&lt;void(tuple&lt;int,
              int&gt;)&gt;`? I suspect it&#39;s the latter, since you can&#=
39;t
              call the lambda with two parameters.<br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>The latter, yeah, just like an <font face=3D"courier new,
            monospace">[](auto){}</font>=C2=A0<font face=3D"arial, sans-ser=
if">lamdba
            with a </font><font face=3D"courier new, monospace">std::functi=
on&lt;void(tuple&lt;int,
            int&gt;)&gt;</font></div>
        <div><font face=3D"arial, sans-serif"><br>
          </font></div>
        <div><font face=3D"arial, sans-serif">If you think anything works
            better than what I have in mind let me know!</font></div>
      </div>
    </blockquote>
    <br>
    I would prefer that this be treated as syntactic sugar such that
    this:<br></div></blockquote><div><br>I did not mean `std::tuple` <i>spe=
cifically</i>; only that it would be a type decomposable into 2 integers.</=
div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4dc30398-bfa1-4b90-b7c2-8cf6374ed711%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4dc30398-bfa1-4b90-b7c2-8cf6374ed711=
%40isocpp.org</a>.<br />

------=_Part_3828_1672541198.1502137527970--

------=_Part_3827_1993053810.1502137527970--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 7 Aug 2017 13:30:05 -0700 (PDT)
Raw View
------=_Part_3476_112285090.1502137805546
Content-Type: multipart/alternative;
 boundary="----=_Part_3477_834682446.1502137805546"

------=_Part_3477_834682446.1502137805546
Content-Type: text/plain; charset="UTF-8"

On Monday, August 7, 2017 at 3:34:36 PM UTC-4, Tom Honermann wrote:
>
> With Concepts, a decomposable constraint could conceivably be added:
>   struct closure_type {
>     template<typename T>
>     requires is_decomposable<T,2>
>     auto operator()(T unnamed_param) {
>       auto& [x,y] = unnamed_param;
>     }
>   };
>

Since concepts is part of C++ now, that should be a given. And even if
concepts weren't standard, it should still have the usual "does not
participate in overload resolution unless it can decompose into X
parameters" statement.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/97de61aa-73c2-4f0a-97d6-3d0c5a7b50aa%40isocpp.org.

------=_Part_3477_834682446.1502137805546
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, August 7, 2017 at 3:34:36 PM UTC-4, Tom Honerma=
nn wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    With Concepts, a decomposable constraint could conceivably be added:<br=
>
    =C2=A0 struct closure_type {<br>
    =C2=A0=C2=A0=C2=A0 template&lt;typename T&gt;<br>
    =C2=A0=C2=A0=C2=A0 requires is_decomposable&lt;T,2&gt;<br>
    =C2=A0=C2=A0=C2=A0 auto operator()(T unnamed_param) {<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto&amp; [x,y] =3D unnamed_param;<br>
    =C2=A0=C2=A0=C2=A0 }<br>
    =C2=A0 };<br></div></blockquote><div><br>Since concepts is part of C++ =
now, that should be a given. And even if concepts weren&#39;t standard, it =
should still have the usual &quot;does not participate in overload resoluti=
on unless it can decompose into X parameters&quot; statement.<br></div></di=
v>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/97de61aa-73c2-4f0a-97d6-3d0c5a7b50aa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/97de61aa-73c2-4f0a-97d6-3d0c5a7b50aa=
%40isocpp.org</a>.<br />

------=_Part_3477_834682446.1502137805546--

------=_Part_3476_112285090.1502137805546--

.


Author: Tom Honermann <tom@honermann.net>
Date: Tue, 8 Aug 2017 11:36:45 -0400
Raw View
This is a multi-part message in MIME format.
--------------409213934D5EF48324B73957
Content-Type: text/plain; charset="UTF-8"; format=flowed

On 08/07/2017 04:30 PM, Nicol Bolas wrote:
> On Monday, August 7, 2017 at 3:34:36 PM UTC-4, Tom Honermann wrote:
>
>     With Concepts, a decomposable constraint could conceivably be added:
>       struct closure_type {
>         template<typename T>
>         requires is_decomposable<T,2>
>         auto operator()(T unnamed_param) {
>           auto& [x,y] = unnamed_param;
>         }
>       };
>
>
> Since concepts is part of C++ now, that should be a given. And even if
> concepts weren't standard, it should still have the usual "does not
> participate in overload resolution unless it can decompose into X
> parameters" statement.

Ideally, yes.  Unfortunately, as far as I am aware, it isn't currently
possible to write a concept that requires decomposition without the help
of compiler intrinsics [1].  I believe this is true for SFINAE as well.

Tom.

[1]:
https://groups.google.com/a/isocpp.org/forum/#!topic/concepts/mz53hNuzN-s

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e8d2ac55-122d-4e2c-98e3-b44a53adcd7e%40honermann.net.

--------------409213934D5EF48324B73957
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 08/07/2017 04:30 PM, Nicol Bolas
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:97de61aa-73c2-4f0a-97d6-3d0c5a7b50aa@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">On Monday, August 7, 2017 at 3:34:36 PM UTC-4, Tom
        Honermann wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000"> With Concepts, a
            decomposable constraint could conceivably be added:<br>
            =C2=A0 struct closure_type {<br>
            =C2=A0=C2=A0=C2=A0 template&lt;typename T&gt;<br>
            =C2=A0=C2=A0=C2=A0 requires is_decomposable&lt;T,2&gt;<br>
            =C2=A0=C2=A0=C2=A0 auto operator()(T unnamed_param) {<br>
            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto&amp; [x,y] =3D unnamed_para=
m;<br>
            =C2=A0=C2=A0=C2=A0 }<br>
            =C2=A0 };<br>
          </div>
        </blockquote>
        <div><br>
          Since concepts is part of C++ now, that should be a given. And
          even if concepts weren't standard, it should still have the
          usual "does not participate in overload resolution unless it
          can decompose into X parameters" statement.</div>
      </div>
    </blockquote>
    <br>
    Ideally, yes.=C2=A0 Unfortunately, as far as I am aware, it isn't
    currently possible to write a concept that requires decomposition
    without the help of compiler intrinsics [1].=C2=A0 I believe this is tr=
ue
    for SFINAE as well.<br>
    <br>
    Tom.<br>
    <br>
    [1]:
<a class=3D"moz-txt-link-freetext" href=3D"https://groups.google.com/a/isoc=
pp.org/forum/#!topic/concepts/mz53hNuzN-s">https://groups.google.com/a/isoc=
pp.org/forum/#!topic/concepts/mz53hNuzN-s</a><br>
  </body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e8d2ac55-122d-4e2c-98e3-b44a53adcd7e%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/e8d2ac55-122d-4e2c-98e3-b44a53adc=
d7e%40honermann.net</a>.<br />

--------------409213934D5EF48324B73957--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 8 Aug 2017 09:01:32 -0700 (PDT)
Raw View
------=_Part_4440_1716051819.1502208092254
Content-Type: multipart/alternative;
 boundary="----=_Part_4441_605214095.1502208092254"

------=_Part_4441_605214095.1502208092254
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 8, 2017 at 11:36:48 AM UTC-4, Tom Honermann wrote:
>
> On 08/07/2017 04:30 PM, Nicol Bolas wrote:
>
> On Monday, August 7, 2017 at 3:34:36 PM UTC-4, Tom Honermann wrote:
>>
>> With Concepts, a decomposable constraint could conceivably be added:
>>   struct closure_type {
>>     template<typename T>
>>     requires is_decomposable<T,2>
>>     auto operator()(T unnamed_param) {
>>       auto& [x,y] = unnamed_param;
>>     }
>>   };
>>
>
> Since concepts is part of C++ now, that should be a given. And even if
> concepts weren't standard, it should still have the usual "does not
> participate in overload resolution unless it can decompose into X
> parameters" statement.
>
>
> Ideally, yes.  Unfortunately, as far as I am aware, it isn't currently
> possible to write a concept that requires decomposition without the help of
> compiler intrinsics [1].  I believe this is true for SFINAE as well.
>

The compiler is the one generating this function. How the compiler does
that is irrelevant; it's OK for them to use magic.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0012d48e-7b98-4969-b6f6-036b5e03765b%40isocpp.org.

------=_Part_4441_605214095.1502208092254
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 8, 2017 at 11:36:48 AM UTC-4, Tom Honer=
mann wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>On 08/07/2017 04:30 PM, Nicol Bolas
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">On Monday, August 7, 2017 at 3:34:36 PM UTC-4, Tom
        Honermann wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000"> With Concepts, a
            decomposable constraint could conceivably be added:<br>
            =C2=A0 struct closure_type {<br>
            =C2=A0=C2=A0=C2=A0 template&lt;typename T&gt;<br>
            =C2=A0=C2=A0=C2=A0 requires is_decomposable&lt;T,2&gt;<br>
            =C2=A0=C2=A0=C2=A0 auto operator()(T unnamed_param) {<br>
            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto&amp; [x,y] =3D unnamed_para=
m;<br>
            =C2=A0=C2=A0=C2=A0 }<br>
            =C2=A0 };<br>
          </div>
        </blockquote>
        <div><br>
          Since concepts is part of C++ now, that should be a given. And
          even if concepts weren&#39;t standard, it should still have the
          usual &quot;does not participate in overload resolution unless it
          can decompose into X parameters&quot; statement.</div>
      </div>
    </blockquote>
    <br>
    Ideally, yes.=C2=A0 Unfortunately, as far as I am aware, it isn&#39;t
    currently possible to write a concept that requires decomposition
    without the help of compiler intrinsics [1].=C2=A0 I believe this is tr=
ue
    for SFINAE as well.<br></div></blockquote><div><br>The compiler is the =
one generating this function. How the compiler does that is irrelevant; it&=
#39;s OK for them to use magic.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0012d48e-7b98-4969-b6f6-036b5e03765b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0012d48e-7b98-4969-b6f6-036b5e03765b=
%40isocpp.org</a>.<br />

------=_Part_4441_605214095.1502208092254--

------=_Part_4440_1716051819.1502208092254--

.