------=_Part_1372_915436459.1494842406123
Content-Type: multipart/alternative;
 boundary="----=_Part_1373_1955337215.1494842406123"

------=_Part_1373_1955337215.1494842406123
Content-Type: text/plain; charset="UTF-8"

Structured Binding is a language feature that has a lot of potential,
although as of C++17 it's a pretty limited feature. (This is part of a
series of proposals generalizing structured binding). I propose allowing
structured binding outside of variable declaration:

int a = 0;
//Random code
std::string text ="";
//More code
[a,text] = tuple(3, "Hello, world");


--
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/e02d79e8-7d80-4614-bd25-e73fb43dad9d%40isocpp.org.

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

<div dir=3D"ltr">Structured Binding is a language feature that has a lot of=
 potential, although as of C++17 it&#39;s a pretty limited feature. (This i=
s part of a series of proposals generalizing structured binding). I propose=
 allowing structured binding outside of variable declaration:<div><br></div=
><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><font color=3D"#660066"><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> a </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">//Random code</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">string</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> text </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #080;" class=3D"st=
yled-by-prettify">&quot;&quot;</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">//More code</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">text</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">]</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> tuple</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #080;" class=3D"styled-by-prettify">&quot;Hello, world&quot=
;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
</font></div></code></div><br><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/e02d79e8-7d80-4614-bd25-e73fb43dad9d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e02d79e8-7d80-4614-bd25-e73fb43dad9d=
%40isocpp.org</a>.<br />

------=_Part_1373_1955337215.1494842406123--

------=_Part_1372_915436459.1494842406123--

.

On 15 May 2017 at 13:00, Antonio Perez <antonio@perezexcelsior.com> wrote:
> Structured Binding is a language feature that has a lot of potential,
> although as of C++17 it's a pretty limited feature. (This is part of a
> series of proposals generalizing structured binding). I propose allowing
> structured binding outside of variable declaration:
>
> int a = 0;
> //Random code
> std::string text ="";
> //More code
> [a,text] = tuple(3, "Hello, world");


Why? std::tie can already do that.

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

.

------=_Part_209_806736343.1494847703884
Content-Type: multipart/alternative;
 boundary="----=_Part_210_276019286.1494847703884"

------=_Part_210_276019286.1494847703884
Content-Type: text/plain; charset="UTF-8"

Structured Binding is much more general than std::tie. std::tie only works
with tuples, but structured binding works with any datatype that fits the
(very minimal) requirements for it. Try compiling the following code with
C++17
struct point
{
    double x,y;
};
void WithTie(){
    double a, b=2.1;
    std::tie(a,b) = point{3.2,1.9};//ERROR - cannot assign point to tuple
    cout << a << endl;
    cout << b << endl;
}
void WithBinding(){//Structured Binding as introduced by C++17
    auto [a,b] = point{3.2,1.9};//No Error
    cout << a << endl;
    cout << b << endl;
}



On Monday, May 15, 2017 at 4:12:27 AM UTC-6, Ville Voutilainen wrote:
>
> On 15 May 2017 at 13:00, Antonio Perez <ant...@perezexcelsior.com
> <javascript:>> wrote:
> > Structured Binding is a language feature that has a lot of potential,
> > although as of C++17 it's a pretty limited feature. (This is part of a
> > series of proposals generalizing structured binding). I propose allowing
> > structured binding outside of variable declaration:
> >
> > int a = 0;
> > //Random code
> > std::string text ="";
> > //More code
> > [a,text] = tuple(3, "Hello, world");
>
>
> Why? std::tie can already do that.
>

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

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

<div dir=3D"ltr">Structured Binding is much more general than std::tie. std=
::tie only works with tuples, but structured binding works with any datatyp=
e that fits the (very minimal) requirements for it. Try compiling the follo=
wing code with C++17<div><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><div class=3D"subprettyprint">struct point</d=
iv><div class=3D"subprettyprint">{</div><div class=3D"subprettyprint">=C2=
=A0 =C2=A0 double x,y;</div><div class=3D"subprettyprint">};</div><div clas=
s=3D"subprettyprint">void WithTie(){</div><div class=3D"subprettyprint">=C2=
=A0 =C2=A0 double a, b=3D2.1;</div><div class=3D"subprettyprint">=C2=A0 =C2=
=A0 std::tie(a,b) =3D point{3.2,1.9};//ERROR - cannot assign point to tuple=
</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 cout &lt;&lt; a &lt;&lt; =
endl;</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 cout &lt;&lt; b &lt;=
&lt; endl;</div><div class=3D"subprettyprint">}</div><div class=3D"subprett=
yprint">void WithBinding(){<span style=3D"font-family: Arial, Helvetica, sa=
ns-serif;">//Structured Binding as introduced by C++17</span></div><div cla=
ss=3D"subprettyprint">=C2=A0 =C2=A0 auto [a,b] =3D point{3.2,1.9};//No Erro=
r</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 cout &lt;&lt; a &lt;&lt;=
 endl;</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 cout &lt;&lt; b &lt=
;&lt; endl;</div><div class=3D"subprettyprint">}</div></div></code></div><b=
r><br><br>On Monday, May 15, 2017 at 4:12:27 AM UTC-6, Ville Voutilainen wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">On 15 May 2017 at 13:00, A=
ntonio Perez &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"VNykGkK9CQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;">ant...@perezexcelsior.com</a>&gt; wrote:
<br>&gt; Structured Binding is a language feature that has a lot of potenti=
al,
<br>&gt; although as of C++17 it&#39;s a pretty limited feature. (This is p=
art of a
<br>&gt; series of proposals generalizing structured binding). I propose al=
lowing
<br>&gt; structured binding outside of variable declaration:
<br>&gt;
<br>&gt; int a =3D 0;
<br>&gt; //Random code
<br>&gt; std::string text =3D&quot;&quot;;
<br>&gt; //More code
<br>&gt; [a,text] =3D tuple(3, &quot;Hello, world&quot;);
<br>
<br>
<br>Why? std::tie can already do that.
<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/70fcbbd4-8c3b-4fb4-9140-07fa2e6149eb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/70fcbbd4-8c3b-4fb4-9140-07fa2e6149eb=
%40isocpp.org</a>.<br />

------=_Part_210_276019286.1494847703884--

------=_Part_209_806736343.1494847703884--

.

------=_Part_1452_1525024644.1494860049992
Content-Type: multipart/alternative;
 boundary="----=_Part_1453_1096682095.1494860049992"

------=_Part_1453_1096682095.1494860049992
Content-Type: text/plain; charset="UTF-8"

On Monday, May 15, 2017 at 6:00:06 AM UTC-4, Antonio Perez wrote:
>
> Structured Binding is a language feature that has a lot of potential,
> although as of C++17 it's a pretty limited feature. (This is part of a
> series of proposals generalizing structured binding). I propose allowing
> structured binding outside of variable declaration:
>
> int a = 0;
> //Random code
> std::string text ="";
> //More code
> [a,text] = tuple(3, "Hello, world");
>
>
You still need the `auto` there. You may not be creating the variables `a`
and `text`, but you *are* creating a hidden variable to store the prvalue.
So it's still a variable declaration.

A more important question is this: exactly how does this work? Structured
binding's behavior is a bit different for structs/arrays than it is for
tuple-like types. If that were a struct, then `a` and `text` would not be
reference variables to those members. They would actually *be those members*;
the compiler would substitute the `a` and `text` identifiers for exactly
those members.

So how would that work if the variable already exists?

--
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/8361ebed-8ecb-44c6-9b36-6fbce460a952%40isocpp.org.

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

<div dir=3D"ltr">On Monday, May 15, 2017 at 6:00:06 AM UTC-4, Antonio Perez=
 wrote:<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">Struct=
ured Binding is a language feature that has a lot of potential, although as=
 of C++17 it&#39;s a pretty limited feature. (This is part of a series of p=
roposals generalizing structured binding). I propose allowing structured bi=
nding outside of variable declaration:<div><br></div><div><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px;word-wrap:break-word"><code><div><font color=3D"#6600=
66"><span style=3D"color:#008">int</span><span style=3D"color:#000"> a </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#066">0</span><span style=3D"color:#660">;</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#800">//Random code</=
span><span style=3D"color:#000"><br>std</span><span style=3D"color:#660">::=
</span><span style=3D"color:#008">string</span><span style=3D"color:#000"> =
text </span><span style=3D"color:#660">=3D</span><span style=3D"color:#080"=
>&quot;&quot;</span><span style=3D"color:#660">;</span><span style=3D"color=
:#000"><br></span><span style=3D"color:#800">//More code</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">[</span><span style=
=3D"color:#000">a</span><span style=3D"color:#660">,</span><span style=3D"c=
olor:#000">text</span><span style=3D"color:#660">]</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">=3D</span><span style=3D"color:=
#000"> tuple</span><span style=3D"color:#660">(</span><span style=3D"color:=
#066">3</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> </span><span style=3D"color:#080">&quot;Hello, world&quot;</span><span st=
yle=3D"color:#660">);</span></font></div></code></div><br></div></div></blo=
ckquote><div><br>You still need the `auto` there. You may not be creating t=
he variables `a` and `text`, but you <i>are</i> creating a hidden variable =
to store the prvalue. So it&#39;s still a variable declaration.<br><br>A mo=
re important question is this: exactly how does this work? Structured bindi=
ng&#39;s behavior is a bit different for structs/arrays than it is for tupl=
e-like types. If that were a struct, then `a` and `text` would not be refer=
ence variables to those members. They would actually <i>be those members</i=
>; the compiler would substitute the `a` and `text` identifiers for exactly=
 those members.<br><br>So how would that work if the variable already exist=
s?<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/8361ebed-8ecb-44c6-9b36-6fbce460a952%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8361ebed-8ecb-44c6-9b36-6fbce460a952=
%40isocpp.org</a>.<br />

------=_Part_1453_1096682095.1494860049992--

------=_Part_1452_1525024644.1494860049992--

.

This is a multi-part message in MIME format.
--------------52112026540B90EEE857DC56
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 15/05/2017 =C3=A0 13:28, Antonio Perez a =C3=A9crit :
> Structured Binding is much more general than std::tie. std::tie only=20
> works with tuples, but structured binding works with any datatype that=20
> fits the (very minimal) requirements for it. Try compiling the=20
> following code with C++17
> |
> struct point
> {
>     double x,y;
> };
> void WithTie(){
>     double a, b=3D2.1;
>     std::tie(a,b) =3D point{3.2,1.9};//ERROR - cannot assign point to tup=
le
>     cout << a << endl;
>     cout << b << endl;
> }
> void WithBinding(){//Structured Binding as introduced by C++17
>     auto [a,b] =3D point{3.2,1.9};//No Error
>     cout << a << endl;
>     cout << b << endl;
> }
> |
>
>
>
tie should end by working on any type that supports structured binding.=20
Thisis the goal of defining an library interface for those ProductType=20
types. See P0327R1.

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/656aaee5-a549-5b94-12b4-600bd8061225%40wanadoo.f=
r.

--------------52112026540B90EEE857DC56
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">Le 15/05/2017 =C3=A0 13:28, Antonio Pere=
z a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:70fcbbd4-8c3b-4fb4-9140-07fa2e6149eb@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">Structured Binding is much more general than
        std::tie. std::tie only works with tuples, but structured
        binding works with any datatype that fits the (very minimal)
        requirements for it. Try compiling the following code with C++17
        <div>
          <div class=3D"prettyprint" style=3D"background-color: rgb(250,
            250, 250); border-color: rgb(187, 187, 187); border-style:
            solid; border-width: 1px; word-wrap: break-word;"><code
              class=3D"prettyprint">
              <div class=3D"subprettyprint">
                <div class=3D"subprettyprint">struct point</div>
                <div class=3D"subprettyprint">{</div>
                <div class=3D"subprettyprint">=C2=A0 =C2=A0 double x,y;</di=
v>
                <div class=3D"subprettyprint">};</div>
                <div class=3D"subprettyprint">void WithTie(){</div>
                <div class=3D"subprettyprint">=C2=A0 =C2=A0 double a, b=3D2=
..1;</div>
                <div class=3D"subprettyprint">=C2=A0 =C2=A0 std::tie(a,b) =
=3D
                  point{3.2,1.9};//ERROR - cannot assign point to tuple</di=
v>
                <div class=3D"subprettyprint">=C2=A0 =C2=A0 cout &lt;&lt; a=
 &lt;&lt;
                  endl;</div>
                <div class=3D"subprettyprint">=C2=A0 =C2=A0 cout &lt;&lt; b=
 &lt;&lt;
                  endl;</div>
                <div class=3D"subprettyprint">}</div>
                <div class=3D"subprettyprint">void WithBinding(){<span
                    style=3D"font-family: Arial, Helvetica, sans-serif;">//=
Structured
                    Binding as introduced by C++17</span></div>
                <div class=3D"subprettyprint">=C2=A0 =C2=A0 auto [a,b] =3D
                  point{3.2,1.9};//No Error</div>
                <div class=3D"subprettyprint">=C2=A0 =C2=A0 cout &lt;&lt; a=
 &lt;&lt;
                  endl;</div>
                <div class=3D"subprettyprint">=C2=A0 =C2=A0 cout &lt;&lt; b=
 &lt;&lt;
                  endl;</div>
                <div class=3D"subprettyprint">}</div>
              </div>
            </code></div>
          <br>
          <br>
          <br>
        </div>
      </div>
    </blockquote>
    tie should end by working on any type that supports structured
    binding. Thisis the goal of defining an library interface for those
    ProductType types. See P0327R1.<br>
    <br>
    Vicente<br>
    <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/656aaee5-a549-5b94-12b4-600bd8061225%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/656aaee5-a549-5b94-12b4-600bd8061225=
%40wanadoo.fr</a>.<br />

--------------52112026540B90EEE857DC56--

.

------=_Part_1889_2045527424.1494911600334
Content-Type: multipart/alternative;
 boundary="----=_Part_1890_1457459762.1494911600334"

------=_Part_1890_1457459762.1494911600334
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Monday, May 15, 2017 at 3:00:06 AM UTC-7, Antonio Perez wrote:
>
> Structured Binding is a language feature that has a lot of potential,=20
> although as of C++17 it's a pretty limited feature. (This is part of a=20
> series of proposals generalizing structured binding). I propose allowing=
=20
> structured binding outside of variable declaration:
>
> int a =3D 0;
> //Random code
> std::string text =3D"";
> //More code
> [a,text] =3D tuple(3, "Hello, world");
>

No, that's just std::tie; we have that.
What we don't have in any sane form, but which IMO every parser-programmer=
=20
is waiting for, is

    std::pair<Key, const char *> parseKey(const char *);
    std::pair<Value, const char *> parseValue(const char *);

    std::pair<KVPair, const char *> parseKVPair(const char *in)
    {
        if (*in++ !=3D '(') throw Failure();
        Key k [,in] =3D parseKey(in);
        if (*in++ !=3D ',') throw Failure();
        Value v [,in] =3D parseValue(in);
        if (*in++ !=3D ')') throw Failure();
        return {KVPair(k, v), in};
    }

Now, this is terrible syntax, and it also doesn't really work if you were=
=20
to put the "const char *" *first* in the return type instead of *last*. So=
=20
I'm by no means proposing this *syntax*. I'm just using it to illustrate=20
the semantic *feature* that is completely missing from C++17, and whose=20
lack IMHO should have been enough to keep structured binding out of the=20
official standard until it had had some baking time.

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

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/10b21241-b683-44d5-82ce-90681b2643a4%40isocpp.or=
g.

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

<div dir=3D"ltr">On Monday, May 15, 2017 at 3:00:06 AM UTC-7, Antonio Perez=
 wrote:<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">Struct=
ured Binding is a language feature that has a lot of potential, although as=
 of C++17 it&#39;s a pretty limited feature. (This is part of a series of p=
roposals generalizing structured binding). I propose allowing structured bi=
nding outside of variable declaration:<div><br></div><div><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px;word-wrap:break-word"><code><div><font color=3D"#6600=
66"><span style=3D"color:#008">int</span><span style=3D"color:#000"> a </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#066">0</span><span style=3D"color:#660">;</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#800">//Random code</=
span><span style=3D"color:#000"><br>std</span><span style=3D"color:#660">::=
</span><span style=3D"color:#008">string</span><span style=3D"color:#000"> =
text </span><span style=3D"color:#660">=3D</span><span style=3D"color:#080"=
>&quot;&quot;</span><span style=3D"color:#660">;</span><span style=3D"color=
:#000"><br></span><span style=3D"color:#800">//More code</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">[</span><span style=
=3D"color:#000">a</span><span style=3D"color:#660">,</span><span style=3D"c=
olor:#000">text</span><span style=3D"color:#660">]</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">=3D</span><span style=3D"color:=
#000"> tuple</span><span style=3D"color:#660">(</span><span style=3D"color:=
#066">3</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> </span><span style=3D"color:#080">&quot;Hello, world&quot;</span><span st=
yle=3D"color:#660">);</span></font></div></code></div></div></div></blockqu=
ote><div><br></div><div>No, that&#39;s just std::tie; we have that.</div><d=
iv>What we don&#39;t have in any sane form, but which IMO every parser-prog=
rammer is waiting for, is</div><div><br></div><div><div><font face=3D"couri=
er new, monospace">=C2=A0 =C2=A0 std::pair&lt;Key, const char *&gt; parseKe=
y(const char *);</font></div></div><div><div><font face=3D"courier new, mon=
ospace">=C2=A0 =C2=A0 std::pair&lt;Value, const char *&gt; parseValue(const=
 char *);</font></div></div><div><font face=3D"courier new, monospace"><br>=
</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 std::=
pair&lt;KVPair, const char *&gt; parseKVPair(const char *in)</font></div><d=
iv><font face=3D"courier new, monospace">=C2=A0 =C2=A0 {</font></div><div><=
font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (*in++ =
!=3D &#39;(&#39;) throw Failure();</font></div><div><font face=3D"courier n=
ew, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 Key k [,in] =3D parseKey(in);<br=
></font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 if (*in++ !=3D &#39;,&#39;) throw Failure();</font></div><div><f=
ont face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 Value v [,i=
n] =3D parseValue(in);<br></font></div><div><font face=3D"courier new, mono=
space">=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (*in++ !=3D &#39;)&#39;) throw Failur=
e();</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 return {KVPair(k, v), in};</font></div><div><font face=3D"cou=
rier new, monospace">=C2=A0 =C2=A0 }</font></div><div><font face=3D"arial, =
sans-serif"><br></font></div><div><font face=3D"arial, sans-serif">Now, thi=
s is terrible syntax, and it also doesn&#39;t really work if you were to pu=
t the &quot;const char *&quot; <i>first</i> in the return type instead of <=
i>last</i>. So I&#39;m by no means proposing this <i>syntax</i>. I&#39;m ju=
st using it to illustrate the semantic <i>feature</i> that is completely mi=
ssing from C++17, and whose lack IMHO should have been enough to keep struc=
tured binding out of the official standard until it had had some baking tim=
e.</font></div><div><font face=3D"arial, sans-serif"><br></font></div><div>=
<font face=3D"arial, sans-serif">my $.02,</font></div><div><font face=3D"ar=
ial, sans-serif">=E2=80=93Arthur</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/10b21241-b683-44d5-82ce-90681b2643a4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/10b21241-b683-44d5-82ce-90681b2643a4=
%40isocpp.org</a>.<br />

------=_Part_1890_1457459762.1494911600334--

------=_Part_1889_2045527424.1494911600334--

.

On 16 May 2017 at 08:13, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
>> [a,text] = tuple(3, "Hello, world");
>
>
> No, that's just std::tie; we have that.
> What we don't have in any sane form, but which IMO every parser-programmer
> is waiting for, is
>
>     std::pair<Key, const char *> parseKey(const char *);
>     std::pair<Value, const char *> parseValue(const char *);
>
>     std::pair<KVPair, const char *> parseKVPair(const char *in)
>     {
>         if (*in++ != '(') throw Failure();
>         Key k [,in] = parseKey(in);
>         if (*in++ != ',') throw Failure();
>         Value v [,in] = parseValue(in);
>         if (*in++ != ')') throw Failure();
>         return {KVPair(k, v), in};
>     }
>
> Now, this is terrible syntax, and it also doesn't really work if you were to
> put the "const char *" first in the return type instead of last. So I'm by
> no means proposing this syntax. I'm just using it to illustrate the semantic

So your point is that std::tie does "assignment bindings", structured
bindings do
"initializing bindings", but neither of them can do a mixture of both.

> feature that is completely missing from C++17, and whose lack IMHO should
> have been enough to keep structured binding out of the official standard
> until it had had some baking time.


Perhaps you should've told the committee before C++17 was finalized.

--
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/CAFk2RUbf5skMEcsLd_hUiZrib2bGCvyrJbgsx9LV-rXaj%3DfBZw%40mail.gmail.com.

.

On 16 May 2017 at 08:37, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 16 May 2017 at 08:13, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
>>> [a,text] = tuple(3, "Hello, world");
>>
>>
>> No, that's just std::tie; we have that.
>> What we don't have in any sane form, but which IMO every parser-programmer
>> is waiting for, is
>>
>>     std::pair<Key, const char *> parseKey(const char *);
>>     std::pair<Value, const char *> parseValue(const char *);
>>
>>     std::pair<KVPair, const char *> parseKVPair(const char *in)
>>     {
>>         if (*in++ != '(') throw Failure();
>>         Key k [,in] = parseKey(in);
>>         if (*in++ != ',') throw Failure();
>>         Value v [,in] = parseValue(in);
>>         if (*in++ != ')') throw Failure();
>>         return {KVPair(k, v), in};
>>     }
>>
>> Now, this is terrible syntax, and it also doesn't really work if you were to
>> put the "const char *" first in the return type instead of last. So I'm by
>> no means proposing this syntax. I'm just using it to illustrate the semantic
>
> So your point is that std::tie does "assignment bindings", structured
> bindings do
> "initializing bindings", but neither of them can do a mixture of both.


On that note, I can cobble together something like

     std::pair<Key, const char *> parseKey(const char *);
     std::pair<Value, const char *> parseValue(const char *);

     std::pair<KVPair, const char *> parseKVPair(const char *in)
     {
         if (*in++ != '(') throw Failure();
         auto [Key k, =in] = parseKey(in);
         if (*in++ != ',') throw Failure();
         auto [Value v, =in] = parseValue(in);
         if (*in++ != ')') throw Failure();
         return {KVPair(k, v), in};
     }

So two things there, allow specifying the type of a binding (my
favorite thing that structured bindings
don't let me do) and allow the binding to assign instead of initializing.

--
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/CAFk2RUbgg7UMc_mFGKQZF7-PVVbEDsdoZoXL46oyxr%2BPLRTfvw%40mail.gmail.com.

.

On 05/16/2017 01:52 AM, Ville Voutilainen wrote:
> On 16 May 2017 at 08:37, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>> On 16 May 2017 at 08:13, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
>>>> [a,text] = tuple(3, "Hello, world");
>>>
>>> No, that's just std::tie; we have that.
>>> What we don't have in any sane form, but which IMO every parser-programmer
>>> is waiting for, is
>>>
>>>      std::pair<Key, const char *> parseKey(const char *);
>>>      std::pair<Value, const char *> parseValue(const char *);
>>>
>>>      std::pair<KVPair, const char *> parseKVPair(const char *in)
>>>      {
>>>          if (*in++ != '(') throw Failure();
>>>          Key k [,in] = parseKey(in);
>>>          if (*in++ != ',') throw Failure();
>>>          Value v [,in] = parseValue(in);
>>>          if (*in++ != ')') throw Failure();
>>>          return {KVPair(k, v), in};
>>>      }
>>>
>>> Now, this is terrible syntax, and it also doesn't really work if you were to
>>> put the "const char *" first in the return type instead of last. So I'm by
>>> no means proposing this syntax. I'm just using it to illustrate the semantic
>> So your point is that std::tie does "assignment bindings", structured
>> bindings do
>> "initializing bindings", but neither of them can do a mixture of both.
>
> On that note, I can cobble together something like
>
>       std::pair<Key, const char *> parseKey(const char *);
>       std::pair<Value, const char *> parseValue(const char *);
>
>       std::pair<KVPair, const char *> parseKVPair(const char *in)
>       {
>           if (*in++ != '(') throw Failure();
>           auto [Key k, =in] = parseKey(in);
>           if (*in++ != ',') throw Failure();
>           auto [Value v, =in] = parseValue(in);
>           if (*in++ != ')') throw Failure();
>           return {KVPair(k, v), in};
>       }
>
> So two things there, allow specifying the type of a binding (my
> favorite thing that structured bindings
> don't let me do) and allow the binding to assign instead of initializing.
>
I like this, but still prefer the following syntax discussed in Issaquah
to specify a type constraint rather than something that looks like a
variable declaration with non-obvious conversion semantics:

      std::pair<Key, const char *> parseKey(const char *);
      std::pair<Value, const char *> parseValue(const char *);

      std::pair<KVPair, const char *> parseKVPair(const char *in)
      {
          if (*in++ != '(') throw Failure();
          auto [k -> Key, =in] = parseKey(in);
          if (*in++ != ',') throw Failure();
          auto [v -> Value, =in] = parseValue(in);
          if (*in++ != ')') throw Failure();
          return {KVPair(k, v), in};
      }

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/08ff73f1-6989-393e-ee4e-8158af2e7bed%40honermann.net.

.

On 16 May 2017 at 17:29, Tom Honermann <tom@honermann.net> wrote:
>> On that note, I can cobble together something like
>>
>>       std::pair<Key, const char *> parseKey(const char *);
>>       std::pair<Value, const char *> parseValue(const char *);
>>
>>       std::pair<KVPair, const char *> parseKVPair(const char *in)
>>       {
>>           if (*in++ != '(') throw Failure();
>>           auto [Key k, =in] = parseKey(in);
>>           if (*in++ != ',') throw Failure();
>>           auto [Value v, =in] = parseValue(in);
>>           if (*in++ != ')') throw Failure();
>>           return {KVPair(k, v), in};
>>       }
>>
>> So two things there, allow specifying the type of a binding (my
>> favorite thing that structured bindings
>> don't let me do) and allow the binding to assign instead of initializing.
>>
> I like this, but still prefer the following syntax discussed in Issaquah to
> specify a type constraint rather than something that looks like a variable
> declaration with non-obvious conversion semantics:
>
>      std::pair<Key, const char *> parseKey(const char *);
>      std::pair<Value, const char *> parseValue(const char *);
>
>      std::pair<KVPair, const char *> parseKVPair(const char *in)
>      {
>          if (*in++ != '(') throw Failure();
>          auto [k -> Key, =in] = parseKey(in);
>          if (*in++ != ',') throw Failure();
>          auto [v -> Value, =in] = parseValue(in);
>          if (*in++ != ')') throw Failure();
>          return {KVPair(k, v), in};
>      }


Well, with the idea I cobbled together, I can write

auto [x, =k->Key] = parseKey();

and it means something completely different, because -> is a member
access operator. So we can safely
assume that k is an entity that supports operator->, and my binding
there assigns to k->Key. It's such fun
to try to extend a language where all good syntaxes have been taken a
long time ago. :)

--
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/CAFk2RUaBhq7KVukgRMvqBMuBiBwZmCf%2BxZpD9jRtBberFoU2Rg%40mail.gmail.com.

.

On 05/16/2017 10:37 AM, Ville Voutilainen wrote:
> On 16 May 2017 at 17:29, Tom Honermann <tom@honermann.net> wrote:
>>> On that note, I can cobble together something like
>>>
>>>        std::pair<Key, const char *> parseKey(const char *);
>>>        std::pair<Value, const char *> parseValue(const char *);
>>>
>>>        std::pair<KVPair, const char *> parseKVPair(const char *in)
>>>        {
>>>            if (*in++ != '(') throw Failure();
>>>            auto [Key k, =in] = parseKey(in);
>>>            if (*in++ != ',') throw Failure();
>>>            auto [Value v, =in] = parseValue(in);
>>>            if (*in++ != ')') throw Failure();
>>>            return {KVPair(k, v), in};
>>>        }
>>>
>>> So two things there, allow specifying the type of a binding (my
>>> favorite thing that structured bindings
>>> don't let me do) and allow the binding to assign instead of initializing.
>>>
>> I like this, but still prefer the following syntax discussed in Issaquah to
>> specify a type constraint rather than something that looks like a variable
>> declaration with non-obvious conversion semantics:
>>
>>       std::pair<Key, const char *> parseKey(const char *);
>>       std::pair<Value, const char *> parseValue(const char *);
>>
>>       std::pair<KVPair, const char *> parseKVPair(const char *in)
>>       {
>>           if (*in++ != '(') throw Failure();
>>           auto [k -> Key, =in] = parseKey(in);
>>           if (*in++ != ',') throw Failure();
>>           auto [v -> Value, =in] = parseValue(in);
>>           if (*in++ != ')') throw Failure();
>>           return {KVPair(k, v), in};
>>       }
>
> Well, with the idea I cobbled together, I can write
>
> auto [x, =k->Key] = parseKey();
>
> and it means something completely different, because -> is a member
> access operator. So we can safely
> assume that k is an entity that supports operator->, and my binding
> there assigns to k->Key. It's such fun
> to try to extend a language where all good syntaxes have been taken a
> long time ago. :)
>
Oh, well, the solution to that is, of course, keyword spackling.

auto [x, =k-> typename Key] = parseKey();

:)

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/c70b0cd6-fa3e-d215-3fef-06eb231ed3cd%40honermann.net.

.

On 16 May 2017 at 18:25, Tom Honermann <tom@honermann.net> wrote:
>>>           auto [k -> Key, =in] = parseKey(in);
>>>           if (*in++ != ',') throw Failure();
>>>           auto [v -> Value, =in] = parseValue(in);
>>>           if (*in++ != ')') throw Failure();
>>>           return {KVPair(k, v), in};
>>>       }
>>
>>
>> Well, with the idea I cobbled together, I can write
>>
>> auto [x, =k->Key] = parseKey();
>>
>> and it means something completely different, because -> is a member
>> access operator. So we can safely
>> assume that k is an entity that supports operator->, and my binding
>> there assigns to k->Key. It's such fun
>> to try to extend a language where all good syntaxes have been taken a
>> long time ago. :)
>>
> Oh, well, the solution to that is, of course, keyword spackling.
>
> auto [x, =k-> typename Key] = parseKey();
>
> :)


What makes you think Key is a typename? :P

--
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/CAFk2RUbiUZ4n_mXdBUTGEZSsh5C%3DMf0hKbKu76PKzCCWnZfrgA%40mail.gmail.com.

.

On 05/16/2017 11:30 AM, Ville Voutilainen wrote:
> On 16 May 2017 at 18:25, Tom Honermann <tom@honermann.net> wrote:
>>>>            auto [k -> Key, =in] = parseKey(in);
>>>>            if (*in++ != ',') throw Failure();
>>>>            auto [v -> Value, =in] = parseValue(in);
>>>>            if (*in++ != ')') throw Failure();
>>>>            return {KVPair(k, v), in};
>>>>        }
>>>
>>> Well, with the idea I cobbled together, I can write
>>>
>>> auto [x, =k->Key] = parseKey();
>>>
>>> and it means something completely different, because -> is a member
>>> access operator. So we can safely
>>> assume that k is an entity that supports operator->, and my binding
>>> there assigns to k->Key. It's such fun
>>> to try to extend a language where all good syntaxes have been taken a
>>> long time ago. :)
>>>
>> Oh, well, the solution to that is, of course, keyword spackling.
>>
>> auto [x, =k-> typename Key] = parseKey();
>>
>> :)
>
> What makes you think Key is a typename? :P
>
Because when I wrote that, I was intending to write a type constraint
and not a member access.  You can tell because I put 'typename' there :P

Also because 'Key' starts with an uppercase letter but isn't all upper
case letters.  As we all know, that means it unambiguously designates a
type.

Actually, a type constraint doesn't makes much sense for an assignment
binding, and a member access doesn't make much sense for a structured
binding, so perhaps there is no ambiguity after all.

auto [x -> SomeType, =k->Key] = parseKey();  // Constrains 'x' to 'SomeType', assigns 'k->Key'

Yes, there is a certain amount of ick factor there.

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/d184a83a-4f99-a8d2-6bba-1b8aeedd797c%40honermann.net.

.

On Tue, May 16, 2017 at 12:36:52PM -0400, Tom Honermann wrote:
> On 05/16/2017 11:30 AM, Ville Voutilainen wrote:
> >On 16 May 2017 at 18:25, Tom Honermann <tom@honermann.net> wrote:
> >>>>           auto [k -> Key, =in] = parseKey(in);
> >>>>           if (*in++ != ',') throw Failure();
> >>>>           auto [v -> Value, =in] = parseValue(in);
> >>>>           if (*in++ != ')') throw Failure();
> >>>>           return {KVPair(k, v), in};
> >>>>       }
> >>>
> >>>Well, with the idea I cobbled together, I can write
> >>>
> >>>auto [x, =k->Key] = parseKey();
> >>>
> >>>and it means something completely different, because -> is a member
> >>>access operator. So we can safely
> >>>assume that k is an entity that supports operator->, and my binding
> >>>there assigns to k->Key. It's such fun
> >>>to try to extend a language where all good syntaxes have been taken a
> >>>long time ago. :)
> >>>
> >>Oh, well, the solution to that is, of course, keyword spackling.
> >>
> >>auto [x, =k-> typename Key] = parseKey();
> >>
> >>:)
> >
> >What makes you think Key is a typename? :P
> >
> Because when I wrote that, I was intending to write a type constraint and
> not a member access.  You can tell because I put 'typename' there :P
>
> Also because 'Key' starts with an uppercase letter but isn't all upper case
> letters.  As we all know, that means it unambiguously designates a type.
>
> Actually, a type constraint doesn't makes much sense for an assignment
> binding, and a member access doesn't make much sense for a structured
> binding, so perhaps there is no ambiguity after all.
>
> auto [x -> SomeType, =k->Key] = parseKey();  // Constrains 'x' to 'SomeType', assigns 'k->Key'
>
> Yes, there is a certain amount of ick factor there.

But why invent a new way to declare/constrain types that is almost unheard
about?

What is wrong with the good old way?

auto [SomeType x, =k->Key] = parseKey();

/MF

--
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/20170516164245.GA16348%40fukushima.lysator.liu.se.

.

On 05/16/2017 12:42 PM, Magnus Fromreide wrote:
> On Tue, May 16, 2017 at 12:36:52PM -0400, Tom Honermann wrote:
>> On 05/16/2017 11:30 AM, Ville Voutilainen wrote:
>>> On 16 May 2017 at 18:25, Tom Honermann <tom@honermann.net> wrote:
>>>>>>            auto [k -> Key, =in] = parseKey(in);
>>>>>>            if (*in++ != ',') throw Failure();
>>>>>>            auto [v -> Value, =in] = parseValue(in);
>>>>>>            if (*in++ != ')') throw Failure();
>>>>>>            return {KVPair(k, v), in};
>>>>>>        }
>>>>> Well, with the idea I cobbled together, I can write
>>>>>
>>>>> auto [x, =k->Key] = parseKey();
>>>>>
>>>>> and it means something completely different, because -> is a member
>>>>> access operator. So we can safely
>>>>> assume that k is an entity that supports operator->, and my binding
>>>>> there assigns to k->Key. It's such fun
>>>>> to try to extend a language where all good syntaxes have been taken a
>>>>> long time ago. :)
>>>>>
>>>> Oh, well, the solution to that is, of course, keyword spackling.
>>>>
>>>> auto [x, =k-> typename Key] = parseKey();
>>>>
>>>> :)
>>> What makes you think Key is a typename? :P
>>>
>> Because when I wrote that, I was intending to write a type constraint and
>> not a member access.  You can tell because I put 'typename' there :P
>>
>> Also because 'Key' starts with an uppercase letter but isn't all upper case
>> letters.  As we all know, that means it unambiguously designates a type.
>>
>> Actually, a type constraint doesn't makes much sense for an assignment
>> binding, and a member access doesn't make much sense for a structured
>> binding, so perhaps there is no ambiguity after all.
>>
>> auto [x -> SomeType, =k->Key] = parseKey();  // Constrains 'x' to 'SomeType', assigns 'k->Key'
>>
>> Yes, there is a certain amount of ick factor there.
> But why invent a new way to declare/constrain types that is almost unheard
> about?
This actually isn't a new way; it comes from the Concepts TS.
>
> What is wrong with the good old way?
>
> auto [SomeType x, =k->Key] = parseKey();

There is the question of what happens if the decomposed type of the
matching element is not reference compatible with type 'SomeType'.
Ill-formed?  Does 'x' change from being a structured binding to a
variable of the declared type?  If so, are conversions performed? What
type is decltype(x) and does it depend on the type of the matching
element?  A syntax that indicates a type constraint (which is, I think,
what is desired regardless of the syntax used) rather than a variable
declaration avoids these questions.

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/ffcb4ca3-5fb8-41b4-8b38-cfd287148cd5%40honermann.net.

.

On 16 May 2017 at 20:01, Tom Honermann <tom@honermann.net> wrote:
>> What is wrong with the good old way?
>>
>> auto [SomeType x, =k->Key] = parseKey();
>
>
> There is the question of what happens if the decomposed type of the matching
> element is not reference compatible with type 'SomeType'. Ill-formed?  Does
> 'x' change from being a structured binding to a variable of the declared
> type?  If so, are conversions performed? What type is decltype(x) and does

Why on earth would it change from being a structured binding to something else?

> it depend on the type of the matching element?  A syntax that indicates a
> type constraint (which is, I think, what is desired regardless of the syntax
> used) rather than a variable declaration avoids these questions.


Funny, such "type constraints" were something I always considered to
be an integral and fundamental
part of variable declarations. I don't write

auto x = foo(); static_assert(is_same_v<decltype(x), int>);

but for some reason it's been suggested that I should do that for
structured bindings, conveniently forgetting
that then I will need to put that "type constraint" far far away from
my structured bindings, like into a for-loop body
when the structured binding is in the loop header.

--
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/CAFk2RUY1AYOen-Rb8n6yzc1jsOiydbUCUDqLdKMPyiyiHnnO4w%40mail.gmail.com.

.

------=_Part_2302_976405073.1494957222690
Content-Type: multipart/alternative;
 boundary="----=_Part_2303_2138458239.1494957222691"

------=_Part_2303_2138458239.1494957222691
Content-Type: text/plain; charset="UTF-8"

On Tuesday, May 16, 2017 at 12:42:50 PM UTC-4, Magnus Fromreide wrote:
>
> On Tue, May 16, 2017 at 12:36:52PM -0400, Tom Honermann wrote:
> > On 05/16/2017 11:30 AM, Ville Voutilainen wrote:
> > >On 16 May 2017 at 18:25, Tom Honermann <t...@honermann.net
> <javascript:>> wrote:
> > >>>>           auto [k -> Key, =in] = parseKey(in);
> > >>>>           if (*in++ != ',') throw Failure();
> > >>>>           auto [v -> Value, =in] = parseValue(in);
> > >>>>           if (*in++ != ')') throw Failure();
> > >>>>           return {KVPair(k, v), in};
> > >>>>       }
> > >>>
> > >>>Well, with the idea I cobbled together, I can write
> > >>>
> > >>>auto [x, =k->Key] = parseKey();
> > >>>
> > >>>and it means something completely different, because -> is a member
> > >>>access operator. So we can safely
> > >>>assume that k is an entity that supports operator->, and my binding
> > >>>there assigns to k->Key. It's such fun
> > >>>to try to extend a language where all good syntaxes have been taken a
> > >>>long time ago. :)
> > >>>
> > >>Oh, well, the solution to that is, of course, keyword spackling.
> > >>
> > >>auto [x, =k-> typename Key] = parseKey();
> > >>
> > >>:)
> > >
> > >What makes you think Key is a typename? :P
> > >
> > Because when I wrote that, I was intending to write a type constraint
> and
> > not a member access.  You can tell because I put 'typename' there :P
> >
> > Also because 'Key' starts with an uppercase letter but isn't all upper
> case
> > letters.  As we all know, that means it unambiguously designates a type.
> >
> > Actually, a type constraint doesn't makes much sense for an assignment
> > binding, and a member access doesn't make much sense for a structured
> > binding, so perhaps there is no ambiguity after all.
> >
> > auto [x -> SomeType, =k->Key] = parseKey();  // Constrains 'x' to
> 'SomeType', assigns 'k->Key'
> >
> > Yes, there is a certain amount of ick factor there.
>
> But why invent a new way to declare/constrain types that is almost unheard
> about?
>
> What is wrong with the good old way?
>
> auto [SomeType x, =k->Key] = parseKey();
>

Allow me to attempt to explain what I think Tom Honermann is trying to say.

If you do:

SomeType z = expr;

`z` shall be a variable of type `SomeType`. It will not be a reference; it
will be an object, initialized by `expr`. If `expr` is not implicitly
convertible to `SomeType`, then you get a compile error. If `expr` is an
lvalue, then you get a copy; if it is an xvalue, you get a move; if it is a
prvalue, you just initialize `z` in-situ.

If you do:

auto [x, y] = expr;

Assuming that the first member of `expr` is of type `SomeType` (an object
or reference), then `x` will effectively be a reference to that `SomeType`
subobject. Note that `x` won't necessarily be an *actual reference*, but it
will act like one. Most important of all, `x` will not provoke a copy or
move (outside of what is needed to initialize the hidden variable).

So, what does this mean:

auto [SomeType x, y] = expr;

`SomeType x` looks like a variable declaration. It looks like `x` ought to
be an object, one that is separate from the product type created by `expr`.
That is, this *looks like* it ought to be equivalent to:

auto __hidden__ = expr;
SomeType x = get<0>(__hidden__);  //Copies the value
auto &y = get<1>(__hidden__);  //Gets a reference

However, I believe that Tom is arguing that this is not how it *should*
behave. That it ought to behave exactly like the `auto [x, y]` case, except
with a compilation error if the type isn't `SomeType`. But since `SomeType
x` looks like a variable declaration, people will expect it to act like one.

By contrast, `x -> SomeType` is new syntax. This new syntax would
explicitly mean "just check to see if its the right type; don't create an
object."

I can agree with this logic in some sense. I agree that we do need a way to
say "create a structured binding member, but also fail to compile if it is
not of this type". At the same time, I'm fine with spelling that `SomeType
&x` (or && as appropriate).

--
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/6bee864f-4ff6-4e1d-9425-1ffd0ade99b1%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, May 16, 2017 at 12:42:50 PM UTC-4, Magnus From=
reide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, May 16, 20=
17 at 12:36:52PM -0400, Tom Honermann wrote:
<br>&gt; On 05/16/2017 11:30 AM, Ville Voutilainen wrote:
<br>&gt; &gt;On 16 May 2017 at 18:25, Tom Honermann &lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"9z8cUCQhCgAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">t...@honermann.net</a>&=
gt; wrote:
<br>&gt; &gt;&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto [k -&gt; =
Key, =3Din] =3D parseKey(in);
<br>&gt; &gt;&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (*in++ !=3D=
 &#39;,&#39;) throw Failure();
<br>&gt; &gt;&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto [v -&gt; =
Value, =3Din] =3D parseValue(in);
<br>&gt; &gt;&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (*in++ !=3D=
 &#39;)&#39;) throw Failure();
<br>&gt; &gt;&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return {KVPair=
(k, v), in};
<br>&gt; &gt;&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 }
<br>&gt; &gt;&gt;&gt;
<br>&gt; &gt;&gt;&gt;Well, with the idea I cobbled together, I can write
<br>&gt; &gt;&gt;&gt;
<br>&gt; &gt;&gt;&gt;auto [x, =3Dk-&gt;Key] =3D parseKey();
<br>&gt; &gt;&gt;&gt;
<br>&gt; &gt;&gt;&gt;and it means something completely different, because -=
&gt; is a member
<br>&gt; &gt;&gt;&gt;access operator. So we can safely
<br>&gt; &gt;&gt;&gt;assume that k is an entity that supports operator-&gt;=
, and my binding
<br>&gt; &gt;&gt;&gt;there assigns to k-&gt;Key. It&#39;s such fun
<br>&gt; &gt;&gt;&gt;to try to extend a language where all good syntaxes ha=
ve been taken a
<br>&gt; &gt;&gt;&gt;long time ago. :)
<br>&gt; &gt;&gt;&gt;
<br>&gt; &gt;&gt;Oh, well, the solution to that is, of course, keyword spac=
kling.
<br>&gt; &gt;&gt;
<br>&gt; &gt;&gt;auto [x, =3Dk-&gt; typename Key] =3D parseKey();
<br>&gt; &gt;&gt;
<br>&gt; &gt;&gt;:)
<br>&gt; &gt;
<br>&gt; &gt;What makes you think Key is a typename? :P
<br>&gt; &gt;
<br>&gt; Because when I wrote that, I was intending to write a type constra=
int and
<br>&gt; not a member access. =C2=A0You can tell because I put &#39;typenam=
e&#39; there :P
<br>&gt;=20
<br>&gt; Also because &#39;Key&#39; starts with an uppercase letter but isn=
&#39;t all upper case
<br>&gt; letters. =C2=A0As we all know, that means it unambiguously designa=
tes a type.
<br>&gt;=20
<br>&gt; Actually, a type constraint doesn&#39;t makes much sense for an as=
signment
<br>&gt; binding, and a member access doesn&#39;t make much sense for a str=
uctured
<br>&gt; binding, so perhaps there is no ambiguity after all.
<br>&gt;=20
<br>&gt; auto [x -&gt; SomeType, =3Dk-&gt;Key] =3D parseKey(); =C2=A0// Con=
strains &#39;x&#39; to &#39;SomeType&#39;, assigns &#39;k-&gt;Key&#39;
<br>&gt;=20
<br>&gt; Yes, there is a certain amount of ick factor there.
<br>
<br>But why invent a new way to declare/constrain types that is almost unhe=
ard
<br>about?
<br>
<br>What is wrong with the good old way?
<br>
<br>auto [SomeType x, =3Dk-&gt;Key] =3D parseKey();
<br></blockquote><div><br>Allow me to attempt to explain what I think Tom H=
onermann is trying to say.<br><br>If you do:<br><br><div style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprin=
t"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #606;" class=3D"styled-by-prettify">SomeType</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> z </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> expr</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span></div></code></div><br>`z` shall be a varia=
ble of type `SomeType`. It will not be a reference; it will be an object, i=
nitialized by `expr`. If `expr` is not implicitly convertible to `SomeType`=
, then you get a compile error. If `expr` is an lvalue, then you get a copy=
; if it is an xvalue, you get a move; if it is a prvalue, you just initiali=
ze `z` in-situ.<br><br>If you do:<br><br><div style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">]</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> expr</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span></div></code></div><br>Assuming that th=
e first member of `expr` is of type `SomeType` (an object or reference), th=
en `x` will effectively be a reference to that `SomeType` subobject. Note t=
hat `x` won&#39;t necessarily be an <i>actual reference</i>, but it will ac=
t like one. Most important of all, `x` will not provoke a copy or move (out=
side of what is needed to initialize the hidden variable).<br><br>So, what =
does this mean:<br><br><div style=3D"background-color: rgb(250, 250, 250); =
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; o=
verflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
[</span><span style=3D"color: #606;" class=3D"styled-by-prettify">SomeType<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"colo=
r: #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">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> expr</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span></div></code></div><br>`SomeType x` looks like a variable =
declaration. It looks like `x` ought to be an object, one that is separate =
from the product type created by `expr`. That is, this <i>looks like</i> it=
 ought to be equivalent to:<br><br><div style=3D"background-color: rgb(250,=
 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> __hidden__ </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> expr</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #606;" class=3D"styled-by-prettify">Som=
eType</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">get</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #0=
66;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">__hidden__</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> =C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">//Copies the value</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">y </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">get</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">__hidden__</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> =C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">//Gets a reference</span></div></code></div><br>However, I believe that=
 Tom is arguing that this is not how it <i>should</i> behave. That it ought=
 to behave exactly like the `auto [x, y]` case, except with a compilation e=
rror if the type isn&#39;t `SomeType`. But since `SomeType x` looks like a =
variable declaration, people will expect it to act like one.<br><br>By cont=
rast, `x -&gt; SomeType` is new syntax. This new syntax would explicitly me=
an &quot;just check to see if its the right type; don&#39;t create an objec=
t.&quot;<br><br>I can agree with this logic in some sense. I agree that we =
do need a way to say &quot;create a structured binding member, but also fai=
l to compile if it is not of this type&quot;. At the same time, I&#39;m fin=
e with spelling that `SomeType &amp;x` (or &amp;&amp; as appropriate).<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/6bee864f-4ff6-4e1d-9425-1ffd0ade99b1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6bee864f-4ff6-4e1d-9425-1ffd0ade99b1=
%40isocpp.org</a>.<br />

------=_Part_2303_2138458239.1494957222691--

------=_Part_2302_976405073.1494957222690--

.

On 05/16/2017 01:35 PM, Ville Voutilainen wrote:
> On 16 May 2017 at 20:01, Tom Honermann <tom@honermann.net> wrote:
>>> What is wrong with the good old way?
>>>
>>> auto [SomeType x, =k->Key] = parseKey();
>>
>> There is the question of what happens if the decomposed type of the matching
>> element is not reference compatible with type 'SomeType'. Ill-formed?  Does
>> 'x' change from being a structured binding to a variable of the declared
>> type?  If so, are conversions performed? What type is decltype(x) and does
> Why on earth would it change from being a structured binding to something else?
Nicol's response nicely explains this perspective; if one expects
'<type-specifier> <identifier>' to declare a variable as it does, I
think, everywhere else that syntax is currently allowed, then use of
that syntax here to declare something other than a variable is
surprising.  An argument that this syntax, rather than declaring a
structured binding, declare a variable initialized by the decomposed
element, is sound.  I'm not saying we need or should have that
capability (to declare a variable instead of a binding), just that it is
arguably the semantic behavior one might expect; exactly as Nicol described.
>
>> it depend on the type of the matching element?  A syntax that indicates a
>> type constraint (which is, I think, what is desired regardless of the syntax
>> used) rather than a variable declaration avoids these questions.
>
> Funny, such "type constraints" were something I always considered to
> be an integral and fundamental
> part of variable declarations.
They certainly are; a variable declaration necessarily identifies a type
(in C++).  But a type constraint doesn't necessarily imply a variable
declaration.
>   I don't write
>
> auto x = foo(); static_assert(is_same_v<decltype(x), int>);
>
> but for some reason it's been suggested that I should do that for
> structured bindings, conveniently forgetting
> that then I will need to put that "type constraint" far far away from
> my structured bindings, like into a for-loop body
> when the structured binding is in the loop header.
>
I'm not following this.  We're discussing:

for (auto [Type x] : c) {}

vs

for (auto [x -> Type] : c) {}

Unless you were responding to questions elsewhere regarding the
motivation to be able to express a type constraint at all?  I agree with
you that some means to constrain the type in the structured binding
declaration is desirable.

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/c0bf3a06-53e5-3411-0967-b167da5d0dcd%40honermann.net.

.

On 16 May 2017 at 21:57, Tom Honermann <tom@honermann.net> wrote:
>> Funny, such "type constraints" were something I always considered to
>> be an integral and fundamental
>> part of variable declarations.
>
> They certainly are; a variable declaration necessarily identifies a type (in
> C++).  But a type constraint doesn't necessarily imply a variable
> declaration.

That makes sense, thanks.

>>   I don't write
>> auto x = foo(); static_assert(is_same_v<decltype(x), int>);
>>
>> but for some reason it's been suggested that I should do that for
>> structured bindings, conveniently forgetting
>> that then I will need to put that "type constraint" far far away from
>> my structured bindings, like into a for-loop body
>> when the structured binding is in the loop header.
>>
> I'm not following this.  We're discussing:
>
> for (auto [Type x] : c) {}
>
> vs
>
> for (auto [x -> Type] : c) {}
>
> Unless you were responding to questions elsewhere regarding the motivation
> to be able to express a type constraint at all?  I agree with you that some
> means to constrain the type in the structured binding declaration is
> desirable.


Oh, it's just rant about the dubious reasons I get for why I "don't
need" to be able to specify the type
of a binding. Today, I need to write

for (auto [x] : something) {
    static_assert(is_same_v<decltype(x), WhatIWant>); // wtf is this
doing in the loop body?
}

--
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/CAFk2RUYaNuKM%3DxhLTP_ZE97KvRUAJybUhaoFAmT%2BV_-7P3t1Mg%40mail.gmail.com.

.

------=_Part_2558_1975579782.1494969152151
Content-Type: multipart/alternative;
 boundary="----=_Part_2559_1803207062.1494969152151"

------=_Part_2559_1803207062.1494969152151
Content-Type: text/plain; charset="UTF-8"

Why not let a variable declaration inside a structured binding be a
variable declaration? If you want a reference to part of the hidden object
use & to create it. Then the compiler can be smart about not keeping the
hidden object if all parts were dug out to by value variables at the time
of binding:

    auto [WhatIWant x, int y] = something();

Here no succeding code can reach the hidden return value so it can be
destroyed.

    auto [WhatIWant& x, y] = something();

Here the first returned value is checked to be a WhatIWant (or subclass)
while y is typed from the rhs. The compiler will easily deduce that the
hidden return value has to be kept until the scope exits.

This needs just a wording that the time of destruction of the hidden value
is unspecified (within reasonable limits) if it can't be reached after the
expression is fully executed. Or alternatively mandate that the hidden
object be kept until the end of the scope anyway.

As for assigining to pre-existing variables I was also disappointed that
this wasn't covered in structured binding. I think the idea with = as a
marker is workable but I would like it to be trailing so it looks like an
assignment. With a leading placement it looks like lambda capture by value
which it certainly isn't.

    MyClass zz;
    auto [WhatIWant x, zz.ix=] = something();

An arbitrary lvalue expression can of course exist before the = inside the
[].

In this type of case the leading auto is somewhat misleading as nothing has
unspecified type. What you would want to be able to write is things like:

    WhatIWant x;
    [x=, auto y] = something();

But I guess making the leading auto optional leads to parsing problems wrt
lambda introducers and/or attributes, right?


Den tisdag 16 maj 2017 kl. 21:44:08 UTC+2 skrev Ville Voutilainen:
>
> On 16 May 2017 at 21:57, Tom Honermann <t...@honermann.net <javascript:>>
> wrote:
> >> Funny, such "type constraints" were something I always considered to
> >> be an integral and fundamental
> >> part of variable declarations.
> >
> > They certainly are; a variable declaration necessarily identifies a type
> (in
> > C++).  But a type constraint doesn't necessarily imply a variable
> > declaration.
>
> That makes sense, thanks.
>
> >>   I don't write
> >> auto x = foo(); static_assert(is_same_v<decltype(x), int>);
> >>
> >> but for some reason it's been suggested that I should do that for
> >> structured bindings, conveniently forgetting
> >> that then I will need to put that "type constraint" far far away from
> >> my structured bindings, like into a for-loop body
> >> when the structured binding is in the loop header.
> >>
> > I'm not following this.  We're discussing:
> >
> > for (auto [Type x] : c) {}
> >
> > vs
> >
> > for (auto [x -> Type] : c) {}
> >
> > Unless you were responding to questions elsewhere regarding the
> motivation
> > to be able to express a type constraint at all?  I agree with you that
> some
> > means to constrain the type in the structured binding declaration is
> > desirable.
>
>
> Oh, it's just rant about the dubious reasons I get for why I "don't
> need" to be able to specify the type
> of a binding. Today, I need to write
>
> for (auto [x] : something) {
>     static_assert(is_same_v<decltype(x), WhatIWant>); // wtf is this
> doing in the loop body?
> }
>

--
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/dedf6bf1-599c-400e-a392-ee7bc8be0afb%40isocpp.org.

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

<div dir=3D"ltr">Why not let a variable declaration inside a structured bin=
ding be a variable declaration? If you want a reference to part of the hidd=
en object use &amp; to create it. Then the compiler can be smart about not =
keeping the hidden object if all parts were dug out to by value variables a=
t the time of binding:<div><br></div><div>=C2=A0 =C2=A0 auto [WhatIWant x, =
int y] =3D something();</div><div><br></div><div>Here no succeding code can=
 reach the hidden return value so it can be destroyed.</div><div><br></div>=
<div>=C2=A0 =C2=A0 auto [WhatIWant&amp; x, y] =3D something();</div><div><b=
r></div><div>Here the first returned value is checked to be a WhatIWant (or=
 subclass) while y is typed from the rhs. The compiler will easily deduce t=
hat the hidden return value has to be kept until the scope exits.</div><div=
><br></div><div>This needs just a wording that the time of destruction of t=
he hidden value is unspecified (within reasonable limits) if it can&#39;t b=
e reached after the expression is fully executed. Or alternatively mandate =
that the hidden object be kept until the end of the scope anyway.</div><div=
><br></div><div>As for assigining to pre-existing variables I was also disa=
ppointed that this wasn&#39;t covered in structured binding. I think the id=
ea with =3D as a marker is workable but I would like it to be trailing so i=
t looks like an assignment. With a leading placement it looks like lambda c=
apture by value which it certainly isn&#39;t.</div><div><br></div><div>=C2=
=A0 =C2=A0 MyClass zz;</div><div>=C2=A0 =C2=A0 auto [WhatIWant x, zz.ix=3D]=
 =3D something();</div><div><br></div><div>An arbitrary lvalue expression c=
an of course exist before the =3D inside the [].</div><div><br></div><div>I=
n this type of case the leading auto is somewhat misleading as nothing has =
unspecified type. What you would want to be able to write is things like:</=
div><div><br></div><div>=C2=A0 =C2=A0 WhatIWant x;<br></div><div>=C2=A0 =C2=
=A0 [x=3D, auto y] =3D something();</div><div><br></div><div>But I guess ma=
king the leading auto optional leads to parsing problems wrt lambda introdu=
cers and/or attributes, right?</div><div><br><br>Den tisdag 16 maj 2017 kl.=
 21:44:08 UTC+2 skrev Ville Voutilainen:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">On 16 May 2017 at 21:57, Tom Honermann &lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"YspFMwkrCgAJ" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"=
this.href=3D&#39;javascript:&#39;;return true;">t...@honermann.net</a>&gt; =
wrote:
<br>&gt;&gt; Funny, such &quot;type constraints&quot; were something I alwa=
ys considered to
<br>&gt;&gt; be an integral and fundamental
<br>&gt;&gt; part of variable declarations.
<br>&gt;
<br>&gt; They certainly are; a variable declaration necessarily identifies =
a type (in
<br>&gt; C++). =C2=A0But a type constraint doesn&#39;t necessarily imply a =
variable
<br>&gt; declaration.
<br>
<br>That makes sense, thanks.
<br>
<br>&gt;&gt; =C2=A0 I don&#39;t write
<br>&gt;&gt; auto x =3D foo(); static_assert(is_same_v&lt;<wbr>decltype(x),=
 int&gt;);
<br>&gt;&gt;
<br>&gt;&gt; but for some reason it&#39;s been suggested that I should do t=
hat for
<br>&gt;&gt; structured bindings, conveniently forgetting
<br>&gt;&gt; that then I will need to put that &quot;type constraint&quot; =
far far away from
<br>&gt;&gt; my structured bindings, like into a for-loop body
<br>&gt;&gt; when the structured binding is in the loop header.
<br>&gt;&gt;
<br>&gt; I&#39;m not following this. =C2=A0We&#39;re discussing:
<br>&gt;
<br>&gt; for (auto [Type x] : c) {}
<br>&gt;
<br>&gt; vs
<br>&gt;
<br>&gt; for (auto [x -&gt; Type] : c) {}
<br>&gt;
<br>&gt; Unless you were responding to questions elsewhere regarding the mo=
tivation
<br>&gt; to be able to express a type constraint at all? =C2=A0I agree with=
 you that some
<br>&gt; means to constrain the type in the structured binding declaration =
is
<br>&gt; desirable.
<br>
<br>
<br>Oh, it&#39;s just rant about the dubious reasons I get for why I &quot;=
don&#39;t
<br>need&quot; to be able to specify the type
<br>of a binding. Today, I need to write
<br>
<br>for (auto [x] : something) {
<br>=C2=A0 =C2=A0 static_assert(is_same_v&lt;<wbr>decltype(x), WhatIWant&gt=
;); // wtf is this
<br>doing in the loop body?
<br>}
<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/dedf6bf1-599c-400e-a392-ee7bc8be0afb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dedf6bf1-599c-400e-a392-ee7bc8be0afb=
%40isocpp.org</a>.<br />

------=_Part_2559_1803207062.1494969152151--

------=_Part_2558_1975579782.1494969152151--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">I think it would be great if the syntax for</div><div style=3D"=
width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-se=
rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c=
olor: rgb(255, 255, 255);">"Constrain this binding"</div><div style=3D"widt=
h: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif,=
 sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color=
: rgb(255, 255, 255);"><span style=3D"font-size: initial; text-align: initi=
al; line-height: initial;">and</span></div><div style=3D"width: 100%; font-=
size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; c=
olor: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255=
, 255);"><span style=3D"font-size: initial; text-align: initial; line-heigh=
t: initial;">"Make a new variable/copy"</span></div><div style=3D"width: 10=
0%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb=
(255, 255, 255);"><span style=3D"font-size: initial; text-align: initial; l=
ine-height: initial;"><br></span></div><div style=3D"width: 100%; font-size=
: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color=
: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 25=
5);"><span style=3D"font-size: initial; text-align: initial; line-height: i=
nitial;">Were completely orthogonal. </span></div><div style=3D"width: 100%=
; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-s=
erif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(2=
55, 255, 255);"><span style=3D"font-size: initial; text-align: initial; lin=
e-height: initial;">Easier to understand; easier to mix and match.&nbsp;</s=
pan></div><div style=3D"width: 100%; font-size: initial; font-family: Calib=
ri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-alig=
n: initial; background-color: rgb(255, 255, 255);"><span style=3D"font-size=
: initial; text-align: initial; line-height: initial;"><br></span></div>   =
                                                                           =
                                                       <div style=3D"width:=
 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, s=
ans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: =
rgb(255, 255, 255);"><br style=3D"display:initial"></div>                  =
                                                                           =
                                                                           =
                           <div style=3D"font-size: initial; font-family: C=
alibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-=
align: initial; background-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;=
my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Device</div>            =
                                                                           =
                                                                           =
                <table width=3D"100%" style=3D"background-color:white;borde=
r-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; =
text-align: initial; background-color: rgb(255, 255, 255);">               =
            <div style=3D"border-style: solid none none; border-top-color: =
rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-famil=
y: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: =
</b>Bengt Gustafsson</div><div><b>Sent: </b>Tuesday, May 16, 2017 3:12 PM</=
div><div><b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply =
To: </b>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: [std-proposa=
ls] Re: Allow Structured Binding Outside of Variable Declaration</div></div=
></td></tr></tbody></table><div style=3D"border-style: solid none none; bor=
der-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initia=
l; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><d=
iv id=3D"_originalContent" style=3D""><div dir=3D"ltr">Why not let a variab=
le declaration inside a structured binding be a variable declaration? If yo=
u want a reference to part of the hidden object use &amp; to create it. The=
n the compiler can be smart about not keeping the hidden object if all part=
s were dug out to by value variables at the time of binding:<div><br></div>=
<div>&nbsp; &nbsp; auto [WhatIWant x, int y] =3D something();</div><div><br=
></div><div>Here no succeding code can reach the hidden return value so it =
can be destroyed.</div><div><br></div><div>&nbsp; &nbsp; auto [WhatIWant&am=
p; x, y] =3D something();</div><div><br></div><div>Here the first returned =
value is checked to be a WhatIWant (or subclass) while y is typed from the =
rhs. The compiler will easily deduce that the hidden return value has to be=
 kept until the scope exits.</div><div><br></div><div>This needs just a wor=
ding that the time of destruction of the hidden value is unspecified (withi=
n reasonable limits) if it can't be reached after the expression is fully e=
xecuted. Or alternatively mandate that the hidden object be kept until the =
end of the scope anyway.</div><div><br></div><div>As for assigining to pre-=
existing variables I was also disappointed that this wasn't covered in stru=
ctured binding. I think the idea with =3D as a marker is workable but I wou=
ld like it to be trailing so it looks like an assignment. With a leading pl=
acement it looks like lambda capture by value which it certainly isn't.</di=
v><div><br></div><div>&nbsp; &nbsp; MyClass zz;</div><div>&nbsp; &nbsp; aut=
o [WhatIWant x, zz.ix=3D] =3D something();</div><div><br></div><div>An arbi=
trary lvalue expression can of course exist before the =3D inside the [].</=
div><div><br></div><div>In this type of case the leading auto is somewhat m=
isleading as nothing has unspecified type. What you would want to be able t=
o write is things like:</div><div><br></div><div>&nbsp; &nbsp; WhatIWant x;=
<br></div><div>&nbsp; &nbsp; [x=3D, auto y] =3D something();</div><div><br>=
</div><div>But I guess making the leading auto optional leads to parsing pr=
oblems wrt lambda introducers and/or attributes, right?</div><div><br><br>D=
en tisdag 16 maj 2017 kl. 21:44:08 UTC+2 skrev Ville Voutilainen:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On 16 May 2017 at 21:57, Tom Honermann &=
lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"YspFM=
wkrCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;">t...@honermann.net=
</a>&gt; wrote:
<br>&gt;&gt; Funny, such "type constraints" were something I always conside=
red to
<br>&gt;&gt; be an integral and fundamental
<br>&gt;&gt; part of variable declarations.
<br>&gt;
<br>&gt; They certainly are; a variable declaration necessarily identifies =
a type (in
<br>&gt; C++). &nbsp;But a type constraint doesn't necessarily imply a vari=
able
<br>&gt; declaration.
<br>
<br>That makes sense, thanks.
<br>
<br>&gt;&gt; &nbsp; I don't write
<br>&gt;&gt; auto x =3D foo(); static_assert(is_same_v&lt;<wbr>decltype(x),=
 int&gt;);
<br>&gt;&gt;
<br>&gt;&gt; but for some reason it's been suggested that I should do that =
for
<br>&gt;&gt; structured bindings, conveniently forgetting
<br>&gt;&gt; that then I will need to put that "type constraint" far far aw=
ay from
<br>&gt;&gt; my structured bindings, like into a for-loop body
<br>&gt;&gt; when the structured binding is in the loop header.
<br>&gt;&gt;
<br>&gt; I'm not following this. &nbsp;We're discussing:
<br>&gt;
<br>&gt; for (auto [Type x] : c) {}
<br>&gt;
<br>&gt; vs
<br>&gt;
<br>&gt; for (auto [x -&gt; Type] : c) {}
<br>&gt;
<br>&gt; Unless you were responding to questions elsewhere regarding the mo=
tivation
<br>&gt; to be able to express a type constraint at all? &nbsp;I agree with=
 you that some
<br>&gt; means to constrain the type in the structured binding declaration =
is
<br>&gt; desirable.
<br>
<br>
<br>Oh, it's just rant about the dubious reasons I get for why I "don't
<br>need" to be able to specify the type
<br>of a binding. Today, I need to write
<br>
<br>for (auto [x] : something) {
<br>&nbsp; &nbsp; static_assert(is_same_v&lt;<wbr>decltype(x), WhatIWant&gt=
;); // wtf is this
<br>doing in the loop body?
<br>}
<br></blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" 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/dedf6bf1-599c-400e-a392-ee7bc8be0afb%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/dedf6bf1-599c-400e-a392-ee7bc8be=
0afb%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></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/20170516213652.5070932.30762.30089%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20170516213652.5070932.30762.30089%40gm=
ail.com</a>.<br />

.

------=_Part_2467_1993634323.1494970669661
Content-Type: multipart/alternative;
 boundary="----=_Part_2468_2075100966.1494970669661"

------=_Part_2468_2075100966.1494970669661
Content-Type: text/plain; charset="UTF-8"

On Tuesday, May 16, 2017 at 5:12:32 PM UTC-4, Bengt Gustafsson wrote:
>
> Why not let a variable declaration inside a structured binding be a
> variable declaration? If you want a reference to part of the hidden object
> use & to create it. Then the compiler can be smart about not keeping the
> hidden object if all parts were dug out to by value variables at the time
> of binding:
>
>     auto [WhatIWant x, int y] = something();
>
> Here no succeding code can reach the hidden return value so it can be
> destroyed.
>
>     auto [WhatIWant& x, y] = something();
>
> Here the first returned value is checked to be a WhatIWant (or subclass)
> while y is typed from the rhs. The compiler will easily deduce that the
> hidden return value has to be kept until the scope exits.
>

Here's the problem. In this case, `decltype(x)` is a reference; it is
*always* a reference. What is `decltype(y)`? Well, that depends on what
`something()` returns. If it returns a product type that involves `get`
calls, then it's a reference. If it returns a struct (without `get` and
such) or an array type, then `decltype(y)` is *not a reference*.

But remember: `decltype(x)` is *always* a reference; that is what you
declared, after all. The problem is that bitfields can undergo structured
binding. And you *cannot* get a reference to a bitfield. So that's...
problematic.

What we want is the structured binding behavior for the name to remain the
same, yet still allow the type that the name is assigned to to be checked.
And `WhatIWant &x` is not a good way to spell that.

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

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

<div dir=3D"ltr">On Tuesday, May 16, 2017 at 5:12:32 PM UTC-4, Bengt Gustaf=
sson wrote:<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">Wh=
y not let a variable declaration inside a structured binding be a variable =
declaration? If you want a reference to part of the hidden object use &amp;=
 to create it. Then the compiler can be smart about not keeping the hidden =
object if all parts were dug out to by value variables at the time of bindi=
ng:<div><br></div><div>=C2=A0 =C2=A0 auto [WhatIWant x, int y] =3D somethin=
g();</div><div><br></div><div>Here no succeding code can reach the hidden r=
eturn value so it can be destroyed.</div><div><br></div><div>=C2=A0 =C2=A0 =
auto [WhatIWant&amp; x, y] =3D something();</div><div><br></div><div>Here t=
he first returned value is checked to be a WhatIWant (or subclass) while y =
is typed from the rhs. The compiler will easily deduce that the hidden retu=
rn value has to be kept until the scope exits.</div></div></blockquote><div=
><br>Here&#39;s the problem. In this case, `decltype(x)` is a reference; it=
 is <i>always</i> a reference. What is `decltype(y)`? Well, that depends on=
 what `something()` returns. If it returns a product type that involves `ge=
t` calls, then it&#39;s a reference. If it returns a struct (without `get` =
and such) or an array type, then `decltype(y)` is <i>not a reference</i>.<b=
r><br>But remember: `decltype(x)` is <i>always</i> a reference; that is wha=
t you declared, after all. The problem is that bitfields can undergo struct=
ured binding. And you <i>cannot</i> get a reference to a bitfield. So that&=
#39;s... problematic.<br><br>What we want is the structured binding behavio=
r for the name to remain the same, yet still allow the type that the name i=
s assigned to to be checked. And `WhatIWant &amp;x` is not a good way to sp=
ell that.</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/99f88905-3bae-4c74-a3bf-71e80a65262c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/99f88905-3bae-4c74-a3bf-71e80a65262c=
%40isocpp.org</a>.<br />

------=_Part_2468_2075100966.1494970669661--

------=_Part_2467_1993634323.1494970669661--

.

This is a multi-part message in MIME format.
--------------14D92A68B88BD11507C7E587
Content-Type: text/plain; charset="UTF-8"; format=flowed

On 05/16/2017 05:12 PM, Bengt Gustafsson wrote:
> Why not let a variable declaration inside a structured binding be a
> variable declaration?
I eluded to this being a sound design in an earlier reply.  Is there
good motivation for being able to declare a variable rather than a
binding?  I find the current design highly motivating specifically
because a binding is effectively an alias.
> If you want a reference to part of the hidden object use & to create
> it. Then the compiler can be smart about not keeping the hidden object
> if all parts were dug out to by value variables at the time of binding:
>
>     auto [WhatIWant x, int y] = something();
>
> Here no succeding code can reach the hidden return value so it can be
> destroyed.
Since destructors can have side effects, I don't care for the idea that
the lifetime of the returned object be dependent on the form of the
declared bindings.  I like the simple model that the returned object is
just an unnamed variable with, effectively, (potentially constrained)
aliases for accessing its components.  Strong motivation should be
required to change that.
>
>     auto [WhatIWant& x, y] = something();
>
> Here the first returned value is checked to be a WhatIWant (or
> subclass) while y is typed from the rhs. The compiler will easily
> deduce that the hidden return value has to be kept until the scope exits.
>
> This needs just a wording that the time of destruction of the hidden
> value is unspecified (within reasonable limits) if it can't be reached
> after the expression is fully executed. Or alternatively mandate that
> the hidden object be kept until the end of the scope anyway.
>
> As for assigining to pre-existing variables I was also disappointed
> that this wasn't covered in structured binding. I think the idea with
> = as a marker is workable but I would like it to be trailing so it
> looks like an assignment. With a leading placement it looks like
> lambda capture by value which it certainly isn't.
>
>     MyClass zz;
>     auto [WhatIWant x, zz.ix=] = something();
>
> An arbitrary lvalue expression can of course exist before the = inside
> the [].
>
> In this type of case the leading auto is somewhat misleading as
> nothing has unspecified type. What you would want to be able to write
> is things like:
>
>     WhatIWant x;
>     [x=, auto y] = something();
>
> But I guess making the leading auto optional leads to parsing problems
> wrt lambda introducers and/or attributes, right?
I believe so.
>
>
> Den tisdag 16 maj 2017 kl. 21:44:08 UTC+2 skrev Ville Voutilainen:
>
>     On 16 May 2017 at 21:57, Tom Honermann <t...@honermann.net
>     <javascript:>> wrote:
>     >> Funny, such "type constraints" were something I always
>     considered to
>     >> be an integral and fundamental
>     >> part of variable declarations.
>     >
>     > They certainly are; a variable declaration necessarily
>     identifies a type (in
>     > C++).  But a type constraint doesn't necessarily imply a variable
>     > declaration.
>
>     That makes sense, thanks.
>
>     >>   I don't write
>     >> auto x = foo(); static_assert(is_same_v<decltype(x), int>);
>     >>
>     >> but for some reason it's been suggested that I should do that for
>     >> structured bindings, conveniently forgetting
>     >> that then I will need to put that "type constraint" far far
>     away from
>     >> my structured bindings, like into a for-loop body
>     >> when the structured binding is in the loop header.
>     >>
>     > I'm not following this.  We're discussing:
>     >
>     > for (auto [Type x] : c) {}
>     >
>     > vs
>     >
>     > for (auto [x -> Type] : c) {}
>     >
>     > Unless you were responding to questions elsewhere regarding the
>     motivation
>     > to be able to express a type constraint at all?  I agree with
>     you that some
>     > means to constrain the type in the structured binding
>     declaration is
>     > desirable.
>
>
>     Oh, it's just rant about the dubious reasons I get for why I "don't
>     need" to be able to specify the type
>     of a binding. Today, I need to write
>
>     for (auto [x] : something) {
>         static_assert(is_same_v<decltype(x), WhatIWant>); // wtf is this
>     doing in the loop body?
>     }
>
> --
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dedf6bf1-599c-400e-a392-ee7bc8be0afb%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dedf6bf1-599c-400e-a392-ee7bc8be0afb%40isocpp.org?utm_medium=email&utm_source=footer>.


--
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/586c2633-4586-12d8-35ae-75ebab176ff8%40honermann.net.

--------------14D92A68B88BD11507C7E587
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 05/16/2017 05:12 PM, Bengt
      Gustafsson wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:dedf6bf1-599c-400e-a392-ee7bc8be0afb@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">Why not let a variable declaration inside a
        structured binding be a variable declaration?</div>
    </blockquote>
    I eluded to this being a sound design in an earlier reply.=C2=A0 Is the=
re
    good motivation for being able to declare a variable rather than a
    binding?=C2=A0 I find the current design highly motivating specifically
    because a binding is effectively an alias.<br>
    <blockquote
      cite=3D"mid:dedf6bf1-599c-400e-a392-ee7bc8be0afb@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"> If you want a reference to part of the hidden
        object use &amp; to create it. Then the compiler can be smart
        about not keeping the hidden object if all parts were dug out to
        by value variables at the time of binding:
        <div><br>
        </div>
        <div>=C2=A0 =C2=A0 auto [WhatIWant x, int y] =3D something();</div>
        <div><br>
        </div>
        <div>Here no succeding code can reach the hidden return value so
          it can be destroyed.</div>
      </div>
    </blockquote>
    Since destructors can have side effects, I don't care for the idea
    that the lifetime of the returned object be dependent on the form of
    the declared bindings.=C2=A0 I like the simple model that the returned
    object is just an unnamed variable with, effectively, (potentially
    constrained) aliases for accessing its components.=C2=A0 Strong
    motivation should be required to change that.<br>
    <blockquote
      cite=3D"mid:dedf6bf1-599c-400e-a392-ee7bc8be0afb@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>=C2=A0 =C2=A0 auto [WhatIWant&amp; x, y] =3D something();</div=
>
        <div><br>
        </div>
        <div>Here the first returned value is checked to be a WhatIWant
          (or subclass) while y is typed from the rhs. The compiler will
          easily deduce that the hidden return value has to be kept
          until the scope exits.</div>
        <div><br>
        </div>
        <div>This needs just a wording that the time of destruction of
          the hidden value is unspecified (within reasonable limits) if
          it can't be reached after the expression is fully executed. Or
          alternatively mandate that the hidden object be kept until the
          end of the scope anyway.</div>
        <div><br>
        </div>
        <div>As for assigining to pre-existing variables I was also
          disappointed that this wasn't covered in structured binding. I
          think the idea with =3D as a marker is workable but I would like
          it to be trailing so it looks like an assignment. With a
          leading placement it looks like lambda capture by value which
          it certainly isn't.</div>
        <div><br>
        </div>
        <div>=C2=A0 =C2=A0 MyClass zz;</div>
        <div>=C2=A0 =C2=A0 auto [WhatIWant x, zz.ix=3D] =3D something();</d=
iv>
        <div><br>
        </div>
        <div>An arbitrary lvalue expression can of course exist before
          the =3D inside the [].</div>
        <div><br>
        </div>
        <div>In this type of case the leading auto is somewhat
          misleading as nothing has unspecified type. What you would
          want to be able to write is things like:</div>
        <div><br>
        </div>
        <div>=C2=A0 =C2=A0 WhatIWant x;<br>
        </div>
        <div>=C2=A0 =C2=A0 [x=3D, auto y] =3D something();</div>
        <div><br>
        </div>
        <div>But I guess making the leading auto optional leads to
          parsing problems wrt lambda introducers and/or attributes,
          right?</div>
      </div>
    </blockquote>
    I believe so.<br>
    <blockquote
      cite=3D"mid:dedf6bf1-599c-400e-a392-ee7bc8be0afb@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          <br>
          Den tisdag 16 maj 2017 kl. 21:44:08 UTC+2 skrev Ville
          Voutilainen:
          <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
            0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 16
            May 2017 at 21:57, Tom Honermann &lt;<a
              moz-do-not-send=3D"true" href=3D"javascript:" target=3D"_blan=
k"
              gdf-obfuscated-mailto=3D"YspFMwkrCgAJ" rel=3D"nofollow"
              onmousedown=3D"this.href=3D'javascript:';return true;"
              onclick=3D"this.href=3D'javascript:';return true;">t...@honer=
mann.net</a>&gt;
            wrote:
            <br>
            &gt;&gt; Funny, such "type constraints" were something I
            always considered to
            <br>
            &gt;&gt; be an integral and fundamental
            <br>
            &gt;&gt; part of variable declarations.
            <br>
            &gt;
            <br>
            &gt; They certainly are; a variable declaration necessarily
            identifies a type (in
            <br>
            &gt; C++). =C2=A0But a type constraint doesn't necessarily impl=
y
            a variable
            <br>
            &gt; declaration.
            <br>
            <br>
            That makes sense, thanks.
            <br>
            <br>
            &gt;&gt; =C2=A0 I don't write
            <br>
            &gt;&gt; auto x =3D foo(); static_assert(is_same_v&lt;<wbr>decl=
type(x),
            int&gt;);
            <br>
            &gt;&gt;
            <br>
            &gt;&gt; but for some reason it's been suggested that I
            should do that for
            <br>
            &gt;&gt; structured bindings, conveniently forgetting
            <br>
            &gt;&gt; that then I will need to put that "type constraint"
            far far away from
            <br>
            &gt;&gt; my structured bindings, like into a for-loop body
            <br>
            &gt;&gt; when the structured binding is in the loop header.
            <br>
            &gt;&gt;
            <br>
            &gt; I'm not following this. =C2=A0We're discussing:
            <br>
            &gt;
            <br>
            &gt; for (auto [Type x] : c) {}
            <br>
            &gt;
            <br>
            &gt; vs
            <br>
            &gt;
            <br>
            &gt; for (auto [x -&gt; Type] : c) {}
            <br>
            &gt;
            <br>
            &gt; Unless you were responding to questions elsewhere
            regarding the motivation
            <br>
            &gt; to be able to express a type constraint at all? =C2=A0I
            agree with you that some
            <br>
            &gt; means to constrain the type in the structured binding
            declaration is
            <br>
            &gt; desirable.
            <br>
            <br>
            <br>
            Oh, it's just rant about the dubious reasons I get for why I
            "don't
            <br>
            need" to be able to specify the type
            <br>
            of a binding. Today, I need to write
            <br>
            <br>
            for (auto [x] : something) {
            <br>
            =C2=A0 =C2=A0 static_assert(is_same_v&lt;<wbr>decltype(x),
            WhatIWant&gt;); // wtf is this
            <br>
            doing in the loop body?
            <br>
            }
            <br>
          </blockquote>
        </div>
      </div>
      -- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
      To view this discussion on the web visit <a
        moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dedf6b=
f1-599c-400e-a392-ee7bc8be0afb%40isocpp.org?utm_medium=3Demail&amp;utm_sour=
ce=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d=
edf6bf1-599c-400e-a392-ee7bc8be0afb%40isocpp.org</a>.<br>
    </blockquote>
    <p><br>
    </p>
  </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/586c2633-4586-12d8-35ae-75ebab176ff8%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/586c2633-4586-12d8-35ae-75ebab176=
ff8%40honermann.net</a>.<br />

--------------14D92A68B88BD11507C7E587--

.

--94eb2c043012259c7a054fabcad2
Content-Type: text/plain; charset="UTF-8"

On Tue, May 16, 2017 at 2:44 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
> for (auto [x] : something) {
>     static_assert(is_same_v<decltype(x), WhatIWant>); // wtf is this
> doing in the loop body?
> }


How about this

  for (TupleLike<A, B> [x, y] : something) { ... }

Where TupleLike is a concept.

--
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/CAGsORuBgzhCGGPYAWjSDg40xhGnV_ghcVTAvn3xaBFz52vs7xw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, May 16, 2017 at 2:44 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutil=
ainen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br=
>
for (auto [x] : something) {<br>
=C2=A0 =C2=A0 static_assert(is_same_v&lt;<wbr>decltype(x), WhatIWant&gt;); =
// wtf is this<br>
doing in the loop body?<br>
<span class=3D"">}</span></blockquote></div><br></div><div class=3D"gmail_e=
xtra">How about this<br><br></div><div class=3D"gmail_extra">=C2=A0 for (Tu=
pleLike&lt;A, B&gt; [x, y] : something) { ... }<br><br></div><div class=3D"=
gmail_extra">Where TupleLike is a concept.<br clear=3D"all"></div><div clas=
s=3D"gmail_extra"><br>-- <br><div class=3D"gmail_signature" data-smartmail=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=
=3D"ltr"><div>Zhihao Yuan, ID lichray<br>The best way to predict the future=
 is to invent it.<br>_______________________________________________<br></d=
iv></div></div></div></div></div></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/CAGsORuBgzhCGGPYAWjSDg40xhGnV_ghcVTAv=
n3xaBFz52vs7xw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBgzhCGGPYA=
WjSDg40xhGnV_ghcVTAvn3xaBFz52vs7xw%40mail.gmail.com</a>.<br />

--94eb2c043012259c7a054fabcad2--

.

On 17 May 2017 at 01:35, Zhihao Yuan <zy@miator.net> wrote:
>
> On Tue, May 16, 2017 at 2:44 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>>
>> for (auto [x] : something) {
>>     static_assert(is_same_v<decltype(x), WhatIWant>); // wtf is this
>> doing in the loop body?
>> }
>
>
> How about this
>
>   for (TupleLike<A, B> [x, y] : something) { ... }
>
> Where TupleLike is a concept.

How does that help me specify the concrete types of the bindings?

--
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/CAFk2RUahRzietkqHtmPrRNSmEorfKF8TfiHGNAB_JDMhC4PU%2Bg%40mail.gmail.com.

.

--94eb2c195864c25c1d054fabdd64
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 16, 2017 at 2:53 PM, Tom Honermann <tom@honermann.net> wrote:

> On 05/16/2017 05:12 PM, Bengt Gustafsson wrote:
>
> Why not let a variable declaration inside a structured binding be a
> variable declaration?
>
> I eluded to this being a sound design in an earlier reply.  Is there good
> motivation for being able to declare a variable rather than a binding?  I
> find the current design highly motivating specifically because a binding =
is
> effectively an alias.
>

Speaking of "being able to declare a variable instead of a binding", this
morning I ran across this example due to Tony van Eerd:

struct Foo {
    int x =3D 0;
    std::string str =3D "world";
    ~Foo() { std::cout << str; }
};

int main() {
    auto [i, s] =3D Foo();
    std::cout << "hello ";
    s =3D "structured bindings";
    // Foo's destructor prints "hello structured bindings"!
}

....which is the nail in the coffin of "ever using C++17 structured bindings
in production code" AFAIC.

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Tue, May 16, 2017 at 2:53 PM, Tom Honermann <span dir=
=3D"ltr">&lt;<a href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@hon=
ermann.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF"><span class=3D"gmail-">
    <div class=3D"gmail-m_-6536589000383708425moz-cite-prefix">On 05/16/201=
7 05:12 PM, Bengt
      Gustafsson wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">Why not let a variable declaration inside a
        structured binding be a variable declaration?</div>
    </blockquote></span>
    I eluded to this being a sound design in an earlier reply.=C2=A0 Is the=
re
    good motivation for being able to declare a variable rather than a
    binding?=C2=A0 I find the current design highly motivating specifically
    because a binding is effectively an alias.</div></blockquote><div><br><=
/div><div>Speaking of &quot;being able to declare a variable instead of a b=
inding&quot;, this morning I ran across this example due to Tony van Eerd:<=
/div><div><br></div><div><div><font face=3D"monospace, monospace">struct Fo=
o {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 int =
x =3D 0;</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0=
 std::string str =3D &quot;world&quot;;</font></div><div><font face=3D"mono=
space, monospace">=C2=A0 =C2=A0 ~Foo() { std::cout &lt;&lt; str; }</font></=
div><div><font face=3D"monospace, monospace">};</font></div><div><font face=
=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace, mo=
nospace">int main() {</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 auto [i, s] =3D Foo();</font></div><div><font face=3D"monospa=
ce, monospace">=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;hello &quot;;</font><=
/div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 s =3D &quot;str=
uctured bindings&quot;;</font></div><div><font face=3D"monospace, monospace=
">=C2=A0 =C2=A0 // Foo&#39;s destructor prints &quot;hello structured bindi=
ngs&quot;!</font></div><div><font face=3D"monospace, monospace">}</font></d=
iv></div><div><br></div><div>...which is the nail in the coffin of &quot;ev=
er using C++17 structured bindings in production code&quot; AFAIC.</div><di=
v><br></div><div>=E2=80=93Arthur</div></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/CADvuK0JFhG1anzEmHLg5%2BmhiLcHGU%2B31=
PRY%3DgWPhSuG0Ejd5zw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JFhG=
1anzEmHLg5%2BmhiLcHGU%2B31PRY%3DgWPhSuG0Ejd5zw%40mail.gmail.com</a>.<br />

--94eb2c195864c25c1d054fabdd64--

.

--f403045c50565645bc054fabe857
Content-Type: text/plain; charset="UTF-8"

On Tue, May 16, 2017 at 5:36 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> > How about this
> >
> >   for (TupleLike<A, B> [x, y] : something) { ... }
> >
> > Where TupleLike is a concept.
>
> How does that help me specify the concrete types of the bindings?


It does type-check, as same as you putting

  static_assert(is_same_v<decltype(x), A>);

in the loop.

But it doesn't change the type object of the
underlying object, or the type of the bindings.

If you want to bind to different types, you can
cast one the right hand side:

  auto [x, y] = rebind<NewA, NewB>(something);

where `rebind` converts a tuple-like to a
std::tuple, or some thin wrappers if you prefer.

--
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/CAGsORuDWRidpKi6nj5Bm8m%2BhHTy7PVKzzZFq_%3DvaA7XMdb3odw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, May 16, 2017 at 5:36 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutil=
ainen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><span class=3D"gmail-">&gt; How about this<br>
&gt;<br>
&gt;=C2=A0 =C2=A0for (TupleLike&lt;A, B&gt; [x, y] : something) { ... }<br>
&gt;<br>
&gt; Where TupleLike is a concept.<br>
<br>
</span>How does that help me specify the concrete types of the bindings?</b=
lockquote></div><br></div><div class=3D"gmail_extra">It does type-check, as=
 same as you putting<br><br>=C2=A0 <span class=3D"gmail-im">static_assert(i=
s_same_v&lt;<wbr>decltype(x), A&gt;);<br><br></span></div><div class=3D"gma=
il_extra"><span class=3D"gmail-im">in the loop.<br><br></span></div><div cl=
ass=3D"gmail_extra"><span class=3D"gmail-im">But it doesn&#39;t change the =
type object of the<br></span></div><div class=3D"gmail_extra"><span class=
=3D"gmail-im">underlying object, or the type of the bindings.<br><br></span=
></div><div class=3D"gmail_extra"><span class=3D"gmail-im">If you want to b=
ind to different types, you can<br></span></div><div class=3D"gmail_extra">=
<span class=3D"gmail-im">cast one the right hand side:<br><br></span></div>=
<div class=3D"gmail_extra"><span class=3D"gmail-im">=C2=A0 auto [x, y] =3D =
rebind&lt;NewA, NewB&gt;(something);<br><br></span></div><div class=3D"gmai=
l_extra"><span class=3D"gmail-im">where `rebind` converts a tuple-like to a=
<br>std::tuple, or some thin wrappers if you prefer.<br></span></div><div c=
lass=3D"gmail_extra"><br>-- <br><div class=3D"gmail_signature"><div dir=3D"=
ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>Zhihao Yuan, ID lichr=
ay<br>The best way to predict the future is to invent it.<br>______________=
_________________________________<br></div></div></div></div></div></div></=
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/CAGsORuDWRidpKi6nj5Bm8m%2BhHTy7PVKzzZ=
Fq_%3DvaA7XMdb3odw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuDWRidp=
Ki6nj5Bm8m%2BhHTy7PVKzzZFq_%3DvaA7XMdb3odw%40mail.gmail.com</a>.<br />

--f403045c50565645bc054fabe857--

.

On 17 May 2017 at 01:43, Zhihao Yuan <zy@miator.net> wrote:
>> > How about this
>> >
>> >   for (TupleLike<A, B> [x, y] : something) { ... }
>> >
>> > Where TupleLike is a concept.
>>
>> How does that help me specify the concrete types of the bindings?
>
>
> It does type-check, as same as you putting
>
>   static_assert(is_same_v<decltype(x), A>);
>
> in the loop.
>
> But it doesn't change the type object of the
> underlying object, or the type of the bindings.

I need to use some weird concept to check that the type of x is A?

--
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/CAFk2RUYeKYjhmX9fVwDaV7zJRLxAmJx%3DhSsgPWLMFJD%2BwTW3MQ%40mail.gmail.com.

.

--94eb2c14f94cdceb57054fac144d
Content-Type: text/plain; charset="UTF-8"

On Tue, May 16, 2017 at 5:49 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> >> >   for (TupleLike<A, B> [x, y] : something) { ... }
> >> >
> >> > Where TupleLike is a concept.
> >>
> >> How does that help me specify the concrete types of the bindings?
> >
> >
> > It does type-check, as same as you putting
> >
> >   static_assert(is_same_v<decltype(x), A>);
> >
> > in the loop.
> >
> > But it doesn't change the type object of the
> > underlying object, or the type of the bindings.
>
> I need to use some weird concept to check that the type of x is A?


If constrained-type-specifier is accepted as-is, I bet
people will have more creative ways to overuse it.
However, if that can restore our energy spent on
inventing new syntax, maybe I can give a "meh"...

--
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/CAGsORuCq3%2BKhQjp7ARb8fvjaROAEEFP45geKENkPg3C_trmT%3Dg%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div><div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Tue, May 16, 2017 at 5:49 PM, Ville Voutilainen <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span>&gt;&gt; &gt;=C2=A0 =C2=A0for (TupleLike&lt;A, B&gt; [x=
, y] : something) { ... }<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Where TupleLike is a concept.<br>
&gt;&gt;<br>
&gt;&gt; How does that help me specify the concrete types of the bindings?<=
br>
&gt;<br>
&gt;<br>
&gt; It does type-check, as same as you putting<br>
&gt;<br>
&gt;=C2=A0 =C2=A0static_assert(is_same_v&lt;declt<wbr>ype(x), A&gt;);<br>
&gt;<br>
&gt; in the loop.<br>
&gt;<br>
&gt; But it doesn&#39;t change the type object of the<br>
&gt; underlying object, or the type of the bindings.<br>
<br>
</span>I need to use some weird concept to check that the type of x is A?</=
blockquote></div><br></div>If constrained-type-specifier is accepted as-is,=
 I bet<br></div>people will have more creative ways to overuse it.<br></div=
>However, if that can restore our energy spent on<br></div>inventing new sy=
ntax, maybe I can give a &quot;meh&quot;...<br><div><div><div><div><div cla=
ss=3D"gmail_extra"><br>-- <br><div class=3D"m_7659099891622532818gmail_sign=
ature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D=
"ltr"><div><div dir=3D"ltr"><div>Zhihao Yuan, ID lichray<br>The best way to=
 predict the future is to invent it.<br>______________________________<wbr>=
_________________<br></div></div></div></div></div></div></div>
</div></div></div></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/CAGsORuCq3%2BKhQjp7ARb8fvjaROAEEFP45g=
eKENkPg3C_trmT%3Dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuCq3%2B=
KhQjp7ARb8fvjaROAEEFP45geKENkPg3C_trmT%3Dg%40mail.gmail.com</a>.<br />

--94eb2c14f94cdceb57054fac144d--

.

On 17 May 2017 at 01:41, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> Speaking of "being able to declare a variable instead of a binding", this
> morning I ran across this example due to Tony van Eerd:
>
> struct Foo {
>     int x = 0;
>     std::string str = "world";
>     ~Foo() { std::cout << str; }
> };
>
> int main() {
>     auto [i, s] = Foo();
>     std::cout << "hello ";
>     s = "structured bindings";
>     // Foo's destructor prints "hello structured bindings"!
> }
>
> ...which is the nail in the coffin of "ever using C++17 structured bindings
> in production code" AFAIC.


...because you insist on thinking that the bindings do something that
they do not?

--
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/CAFk2RUas7u5rzMdxdAZZ_qFxhN9rFfvw7Betfo06XoOjwZh0nQ%40mail.gmail.com.

.

This is a multi-part message in MIME format.
--------------8C013CBA4CC1370326F81341
Content-Type: text/plain; charset="UTF-8"; format=flowed

On 05/16/2017 06:41 PM, Arthur O'Dwyer wrote:
> On Tue, May 16, 2017 at 2:53 PM, Tom Honermann <tom@honermann.net
> <mailto:tom@honermann.net>> wrote:
>
>     On 05/16/2017 05:12 PM, Bengt Gustafsson wrote:
>>     Why not let a variable declaration inside a structured binding be
>>     a variable declaration?
>     I eluded to this being a sound design in an earlier reply.  Is
>     there good motivation for being able to declare a variable rather
>     than a binding?  I find the current design highly motivating
>     specifically because a binding is effectively an alias.
>
>
> Speaking of "being able to declare a variable instead of a binding",
> this morning I ran across this example due to Tony van Eerd:
>
> struct Foo {
>     int x = 0;
>     std::string str = "world";
>     ~Foo() { std::cout << str; }
> };
>
> int main() {
>     auto [i, s] = Foo();
>     std::cout << "hello ";
>     s = "structured bindings";
>     // Foo's destructor prints "hello structured bindings"!
> }
>
> ...which is the nail in the coffin of "ever using C++17 structured
> bindings in production code" AFAIC.

Do you find the fact that the following code exhibits the same behavior
surprising?

int main() {
     auto foo = Foo();
     std::cout << "hello ";
     foo.s = "structured bindings";
     // Foo's destructor prints "hello structured bindings"!
}

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/1c728d4e-7f8e-4528-23a7-5a9ba198ebbc%40honermann.net.

--------------8C013CBA4CC1370326F81341
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 05/16/2017 06:41 PM, Arthur O'Dwyer
      wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CADvuK0JFhG1anzEmHLg5+mhiLcHGU+31PRY=3DgWPhSuG0Ejd5zw@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">On Tue, May 16, 2017 at 2:53 PM, Tom Honermann <span
          dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
            href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@honerma=
nn.net</a>&gt;</span>
        wrote:<br>
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
              <div bgcolor=3D"#FFFFFF"><span class=3D"gmail-">
                  <div
                    class=3D"gmail-m_-6536589000383708425moz-cite-prefix">O=
n
                    05/16/2017 05:12 PM, Bengt Gustafsson wrote:<br>
                  </div>
                  <blockquote type=3D"cite">
                    <div dir=3D"ltr">Why not let a variable declaration
                      inside a structured binding be a variable
                      declaration?</div>
                  </blockquote>
                </span> I eluded to this being a sound design in an
                earlier reply.=C2=A0 Is there good motivation for being abl=
e
                to declare a variable rather than a binding?=C2=A0 I find t=
he
                current design highly motivating specifically because a
                binding is effectively an alias.</div>
            </blockquote>
            <div><br>
            </div>
            <div>Speaking of "being able to declare a variable instead
              of a binding", this morning I ran across this example due
              to Tony van Eerd:</div>
            <div><br>
            </div>
            <div>
              <div><font face=3D"monospace, monospace">struct Foo {</font><=
/div>
              <div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 int x =
=3D 0;</font></div>
              <div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 std::s=
tring str
                  =3D "world";</font></div>
              <div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 ~Foo()=
 {
                  std::cout &lt;&lt; str; }</font></div>
              <div><font face=3D"monospace, monospace">};</font></div>
              <div><font face=3D"monospace, monospace"><br>
                </font></div>
              <div><font face=3D"monospace, monospace">int main() {</font><=
/div>
              <div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 auto [=
i, s] =3D
                  Foo();</font></div>
              <div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 std::c=
out
                  &lt;&lt; "hello ";</font></div>
              <div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 s =3D =
"structured
                  bindings";</font></div>
              <div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 // Foo=
's
                  destructor prints "hello structured bindings"!</font></di=
v>
              <div><font face=3D"monospace, monospace">}</font></div>
            </div>
            <div><br>
            </div>
            <div>...which is the nail in the coffin of "ever using C++17
              structured bindings in production code" AFAIC.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Do you find the fact that the following code exhibits the same
    behavior surprising?<br>
    <br>
    <div><font face=3D"monospace, monospace">int main() {</font></div>
    <div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 auto foo =3D Foo=
();</font></div>
    <div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 std::cout &lt;&l=
t; "hello
        ";</font></div>
    <div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 foo.s =3D "struc=
tured
        bindings";</font></div>
    <div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 // Foo's destruc=
tor
        prints "hello structured bindings"!</font></div>
    <div><font face=3D"monospace, monospace">}</font></div>
    <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/1c728d4e-7f8e-4528-23a7-5a9ba198ebbc%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/1c728d4e-7f8e-4528-23a7-5a9ba198e=
bbc%40honermann.net</a>.<br />

--------------8C013CBA4CC1370326F81341--

.

------=_Part_1404_1938301896.1495030078238
Content-Type: multipart/alternative;
 boundary="----=_Part_1405_217602678.1495030078238"

------=_Part_1405_217602678.1495030078238
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


>
> Speaking of "being able to declare a variable instead of a binding", this=
=20
> morning I ran across this example due to Tony van Eerd:
>
> struct Foo {
>     int x =3D 0;
>     std::string str =3D "world";
>     ~Foo() { std::cout << str; }
> };
>
> int main() {
>     auto [i, s] =3D Foo();
>     std::cout << "hello ";
>     s =3D "structured bindings";
>     // Foo's destructor prints "hello structured bindings"!
> }
>
> ...which is the nail in the coffin of "ever using C++17 structured=20
> bindings in production code" AFAIC.
>
> =E2=80=93Arthur
>

Why is this surprising? s refers to the string inside of the (one) Foo=20
object, and then you're modifying it. (Also, the destructor just prints=20
"structured bindings"). Is the implication that you wanted s to be not a=20
reference?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/479648c9-2815-4f8d-a527-519940ee9b9c%40isocpp.or=
g.

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D=
"gmail_quote"><div>Speaking of &quot;being able to declare a variable inste=
ad of a binding&quot;, this morning I ran across this example due to Tony v=
an Eerd:<br></div><div><br></div><div><div><font face=3D"monospace, monospa=
ce">struct Foo {</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 int x =3D 0;</font></div><div><font face=3D"monospace, monospace=
">=C2=A0 =C2=A0 std::string str =3D &quot;world&quot;;</font></div><div><fo=
nt face=3D"monospace, monospace">=C2=A0 =C2=A0 ~Foo() { std::cout &lt;&lt; =
str; }</font></div><div><font face=3D"monospace, monospace">};</font></div>=
<div><font face=3D"monospace, monospace"><br></font></div><div><font face=
=3D"monospace, monospace">int main() {</font></div><div><font face=3D"monos=
pace, monospace">=C2=A0 =C2=A0 auto [i, s] =3D Foo();</font></div><div><fon=
t face=3D"monospace, monospace">=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;hell=
o &quot;;</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 s =3D &quot;structured bindings&quot;;</font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 =C2=A0 // Foo&#39;s destructor prints &quot;hel=
lo structured bindings&quot;!</font></div><div><font face=3D"monospace, mon=
ospace">}</font></div></div><div><br></div><div>...which is the nail in the=
 coffin of &quot;ever using C++17 structured bindings in production code&qu=
ot; AFAIC.</div><div><br></div><div>=E2=80=93Arthur<br></div></div></div></=
blockquote><div><br></div><div>Why is this surprising? s refers to the stri=
ng inside of the (one) Foo object, and then you&#39;re modifying it. (Also,=
 the destructor just prints &quot;structured bindings&quot;). Is the implic=
ation that you wanted s to be not a reference?</div><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/479648c9-2815-4f8d-a527-519940ee9b9c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/479648c9-2815-4f8d-a527-519940ee9b9c=
%40isocpp.org</a>.<br />

------=_Part_1405_217602678.1495030078238--

------=_Part_1404_1938301896.1495030078238--

.