------=_Part_532_144562334.1449860688934
Content-Type: multipart/alternative;
 boundary="----=_Part_533_155992412.1449860688935"

------=_Part_533_155992412.1449860688935
Content-Type: text/plain; charset=UTF-8

After reading through the Structured Bindings proposals P01440 and P0151 I
feel both of them miss an opportunity to include variadic variables. The
structured bindings proposals would allow you to bind variables as:

tuple<T1, T2, T3> f();

auto{a,b,c} = f(); // P0144R0
<a,b,c> = f();     // P0151R0

I would like to see both proposals extended to include a variable amount of
identifiers as

<T... p> = foo();

This would create a natural way to unpack a tuple, something that is not
straight forward with the current standard. In short, the extension I
propose to P0144 and P0151 would allow you to pack and unpack tuples (or
structs) like:

// Packing:
auto s = std::make_tuple(std::forward<Args>(args)...);

// Unpacking:
<...p> = s;     // P0151 most terse version
<T... p> = s;   // P0151 with implicit auto return value
auto{... p} =s; // P0144

// Using unpacked values:
func(p...);
MyType inst(p...);

Any feedback appreciated!

--

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

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

<div dir=3D"ltr">After reading through the Structured Bindings proposals P0=
1440 and P0151 I feel both of them miss an opportunity to include variadic =
variables. The structured bindings proposals would allow you to bind variab=
les as:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 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"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">tuple</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T1</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> T2</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> T3</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">auto</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">b</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">c</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// P0144R0</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">a</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">b</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> =C2=A0 =C2=A0 </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// P0151R0</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><br>I would =
like to see both proposals extended to include a variable amount of identif=
iers as<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 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"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">&lt;T</span><span style=3D"color: #000;" class=3D"styled-by-prettify">..=
.. </span><span style=3D"color: #606;" class=3D"styled-by-prettify">p</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">&gt;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> =3D foo(); <br></span>=
</div></code></div><br>This would create a natural way to unpack a tuple, s=
omething that is not straight forward with the current standard. In short, =
the extension I propose to P0144 and P0151 would allow you to pack and unpa=
ck tuples (or structs) like:<br><br><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// Packing:</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> s </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">make_tuple</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">forward</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Args</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)...);</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br><br></span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// Unpacking:</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;...</span><span style=3D"color: #000;" class=3D"styled-by-prettify">p<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> s</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> =C2=A0 =C2=A0 </span><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">// P0151 most terse version</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> p</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// P0151 with implicit auto =
return value</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{...</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">s</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/ P0144</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Us=
ing unpacked values:</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>func</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">p=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...);</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">MyType</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> inst</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">p</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">...);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>Any feedback appr=
eciated!<br></div>

<p></p>

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

------=_Part_533_155992412.1449860688935--
------=_Part_532_144562334.1449860688934--

.

On 11 December 2015 at 21:04, Jens =C3=85kerblom <akerblom.jens@gmail.com> =
wrote:
> After reading through the Structured Bindings proposals P01440 and P0151 =
I
> feel both of them miss an opportunity to include variadic variables. The
> structured bindings proposals would allow you to bind variables as:
>
> tuple<T1, T2, T3> f();
>
> auto{a,b,c} =3D f(); // P0144R0
> <a,b,c> =3D f();     // P0151R0
>
> I would like to see both proposals extended to include a variable amount =
of
> identifiers as
>
> <T... p> =3D foo();
>
> This would create a natural way to unpack a tuple, something that is not
> straight forward with the current standard. In short, the extension I
> propose to P0144 and P0151 would allow you to pack and unpack tuples (or
> structs) like:
>
> // Packing:
> auto s =3D std::make_tuple(std::forward<Args>(args)...);
>
> // Unpacking:
> <...p> =3D s;     // P0151 most terse version
> <T... p> =3D s;   // P0151 with implicit auto return value
> auto{... p} =3Ds; // P0144
>
> // Using unpacked values:
> func(p...);
> MyType inst(p...);
>
> Any feedback appreciated!

If you unpack, what would be the type of p in <...p>? How would I
access the individual
unpacked components?

Just as a potentially related point; we can already do, with concepts,
the following:

tuple<int, int> f() {return {};}
int main()
{
    tuple<auto...> x =3D f();
}

With that, I can certainly understand the desire to be able to do
variadic unpacking. I just
don't yet quite grasp how it would really work.

--=20

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

.

------=_Part_2612_987326660.1449870157409
Content-Type: multipart/alternative;
 boundary="----=_Part_2613_844785858.1449870157410"

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

Regarding: "If you unpack, what would be the type of p in <...p>?"
As "p" isn't a variable as such, it wouldn't be a type. Just like the=20
identifier "p" in

template <typename... Arg>
void f(Arg... p);

doesn't have a type in there but represents a collection of variables.

And regarding: "How would I access the individual unpacked components?"
Just like one cannot directly access the argument of the n:th parameter of=
=20
the above parameters, one cannot directly access the n:th variable in <...=
=20
p>. However, one could implement the features to support the following:

<x, y, ...p> =3D f();

Then you can access the first 2 parameter with "x" and "y".

An example of how it could be implemented,

void foo(int, float);

<... p> =3D tuple<int, float>(1, 1.0f);
foo(p...);

would be the same as:

void foo(int, float);

<intValue, floatValue> =3D tuple<int, float>(1, 1.0f);
foo(intValue, floatValue);

I hope this answers your questions.

On Friday, December 11, 2015 at 9:15:30 PM UTC+2, Ville Voutilainen wrote:
>
> On 11 December 2015 at 21:04, Jens =C3=85kerblom <akerbl...@gmail.com=20
> <javascript:>> wrote:=20
> > After reading through the Structured Bindings proposals P01440 and P015=
1=20
> I=20
> > feel both of them miss an opportunity to include variadic variables. Th=
e=20
> > structured bindings proposals would allow you to bind variables as:=20
> >=20
> > tuple<T1, T2, T3> f();=20
> >=20
> > auto{a,b,c} =3D f(); // P0144R0=20
> > <a,b,c> =3D f();     // P0151R0=20
> >=20
> > I would like to see both proposals extended to include a variable amoun=
t=20
> of=20
> > identifiers as=20
> >=20
> > <T... p> =3D foo();=20
> >=20
> > This would create a natural way to unpack a tuple, something that is no=
t=20
> > straight forward with the current standard. In short, the extension I=
=20
> > propose to P0144 and P0151 would allow you to pack and unpack tuples (o=
r=20
> > structs) like:=20
> >=20
> > // Packing:=20
> > auto s =3D std::make_tuple(std::forward<Args>(args)...);=20
> >=20
> > // Unpacking:=20
> > <...p> =3D s;     // P0151 most terse version=20
> > <T... p> =3D s;   // P0151 with implicit auto return value=20
> > auto{... p} =3Ds; // P0144=20
> >=20
> > // Using unpacked values:=20
> > func(p...);=20
> > MyType inst(p...);=20
> >=20
> > Any feedback appreciated!=20
>
> If you unpack, what would be the type of p in <...p>? How would I=20
> access the individual=20
> unpacked components?=20
>
> Just as a potentially related point; we can already do, with concepts,=20
> the following:=20
>
> tuple<int, int> f() {return {};}=20
> int main()=20
> {=20
>     tuple<auto...> x =3D f();=20
> }=20
>
> With that, I can certainly understand the desire to be able to do=20
> variadic unpacking. I just=20
> don't yet quite grasp how it would really work.=20
>

--=20

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

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

<div dir=3D"ltr">Regarding: &quot;If you unpack, what would be the type of =
p in &lt;...p&gt;?&quot;<br>As &quot;p&quot; isn&#39;t a variable as such, =
it wouldn&#39;t be a type. Just like the identifier &quot;p&quot; in<br><br=
><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); =
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; w=
ord-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">Arg</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Arg</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span></div></code></div><br>doesn&#=
39;t have a type in there but represents a collection of variables.<br><br>=
And regarding: &quot;How would I access the individual
unpacked components?&quot;<br>Just like one cannot directly access the argu=
ment of the n:th parameter of the above parameters, one cannot directly acc=
ess the n:th variable in &lt;... p&gt;. However, one could implement the fe=
atures to support the following:<br><br><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">&lt;x</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">, </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">y</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">, ...</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">p</span><span style=3D"color: #008;" class=3D"styled-by-prettify">&gt;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =3D f();<br=
></span></div></code></div><br>Then you can access the first 2 parameter wi=
th &quot;x&quot; and &quot;y&quot;.<br><br>An example of how it could be im=
plemented,<br><br><div class=3D"prettyprint" style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">float</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;...</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> p</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> tuple<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">float</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">1.0=
f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>foo</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">p</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">...);</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><br>would be=
 the same as:<br><br><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; =
border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div=
 class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">float</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">intValue</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> floatValue</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> tuple</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">float</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;(</span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">1.0f</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>foo</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">intValue</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> floatValue</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span></div></code></div><br>I hope this answers y=
our questions.<br><br>On Friday, December 11, 2015 at 9:15:30 PM UTC+2, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 11 Dec=
ember 2015 at 21:04, Jens =C3=85kerblom &lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"QMoC_TnDCwAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">akerbl...@gmail.com</a>&gt; wrote:
<br>&gt; After reading through the Structured Bindings proposals P01440 and=
 P0151 I
<br>&gt; feel both of them miss an opportunity to include variadic variable=
s. The
<br>&gt; structured bindings proposals would allow you to bind variables as=
:
<br>&gt;
<br>&gt; tuple&lt;T1, T2, T3&gt; f();
<br>&gt;
<br>&gt; auto{a,b,c} =3D f(); // P0144R0
<br>&gt; &lt;a,b,c&gt; =3D f(); =C2=A0 =C2=A0 // P0151R0
<br>&gt;
<br>&gt; I would like to see both proposals extended to include a variable =
amount of
<br>&gt; identifiers as
<br>&gt;
<br>&gt; &lt;T... p&gt; =3D foo();
<br>&gt;
<br>&gt; This would create a natural way to unpack a tuple, something that =
is not
<br>&gt; straight forward with the current standard. In short, the extensio=
n I
<br>&gt; propose to P0144 and P0151 would allow you to pack and unpack tupl=
es (or
<br>&gt; structs) like:
<br>&gt;
<br>&gt; // Packing:
<br>&gt; auto s =3D std::make_tuple(std::forward&lt;<wbr>Args&gt;(args)...)=
;
<br>&gt;
<br>&gt; // Unpacking:
<br>&gt; &lt;...p&gt; =3D s; =C2=A0 =C2=A0 // P0151 most terse version
<br>&gt; &lt;T... p&gt; =3D s; =C2=A0 // P0151 with implicit auto return va=
lue
<br>&gt; auto{... p} =3Ds; // P0144
<br>&gt;
<br>&gt; // Using unpacked values:
<br>&gt; func(p...);
<br>&gt; MyType inst(p...);
<br>&gt;
<br>&gt; Any feedback appreciated!
<br>
<br>If you unpack, what would be the type of p in &lt;...p&gt;? How would I
<br>access the individual
<br>unpacked components?
<br>
<br>Just as a potentially related point; we can already do, with concepts,
<br>the following:
<br>
<br>tuple&lt;int, int&gt; f() {return {};}
<br>int main()
<br>{
<br>=C2=A0 =C2=A0 tuple&lt;auto...&gt; x =3D f();
<br>}
<br>
<br>With that, I can certainly understand the desire to be able to do
<br>variadic unpacking. I just
<br>don&#39;t yet quite grasp how it would really work.
<br></blockquote></div>

<p></p>

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

------=_Part_2613_844785858.1449870157410--
------=_Part_2612_987326660.1449870157409--

.

------=_Part_2643_2036838019.1449880028104
Content-Type: multipart/alternative;
 boundary="----=_Part_2644_400262053.1449880028104"

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

Circling back to the original problem that at least P0144 tries to address=
=20
we already have a quite good solution for multiple return values, return by=
=20
anonymous struct:

struct { double angle; double length; } ToPolar(double x, double y)
{
     return { atan2(y,  x), hypot(x, y); }
}

auto v =3D ToPolar(3.5, 7.7);

cout << v.angle << endl;


While this does not give the exact same result as the proposal or what this=
=20
thread aims at I think it is actually better as the called function gets to=
=20
name its return values which is a drawback with returning tuples: lack of=
=20
inherent documentation.

Note that this pattern was made significantly easier to use with C++11's=20
brace initializers (in the return) and auto (for capturing the result).

This said, I do agree that this thread illustrates an interesting use for=
=20
pack variables.

Someone asked for the type of the "variable" p. Don't we need something=20
like decltype...(p) which returns a type pack for this case:

<... p> =3D something

tuple<decltype...(p)> tup(p...);
=20

Den fredag 11 december 2015 kl. 22:42:37 UTC+1 skrev Jens =C3=85kerblom:
>
> Regarding: "If you unpack, what would be the type of p in <...p>?"
> As "p" isn't a variable as such, it wouldn't be a type. Just like the=20
> identifier "p" in
>
> template <typename... Arg>
> void f(Arg... p);
>
> doesn't have a type in there but represents a collection of variables.
>
> And regarding: "How would I access the individual unpacked components?"
> Just like one cannot directly access the argument of the n:th parameter o=
f=20
> the above parameters, one cannot directly access the n:th variable in <..=
..=20
> p>. However, one could implement the features to support the following:
>
> <x, y, ...p> =3D f();
>
> Then you can access the first 2 parameter with "x" and "y".
>
> An example of how it could be implemented,
>
> void foo(int, float);
>
> <... p> =3D tuple<int, float>(1, 1.0f);
> foo(p...);
>
> would be the same as:
>
> void foo(int, float);
>
> <intValue, floatValue> =3D tuple<int, float>(1, 1.0f);
> foo(intValue, floatValue);
>
> I hope this answers your questions.
>
> On Friday, December 11, 2015 at 9:15:30 PM UTC+2, Ville Voutilainen wrote=
:
>>
>> On 11 December 2015 at 21:04, Jens =C3=85kerblom <akerbl...@gmail.com> w=
rote:=20
>> > After reading through the Structured Bindings proposals P01440 and=20
>> P0151 I=20
>> > feel both of them miss an opportunity to include variadic variables.=
=20
>> The=20
>> > structured bindings proposals would allow you to bind variables as:=20
>> >=20
>> > tuple<T1, T2, T3> f();=20
>> >=20
>> > auto{a,b,c} =3D f(); // P0144R0=20
>> > <a,b,c> =3D f();     // P0151R0=20
>> >=20
>> > I would like to see both proposals extended to include a variable=20
>> amount of=20
>> > identifiers as=20
>> >=20
>> > <T... p> =3D foo();=20
>> >=20
>> > This would create a natural way to unpack a tuple, something that is=
=20
>> not=20
>> > straight forward with the current standard. In short, the extension I=
=20
>> > propose to P0144 and P0151 would allow you to pack and unpack tuples=
=20
>> (or=20
>> > structs) like:=20
>> >=20
>> > // Packing:=20
>> > auto s =3D std::make_tuple(std::forward<Args>(args)...);=20
>> >=20
>> > // Unpacking:=20
>> > <...p> =3D s;     // P0151 most terse version=20
>> > <T... p> =3D s;   // P0151 with implicit auto return value=20
>> > auto{... p} =3Ds; // P0144=20
>> >=20
>> > // Using unpacked values:=20
>> > func(p...);=20
>> > MyType inst(p...);=20
>> >=20
>> > Any feedback appreciated!=20
>>
>> If you unpack, what would be the type of p in <...p>? How would I=20
>> access the individual=20
>> unpacked components?=20
>>
>> Just as a potentially related point; we can already do, with concepts,=
=20
>> the following:=20
>>
>> tuple<int, int> f() {return {};}=20
>> int main()=20
>> {=20
>>     tuple<auto...> x =3D f();=20
>> }=20
>>
>> With that, I can certainly understand the desire to be able to do=20
>> variadic unpacking. I just=20
>> don't yet quite grasp how it would really work.=20
>>
>

--=20

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

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

<div dir=3D"ltr">Circling back to the original problem that at least P0144 =
tries to address we already have a quite good solution for multiple return =
values, return by anonymous struct:<div><br></div><div>struct { double angl=
e; double length; } ToPolar(double x, double y)</div><div>{</div><div>=C2=
=A0 =C2=A0 =C2=A0return { atan2(y, =C2=A0x), hypot(x, y); }</div><div>}</di=
v><div><br></div><div>auto v =3D ToPolar(3.5, 7.7);</div><div><br></div><di=
v>cout &lt;&lt; v.angle &lt;&lt; endl;</div><div><br></div><div><br></div><=
div>While this does not give the exact same result as the proposal or what =
this thread aims at I think it is actually better as the called function ge=
ts to name its return values which is a drawback with returning tuples: lac=
k of inherent documentation.</div><div><br></div><div>Note that this patter=
n was made significantly easier to use with C++11&#39;s brace initializers =
(in the return) and auto (for capturing the result).</div><div><br></div><d=
iv>This said, I do agree that this thread illustrates an interesting use fo=
r pack variables.</div><div><br></div><div>Someone asked for the type of th=
e &quot;variable&quot; p. Don&#39;t we need something like decltype...(p) w=
hich returns a type pack for this case:</div><div><br></div><div>&lt;... p&=
gt; =3D something</div><div><br></div><div>tuple&lt;decltype...(p)&gt; tup(=
p...);</div><div>=C2=A0<br><br>Den fredag 11 december 2015 kl. 22:42:37 UTC=
+1 skrev Jens =C3=85kerblom:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">Regarding: &quot;If you unpack, what would be the type of p =
in &lt;...p&gt;?&quot;<br>As &quot;p&quot; isn&#39;t a variable as such, it=
 wouldn&#39;t be a type. Just like the identifier &quot;p&quot; in<br><br><=
div 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><div><spa=
n style=3D"color:#008">template</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">&lt;</span><span style=3D"color:#008">typename</sp=
an><span style=3D"color:#660">...</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#606">Arg</span><span style=3D"color:#660">&gt;</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#008">void</span=
><span style=3D"color:#000"> f</span><span style=3D"color:#660">(</span><sp=
an style=3D"color:#606">Arg</span><span style=3D"color:#660">...</span><spa=
n style=3D"color:#000"> p</span><span style=3D"color:#660">);</span><span s=
tyle=3D"color:#000"><br></span></div></code></div><br>doesn&#39;t have a ty=
pe in there but represents a collection of variables.<br><br>And regarding:=
 &quot;How would I access the individual
unpacked components?&quot;<br>Just like one cannot directly access the argu=
ment of the n:th parameter of the above parameters, one cannot directly acc=
ess the n:th variable in &lt;... p&gt;. However, one could implement the fe=
atures to support the following:<br><br><div 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><div><span style=3D"color:#008">&lt;x</span=
><span style=3D"color:#000">, </span><span style=3D"color:#606">y</span><sp=
an style=3D"color:#000">, ...</span><span style=3D"color:#606">p</span><spa=
n style=3D"color:#008">&gt;</span><span style=3D"color:#000"> =3D f();<br><=
/span></div></code></div><br>Then you can access the first 2 parameter with=
 &quot;x&quot; and &quot;y&quot;.<br><br>An example of how it could be impl=
emented,<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
"><code><div><span style=3D"color:#008">void</span><span style=3D"color:#00=
0"> foo</span><span style=3D"color:#660">(</span><span style=3D"color:#008"=
>int</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#008">float</span><span style=3D"color:#660">);<=
/span><span style=3D"color:#000"><br><br></span><span style=3D"color:#660">=
&lt;...</span><span style=3D"color:#000"> p</span><span style=3D"color:#660=
">&gt;</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> tuple</span><span style=3D"color:#660=
">&lt;</span><span style=3D"color:#008">int</span><span style=3D"color:#660=
">,</span><span style=3D"color:#000"> </span><span style=3D"color:#008">flo=
at</span><span style=3D"color:#660">&gt;(</span><span style=3D"color:#066">=
1</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#066">1.0f</span><span style=3D"color:#660">);</spa=
n><span style=3D"color:#000"><br>foo</span><span style=3D"color:#660">(</sp=
an><span style=3D"color:#000">p</span><span style=3D"color:#660">...);</spa=
n><span style=3D"color:#000"><br></span></div></code></div><br>would be the=
 same as:<br><br><div style=3D"background-color:rgb(250,250,250);border-col=
or:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-wor=
d"><code><div><span style=3D"color:#008">void</span><span style=3D"color:#0=
00"> foo</span><span style=3D"color:#660">(</span><span style=3D"color:#008=
">int</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> =
</span><span style=3D"color:#008">float</span><span style=3D"color:#660">);=
</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#660"=
>&lt;</span><span style=3D"color:#000">intValue</span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"> floatValue</span><span style=3D"c=
olor:#660">&gt;</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">=3D</span><span style=3D"color:#000"> tuple</span><span style=3D"c=
olor:#660">&lt;</span><span style=3D"color:#008">int</span><span style=3D"c=
olor:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">float</span><span style=3D"color:#660">&gt;(</span><span style=3D"col=
or:#066">1</span><span style=3D"color:#660">,</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#066">1.0f</span><span style=3D"color:#660=
">);</span><span style=3D"color:#000"><br>foo</span><span style=3D"color:#6=
60">(</span><span style=3D"color:#000">intValue</span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"> floatValue</span><span style=3D"c=
olor:#660">);</span><span style=3D"color:#000"><br></span></div></code></di=
v><br>I hope this answers your questions.<br><br>On Friday, December 11, 20=
15 at 9:15:30 PM UTC+2, Ville Voutilainen wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">On 11 December 2015 at 21:04, Jens =C3=85kerblom &lt;<a rel=3D=
"nofollow">akerbl...@gmail.com</a>&gt; wrote:
<br>&gt; After reading through the Structured Bindings proposals P01440 and=
 P0151 I
<br>&gt; feel both of them miss an opportunity to include variadic variable=
s. The
<br>&gt; structured bindings proposals would allow you to bind variables as=
:
<br>&gt;
<br>&gt; tuple&lt;T1, T2, T3&gt; f();
<br>&gt;
<br>&gt; auto{a,b,c} =3D f(); // P0144R0
<br>&gt; &lt;a,b,c&gt; =3D f(); =C2=A0 =C2=A0 // P0151R0
<br>&gt;
<br>&gt; I would like to see both proposals extended to include a variable =
amount of
<br>&gt; identifiers as
<br>&gt;
<br>&gt; &lt;T... p&gt; =3D foo();
<br>&gt;
<br>&gt; This would create a natural way to unpack a tuple, something that =
is not
<br>&gt; straight forward with the current standard. In short, the extensio=
n I
<br>&gt; propose to P0144 and P0151 would allow you to pack and unpack tupl=
es (or
<br>&gt; structs) like:
<br>&gt;
<br>&gt; // Packing:
<br>&gt; auto s =3D std::make_tuple(std::forward&lt;<wbr>Args&gt;(args)...)=
;
<br>&gt;
<br>&gt; // Unpacking:
<br>&gt; &lt;...p&gt; =3D s; =C2=A0 =C2=A0 // P0151 most terse version
<br>&gt; &lt;T... p&gt; =3D s; =C2=A0 // P0151 with implicit auto return va=
lue
<br>&gt; auto{... p} =3Ds; // P0144
<br>&gt;
<br>&gt; // Using unpacked values:
<br>&gt; func(p...);
<br>&gt; MyType inst(p...);
<br>&gt;
<br>&gt; Any feedback appreciated!
<br>
<br>If you unpack, what would be the type of p in &lt;...p&gt;? How would I
<br>access the individual
<br>unpacked components?
<br>
<br>Just as a potentially related point; we can already do, with concepts,
<br>the following:
<br>
<br>tuple&lt;int, int&gt; f() {return {};}
<br>int main()
<br>{
<br>=C2=A0 =C2=A0 tuple&lt;auto...&gt; x =3D f();
<br>}
<br>
<br>With that, I can certainly understand the desire to be able to do
<br>variadic unpacking. I just
<br>don&#39;t yet quite grasp how it would really work.
<br></blockquote></div></blockquote></div></div>

<p></p>

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

------=_Part_2644_400262053.1449880028104--
------=_Part_2643_2036838019.1449880028104--

.

On Fri, Dec 11, 2015 at 1:04 PM, Jens =C3=85kerblom <akerblom.jens@gmail.co=
m> wrote:
>
> // Packing:
> auto s =3D std::make_tuple(std::forward<Args>(args)...);
>
> // Unpacking:
> <...p> =3D s;     // P0151 most terse version
> <T... p> =3D s;   // P0151 with implicit auto return value
> auto{... p} =3Ds; // P0144
>
> // Using unpacked values:
> func(p...);
> MyType inst(p...);

  apply(func, std::move(s));

Seems to work. Not objecting a syntax sugar rather than
`apply` if that's what you want though.

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--=20

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

.

------=_Part_2861_719304079.1449882147560
Content-Type: multipart/alternative;
 boundary="----=_Part_2862_1454179944.1449882147560"

------=_Part_2862_1454179944.1449882147560
Content-Type: text/plain; charset=UTF-8

If you're going to go that far and introduce the ability to create
parameter packs this easily, then... why bother with tuples at all? Just
cut out the middle man and have `foo` return a parameter pack:

auto... x = foo();
bar(x...);
zed(x)...;

Then add the ability to broadcast a pack to variables:

auto... x = foo(); //Intermediate storage
auto{a, b, c} = x;

auto{g, e, f} = foo(); //Direct broadcast

Once you start getting the ability to create parameter packs, it becomes
very difficult to justify why you need that tuple there at all. It's silly
to construct an object, copy/move stuff into it, then build a parameter
pack (which is not an object) for its values, when you could just return a
parameter pack itself.

You'd need some special syntax for returning a pack of course. But other
than that, it's so much cleaner and simpler than throwing std::tuple
objects around.

That's not to say that the ability to broadcast tuple contents to variables
wouldn't be useful on top of it. But it wouldn't exactly be the main
feature.

--

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

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

<div dir=3D"ltr">If you&#39;re going to go that far and introduce the abili=
ty to create parameter packs this easily, then... why bother with tuples at=
 all? Just cut out the middle man and have `foo` return a parameter pack:<b=
r><br><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"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>bar</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">...);</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>zed</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)...;</span></div>=
</code></div><br>Then add the ability to broadcast a pack to variables:<br>=
<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250=
); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px=
; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">//Intermediate storage</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"co=
lor: #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"sty=
led-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">au=
to</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">g</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> e</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//Direct broadcast</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></c=
ode></div><br>Once you start getting the ability to create parameter packs,=
 it becomes very difficult to justify why you need that tuple there at all.=
 It&#39;s silly to construct an object, copy/move stuff into it, then build=
 a parameter pack (which is not an object) for its values, when you could j=
ust return a parameter pack itself.<br><br>You&#39;d need some special synt=
ax for returning a pack of course. But other than that, it&#39;s so much cl=
eaner and simpler than throwing std::tuple objects around.<br><br>That&#39;=
s not to say that the ability to broadcast tuple contents to variables woul=
dn&#39;t be useful on top of it. But it wouldn&#39;t exactly be the main fe=
ature.<br></div>

<p></p>

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

------=_Part_2862_1454179944.1449882147560--
------=_Part_2861_719304079.1449882147560--

.

------=_Part_2897_233850422.1449924652043
Content-Type: multipart/alternative;
 boundary="----=_Part_2898_100882630.1449924652043"

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

I totally agree, Nicol. I would like packs to be more of first class=20
citizens, seeing std::tuple as a intermediate solution for not having this=
=20
built in. I don't like the idea of connecting std::tuple to language=20
features as suggested by P0144R0 at all. We don't need more=20
std::initializer_list magic.

I would add to your examples that if foo() is a template function it could=
=20
return different number of things depending on its parameter types or=20
counts. I don't see this as in any way compromizing your suggestion other=
=20
than of course that there will be compile time errors if at auto{a, b, c} =
=3D
 x; the pack x doesn't contain 3 values.

An example of such a function:

template<typename... Ts> Ts... double_all(Ts... values) { return { values *=
=20
2... }; }      // Unsure if this type of pack expansion works today, but it=
=20
should anyway.

auto... doubled =3D double_all(3.0, 1, 4.5f);

Note that while the return type specification above looks innocent and=20
logical enough it is very limited as written. How would we define a plain=
=20
function just returning a pack of int, float without having a pack to=20
expand?
I would like type packs as well as value packs to have some syntax that can=
=20
be used to create them. Problem is that we only have so many types of=20
parentheses to choose from and they are all heavily overloaded already,=20
making both parsing and understanding difficult. Here is at least a try:

A type pack literal:

typename...<int, float, double>

A variable pack literal of values of one type:
int...<1,2,3>  or maybe int.../1, 2, 3) or int...{1,2,3}

A variable pack of different types:
auto...{2, 3.4, "hello"}

So a function returning an int and a bool would be declared:

typename...<int, bool> MyFunc() { return { 3, true }; }    =20

Why is this return allowed? I think due to the same rule as today: There is=
=20
an implied type name, in this case the full thing is: typename...<int,=20
bool> { 3, true }. This still requires a rule that a pack can be=20
initialized from a brace init list, but that seems only logical.


Den l=C3=B6rdag 12 december 2015 kl. 02:02:27 UTC+1 skrev Nicol Bolas:
>
> If you're going to go that far and introduce the ability to create=20
> parameter packs this easily, then... why bother with tuples at all? Just=
=20
> cut out the middle man and have `foo` return a parameter pack:
>
> auto... x =3D foo();
> bar(x...);
> zed(x)...;
>
> Then add the ability to broadcast a pack to variables:
>
> auto... x =3D foo(); //Intermediate storage
> auto{a, b, c} =3D x;
>
> auto{g, e, f} =3D foo(); //Direct broadcast
>
> Once you start getting the ability to create parameter packs, it becomes=
=20
> very difficult to justify why you need that tuple there at all. It's sill=
y=20
> to construct an object, copy/move stuff into it, then build a parameter=
=20
> pack (which is not an object) for its values, when you could just return =
a=20
> parameter pack itself.
>
> You'd need some special syntax for returning a pack of course. But other=
=20
> than that, it's so much cleaner and simpler than throwing std::tuple=20
> objects around.
>
> That's not to say that the ability to broadcast tuple contents to=20
> variables wouldn't be useful on top of it. But it wouldn't exactly be the=
=20
> main feature.
>

--=20

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

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

<div dir=3D"ltr">I totally agree, Nicol. I would like packs to be more of f=
irst class citizens, seeing std::tuple as a intermediate solution for not h=
aving this built in. I don&#39;t like the idea of connecting std::tuple to =
language features as suggested by P0144R0 at all. We don&#39;t need more st=
d::initializer_list magic.<div><br></div><div>I would add to your examples =
that if foo() is a template function it could return different number of th=
ings depending on its parameter types or counts. I don&#39;t see this as in=
 any way compromizing your suggestion other than of course that there will =
be compile time errors if at=C2=A0<span style=3D"font-family: monospace; co=
lor: rgb(0, 0, 136); background-color: rgb(250, 250, 250);">auto</span><spa=
n style=3D"font-family: monospace; color: rgb(102, 102, 0); background-colo=
r: rgb(250, 250, 250);">{</span><span style=3D"font-family: monospace; colo=
r: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">a</span><span style=
=3D"font-family: monospace; color: rgb(102, 102, 0); background-color: rgb(=
250, 250, 250);">,</span><span style=3D"font-family: monospace; color: rgb(=
0, 0, 0); background-color: rgb(250, 250, 250);">=C2=A0b</span><span style=
=3D"font-family: monospace; color: rgb(102, 102, 0); background-color: rgb(=
250, 250, 250);">,</span><span style=3D"font-family: monospace; color: rgb(=
0, 0, 0); background-color: rgb(250, 250, 250);">=C2=A0c</span><span style=
=3D"font-family: monospace; color: rgb(102, 102, 0); background-color: rgb(=
250, 250, 250);">}</span><span style=3D"font-family: monospace; color: rgb(=
0, 0, 0); background-color: rgb(250, 250, 250);">=C2=A0</span><span style=
=3D"font-family: monospace; color: rgb(102, 102, 0); background-color: rgb(=
250, 250, 250);">=3D</span><span style=3D"font-family: monospace; color: rg=
b(0, 0, 0); background-color: rgb(250, 250, 250);">=C2=A0x</span><span styl=
e=3D"font-family: monospace; color: rgb(102, 102, 0); background-color: rgb=
(250, 250, 250);">;<font size=3D"2"> the pack x doesn&#39;t contain 3 value=
s.</font></span></div><div><br></div><div>An example of such a function:</d=
iv><div><br></div><div>template&lt;typename... Ts&gt; Ts... double_all(Ts..=
.. values) { return { values * 2... }; } =C2=A0 =C2=A0 =C2=A0// Unsure if th=
is type of pack expansion works today, but it should anyway.</div><div><br>=
</div><div>auto... doubled =3D double_all(3.0, 1, 4.5f);</div><div><br></di=
v><div>Note that while the return type specification above looks innocent a=
nd logical enough it is very limited as written. How would we define a plai=
n function just returning a pack of int, float without having a pack to exp=
and?</div><div>I would like type packs as well as value packs to have some =
syntax that can be used to create them. Problem is that we only have so man=
y types of parentheses to choose from and they are all heavily overloaded a=
lready, making both parsing and understanding difficult. Here is at least a=
 try:</div><div><br></div><div>A type pack literal:</div><div><br></div><di=
v>typename...&lt;int, float, double&gt;</div><div><br></div><div>A variable=
 pack literal of values of one type:</div><div>int...&lt;1,2,3&gt; =C2=A0or=
 maybe int.../1, 2, 3) or int...{1,2,3}</div><div><br></div><div>A variable=
 pack of different types:</div><div>auto...{2, 3.4, &quot;hello&quot;}</div=
><div><br></div><div>So a function returning an int and a bool would be dec=
lared:</div><div><br></div><div>typename...&lt;int, bool&gt; MyFunc() { ret=
urn { 3, true }; } =C2=A0 =C2=A0=C2=A0</div><div><br></div><div>Why is this=
 return allowed? I think due to the same rule as today: There is an implied=
 type name, in this case the full thing is: typename...&lt;int, bool&gt; { =
3, true }. This still requires a rule that a pack can be initialized from a=
 brace init list, but that seems only logical.</div><div><br></div><div><br=
></div><div><div>Den l=C3=B6rdag 12 december 2015 kl. 02:02:27 UTC+1 skrev =
Nicol Bolas:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I=
f you&#39;re going to go that far and introduce the ability to create param=
eter packs this easily, then... why bother with tuples at all? Just cut out=
 the middle man and have `foo` return a parameter pack:<br><br><div 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><div><span style=
=3D"color:#008">auto</span><span style=3D"color:#660">...</span><span style=
=3D"color:#000"> x </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> foo</span><span style=3D"color:#660">();</span><span style=
=3D"color:#000"><br>bar</span><span style=3D"color:#660">(</span><span styl=
e=3D"color:#000">x</span><span style=3D"color:#660">...);</span><span style=
=3D"color:#000"><br>zed</span><span style=3D"color:#660">(</span><span styl=
e=3D"color:#000">x</span><span style=3D"color:#660">)...;</span></div></cod=
e></div><br>Then add the ability to broadcast a pack to variables:<br><br><=
div 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><div><spa=
n style=3D"color:#008">auto</span><span style=3D"color:#660">...</span><spa=
n style=3D"color:#000"> x </span><span style=3D"color:#660">=3D</span><span=
 style=3D"color:#000"> foo</span><span style=3D"color:#660">();</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#800">//Intermediate sto=
rage</span><span style=3D"color:#000"><br></span><span style=3D"color:#008"=
>auto</span><span style=3D"color:#660">{</span><span style=3D"color:#000">a=
</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> b</sp=
an><span style=3D"color:#660">,</span><span style=3D"color:#000"> c</span><=
span style=3D"color:#660">}</span><span style=3D"color:#000"> </span><span =
style=3D"color:#660">=3D</span><span style=3D"color:#000"> x</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"><br><br></span><span =
style=3D"color:#008">auto</span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#000">g</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> e</span><span style=3D"color:#660">,</span><span style=3D"=
color:#000"> f</span><span style=3D"color:#660">}</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">=3D</span><span style=3D"color:#=
000"> foo</span><span style=3D"color:#660">();</span><span style=3D"color:#=
000"> </span><span style=3D"color:#800">//Direct broadcast</span><span styl=
e=3D"color:#000"><br></span></div></code></div><br>Once you start getting t=
he ability to create parameter packs, it becomes very difficult to justify =
why you need that tuple there at all. It&#39;s silly to construct an object=
, copy/move stuff into it, then build a parameter pack (which is not an obj=
ect) for its values, when you could just return a parameter pack itself.<br=
><br>You&#39;d need some special syntax for returning a pack of course. But=
 other than that, it&#39;s so much cleaner and simpler than throwing std::t=
uple objects around.<br><br>That&#39;s not to say that the ability to broad=
cast tuple contents to variables wouldn&#39;t be useful on top of it. But i=
t wouldn&#39;t exactly be the main feature.<br></div></blockquote></div></d=
iv></div>

<p></p>

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

------=_Part_2898_100882630.1449924652043--
------=_Part_2897_233850422.1449924652043--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;"><div style=3D"width: 100%; font-size: in=
itial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rg=
b(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"=
><span style=3D"line-height: initial;">&gt; Problem is that we only have so=
 many types of parentheses to choose from and they are all heavily overload=
ed already</span></div><div style=3D"width: 100%; font-size: initial; font-=
family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 12=
5); text-align: initial; background-color: rgb(255, 255, 255);"><span style=
=3D"line-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, 25=
5, 255);"><span style=3D"line-height: initial;">We can make more by combini=
ng characters &nbsp;{: =E2=80=8Eetc</span></div>                           =
                                                                           =
                               <div style=3D"width: 100%; font-size: initia=
l; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31=
, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br=
></div>                                                                    =
                                                                           =
                                                    <div style=3D"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);">Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp=
;Device</div>                                                              =
                                                                           =
                                         <table width=3D"100%" style=3D"bac=
kground-color:white;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" styl=
e=3D"font-size: initial; text-align: initial; background-color: rgb(255, 25=
5, 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-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size=
: 10pt;">  <div><b>From: </b>Bengt Gustafsson</div><div><b>Sent: </b>Saturd=
ay, December 12, 2015 7:50 AM</div><div><b>To: </b>ISO C++ Standard - Futur=
e Proposals</div><div><b>Reply To: </b>std-proposals@isocpp.org</div><div><=
b>Subject: </b>[std-proposals] Re: Structured Bindings with Variadic Templa=
tes</div></div></td></tr></tbody></table><div style=3D"border-style: solid =
none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; fon=
t-size: initial; text-align: initial; background-color: rgb(255, 255, 255);=
"></div><br><div id=3D"_originalContent" style=3D""><div dir=3D"ltr">I tota=
lly agree, Nicol. I would like packs to be more of first class citizens, se=
eing std::tuple as a intermediate solution for not having this built in. I =
don't like the idea of connecting std::tuple to language features as sugges=
ted by P0144R0 at all. We don't need more std::initializer_list magic.<div>=
<br></div><div>I would add to your examples that if foo() is a template fun=
ction it could return different number of things depending on its parameter=
 types or counts. I don't see this as in any way compromizing your suggesti=
on other than of course that there will be compile time errors if at&nbsp;<=
span style=3D"font-family: monospace; color: rgb(0, 0, 136); background-col=
or: rgb(250, 250, 250);">auto</span><span style=3D"font-family: monospace; =
color: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">{</span><sp=
an style=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: =
rgb(250, 250, 250);">a</span><span style=3D"font-family: monospace; color: =
rgb(102, 102, 0); background-color: rgb(250, 250, 250);">,</span><span styl=
e=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: rgb(250=
, 250, 250);">&nbsp;b</span><span style=3D"font-family: monospace; color: r=
gb(102, 102, 0); background-color: rgb(250, 250, 250);">,</span><span style=
=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: rgb(250,=
 250, 250);">&nbsp;c</span><span style=3D"font-family: monospace; color: rg=
b(102, 102, 0); background-color: rgb(250, 250, 250);">}</span><span style=
=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: rgb(250,=
 250, 250);">&nbsp;</span><span style=3D"font-family: monospace; color: rgb=
(102, 102, 0); background-color: rgb(250, 250, 250);">=3D</span><span style=
=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: rgb(250,=
 250, 250);">&nbsp;x</span><span style=3D"font-family: monospace; color: rg=
b(102, 102, 0); background-color: rgb(250, 250, 250);">;<font size=3D"2"> t=
he pack x doesn't contain 3 values.</font></span></div><div><br></div><div>=
An example of such a function:</div><div><br></div><div>template&lt;typenam=
e... Ts&gt; Ts... double_all(Ts... values) { return { values * 2... }; } &n=
bsp; &nbsp; &nbsp;// Unsure if this type of pack expansion works today, but=
 it should anyway.</div><div><br></div><div>auto... doubled =3D double_all(=
3.0, 1, 4.5f);</div><div><br></div><div>Note that while the return type spe=
cification above looks innocent and logical enough it is very limited as wr=
itten. How would we define a plain function just returning a pack of int, f=
loat without having a pack to expand?</div><div>I would like type packs as =
well as value packs to have some syntax that can be used to create them. Pr=
oblem is that we only have so many types of parentheses to choose from and =
they are all heavily overloaded already, making both parsing and understand=
ing difficult. Here is at least a try:</div><div><br></div><div>A type pack=
 literal:</div><div><br></div><div>typename...&lt;int, float, double&gt;</d=
iv><div><br></div><div>A variable pack literal of values of one type:</div>=
<div>int...&lt;1,2,3&gt; &nbsp;or maybe int.../1, 2, 3) or int...{1,2,3}</d=
iv><div><br></div><div>A variable pack of different types:</div><div>auto..=
..{2, 3.4, "hello"}</div><div><br></div><div>So a function returning an int =
and a bool would be declared:</div><div><br></div><div>typename...&lt;int, =
bool&gt; MyFunc() { return { 3, true }; } &nbsp; &nbsp;&nbsp;</div><div><br=
></div><div>Why is this return allowed? I think due to the same rule as tod=
ay: There is an implied type name, in this case the full thing is: typename=
....&lt;int, bool&gt; { 3, true }. This still requires a rule that a pack ca=
n be initialized from a brace init list, but that seems only logical.</div>=
<div><br></div><div><br></div><div><div>Den l=C3=B6rdag 12 december 2015 kl=
.. 02:02:27 UTC+1 skrev Nicol Bolas:<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">If you're going to go that far and introduce the abi=
lity to create parameter packs this easily, then... why bother with tuples =
at all? Just cut out the middle man and have `foo` return a parameter pack:=
<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>=
<div><span style=3D"color:#008">auto</span><span style=3D"color:#660">...</=
span><span style=3D"color:#000"> x </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> foo</span><span style=3D"color:#660">();</s=
pan><span style=3D"color:#000"><br>bar</span><span style=3D"color:#660">(</=
span><span style=3D"color:#000">x</span><span style=3D"color:#660">...);</s=
pan><span style=3D"color:#000"><br>zed</span><span style=3D"color:#660">(</=
span><span style=3D"color:#000">x</span><span style=3D"color:#660">)...;</s=
pan></div></code></div><br>Then add the ability to broadcast a pack to vari=
ables:<br><br><div 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><div><span style=3D"color:#008">auto</span><span style=3D"color:#660"=
>...</span><span style=3D"color:#000"> x </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> foo</span><span style=3D"color:#660">=
();</span><span style=3D"color:#000"> </span><span style=3D"color:#800">//I=
ntermediate storage</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#008">auto</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"> b</span><span style=3D"color:#660">,</span><span style=3D"color=
:#000"> c</span><span style=3D"color:#660">}</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000">=
 x</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=
<br></span><span style=3D"color:#008">auto</span><span style=3D"color:#660"=
>{</span><span style=3D"color:#000">g</span><span style=3D"color:#660">,</s=
pan><span style=3D"color:#000"> e</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> f</span><span style=3D"color:#660">}</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span s=
tyle=3D"color:#000"> foo</span><span style=3D"color:#660">();</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#800">//Direct broadcast</=
span><span style=3D"color:#000"><br></span></div></code></div><br>Once you =
start getting the ability to create parameter packs, it becomes very diffic=
ult to justify why you need that tuple there at all. It's silly to construc=
t an object, copy/move stuff into it, then build a parameter pack (which is=
 not an object) for its values, when you could just return a parameter pack=
 itself.<br><br>You'd need some special syntax for returning a pack of cour=
se. But other than that, it's so much cleaner and simpler than throwing std=
::tuple objects around.<br><br>That's not to say that the ability to broadc=
ast tuple contents to variables wouldn't be useful on top of it. But it wou=
ldn't exactly be the main feature.<br></div></blockquote></div></div></div>

<p></p>

-- <br>
<br>
--- <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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

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

.

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

On 12 December 2015 at 17:45, Tony V E <tvaneerd@gmail.com> wrote:

> > Problem is that we only have so many types of parentheses to choose fro=
m
> and they are all heavily overloaded already
>
> We can make more by combining characters  {: =E2=80=8Eetc
>
>

That sort of ideas have more or less always been laughed out of the court.

--=20

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 12 December 2015 at 17:45, Tony V E <span dir=3D"ltr">&lt;<a href=3D=
"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"background-colo=
r:rgb(255,255,255);line-height:initial" lang=3D"en-US"><span class=3D""><di=
v style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&=
#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgrou=
nd-color:rgb(255,255,255)"><span style=3D"line-height:initial">&gt; Problem=
 is that we only have so many types of parentheses to choose from and they =
are all heavily overloaded already</span></div><div style=3D"width:100%;fon=
t-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-seri=
f;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)=
"><span style=3D"line-height:initial"><br></span></div></span><div style=3D=
"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-=
serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:r=
gb(255,255,255)"><span style=3D"line-height:initial">We can make more by co=
mbining characters =C2=A0{: =E2=80=8Eetc</span></div>=C2=A0</div></blockquo=
te></div><br></div><div class=3D"gmail_extra">That sort of ideas have more =
or less always been laughed out of the court.<br></div></div>

<p></p>

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

--001a1143da6259b66f0526b61457--

.

<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);">So was &lt;insert famous scientist here&gt; when he/she first p=
roposed their theory :-)</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, 255);">&nbs=
p;</div>                                                                   =
                                                                  <div styl=
e=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgro=
und-color: rgb(255, 255, 255);"><br style=3D"display:initial"></div>       =
                                                                           =
                                                                           =
                                      <div style=3D"font-size: initial; fon=
t-family: Calibri, '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;border-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-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <di=
v><b>From: </b>Ville Voutilainen</div><div><b>Sent: </b>Saturday, December =
12, 2015 11:39 AM</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-proposals] Re: Structured Bindings with Variadic Templates</div=
></div></td></tr></tbody></table><div style=3D"border-style: solid none non=
e; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: =
initial; text-align: initial; background-color: rgb(255, 255, 255);"></div>=
<br><div id=3D"_originalContent" style=3D""><div dir=3D"ltr"><br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On 12 December 2015 at 17:4=
5, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" tar=
get=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div style=3D"background-color:rgb(255,255,255);line-height:=
initial" lang=3D"en-US"><span class=3D""><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,255)"><span style=
=3D"line-height:initial">&gt; Problem is that we only have so many types of=
 parentheses to choose from and they are all heavily overloaded already</sp=
an></div><div style=3D"width:100%;font-size:initial;font-family:Calibri,'Sl=
ate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;back=
ground-color:rgb(255,255,255)"><span style=3D"line-height:initial"><br></sp=
an></div></span><div style=3D"width:100%;font-size:initial;font-family:Cali=
bri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initi=
al;background-color:rgb(255,255,255)"><span style=3D"line-height:initial">W=
e can make more by combining characters &nbsp;{: =E2=80=8Eetc</span></div>&=
nbsp;</div></blockquote></div><br></div><div class=3D"gmail_extra">That sor=
t of ideas have more or less always been laughed out of the court.<br></div=
></div>

<p></p>

-- <br>
<br>
--- <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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

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

.

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

On 12 December 2015 at 18:51, Tony V E <tvaneerd@gmail.com> wrote:

> So was <insert famous scientist here> when he/she first proposed their
> theory :-)
>

I don't think scientific theories are equivalent to desperate attempts to
find punctuation
that doesn't clash with existing punctuation.

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 12 December 2015 at 18:51, Tony V E <span dir=3D"ltr">&lt;<a href=3D=
"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"background-colo=
r:rgb(255,255,255);line-height:initial" lang=3D"en-US">                    =
                                                                  <div styl=
e=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,s=
ans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-col=
or:rgb(255,255,255)">So was &lt;insert famous scientist here&gt; when he/sh=
e first proposed their theory :-)</div></div></blockquote><div><br></div><d=
iv>I don&#39;t think scientific theories are equivalent to desperate attemp=
ts to find punctuation<br></div><div>that doesn&#39;t clash with existing p=
unctuation.<br></div></div></div></div>

<p></p>

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

--001a1143f74cc7d5390526b6a885--

.

<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);">Shhhh....</div><div style=3D"width: 100%; font-size: initial; f=
ont-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73=
, 125); text-align: initial; background-color: rgb(255, 255, 255);">You are=
 correct, but reality really spoils my fantasies. </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);"><br style=3D"display:initial"></div>                                  =
                                                                           =
                                                                           =
           <div style=3D"font-size: initial; font-family: Calibri, 'Slate P=
ro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; =
background-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackBer=
ry&nbsp;portable&nbsp;Babbage&nbsp;Device</div>                            =
                                                                           =
                                                                           =
<table width=3D"100%" style=3D"background-color:white;border-spacing:0px;">=
 <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: init=
ial; background-color: rgb(255, 255, 255);">                           <div=
 style=3D"border-style: solid none none; border-top-color: rgb(181, 196, 22=
3); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB A=
lpha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>Ville Voutil=
ainen</div><div><b>Sent: </b>Saturday, December 12, 2015 12:20 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-proposals] Re: =
Structured Bindings with Variadic Templates</div></div></td></tr></tbody></=
table><div style=3D"border-style: solid none none; border-top-color: rgb(18=
6, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initia=
l; background-color: rgb(255, 255, 255);"></div><br><div id=3D"_originalCon=
tent" style=3D""><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On 12 December 2015 at 18:51, Tony V E <span dir=3D"lt=
r">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gma=
il.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"><div style=
=3D"background-color:rgb(255,255,255);line-height:initial" lang=3D"en-US"> =
                                                                           =
          <div style=3D"width:100%;font-size:initial;font-family:Calibri,'S=
late Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;bac=
kground-color:rgb(255,255,255)">So was &lt;insert famous scientist here&gt;=
 when he/she first proposed their theory :-)</div></div></blockquote><div><=
br></div><div>I don't think scientific theories are equivalent to desperate=
 attempts to find punctuation<br></div><div>that doesn't clash with existin=
g punctuation.<br></div></div></div></div>

<p></p>

-- <br>
<br>
--- <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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

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

.

------=_Part_3351_172969210.1449941248026
Content-Type: multipart/alternative;
 boundary="----=_Part_3352_1792490907.1449941248026"

------=_Part_3352_1792490907.1449941248026
Content-Type: text/plain; charset=UTF-8

On Saturday, December 12, 2015 at 12:20:43 PM UTC-5, Ville Voutilainen
wrote:
>
> On 12 December 2015 at 18:51, Tony V E <tvan...@gmail.com <javascript:>>
> wrote:
>
>> So was <insert famous scientist here> when he/she first proposed their
>> theory :-)
>>
>
> I don't think scientific theories are equivalent to desperate attempts to
> find punctuation
> that doesn't clash with existing punctuation.
>

It's so sad that P0151R0 and Concepts TS's terse template syntax can't
switch places. Using <> as a template inducer makes much more sense than
{}, while using {} to declare and initialize variables fits right into
braced-init-list syntax.

--

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

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

On Saturday, December 12, 2015 at 12:20:43 PM UTC-5, Ville Voutilainen wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote">On 12 December 2015 at 18:51, Tony V E <span dir=3D"lt=
r">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"i=
_E464oLDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">tvan...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div style=3D"background-color:rgb(255,255,255);line-height:initial" lang=
=3D"en-US">                                                                =
                      <div style=3D"width:100%;font-size:initial;font-famil=
y:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);te=
xt-align:initial;background-color:rgb(255,255,255)">So was &lt;insert famou=
s scientist here&gt; when he/she first proposed their theory :-)</div></div=
></blockquote><div><br></div><div>I don&#39;t think scientific theories are=
 equivalent to desperate attempts to find punctuation<br></div><div>that do=
esn&#39;t clash with existing punctuation.<br></div></div></div></div></blo=
ckquote><div><br>It&#39;s so sad that P0151R0 and Concepts TS&#39;s terse t=
emplate syntax can&#39;t switch places. Using &lt;&gt; as a template induce=
r makes much more sense than {}, while using {} to declare and initialize v=
ariables fits right into braced-init-list syntax.<br></div>

<p></p>

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

------=_Part_3352_1792490907.1449941248026--
------=_Part_3351_172969210.1449941248026--

.

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

Le 12/12/2015 13:50, Bengt Gustafsson a =C3=A9crit :
> I totally agree, Nicol. I would like packs to be more of first class=20
> citizens, seeing std::tuple as a intermediate solution for not having=20
> this built in. I don't like the idea of connecting std::tuple to=20
> language features as suggested by P0144R0 at all. We don't need more=20
> std::initializer_list magic.
>
> I would add to your examples that if foo() is a template function it=20
> could return different number of things depending on its parameter=20
> types or counts. I don't see this as in any way compromizing your=20
> suggestion other than of course that there will be compile time errors=20
> if at auto{a, b, c}=3D x;the pack x doesn't contain 3 values.
>
> An example of such a function:
>
> template<typename... Ts> Ts... double_all(Ts... values) { return {=20
> values * 2... }; }      // Unsure if this type of pack expansion works=20
> today, but it should anyway.
>
> auto... doubled =3D double_all(3.0, 1, 4.5f);
>
> Note that while the return type specification above looks innocent and=20
> logical enough it is very limited as written. How would we define a=20
> plain function just returning a pack of int, float without having a=20
> pack to expand?
> I would like type packs as well as value packs to have some syntax=20
> that can be used to create them. Problem is that we only have so many=20
> types of parentheses to choose from and they are all heavily=20
> overloaded already, making both parsing and understanding difficult.=20
> Here is at least a try:
>
> A type pack literal:
>
> typename...<int, float, double>

We have almost something like that in the language already

     struct {int a; float b; double c;}

We just need to don't provide the fields

     struct {int; float; double;}

>
> A variable pack literal of values of one type:
> int...<1,2,3>  or maybe int.../1, 2, 3) or int...{1,2,3}
IMHO {1,2,3} is the best literal we have.
>
> A variable pack of different types:
> auto...{2, 3.4, "hello"}
and the same here

     {2, 3.4, "hello"}
>
> So a function returning an int and a bool would be declared:
>
> typename...<int, bool> MyFunc() { return { 3, true }; }
     struct {int, bool} MyFunct() { return { 3, true };}
>
> Why is this return allowed? I think due to the same rule as today:=20
> There is an implied type name, in this case the full thing is:=20
> typename...<int, bool> { 3, true }. This still requires a rule that a=20
> pack can be initialized from a brace init list, but that seems only=20
> logical.
Agreed.

If we adopt POD struct without field names, the compiler generates the=20
tuple_size, tuple_element traits and the get<I> accessor and the=20
following fold expression is valid

     Ts; ...

then a tuple could be defined as

     template <class ... TS>
     struct tuple {
         Ts; ...
     };


Now the structural bindings wouldn't be any more specific for tuple, but=20
generic for any POD struct.

In addition to auto meaning deduce the POD name, I propose to support=20
also (if the syntax is not ambiguous) the use of the POD type name


struct mystruct { int i; string s; double d; };
mystruct s =3D { 1, =E2=80=9Cxyzzy=E2=80=9Ds, 3.14 };
auto {x,y,z} =3D s; // valid as for pO144
mystruct {x,y,z} =3D s; // my generic proposal


The above function

template<typename... Ts>
tuple<Ts...> double_all(Ts... values) { return { values * 2... }; }

auto doubled =3D double_all(3.0, 1, 4.5f);

or

tuple {x,y,z} =3D double_all(3.0, 1, 4.5f);

This doesn't requires any change in parameter packs and avoid the=20
question of what is the meaning of ...double.

Best,
Vicente
>
>
> Den l=C3=B6rdag 12 december 2015 kl. 02:02:27 UTC+1 skrev Nicol Bolas:
>
>     If you're going to go that far and introduce the ability to create
>     parameter packs this easily, then... why bother with tuples at
>     all? Just cut out the middle man and have `foo` return a parameter
>     pack:
>
>     |
>     auto...x =3Dfoo();
>     bar(x...);
>     zed(x)...;
>     |
>
>     Then add the ability to broadcast a pack to variables:
>
>     |
>     auto...x =3Dfoo();//Intermediate storage
>     auto{a,b,c}=3Dx;
>
>     auto{g,e,f}=3Dfoo();//Direct broadcast
>     |
>
>     Once you start getting the ability to create parameter packs, it
>     becomes very difficult to justify why you need that tuple there at
>     all. It's silly to construct an object, copy/move stuff into it,
>     then build a parameter pack (which is not an object) for its
>     values, when you could just return a parameter pack itself.
>
>     You'd need some special syntax for returning a pack of course. But
>     other than that, it's so much cleaner and simpler than throwing
>     std::tuple objects around.
>
>     That's not to say that the ability to broadcast tuple contents to
>     variables wouldn't be useful on top of it. But it wouldn't exactly
>     be the main feature.
>
>

--=20

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

--------------010507060604040708010606
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 text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 12/12/2015 13:50, Bengt Gustafsson a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:e0fee097-0083-4ae7-aa3c-bbe3d2fb3c6f@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">I totally agree, Nicol. I would like packs to be
        more of first class citizens, seeing std::tuple as a
        intermediate solution for not having this built in. I don't like
        the idea of connecting std::tuple to language features as
        suggested by P0144R0 at all. We don't need more
        std::initializer_list magic.
        <div><br>
        </div>
        <div>I would add to your examples that if foo() is a template
          function it could return different number of things depending
          on its parameter types or counts. I don't see this as in any
          way compromizing your suggestion other than of course that
          there will be compile time errors if at=C2=A0<span
            style=3D"font-family: monospace; color: rgb(0, 0, 136);
            background-color: rgb(250, 250, 250);">auto</span><span
            style=3D"font-family: monospace; color: rgb(102, 102, 0);
            background-color: rgb(250, 250, 250);">{</span><span
            style=3D"font-family: monospace; color: rgb(0, 0, 0);
            background-color: rgb(250, 250, 250);">a</span><span
            style=3D"font-family: monospace; color: rgb(102, 102, 0);
            background-color: rgb(250, 250, 250);">,</span><span
            style=3D"font-family: monospace; color: rgb(0, 0, 0);
            background-color: rgb(250, 250, 250);">=C2=A0b</span><span
            style=3D"font-family: monospace; color: rgb(102, 102, 0);
            background-color: rgb(250, 250, 250);">,</span><span
            style=3D"font-family: monospace; color: rgb(0, 0, 0);
            background-color: rgb(250, 250, 250);">=C2=A0c</span><span
            style=3D"font-family: monospace; color: rgb(102, 102, 0);
            background-color: rgb(250, 250, 250);">}</span><span
            style=3D"font-family: monospace; color: rgb(0, 0, 0);
            background-color: rgb(250, 250, 250);">=C2=A0</span><span
            style=3D"font-family: monospace; color: rgb(102, 102, 0);
            background-color: rgb(250, 250, 250);">=3D</span><span
            style=3D"font-family: monospace; color: rgb(0, 0, 0);
            background-color: rgb(250, 250, 250);">=C2=A0x</span><span
            style=3D"font-family: monospace; color: rgb(102, 102, 0);
            background-color: rgb(250, 250, 250);">;<font size=3D"2"> the
              pack x doesn't contain 3 values.</font></span></div>
        <div><br>
        </div>
        <div>An example of such a function:</div>
        <div><br>
        </div>
        <div>template&lt;typename... Ts&gt; Ts... double_all(Ts...
          values) { return { values * 2... }; } =C2=A0 =C2=A0 =C2=A0// Unsu=
re if this
          type of pack expansion works today, but it should anyway.</div>
        <div><br>
        </div>
        <div>auto... doubled =3D double_all(3.0, 1, 4.5f);</div>
        <div><br>
        </div>
        <div>Note that while the return type specification above looks
          innocent and logical enough it is very limited as written. How
          would we define a plain function just returning a pack of int,
          float without having a pack to expand?</div>
        <div>I would like type packs as well as value packs to have some
          syntax that can be used to create them. Problem is that we
          only have so many types of parentheses to choose from and they
          are all heavily overloaded already, making both parsing and
          understanding difficult. Here is at least a try:</div>
        <div><br>
        </div>
        <div>A type pack literal:</div>
        <div><br>
        </div>
        <div>typename...&lt;int, float, double&gt;</div>
      </div>
    </blockquote>
    <br>
    We have almost something like that in the language already<br>
    <br>
    =C2=A0=C2=A0=C2=A0 struct {int a; float b; double c;}<br>
    <br>
    We just need to don't provide the fields<br>
    <br>
    =C2=A0=C2=A0=C2=A0 struct {int; float; double;}<br>
    <br>
    <blockquote
      cite=3D"mid:e0fee097-0083-4ae7-aa3c-bbe3d2fb3c6f@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>A variable pack literal of values of one type:</div>
        <div>int...&lt;1,2,3&gt; =C2=A0or maybe int.../1, 2, 3) or
          int...{1,2,3}</div>
      </div>
    </blockquote>
    IMHO {1,2,3} is the best literal we have.<br>
    <blockquote
      cite=3D"mid:e0fee097-0083-4ae7-aa3c-bbe3d2fb3c6f@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>A variable pack of different types:</div>
        <div>auto...{2, 3.4, "hello"}</div>
      </div>
    </blockquote>
    and the same here<br>
    <br>
    =C2=A0=C2=A0=C2=A0 {2, 3.4, "hello"}<br>
    <blockquote
      cite=3D"mid:e0fee097-0083-4ae7-aa3c-bbe3d2fb3c6f@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>So a function returning an int and a bool would be
          declared:</div>
        <div><br>
        </div>
        <div>typename...&lt;int, bool&gt; MyFunc() { return { 3, true };
          } =C2=A0 =C2=A0 <br>
        </div>
      </div>
    </blockquote>
    =C2=A0=C2=A0=C2=A0 struct {int, bool} MyFunct() { return { 3, true };}<=
br>
    <blockquote
      cite=3D"mid:e0fee097-0083-4ae7-aa3c-bbe3d2fb3c6f@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>Why is this return allowed? I think due to the same rule as
          today: There is an implied type name, in this case the full
          thing is: typename...&lt;int, bool&gt; { 3, true }. This still
          requires a rule that a pack can be initialized from a brace
          init list, but that seems only logical.</div>
      </div>
    </blockquote>
    Agreed.<br>
    <br>
    If we adopt POD struct without field names, the compiler generates
    the tuple_size, tuple_element traits and the get&lt;I&gt; accessor
    and the following fold expression is valid<br>
    <br>
    =C2=A0=C2=A0=C2=A0 Ts; ...<br>
    <br>
    then a tuple could be defined as<br>
    <br>
    =C2=A0=C2=A0=C2=A0 template &lt;class ... TS&gt;<br>
    =C2=A0=C2=A0=C2=A0 struct tuple {<br>
    =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Ts; ...<br>
    =C2=A0=C2=A0=C2=A0 };<br>
    <br>
    <br>
    Now the structural bindings wouldn't be any more specific for tuple,
    but generic for any POD struct. <br>
    <br>
    In addition to auto meaning deduce the POD name, I propose to
    support also (if the syntax is not ambiguous) the use of the POD
    type name<br>
    <br>
    <br>
    <t1,t2,t3>struct mystruct { int i; string s; double d; }; <br>
      mystruct s =3D { 1, =E2=80=9Cxyzzy=E2=80=9Ds, 3.14 }; <br>
      auto {x,y,z} =3D s; // valid as for pO144<br>
    </t1,t2,t3>mystruct {x,y,z} =3D s; // my generic proposal<br>
    <br>
    <br>
    The above function<br>
    <br>
    <div>template&lt;typename... Ts&gt; <br>
      tuple&lt;Ts...&gt; double_all(Ts... values) { return { values *
      2... }; }=C2=A0 <br>
    </div>
    <br>
    <div>auto doubled =3D double_all(3.0, 1, 4.5f);<br>
      <br>
      or<br>
      <br>
      tuple {x,y,z} =3D double_all(3.0, 1, 4.5f);<br>
      <br>
      This doesn't requires any change in parameter packs and avoid the
      question of what is the meaning of ...double.<br>
      <br>
      Best,<br>
      Vicente<br>
    </div>
    <blockquote
      cite=3D"mid:e0fee097-0083-4ae7-aa3c-bbe3d2fb3c6f@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div><br>
        </div>
        <div>
          <div>Den l=C3=B6rdag 12 december 2015 kl. 02:02:27 UTC+1 skrev
            Nicol Bolas:
            <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">If you're going to go that far and
                introduce the ability to create parameter packs this
                easily, then... why bother with tuples at all? Just cut
                out the middle man and have `foo` return a parameter
                pack:<br>
                <br>
                <div
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px;word-wrap:break-word"><code>
                    <div><span style=3D"color:#008">auto</span><span
                        style=3D"color:#660">...</span><span
                        style=3D"color:#000"> x </span><span
                        style=3D"color:#660">=3D</span><span
                        style=3D"color:#000"> foo</span><span
                        style=3D"color:#660">();</span><span
                        style=3D"color:#000"><br>
                        bar</span><span style=3D"color:#660">(</span><span
                        style=3D"color:#000">x</span><span
                        style=3D"color:#660">...);</span><span
                        style=3D"color:#000"><br>
                        zed</span><span style=3D"color:#660">(</span><span
                        style=3D"color:#000">x</span><span
                        style=3D"color:#660">)...;</span></div>
                  </code></div>
                <br>
                Then add the ability to broadcast a pack to variables:<br>
                <br>
                <div
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px;word-wrap:break-word"><code>
                    <div><span style=3D"color:#008">auto</span><span
                        style=3D"color:#660">...</span><span
                        style=3D"color:#000"> x </span><span
                        style=3D"color:#660">=3D</span><span
                        style=3D"color:#000"> foo</span><span
                        style=3D"color:#660">();</span><span
                        style=3D"color:#000"> </span><span
                        style=3D"color:#800">//Intermediate storage</span><=
span
                        style=3D"color:#000"><br>
                      </span><span style=3D"color:#008">auto</span><span
                        style=3D"color:#660">{</span><span
                        style=3D"color:#000">a</span><span
                        style=3D"color:#660">,</span><span
                        style=3D"color:#000"> b</span><span
                        style=3D"color:#660">,</span><span
                        style=3D"color:#000"> c</span><span
                        style=3D"color:#660">}</span><span
                        style=3D"color:#000"> </span><span
                        style=3D"color:#660">=3D</span><span
                        style=3D"color:#000"> x</span><span
                        style=3D"color:#660">;</span><span
                        style=3D"color:#000"><br>
                        <br>
                      </span><span style=3D"color:#008">auto</span><span
                        style=3D"color:#660">{</span><span
                        style=3D"color:#000">g</span><span
                        style=3D"color:#660">,</span><span
                        style=3D"color:#000"> e</span><span
                        style=3D"color:#660">,</span><span
                        style=3D"color:#000"> f</span><span
                        style=3D"color:#660">}</span><span
                        style=3D"color:#000"> </span><span
                        style=3D"color:#660">=3D</span><span
                        style=3D"color:#000"> foo</span><span
                        style=3D"color:#660">();</span><span
                        style=3D"color:#000"> </span><span
                        style=3D"color:#800">//Direct broadcast</span><span
                        style=3D"color:#000"><br>
                      </span></div>
                  </code></div>
                <br>
                Once you start getting the ability to create parameter
                packs, it becomes very difficult to justify why you need
                that tuple there at all. It's silly to construct an
                object, copy/move stuff into it, then build a parameter
                pack (which is not an object) for its values, when you
                could just return a parameter pack itself.<br>
                <br>
                You'd need some special syntax for returning a pack of
                course. But other than that, it's so much cleaner and
                simpler than throwing std::tuple objects around.<br>
                <br>
                That's not to say that the ability to broadcast tuple
                contents to variables wouldn't be useful on top of it.
                But it wouldn't exactly be the main feature.<br>
              </div>
            </blockquote>
          </div>
        </div>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>

<p></p>

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

--------------010507060604040708010606--

.

------=_Part_3737_642100098.1449999381423
Content-Type: multipart/alternative;
 boundary="----=_Part_3738_519422421.1449999381424"

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

On Saturday, December 12, 2015 at 11:32:28 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 12/12/2015 13:50, Bengt Gustafsson a =C3=A9crit :
>
> I totally agree, Nicol. I would like packs to be more of first class=20
> citizens, seeing std::tuple as a intermediate solution for not having thi=
s=20
> built in. I don't like the idea of connecting std::tuple to language=20
> features as suggested by P0144R0 at all. We don't need more=20
> std::initializer_list magic.=20
>
> I would add to your examples that if foo() is a template function it coul=
d=20
> return different number of things depending on its parameter types or=20
> counts. I don't see this as in any way compromizing your suggestion other=
=20
> than of course that there will be compile time errors if at auto{a, b, c}=
=20
> =3D x; the pack x doesn't contain 3 values.
>
> An example of such a function:
>
> template<typename... Ts> Ts... double_all(Ts... values) { return { values=
=20
> * 2... }; }      // Unsure if this type of pack expansion works today, bu=
t=20
> it should anyway.
>
> auto... doubled =3D double_all(3.0, 1, 4.5f);
>
> Note that while the return type specification above looks innocent and=20
> logical enough it is very limited as written. How would we define a plain=
=20
> function just returning a pack of int, float without having a pack to=20
> expand?
> I would like type packs as well as value packs to have some syntax that=
=20
> can be used to create them. Problem is that we only have so many types of=
=20
> parentheses to choose from and they are all heavily overloaded already,=
=20
> making both parsing and understanding difficult. Here is at least a try:
>
> A type pack literal:
>
> typename...<int, float, double>
>
>
> We have almost something like that in the language already
>
>     struct {int a; float b; double c;}
>
> We just need to don't provide the fields
>
>     struct {int; float; double;}
>
>
> A variable pack literal of values of one type:
> int...<1,2,3>  or maybe int.../1, 2, 3) or int...{1,2,3}
>
> IMHO {1,2,3} is the best literal we have.
>
>
> A variable pack of different types:
> auto...{2, 3.4, "hello"}
>
> and the same here
>
>     {2, 3.4, "hello"}
>
>
> So a function returning an int and a bool would be declared:
>
> typename...<int, bool> MyFunc() { return { 3, true }; }    =20
>
>     struct {int, bool} MyFunct() { return { 3, true };}
>
>
> Why is this return allowed? I think due to the same rule as today: There=
=20
> is an implied type name, in this case the full thing is: typename...<int,=
=20
> bool> { 3, true }. This still requires a rule that a pack can be=20
> initialized from a brace init list, but that seems only logical.
>
> Agreed.
>
> If we adopt POD struct without field names, the compiler generates the=20
> tuple_size, tuple_element traits and the get<I> accessor and the followin=
g=20
> fold expression is valid
>
>     Ts; ...
>
> then a tuple could be defined as
>
>     template <class ... TS>
>     struct tuple {
>         Ts; ...
>     };
>
>
> Now the structural bindings wouldn't be any more specific for tuple, but=
=20
> generic for any POD struct.=20
>
> In addition to auto meaning deduce the POD name, I propose to support als=
o=20
> (if the syntax is not ambiguous) the use of the POD type name
>
>
> struct mystruct { int i; string s; double d; };=20
> mystruct s =3D { 1, =E2=80=9Cxyzzy=E2=80=9Ds, 3.14 };=20
> auto {x,y,z} =3D s; // valid as for pO144
> mystruct {x,y,z} =3D s; // my generic proposal
>
>
> The above function
>
> template<typename... Ts>=20
> tuple<Ts...> double_all(Ts... values) { return { values * 2... }; } =20
>
> auto doubled =3D double_all(3.0, 1, 4.5f);
>
> or
>
> tuple {x,y,z} =3D double_all(3.0, 1, 4.5f);
>
> This doesn't requires any change in parameter packs and avoid the questio=
n=20
> of what is the meaning of ...double.
>

Except that `Ts; ...` isn't legal code; pack expansions cannot create=20
statements, only a single expression. So it would require changes to=20
parameter packs.

Your idea also seems to miss the point of wanting to be able to create=20
packs. It's not that `tuple` as it currently exists is wrong. It's that=20
it's a *tuple* and not a pack.

Parameter packs have powers that tuples do not, and *should not* have. You=
=20
can expand arbitrary expressions with parameter packs. You can play games=
=20
with function parameters through parameter packs. And so forth.

My main point was that the current structured binding proposals are very=20
focused on a specific use case: breaking down an aggregation type and=20
feeding its values to a sequence of variables to be initialized. But if you=
=20
start adopting what Jens originally suggested, then you're only one step=20
removed from just creating parameter packs. And if you can do that... why=
=20
would you want to deal with tuples and structs and the like at all?

I fail to see how `mystruct{x, y, z}` is an improvement over `auto{x, y,=20
z}`. Indeed, I'm not even sure what it means. After all, do you really care=
=20
if the given expression is of `mystruct` type? No; what you want is to=20
broadcast the three component values to 3 new variables. Just like if you=
=20
do `func({x, y, z})`, you don't need to explicit specify the typename for=
=20
that braced-init-list. Let the compiler figure that out.

Oh, and your `mystruct{x, y, z}` syntax almost certainly runs afoul of=20
uniform initialization syntax. At the very least, it would require the=20
compiler to do some look-ahead to see what the construct actually is. It=20
needs to see a typename followed by an openbrace followed by an identifier=
=20
before it can tell if it's creating a temporary or declaring some variables=
..

--=20

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

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

On Saturday, December 12, 2015 at 11:32:28 PM UTC-5, Vicente J. Botet Escri=
ba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 12/12/2015 13:50, Bengt Gustafsson a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">I totally agree, Nicol. I would like packs to be
        more of first class citizens, seeing std::tuple as a
        intermediate solution for not having this built in. I don&#39;t lik=
e
        the idea of connecting std::tuple to language features as
        suggested by P0144R0 at all. We don&#39;t need more
        std::initializer_list magic.
        <div><br>
        </div>
        <div>I would add to your examples that if foo() is a template
          function it could return different number of things depending
          on its parameter types or counts. I don&#39;t see this as in any
          way compromizing your suggestion other than of course that
          there will be compile time errors if at=C2=A0<span style=3D"font-=
family:monospace;color:rgb(0,0,136);background-color:rgb(250,250,250)">auto=
</span><span style=3D"font-family:monospace;color:rgb(102,102,0);background=
-color:rgb(250,250,250)">{</span><span style=3D"font-family:monospace;color=
:rgb(0,0,0);background-color:rgb(250,250,250)">a</span><span style=3D"font-=
family:monospace;color:rgb(102,102,0);background-color:rgb(250,250,250)">,<=
/span><span style=3D"font-family:monospace;color:rgb(0,0,0);background-colo=
r:rgb(250,250,250)">=C2=A0b</span><span style=3D"font-family:monospace;colo=
r:rgb(102,102,0);background-color:rgb(250,250,250)">,</span><span style=3D"=
font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,250,250)">=
=C2=A0c</span><span style=3D"font-family:monospace;color:rgb(102,102,0);bac=
kground-color:rgb(250,250,250)">}</span><span style=3D"font-family:monospac=
e;color:rgb(0,0,0);background-color:rgb(250,250,250)">=C2=A0</span><span st=
yle=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(250,=
250,250)">=3D</span><span style=3D"font-family:monospace;color:rgb(0,0,0);b=
ackground-color:rgb(250,250,250)">=C2=A0x</span><span style=3D"font-family:=
monospace;color:rgb(102,102,0);background-color:rgb(250,250,250)">;<font si=
ze=3D"2"> the
              pack x doesn&#39;t contain 3 values.</font></span></div>
        <div><br>
        </div>
        <div>An example of such a function:</div>
        <div><br>
        </div>
        <div>template&lt;typename... Ts&gt; Ts... double_all(Ts...
          values) { return { values * 2... }; } =C2=A0 =C2=A0 =C2=A0// Unsu=
re if this
          type of pack expansion works today, but it should anyway.</div>
        <div><br>
        </div>
        <div>auto... doubled =3D double_all(3.0, 1, 4.5f);</div>
        <div><br>
        </div>
        <div>Note that while the return type specification above looks
          innocent and logical enough it is very limited as written. How
          would we define a plain function just returning a pack of int,
          float without having a pack to expand?</div>
        <div>I would like type packs as well as value packs to have some
          syntax that can be used to create them. Problem is that we
          only have so many types of parentheses to choose from and they
          are all heavily overloaded already, making both parsing and
          understanding difficult. Here is at least a try:</div>
        <div><br>
        </div>
        <div>A type pack literal:</div>
        <div><br>
        </div>
        <div>typename...&lt;int, float, double&gt;</div>
      </div>
    </blockquote>
    <br>
    We have almost something like that in the language already<br>
    <br>
    =C2=A0=C2=A0=C2=A0 struct {int a; float b; double c;}<br>
    <br>
    We just need to don&#39;t provide the fields<br>
    <br>
    =C2=A0=C2=A0=C2=A0 struct {int; float; double;}<br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>A variable pack literal of values of one type:</div>
        <div>int...&lt;1,2,3&gt; =C2=A0or maybe int.../1, 2, 3) or
          int...{1,2,3}</div>
      </div>
    </blockquote>
    IMHO {1,2,3} is the best literal we have.<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>A variable pack of different types:</div>
        <div>auto...{2, 3.4, &quot;hello&quot;}</div>
      </div>
    </blockquote>
    and the same here<br>
    <br>
    =C2=A0=C2=A0=C2=A0 {2, 3.4, &quot;hello&quot;}<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>So a function returning an int and a bool would be
          declared:</div>
        <div><br>
        </div>
        <div>typename...&lt;int, bool&gt; MyFunc() { return { 3, true };
          } =C2=A0 =C2=A0 <br>
        </div>
      </div>
    </blockquote>
    =C2=A0=C2=A0=C2=A0 struct {int, bool} MyFunct() { return { 3, true };}<=
br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>Why is this return allowed? I think due to the same rule as
          today: There is an implied type name, in this case the full
          thing is: typename...&lt;int, bool&gt; { 3, true }. This still
          requires a rule that a pack can be initialized from a brace
          init list, but that seems only logical.</div>
      </div>
    </blockquote>
    Agreed.<br>
    <br>
    If we adopt POD struct without field names, the compiler generates
    the tuple_size, tuple_element traits and the get&lt;I&gt; accessor
    and the following fold expression is valid<br>
    <br>
    =C2=A0=C2=A0=C2=A0 Ts; ...<br>
    <br>
    then a tuple could be defined as<br>
    <br>
    =C2=A0=C2=A0=C2=A0 template &lt;class ... TS&gt;<br>
    =C2=A0=C2=A0=C2=A0 struct tuple {<br>
    =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Ts; ...<br>
    =C2=A0=C2=A0=C2=A0 };<br>
    <br>
    <br>
    Now the structural bindings wouldn&#39;t be any more specific for tuple=
,
    but generic for any POD struct. <br>
    <br>
    In addition to auto meaning deduce the POD name, I propose to
    support also (if the syntax is not ambiguous) the use of the POD
    type name<br>
    <br>
    <br>
    struct mystruct { int i; string s; double d; }; <br>
      mystruct s =3D { 1, =E2=80=9Cxyzzy=E2=80=9Ds, 3.14 }; <br>
      auto {x,y,z} =3D s; // valid as for pO144<br>
    mystruct {x,y,z} =3D s; // my generic proposal<br>
    <br>
    <br>
    The above function<br>
    <br>
    <div>template&lt;typename... Ts&gt; <br>
      tuple&lt;Ts...&gt; double_all(Ts... values) { return { values *
      2... }; }=C2=A0 <br>
    </div>
    <br>
    <div>auto doubled =3D double_all(3.0, 1, 4.5f);<br>
      <br>
      or<br>
      <br>
      tuple {x,y,z} =3D double_all(3.0, 1, 4.5f);<br>
      <br>
      This doesn&#39;t requires any change in parameter packs and avoid the
      question of what is the meaning of ...double.<br></div></div></blockq=
uote><div><br>Except that `Ts; ...` isn&#39;t legal code; pack expansions c=
annot create statements, only a single expression. So it would require chan=
ges to parameter packs.<br><br>Your idea also seems to miss the point of wa=
nting to be able to create packs. It&#39;s not that `tuple` as it currently=
 exists is wrong. It&#39;s that it&#39;s a <i>tuple</i> and not a pack.<br>=
<br>Parameter packs have powers that tuples do not, and <i>should not</i> h=
ave. You can expand arbitrary expressions with parameter packs. You can pla=
y games with function parameters through parameter packs. And so forth.<br>=
<br>My main point was that the current structured binding proposals are ver=
y focused on a specific use case: breaking down an aggregation type and fee=
ding its values to a sequence of variables to be initialized. But if you st=
art adopting what Jens originally suggested, then you&#39;re only one step =
removed from just creating parameter packs. And if you can do that... why w=
ould you want to deal with tuples and structs and the like at all?<br><br>I=
 fail to see how `mystruct{x, y, z}` is an improvement over `auto{x, y, z}`=
.. Indeed, I&#39;m not even sure what it means. After all, do you really car=
e if the given expression is of `mystruct` type? No; what you want is to br=
oadcast the three component values to 3 new variables. Just like if you do =
`func({x, y, z})`, you don&#39;t need to explicit specify the typename for =
that braced-init-list. Let the compiler figure that out.<br><br>Oh, and you=
r `mystruct{x, y, z}` syntax almost certainly runs afoul of uniform initial=
ization syntax. At the very least, it would require the compiler to do some=
 look-ahead to see what the construct actually is. It needs to see a typena=
me followed by an openbrace followed by an identifier before it can tell if=
 it&#39;s creating a temporary or declaring some variables.<br></div>

<p></p>

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

------=_Part_3738_519422421.1449999381424--
------=_Part_3737_642100098.1449999381423--

.

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

Le 13/12/2015 10:36, Nicol Bolas a =C3=A9crit :
> On Saturday, December 12, 2015 at 11:32:28 PM UTC-5, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 12/12/2015 13:50, Bengt Gustafsson a =C3=A9crit :
>>     I totally agree, Nicol. I would like packs to be more of first
>>     class citizens, seeing std::tuple as a intermediate solution for
>>     not having this built in. I don't like the idea of connecting
>>     std::tuple to language features as suggested by P0144R0 at all.
>>     We don't need more std::initializer_list magic.
>>
>>     I would add to your examples that if foo() is a template function
>>     it could return different number of things depending on its
>>     parameter types or counts. I don't see this as in any way
>>     compromizing your suggestion other than of course that there will
>>     be compile time errors if at auto{a, b, c}=3D x;the pack x doesn't
>>     contain 3 values.
>>
>>     An example of such a function:
>>
>>     template<typename... Ts> Ts... double_all(Ts... values) { return
>>     { values * 2... }; }      // Unsure if this type of pack
>>     expansion works today, but it should anyway.
>>
>>     auto... doubled =3D double_all(3.0, 1, 4.5f);
>>
>>     Note that while the return type specification above looks
>>     innocent and logical enough it is very limited as written. How
>>     would we define a plain function just returning a pack of int,
>>     float without having a pack to expand?
>>     I would like type packs as well as value packs to have some
>>     syntax that can be used to create them. Problem is that we only
>>     have so many types of parentheses to choose from and they are all
>>     heavily overloaded already, making both parsing and understanding
>>     difficult. Here is at least a try:
>>
>>     A type pack literal:
>>
>>     typename...<int, float, double>
>
>     We have almost something like that in the language already
>
>         struct {int a; float b; double c;}
>
>     We just need to don't provide the fields
>
>         struct {int; float; double;}
>
>>
>>     A variable pack literal of values of one type:
>>     int...<1,2,3>  or maybe int.../1, 2, 3) or int...{1,2,3}
>     IMHO {1,2,3} is the best literal we have.
>>
>>     A variable pack of different types:
>>     auto...{2, 3.4, "hello"}
>     and the same here
>
>         {2, 3.4, "hello"}
>>
>>     So a function returning an int and a bool would be declared:
>>
>>     typename...<int, bool> MyFunc() { return { 3, true }; }
>         struct {int, bool} MyFunct() { return { 3, true };}
>>
>>     Why is this return allowed? I think due to the same rule as
>>     today: There is an implied type name, in this case the full thing
>>     is: typename...<int, bool> { 3, true }. This still requires a
>>     rule that a pack can be initialized from a brace init list, but
>>     that seems only logical.
>     Agreed.
>
>     If we adopt POD struct without field names, the compiler generates
>     the tuple_size, tuple_element traits and the get<I> accessor and
>     the following fold expression is valid
>
>         Ts; ...
>
>     then a tuple could be defined as
>
>         template <class ... TS>
>         struct tuple {
>             Ts; ...
>         };
>
>
>     Now the structural bindings wouldn't be any more specific for
>     tuple, but generic for any POD struct.
>
>     In addition to auto meaning deduce the POD name, I propose to
>     support also (if the syntax is not ambiguous) the use of the POD
>     type name
>
>
>     struct mystruct { int i; string s; double d; };
>     mystruct s =3D { 1, =E2=80=9Cxyzzy=E2=80=9Ds, 3.14 };
>     auto {x,y,z} =3D s; // valid as for pO144
>     mystruct {x,y,z} =3D s; // my generic proposal
>
>
>     The above function
>
>     template<typename... Ts>
>     tuple<Ts...> double_all(Ts... values) { return { values * 2... }; }
>
>     auto doubled =3D double_all(3.0, 1, 4.5f);
>
>     or
>
>     tuple {x,y,z} =3D double_all(3.0, 1, 4.5f);
>
>     This doesn't requires any change in parameter packs and avoid the
>     question of what is the meaning of ...double.
>
>
> Except that `Ts; ...` isn't legal code; pack expansions cannot create=20
> statements, only a single expression. So it would require changes to=20
> parameter packs.
>
This is why I said "I we adopt ....". And yes the sentence contained 3=20
conditions :)
> Your idea also seems to miss the point of wanting to be able to create=20
> packs. It's not that `tuple` as it currently exists is wrong. It's=20
> that it's a /tuple/ and not a pack.
I know. But I want to work with types, not with packs.
>
> Parameter packs have powers that tuples do not, and /should not/ have.=20
> You can expand arbitrary expressions with parameter packs. You can=20
> play games with function parameters through parameter packs. And so forth=
..
And ?
>
> My main point was that the current structured binding proposals are=20
> very focused on a specific use case: breaking down an aggregation type=20
> and feeding its values to a sequence of variables to be initialized.
I was not replaying to your post.
> But if you start adopting what Jens originally suggested, then you're=20
> only one step removed from just creating parameter packs. And if you=20
> can do that... why would you want to deal with tuples and structs and=20
> the like at all?
Because I want to work with types, and a pack is not type :)
And you why do you want to work with parameter packs?
>
> I fail to see how `mystruct{x, y, z}` is an improvement over `auto{x,=20
> y, z}`. Indeed, I'm not even sure what it means. After all, do you=20
> really care if the given expression is of `mystruct` type? No; what=20
> you want is to broadcast the three component values to 3 new=20
> variables. Just like if you do `func({x, y, z})`, you don't need to=20
> explicit specify the typename for that braced-init-list. Let the=20
> compiler figure that out.
I don't need it in this particular case. I will need it when pattern=20
matching variant types.
>
> Oh, and your `mystruct{x, y, z}` syntax almost certainly runs afoul of=20
> uniform initialization syntax. At the very least, it would require the=20
> compiler to do some look-ahead to see what the construct actually is.=20
> It needs to see a typename followed by an openbrace followed by an=20
> identifier before it can tell if it's creating a temporary or=20
> declaring some variables.

This is why I said if the syntax is not ambiguous.

Thanks as always for your constructive comments,
Vicente

--=20

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

--------------000301080407040204050809
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 text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 13/12/2015 10:36, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:61125836-c7ca-4da8-b9b1-d2eaf11eb44b@isocpp.org"
      type=3D"cite">On Saturday, December 12, 2015 at 11:32:28 PM UTC-5,
      Vicente J. Botet Escriba wrote:
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
        <div text=3D"#000000" bgcolor=3D"#FFFFFF">
          <div>Le 12/12/2015 13:50, Bengt Gustafsson a =C3=A9crit=C2=A0:<br=
>
          </div>
          <blockquote type=3D"cite">
            <div dir=3D"ltr">I totally agree, Nicol. I would like packs to
              be more of first class citizens, seeing std::tuple as a
              intermediate solution for not having this built in. I
              don't like the idea of connecting std::tuple to language
              features as suggested by P0144R0 at all. We don't need
              more std::initializer_list magic.
              <div><br>
              </div>
              <div>I would add to your examples that if foo() is a
                template function it could return different number of
                things depending on its parameter types or counts. I
                don't see this as in any way compromizing your
                suggestion other than of course that there will be
                compile time errors if at=C2=A0<span
style=3D"font-family:monospace;color:rgb(0,0,136);background-color:rgb(250,=
250,250)">auto</span><span
style=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(25=
0,250,250)">{</span><span
style=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,25=
0,250)">a</span><span
style=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(25=
0,250,250)">,</span><span
style=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,25=
0,250)">=C2=A0b</span><span
style=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(25=
0,250,250)">,</span><span
style=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,25=
0,250)">=C2=A0c</span><span
style=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(25=
0,250,250)">}</span><span
style=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,25=
0,250)">=C2=A0</span><span
style=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(25=
0,250,250)">=3D</span><span
style=3D"font-family:monospace;color:rgb(0,0,0);background-color:rgb(250,25=
0,250)">=C2=A0x</span><span
style=3D"font-family:monospace;color:rgb(102,102,0);background-color:rgb(25=
0,250,250)">;<font
                    size=3D"2"> the pack x doesn't contain 3 values.</font>=
</span></div>
              <div><br>
              </div>
              <div>An example of such a function:</div>
              <div><br>
              </div>
              <div>template&lt;typename... Ts&gt; Ts... double_all(Ts...
                values) { return { values * 2... }; } =C2=A0 =C2=A0 =C2=A0/=
/ Unsure if
                this type of pack expansion works today, but it should
                anyway.</div>
              <div><br>
              </div>
              <div>auto... doubled =3D double_all(3.0, 1, 4.5f);</div>
              <div><br>
              </div>
              <div>Note that while the return type specification above
                looks innocent and logical enough it is very limited as
                written. How would we define a plain function just
                returning a pack of int, float without having a pack to
                expand?</div>
              <div>I would like type packs as well as value packs to
                have some syntax that can be used to create them.
                Problem is that we only have so many types of
                parentheses to choose from and they are all heavily
                overloaded already, making both parsing and
                understanding difficult. Here is at least a try:</div>
              <div><br>
              </div>
              <div>A type pack literal:</div>
              <div><br>
              </div>
              <div>typename...&lt;int, float, double&gt;</div>
            </div>
          </blockquote>
          <br>
          We have almost something like that in the language already<br>
          <br>
          =C2=A0=C2=A0=C2=A0 struct {int a; float b; double c;}<br>
          <br>
          We just need to don't provide the fields<br>
          <br>
          =C2=A0=C2=A0=C2=A0 struct {int; float; double;}<br>
          <br>
          <blockquote type=3D"cite">
            <div dir=3D"ltr">
              <div><br>
              </div>
              <div>A variable pack literal of values of one type:</div>
              <div>int...&lt;1,2,3&gt; =C2=A0or maybe int.../1, 2, 3) or
                int...{1,2,3}</div>
            </div>
          </blockquote>
          IMHO {1,2,3} is the best literal we have.<br>
          <blockquote type=3D"cite">
            <div dir=3D"ltr">
              <div><br>
              </div>
              <div>A variable pack of different types:</div>
              <div>auto...{2, 3.4, "hello"}</div>
            </div>
          </blockquote>
          and the same here<br>
          <br>
          =C2=A0=C2=A0=C2=A0 {2, 3.4, "hello"}<br>
          <blockquote type=3D"cite">
            <div dir=3D"ltr">
              <div><br>
              </div>
              <div>So a function returning an int and a bool would be
                declared:</div>
              <div><br>
              </div>
              <div>typename...&lt;int, bool&gt; MyFunc() { return { 3,
                true }; } =C2=A0 =C2=A0 <br>
              </div>
            </div>
          </blockquote>
          =C2=A0=C2=A0=C2=A0 struct {int, bool} MyFunct() { return { 3, tru=
e };}<br>
          <blockquote type=3D"cite">
            <div dir=3D"ltr">
              <div><br>
              </div>
              <div>Why is this return allowed? I think due to the same
                rule as today: There is an implied type name, in this
                case the full thing is: typename...&lt;int, bool&gt; {
                3, true }. This still requires a rule that a pack can be
                initialized from a brace init list, but that seems only
                logical.</div>
            </div>
          </blockquote>
          Agreed.<br>
          <br>
          If we adopt POD struct without field names, the compiler
          generates the tuple_size, tuple_element traits and the
          get&lt;I&gt; accessor and the following fold expression is
          valid<br>
          <br>
          =C2=A0=C2=A0=C2=A0 Ts; ...<br>
          <br>
          then a tuple could be defined as<br>
          <br>
          =C2=A0=C2=A0=C2=A0 template &lt;class ... TS&gt;<br>
          =C2=A0=C2=A0=C2=A0 struct tuple {<br>
          =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Ts; ...<br>
          =C2=A0=C2=A0=C2=A0 };<br>
          <br>
          <br>
          Now the structural bindings wouldn't be any more specific for
          tuple, but generic for any POD struct. <br>
          <br>
          In addition to auto meaning deduce the POD name, I propose to
          support also (if the syntax is not ambiguous) the use of the
          POD type name<br>
          <br>
          <br>
          struct mystruct { int i; string s; double d; }; <br>
          mystruct s =3D { 1, =E2=80=9Cxyzzy=E2=80=9Ds, 3.14 }; <br>
          auto {x,y,z} =3D s; // valid as for pO144<br>
          mystruct {x,y,z} =3D s; // my generic proposal<br>
          <br>
          <br>
          The above function<br>
          <br>
          <div>template&lt;typename... Ts&gt; <br>
            tuple&lt;Ts...&gt; double_all(Ts... values) { return {
            values * 2... }; }=C2=A0 <br>
          </div>
          <br>
          <div>auto doubled =3D double_all(3.0, 1, 4.5f);<br>
            <br>
            or<br>
            <br>
            tuple {x,y,z} =3D double_all(3.0, 1, 4.5f);<br>
            <br>
            This doesn't requires any change in parameter packs and
            avoid the question of what is the meaning of ...double.<br>
          </div>
        </div>
      </blockquote>
      <div><br>
        Except that `Ts; ...` isn't legal code; pack expansions cannot
        create statements, only a single expression. So it would require
        changes to parameter packs.<br>
        <br>
      </div>
    </blockquote>
    This is why I said "I we adopt ....". And yes the sentence contained
    3 conditions :)<br>
    <blockquote
      cite=3D"mid:61125836-c7ca-4da8-b9b1-d2eaf11eb44b@isocpp.org"
      type=3D"cite">
      <div>Your idea also seems to miss the point of wanting to be able
        to create packs. It's not that `tuple` as it currently exists is
        wrong. It's that it's a <i>tuple</i> and not a pack.<br>
      </div>
    </blockquote>
    I know. But I want to work with types, not with packs.<br>
    <blockquote
      cite=3D"mid:61125836-c7ca-4da8-b9b1-d2eaf11eb44b@isocpp.org"
      type=3D"cite">
      <div><br>
        Parameter packs have powers that tuples do not, and <i>should
          not</i> have. You can expand arbitrary expressions with
        parameter packs. You can play games with function parameters
        through parameter packs. And so forth.<br>
      </div>
    </blockquote>
    And ?<br>
    <blockquote
      cite=3D"mid:61125836-c7ca-4da8-b9b1-d2eaf11eb44b@isocpp.org"
      type=3D"cite">
      <div><br>
        My main point was that the current structured binding proposals
        are very focused on a specific use case: breaking down an
        aggregation type and feeding its values to a sequence of
        variables to be initialized. </div>
    </blockquote>
    I was not replaying to your post.<br>
    <blockquote
      cite=3D"mid:61125836-c7ca-4da8-b9b1-d2eaf11eb44b@isocpp.org"
      type=3D"cite">
      <div>But if you start adopting what Jens originally suggested,
        then you're only one step removed from just creating parameter
        packs. And if you can do that... why would you want to deal with
        tuples and structs and the like at all?<br>
      </div>
    </blockquote>
    Because I want to work with types, and a pack is not type :)<br>
    And you why do you want to work with parameter packs?<br>
    <blockquote
      cite=3D"mid:61125836-c7ca-4da8-b9b1-d2eaf11eb44b@isocpp.org"
      type=3D"cite">
      <div><br>
        I fail to see how `mystruct{x, y, z}` is an improvement over
        `auto{x, y, z}`. Indeed, I'm not even sure what it means. After
        all, do you really care if the given expression is of `mystruct`
        type? No; what you want is to broadcast the three component
        values to 3 new variables. Just like if you do `func({x, y,
        z})`, you don't need to explicit specify the typename for that
        braced-init-list. Let the compiler figure that out.<br>
      </div>
    </blockquote>
    I don't need it in this particular case. I will need it when pattern
    matching variant types.<br>
    <blockquote
      cite=3D"mid:61125836-c7ca-4da8-b9b1-d2eaf11eb44b@isocpp.org"
      type=3D"cite">
      <div><br>
        Oh, and your `mystruct{x, y, z}` syntax almost certainly runs
        afoul of uniform initialization syntax. At the very least, it
        would require the compiler to do some look-ahead to see what the
        construct actually is. It needs to see a typename followed by an
        openbrace followed by an identifier before it can tell if it's
        creating a temporary or declaring some variables.<br>
      </div>
    </blockquote>
    <br>
    This is why I said if the syntax is not ambiguous.<br>
    <br>
    Thanks as always for your constructive comments,<br>
    Vicente<br>
  </body>
</html>

<p></p>

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

--------------000301080407040204050809--

.

On 2015-12-11 19:50, Zhihao Yuan wrote:
> On Fri, Dec 11, 2015 at 1:04 PM, Jens =C3=85kerblom <akerblom.jens@gmail.=
com> wrote:
>>
>> // Packing:
>> auto s =3D std::make_tuple(std::forward<Args>(args)...);
>>
>> // Unpacking:
>> <...p> =3D s;     // P0151 most terse version
>> <T... p> =3D s;   // P0151 with implicit auto return value
>> auto{... p} =3Ds; // P0144
>>
>> // Using unpacked values:
>> func(p...);
>> MyType inst(p...);
>=20
>   apply(func, std::move(s));
>=20
> Seems to work. Not objecting a syntax sugar rather than
> `apply` if that's what you want though.

I'd still like to see syntactic unpacking, for cases like:

  auto p1 =3D returns_a_pack_1();
  auto p2 =3D returns_a_pack_2();

  use(a, b, ...p1, c, ...p2);

And I'd like to be able to use it on things that aren't necessarily pack
types, also:

  array<float, 2> arr =3D foo();
  auto l =3D std::hypot(...arr);

--=20
Matthew

--=20

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

.

On 2015-12-12 07:50, Bengt Gustafsson wrote:
> I totally agree, Nicol. I would like packs to be more of first class
> citizens, seeing std::tuple as a intermediate solution for not having this
> built in. I don't like the idea of connecting std::tuple to language
> features as suggested by P0144R0 at all. We don't need more
> std::initializer_list magic.

I don't see P0144R0 as connecting language features to std::tuple... I
see it as connecting language features to "things that can be unpacked".
Which... just happens to include std::pair and std::tuple. IMHO, if
P0144R0 were to be accepted, but not in a way that users can create
their own types that can be unpacked (or, better, define unpacking for
types i.e. via appropriate free functions), we'll have done it wrong.

The "magic" happens - necessarily, I think - with respect to C-like
structs. Without introspection, I don't see a way to avoid that. For C++
classes, however, there should be nothing "magical". (In the "best
case", that magic is implicit generation of get<I>(), as mentioned by
Vicente. But it's still magic.)

--
Matthew

--

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

.

------=_Part_5354_1539497660.1450134095143
Content-Type: multipart/alternative;
 boundary="----=_Part_5355_1649427716.1450134095144"

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

Yes, I know I misread the proposal, there is no specific connection to a=20
tuple. Or maybe there is:

For instance in Micrsoft's tuple implementation a recursion causes the data=
=20
to be layed out backwards. What would that yield when unpacking. Not what=
=20
you think:

auto...{ a, b, c } =3D std::tuple<int, float, bool>;  // Error, wrong numbe=
r=20
of members.
auto...{a, b} =3D std::tuple<int, float, bool>;        // No error.
decltype(a) =3D=3D decltype(bool)                         // true
decltype(b) =3D=3D decltype(tuple<int, float>)       // true

So while we're not connected to tuple as such, it is worse: it is connected=
=20
to the implementation of tuple in that particular incarnation of stl.

When it comes to unpacking structs this way it is a bit strange, we already=
=20
have names for the members and now we desperately want to get different=20
names to refer to???

struct X { int a; float b; };

X foo() { return { 1, 2.3 }; }

auto...{b, a} =3D foo();      // Oops...
cout << x.a << x.b << endl;      // Probably wrong...

auto x =3D foo();
cout << x.a << x.b << endl;      // Probably ok

and as icing on the cake we can (today) return by anonymous union:

struct { int a; float b; } foo() { return { 1, 2.3 }; }

auto x =3D foo();

I think this puts the naming in the right place: The function that knows=20
what it returns. Designated brace initializers would make the return=20
statement less error prone, but that's another story.







Den m=C3=A5ndag 14 december 2015 kl. 17:46:09 UTC+1 skrev Matthew Woehlke:
>
> On 2015-12-12 07:50, Bengt Gustafsson wrote:=20
> > I totally agree, Nicol. I would like packs to be more of first class=20
> > citizens, seeing std::tuple as a intermediate solution for not having=
=20
> this=20
> > built in. I don't like the idea of connecting std::tuple to language=20
> > features as suggested by P0144R0 at all. We don't need more=20
> > std::initializer_list magic.=20
>
> I don't see P0144R0 as connecting language features to std::tuple... I=20
> see it as connecting language features to "things that can be unpacked".=
=20
> Which... just happens to include std::pair and std::tuple. IMHO, if=20
> P0144R0 were to be accepted, but not in a way that users can create=20
> their own types that can be unpacked (or, better, define unpacking for=20
> types i.e. via appropriate free functions), we'll have done it wrong.=20
>
> The "magic" happens - necessarily, I think - with respect to C-like=20
> structs. Without introspection, I don't see a way to avoid that. For C++=
=20
> classes, however, there should be nothing "magical". (In the "best=20
> case", that magic is implicit generation of get<I>(), as mentioned by=20
> Vicente. But it's still magic.)=20
>
> --=20
> Matthew=20
>
>

--=20

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

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

<div dir=3D"ltr">Yes, I know I misread the proposal, there is no specific c=
onnection to a tuple. Or maybe there is:<div><br></div><div>For instance in=
 Micrsoft&#39;s tuple implementation a recursion causes the data to be laye=
d out backwards. What would that yield when unpacking. Not what you think:<=
/div><div><br></div><div>auto...{ a, b, c } =3D std::tuple&lt;int, float, b=
ool&gt;; =C2=A0// Error, wrong number of members.</div><div>auto...{a, b} =
=3D std::tuple&lt;int, float, bool&gt;; =C2=A0 =C2=A0 =C2=A0 =C2=A0// No er=
ror.</div><div>decltype(a) =3D=3D decltype(bool) =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // true</div><d=
iv>decltype(b) =3D=3D decltype(tuple&lt;int, float&gt;) =C2=A0 =C2=A0 =C2=
=A0 // true</div><div><br></div><div>So while we&#39;re not connected to tu=
ple as such, it is worse: it is connected to the implementation of tuple in=
 that particular incarnation of stl.</div><div><br></div><div>When it comes=
 to unpacking structs this way it is a bit strange, we already have names f=
or the members and now we desperately want to get different names to refer =
to???</div><div><br></div><div>struct X { int a; float b; };</div><div><br>=
</div><div>X foo() { return { 1, 2.3 }; }</div><div><br></div><div>auto...{=
b, a} =3D foo(); =C2=A0 =C2=A0 =C2=A0// Oops...</div><div>cout &lt;&lt; x.a=
 &lt;&lt; x.b &lt;&lt; endl; =C2=A0 =C2=A0 =C2=A0// Probably wrong...<br></=
div><div><br></div><div>auto x =3D foo();</div><div>cout &lt;&lt; x.a &lt;&=
lt; x.b &lt;&lt; endl; =C2=A0 =C2=A0 =C2=A0// Probably ok</div><div><br></d=
iv><div>and as icing on the cake we can (today) return by anonymous union:<=
/div><div><br></div><div><div>struct { int a; float b; } foo() { return { 1=
, 2.3 }; }</div><div><br></div><div>auto x =3D foo();</div><div><br></div><=
div>I think this puts the naming in the right place: The function that know=
s what it returns. Designated brace initializers would make the return stat=
ement less error prone, but that&#39;s another story.</div><div><br></div><=
div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><=
br>Den m=C3=A5ndag 14 december 2015 kl. 17:46:09 UTC+1 skrev Matthew Woehlk=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On 2015-12-12 07:50, Bengt G=
ustafsson wrote:
<br>&gt; I totally agree, Nicol. I would like packs to be more of first cla=
ss=20
<br>&gt; citizens, seeing std::tuple as a intermediate solution for not hav=
ing this=20
<br>&gt; built in. I don&#39;t like the idea of connecting std::tuple to la=
nguage=20
<br>&gt; features as suggested by P0144R0 at all. We don&#39;t need more=20
<br>&gt; std::initializer_list magic.
<br>
<br>I don&#39;t see P0144R0 as connecting language features to std::tuple..=
.. I
<br>see it as connecting language features to &quot;things that can be unpa=
cked&quot;.
<br>Which... just happens to include std::pair and std::tuple. IMHO, if
<br>P0144R0 were to be accepted, but not in a way that users can create
<br>their own types that can be unpacked (or, better, define unpacking for
<br>types i.e. via appropriate free functions), we&#39;ll have done it wron=
g.
<br>
<br>The &quot;magic&quot; happens - necessarily, I think - with respect to =
C-like
<br>structs. Without introspection, I don&#39;t see a way to avoid that. Fo=
r C++
<br>classes, however, there should be nothing &quot;magical&quot;. (In the =
&quot;best
<br>case&quot;, that magic is implicit generation of get&lt;I&gt;(), as men=
tioned by
<br>Vicente. But it&#39;s still magic.)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></div>

<p></p>

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

------=_Part_5355_1649427716.1450134095144--
------=_Part_5354_1539497660.1450134095143--

.

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

On 14 December 2015 at 17:01, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> Yes, I know I misread the proposal, there is no specific connection to a
> tuple. Or maybe there is:
>
> For instance in Micrsoft's tuple implementation a recursion causes the
> data to be layed out backwards. What would that yield when unpacking. Not
> what you think:
>
> auto...{ a, b, c } = std::tuple<int, float, bool>;  // Error, wrong number
> of members.
> auto...{a, b} = std::tuple<int, float, bool>;        // No error.
> decltype(a) == decltype(bool)                         // true
> decltype(b) == decltype(tuple<int, float>)       // true
>
> So while we're not connected to tuple as such, it is worse: it is
> connected to the implementation of tuple in that particular incarnation of
> stl.
>

So?  We can harden the specification for tuple if need be, and in the case
of Microsoft specifically, they don't mind breaking their ABI on every
release.

I think this puts the naming in the right place: The function that knows
> what it returns.
>

The caller wants better domain-specific names, which cannot necessarily be
provided by the callee, especially for things based on generics.

Take *map.  It is horrible that *map returns a pair for elements, because
"first" and "second" are nondescript.  More horrible is that other
functions (such as insert) return a different type of pair, which leads to
the abomination:

    inserted.first->second

to reference the value.  And if you have a map of structures that contain
maps, even slightly better names like "key" and "value" are insufficient.

In other words, both sides (caller and callee) want to be able to name
things.
--
 Nevin ":-)" Liber  <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>>
+1-847-691-1404

--

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

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

<div dir=3D"ltr">On 14 December 2015 at 17:01, Bengt Gustafsson <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_bl=
ank">bengt.gustafsson@beamways.com</a>&gt;</span> wrote:<br><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=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 dir=3D"ltr">Ye=
s, I know I misread the proposal, there is no specific connection to a tupl=
e. Or maybe there is:<div><br></div><div>For instance in Micrsoft&#39;s tup=
le implementation a recursion causes the data to be layed out backwards. Wh=
at would that yield when unpacking. Not what you think:</div><div><br></div=
><div>auto...{ a, b, c } =3D std::tuple&lt;int, float, bool&gt;; =C2=A0// E=
rror, wrong number of members.</div><div>auto...{a, b} =3D std::tuple&lt;in=
t, float, bool&gt;; =C2=A0 =C2=A0 =C2=A0 =C2=A0// No error.</div><div>declt=
ype(a) =3D=3D decltype(bool) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // true</div><div>decltype(b) =3D=3D=
 decltype(tuple&lt;int, float&gt;) =C2=A0 =C2=A0 =C2=A0 // true</div><div><=
br></div><div>So while we&#39;re not connected to tuple as such, it is wors=
e: it is connected to the implementation of tuple in that particular incarn=
ation of stl.</div></div></blockquote><div><br></div><div>So?=C2=A0 We can =
harden the specification for tuple if need be, and in the case of Microsoft=
 specifically, they don&#39;t mind breaking their ABI on every release.</di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div>I think this p=
uts the naming in the right place: The function that knows what it returns.=
</div></div></div></blockquote><div><br></div><div>The caller wants better =
domain-specific names, which cannot necessarily be provided by the callee, =
especially for things based on generics.</div><div><br></div><div>Take *map=
..=C2=A0 It is horrible that *map returns a pair for elements, because &quot=
;first&quot; and &quot;second&quot; are nondescript.=C2=A0 More horrible is=
 that other functions (such as insert) return a different type of pair, whi=
ch leads to the abomination:</div><div><br></div><div>=C2=A0 =C2=A0 inserte=
d.first-&gt;second</div><div><br></div><div>to reference the value.=C2=A0 A=
nd if you have a map of structures that contain maps, even slightly better =
names like &quot;key&quot; and &quot;value&quot; are insufficient.</div><di=
v><br></div><div>In other words, both sides (caller and callee) want to be =
able to name things.</div></div>-- <br><div class=3D"gmail_signature"><div =
dir=3D"ltr">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@cplusplusguy.com</a>&=
gt;=C2=A0 +1-847-691-1404<br></div></div>
</div></div>

<p></p>

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

--001a113dcb1e30344a0526e41359--

.

--047d7b86d5d03b276f0526ea6208
Content-Type: text/plain; charset=UTF-8

On Fri, Dec 11, 2015 at 8:15 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> Just as a potentially related point; we can already do, with concepts,
> the following:
>
> tuple<int, int> f() {return {};}
> int main()
> {
>     tuple<auto...> x = f();
> }
>
> With that, I can certainly understand the desire to be able to do
> variadic unpacking. I just
> don't yet quite grasp how it would really work.
>
>
I think we are missing some more fundamental pieces wrt to packs.

We can declare a type as a template parameter or as a local typedef:

template<typename T1 t1>
void f() {
  using T2 = something;
}

but we can't do the same with a pack

template<typename T1... t1>
void f() {
  using T2... = something;
}

Basically packs are not yet first-class entities, in the above way and in
other ways.  I think we need to solve that problem first before we worry
about how to integrate them further with the rest of the language.

As for the OP question, there were discussions around P0144/P0151 with
suggestions for a variety of extensions.  I think the best approach is to
get the basic feature shipped, and leave extra bells and whistles as
possible future extensions once we have experience with the basic feature.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 11, 2015 at 8:15 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex">Just as a potentially=
 related point; we can already do, with concepts,<br>
the following:<br>
<br>
tuple&lt;int, int&gt; f() {return {};}<br>
int main()<br>
{<br>
=C2=A0 =C2=A0 tuple&lt;auto...&gt; x =3D f();<br>
}<br>
<br>
With that, I can certainly understand the desire to be able to do<br>
variadic unpacking. I just<br>
don&#39;t yet quite grasp how it would really work.<br>
<div><div><br></div></div></blockquote><div>=C2=A0</div><div>I think we are=
 missing some more fundamental pieces wrt to packs.</div><div><br></div><di=
v>We can declare a type as a template parameter or as a local typedef:</div=
><div><br></div><div>template&lt;typename T1 t1&gt;</div><div>void f() {</d=
iv><div>=C2=A0 using T2 =3D something;</div><div>}</div><div><br></div><div=
>but we can&#39;t do the same with a pack</div><div><br></div><div>template=
&lt;typename T1... t1&gt;</div><div>void f() {</div><div>=C2=A0 using T2...=
 =3D something;</div><div>}</div><div><br></div><div>Basically packs are no=
t yet first-class entities, in the above way and in other ways.=C2=A0 I thi=
nk we need to solve that problem first before we worry about how to integra=
te them further with the rest of the language.</div><div><br></div><div>As =
for the OP question, there were discussions around=C2=A0P0144/P0151 with su=
ggestions for a variety of extensions.=C2=A0 I think the best approach is t=
o get the basic feature shipped, and leave extra bells and whistles as poss=
ible future extensions once we have experience with the basic feature.</div=
><div><br></div></div></div></div>

<p></p>

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

--047d7b86d5d03b276f0526ea6208--

.

On Mon, Dec 14, 2015 at 05:31:00PM -0600, Nevin Liber wrote:
> On 14 December 2015 at 17:01, Bengt Gustafsson <
> bengt.gustafsson@beamways.com> wrote:
>
> I think this puts the naming in the right place: The function that knows
> > what it returns.
>
> The caller wants better domain-specific names, which cannot necessarily be
> provided by the callee, especially for things based on generics.

Agreed, but doing better than inserted.second is a step in the right direction.

> Take *map.  It is horrible that *map returns a pair for elements, because
> "first" and "second" are nondescript.  More horrible is that other
> functions (such as insert) return a different type of pair, which leads to
> the abomination:
>
>     inserted.first->second
>
> to reference the value.  And if you have a map of structures that contain
> maps, even slightly better names like "key" and "value" are insufficient.

But the second horror you describe is addressed by struct return - so now we
have 'inserted.iterator->second'.

The first problem is that sgi_stl::tree never got standardized in spite of it
supporting better names and allowing a saner value_type than std::pair.

/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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-12-14 18:01, Bengt Gustafsson wrote:
> Yes, I know I misread the proposal, there is no specific connection to a
> tuple. Or maybe there is:
>
> For instance in Micrsoft's tuple implementation a recursion causes the data
> to be layed out backwards. What would that yield when unpacking. Not what
> you think:
>
> auto...{ a, b, c } = std::tuple<int, float, bool>;  // Error, wrong number
> of members.
> auto...{a, b} = std::tuple<int, float, bool>;        // No error.
> decltype(a) == decltype(bool)                         // true
> decltype(b) == decltype(tuple<int, float>)       // true

Huh? Do you mean that for t = tuple<int, float, bool>,
decltype(get<0>(t)) == bool, and get<2>(t) is an error? That... would
just be broken. Horribly.

Unpacking I really, really hope uses get<N>() when available, and only
implicit unpacking for C-like structs *for which get<N>() is not defined*.

> When it comes to unpacking structs this way it is a bit strange, we already
> have names for the members and now we desperately want to get different
> names to refer to???
>
> struct X { int a; float b; };

But that's true of std::pair also. Or user types (QPoint is an example I
like to use) that we might also wish to unpack, e.g.:

  auto {x, y} = QPoint(...);

The point of unpacking is that it is shorthand for having to assign the
"pack" to a local and then have additional explicit declarations to
unpack the members. (Especially in e.g. range-based for.)

TBH I could live without unpacking of C-like structs and have unpacking
only for things that have explicit get<N>(). (You can always define
those for something you want to unpack if they aren't already.)

Also TBH, you probably shouldn't use unpacking on something that does
not have an obvious member order. Things like std::pair, std::tuple,
std::array, QPoint (anything like a linear algebra vector, in fact)
qualify. Arbitrary structs... not necessarily.

--
Matthew

--

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

.