------=_Part_25_456577199.1500593844285
Content-Type: multipart/alternative;
 boundary="----=_Part_26_1606967944.1500593844287"

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

Hi,

So I've been reading the past discussions surrounding structured binding.
It is my understanding that due to time constraints the proposal was really=
=20
bare bone and that some possible improvements should be checked in the=20
future.
https://stackoverflow.com/questions/41622896/why-cant-decomposition-declara=
tions-be-constexpr

This got me quite inspired and I'm waiting for some feedback.
*Disclaimer*: Most of them depends on constexpr structured binding.

*I. Declarator specifiers for structured binding *(useful, desirable)

allowing constexpr, static, thread_local specifiers.
if constexpr (constexpr auto[state, value] =3D ...;  state) {}

*II.* initialization from a braced-init-*list *(trivial, one use case)

While reading the old *P0144R0 *(
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0144r0.pdf) the=20
section 3.2 caught my attention.
3.2 Should this syntax support initialization from a braced-init-list?

For example:
auto {x,y,z} =3D {1, =E2=80=9Cxyzzy=E2=80=9Ds, 3.14159}; // NOT proposed We=
 think the answer=20
should be no.

This would be trivial to add, but should be well motivated and we know of n=
o=20
use cases where this offers additional expressive power not already=20
available (and with greater clarity) using individual variable declarations=
..
"

I think I've found a use case. Not a big one, but still
for (auto[x, y, z] =3D {1, "xyzzy"s, 3.14159}; ...; ...) {}

Which would be the same as:
for (auto[x, y, z] =3D std::tuple{1, "xyzzy"s, 3.14159}; ...; ...) {}

But without having to use std::tuple.

*III. Parameter pack through structured binding *(controversial?, useful,=
=20
complex to implement?)

auto[x...] =3D something;

This would allow *std::apply* to be expressed much simpler
template <class F, class Tuple>
constexpr decltype(auto) apply(F&& f, Tuple&& t)
{
    auto&&[values...] =3D std::forward<T>(t);
    return std::invoke(std::forward<F>(f), values...);
}

solving the unresolved function overload issue of *std::apply* by users
template <class... Args> void print(Args... args);

auto[values...] =3D func(...);
print(values...);

making *std::make_index_sequence*'s use much easier
//uses std::make_index_sequence
template <size_t End> constexpr auto make_index_sequence_array() -> std::
array<size_t, End>;

template <size_t From, size_t To, class Tuple>
constexpr auto select_tuple_part(Tuple&& tuple)
{
    using T =3D std::decay_t<Tuple>;
    static_assert(From < To && To < std::tuple_size_v<T> && From < std::
tuple_size_v<T>);
    constexpr auto[I...] =3D make_index_sequence_array<To - From>();
    return std::tuple{std::get<(I+From)...>(tuple)};
}

template <class Tuple>
constexpr auto reverse_tuple(Tuple&& tuple)
{
    using T =3D std::decay_t<Tuple>;
    constexpr size_t len =3D std::tuple_size_v<T>;
    if constexpr (len =3D=3D 0)
       return std::tuple{};
    else
    {
       constexpr auto[I...] =3D make_index_sequence_array<len>();
       return std::tuple{std::get<len - I - 1>(tuple)...};
    }
}

*IV. structured binding in template lists* (controversial, user class=20
non-type parameter, complex, require auto[x...], N3413 is better)

I believe this could solve *N3413*'s mangling issues and member value vs=20
*operator=3D=3D* dilemmas.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html
Disclaimer: It would also require something like nested structured binding=
=20
to be really useful with user types and wouldn't solve the floating point=
=20
non-type template parameter issue.
template<auto[values....]> struct A;

template <class CharT, CharT... Chars> constexpr auto operator""_s() ->=20
std::array<CharT, sizeof...(Chars)>;

A<"Hello"_s> tmp;

*Conclusion*
Thanks for the read and please let me know what you think.

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

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

<div dir=3D"ltr">Hi,<div><br></div><div>So I&#39;ve been reading the past d=
iscussions surrounding structured binding.</div><div>It is my understanding=
 that due to time constraints the proposal was really bare bone and that so=
me possible improvements should be checked in the future.</div><div><a href=
=3D"https://stackoverflow.com/questions/41622896/why-cant-decomposition-dec=
larations-be-constexpr">https://stackoverflow.com/questions/41622896/why-ca=
nt-decomposition-declarations-be-constexpr</a><br></div><div><br></div><div=
>This got me quite inspired and I&#39;m waiting for some feedback.</div><di=
v><b>Disclaimer</b>: Most of them depends on constexpr structured binding.<=
/div><div><font size=3D"4"><b><br></b></font></div><div><font size=3D"4"><b=
>I. Declarator specifiers for structured binding </b>(useful, desirable)</f=
ont></div><div><div><br></div><div>allowing=C2=A0<span class=3D"styled-by-p=
rettify" style=3D"background-color: rgb(250, 250, 250); color: rgb(0, 0, 13=
6);">constexpr</span><span class=3D"styled-by-prettify" style=3D"background=
-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">,</span><span class=
=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250, 250); colo=
r: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"backg=
round-color: rgb(250, 250, 250); color: rgb(0, 0, 136);">static, thread_loc=
al=C2=A0</span><span class=3D"styled-by-prettify" style=3D"background-color=
: rgb(250, 250, 250); color: rgb(0, 0, 0);">specifiers.</span><br></div><di=
v class=3D"prettyprint" style=3D"border-width: 1px; border-style: solid; bo=
rder-color: rgb(187, 187, 187); background-color: rgb(250, 250, 250); word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
state</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> value</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">]</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">...;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> =C2=A0state</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span></div></code></div></div><div><br></div><div><font size=3D"4"><b>II.</=
b><span class=3D"styled-by-prettify" style=3D"font-weight: bold; color: rgb=
(0, 0, 0);">=C2=A0initialization=C2=A0</span><span class=3D"styled-by-prett=
ify" style=3D"font-weight: bold;"><font color=3D"#000000">from</font></span=
><span class=3D"styled-by-prettify" style=3D"font-weight: bold; color: rgb(=
0, 0, 0);">=C2=A0a braced</span><span class=3D"styled-by-prettify" style=3D=
"font-weight: bold; color: rgb(102, 102, 0);">-</span><span class=3D"styled=
-by-prettify" style=3D"font-weight: bold; color: rgb(0, 0, 0);">init</span>=
<span class=3D"styled-by-prettify" style=3D"font-weight: bold; color: rgb(1=
02, 102, 0);">-</span><span class=3D"styled-by-prettify"><b style=3D"color:=
 rgb(0, 0, 0);">list </b><font color=3D"#000000">(trivial, one use case)</f=
ont></span></font></div><div><div><br></div><div>While reading the old=C2=
=A0<b>P0144R0 </b>(<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2015/p0144r0.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2015/p0144r0.pdf</a>) the section 3.2 caught my attention.<br></div><div cl=
ass=3D"prettyprint" style=3D"border-width: 1px; border-style: solid; border=
-color: rgb(187, 187, 187); background-color: rgb(250, 250, 250); word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"font-family: Arial, Helvetica, sans-serif; background-color: r=
gb(255, 255, 255);"><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">3.2</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Should</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">this</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> syntax support initialization <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">from</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> a braced</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">-</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">init</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">-</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">list</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">?</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #606;" class=3D"styled-=
by-prettify">For</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> example</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">:</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: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">y</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">z</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">1</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=
">=E2=80=9C</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>xyzzy</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=E2=
=80=9D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s</s=
pan><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: #066;" class=3D"styled-by-prettify">3.14159</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// NOT proposed We think the answer should be no.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">This</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> would be trivial to=
 add</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> but should be =
well motivated </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">and</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> w=
e know of </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
no</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">use</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> cases </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">where</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">this</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> offers additional expressive power </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">not</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> already available </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">and</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">with</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> greater clarity</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"style=
d-by-prettify">using</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> individual variable declarations</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">.</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">&quot;</span></div></code></div><div><br></div><div=
>I think I&#39;ve found a use case. Not a big one, but still</div><div clas=
s=3D"prettyprint" style=3D"border-width: 1px; border-style: solid; border-c=
olor: rgb(187, 187, 187); background-color: rgb(250, 250, 250); word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #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"style=
d-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> z</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"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">&quot;xyzzy&quot;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">s</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: #0=
66;" class=3D"styled-by-prettify">3.14159</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"style=
d-by-prettify">...;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
....)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{}</span></div>=
</code></div><div><br></div><div>Which would be the same as:</div><div clas=
s=3D"prettyprint" style=3D"border-width: 1px; border-style: solid; border-c=
olor: rgb(187, 187, 187); background-color: rgb(250, 250, 250); word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #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"style=
d-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> z</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"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">tuple</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</s=
pan><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: #080;" class=3D"styled-by-prettify">&quot;xyzzy&quot;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">s</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">3.14159</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-pretti=
fy">...;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">...)</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{}</span></div></code></di=
v><div><br></div><div>But without having to use std::tuple.</div></div><div=
><br></div><div><font size=3D"4"><b>III. Parameter pack through structured =
binding </b>(controversial?, useful, complex to implement?)</font></div><di=
v><font size=3D"4"><br></font></div><div><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">...]</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> something</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span></font></div></code></div><div><br></div><div>This would a=
llow <b>std::apply</b> to be expressed much simpler</div><div class=3D"pret=
typrint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(1=
87, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wor=
d;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><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">class</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> F</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Tuple</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">decltype</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cl=
ass=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-b=
y-prettify"> apply</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">F=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;=
</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 styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Tuple</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #0=
00;" 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"sty=
led-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&amp;&amp;[</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">values</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>...]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">forward</span><span style=3D"color:=
 #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;" class=
=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">t</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">invoke</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">forward</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">F</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">f</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
values</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...)=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div><=
/code></div><div><br></div><div>solving the unresolved function overload is=
sue of <b>std::apply</b>=C2=A0by users</div><div><div class=3D"prettyprint"=
 style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">class</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">A=
rgs</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">print</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><font color=3D"#000000"><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Args</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> args</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">);</span></font><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">[</span><font color=3D"#000000"><span style=3D"color: =
#000;" class=3D"styled-by-prettify">values</span></font><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">...]</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><font color=3D"#000000"><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(...);</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">print</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">values</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">...);</span></font></div></code></div><br>making <b>std::make_index=
_sequence</b>&#39;s use much easier</div><div><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">//uses std::make_index_sequence</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">template</span><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: #000=
;" class=3D"styled-by-prettify">size_t </span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">End</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> make_i=
ndex_sequence_array</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">array</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">size_t</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">End</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>template</span><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: #000;" class=3D"styled-by-prettify">size_t </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">From</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> size_t </span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">To</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"style=
d-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Tuple</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> select_tuple_part</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Tuple</span><font color=3D"#00000=
0"><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> tuple</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span></font><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">using</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> T </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">decay_t</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Tuple</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&gt;;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">static_assert</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">F=
rom</span><font color=3D"#666600"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">To</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">To</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">tuple_size_v</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">From</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">tuple_size_v</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt=
;);</span></font><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </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">I</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">...]</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> make_index_sequence_array</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color:=
 #606;" class=3D"styled-by-prettify">To</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">-</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">From</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;=
();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">tuple</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">get</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">I</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">+</span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>From</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)...&=
gt;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">tuple<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)};</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">template</span><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">class</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Tuple</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">constex=
pr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> reverse_tuple</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Tuple</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> tuple</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">using</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> T </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">decay_t</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Tuple</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&gt;;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> size_t len </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=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">tuple_size_v</span><span style=3D"color:=
 #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;" class=
=3D"styled-by-prettify">&gt;;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">len </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">tuple</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">else</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">I</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">...]</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> make_i=
ndex_sequence_array</span><span style=3D"color: #080;" class=3D"styled-by-p=
rettify">&lt;len&gt;</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">tuple</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">get</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">len </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">-</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> I </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">-</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">tuple</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)...};</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><=
br></div></div><div><b style=3D"font-size: large;">IV. structured binding i=
n template lists</b><font size=3D"4"><b>=C2=A0</b>(controversial, <font fac=
e=3D"arial, sans-serif">user class non-type parameter, complex, require aut=
o[x...], N3413 is better)</font></font></div><font size=3D"2"><br>I believe=
 this could solve <b>N3413</b>&#39;s mangling issues and member value vs=C2=
=A0<b>operator=3D=3D</b> dilemmas.</font><div><font size=3D"2"><a href=3D"h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html">http://w=
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html</a></font></div>=
<div><font size=3D"2">Disclaimer: It would also require something like nest=
ed structured binding to be really useful with user types and wouldn&#39;t=
=C2=A0solve the floating point non-type template parameter issue.<br></font=
><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"></div><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">template</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&lt;</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 class=3D"styled-by-prettify"><font color=3D=
"#000000">values</font></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">....]&gt;=C2=A0</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">struct A;<br><br>template &lt;class CharT, CharT... Chars=
&gt; constexpr auto operator&quot;&quot;_s() -&gt; std::array&lt;CharT, siz=
eof...(Chars)&gt;;<br><br>A&lt;&quot;Hello&quot;_s&gt; tmp;</span></div></c=
ode></div><div><br></div></div><div><font size=3D"4"><b>Conclusion</b></fon=
t></div><div>Thanks for the read and p<font size=3D"2">lease let me know wh=
at you think</font><span style=3D"font-size: large;">.</span></div></div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/312026fa-7dd0-4c5e-939e-1c465dc240cf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/312026fa-7dd0-4c5e-939e-1c465dc240cf=
%40isocpp.org</a>.<br />

------=_Part_26_1606967944.1500593844287--

------=_Part_25_456577199.1500593844285--

.

------=_Part_1054_1178502103.1500596400099
Content-Type: multipart/alternative;
 boundary="----=_Part_1055_467475683.1500596400100"

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

On Thursday, July 20, 2017 at 7:37:24 PM UTC-4, Daemon Snake wrote:
>
> Hi,
>
> So I've been reading the past discussions surrounding structured binding.
> It is my understanding that due to time constraints the proposal was=20
> really bare bone and that some possible improvements should be checked in=
=20
> the future.
>
> https://stackoverflow.com/questions/41622896/why-cant-decomposition-decla=
rations-be-constexpr
>
> This got me quite inspired and I'm waiting for some feedback.
> *Disclaimer*: Most of them depends on constexpr structured binding.
>
> *I. Declarator specifiers for structured binding *(useful, desirable)
>
> allowing constexpr, static, thread_local specifiers.
> if constexpr (constexpr auto[state, value] =3D ...;  state) {}
>
> *II.* initialization from a braced-init-*list *(trivial, one use case)
>
> While reading the old *P0144R0 *(
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0144r0.pdf) the=
=20
> section 3.2 caught my attention.
> 3.2 Should this syntax support initialization from a braced-init-list?
>
> For example:
> auto {x,y,z} =3D {1, =E2=80=9Cxyzzy=E2=80=9Ds, 3.14159}; // NOT proposed =
We think the=20
> answer should be no.
>
> This would be trivial to add, but should be well motivated and we know of=
=20
> no use cases where this offers additional expressive power not already=20
> available (and with greater clarity) using individual variable=20
> declarations."
>
> I think I've found a use case. Not a big one, but still
> for (auto[x, y, z] =3D {1, "xyzzy"s, 3.14159}; ...; ...) {}
>
> Which would be the same as:
> for (auto[x, y, z] =3D std::tuple{1, "xyzzy"s, 3.14159}; ...; ...) {}
>
> But without having to use std::tuple.
>

No.

First, the only reason to want this is to declare multiple variables of=20
different types in places where we currently only allow declaring variables=
=20
of one type. And generally speaking, places where you're doing that have=20
serious constraints on what you can do with those variables.

We really don't need to see bloated `for` and `if` statements.

Second, if we're going to allow this, then it should *not* involve=20
`std::tuple`. We would simply declare that a structured binding statement=
=20
initialized with a braced-init-list simply creates multiple variables with=
=20
types deduced from the appropriate locations in the braced-init-list. We=20
should not needlessly associate a language feature like this with a library=
=20
type.


> *III. Parameter pack through structured binding *(controversial?, useful,=
=20
> complex to implement?)
>

No, we have other proposals dealing with packs.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/50d1d935-03d2-47f7-836e-a8984db9f53d%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, July 20, 2017 at 7:37:24 PM UTC-4, Daemon Sna=
ke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi,<=
div><br></div><div>So I&#39;ve been reading the past discussions surroundin=
g structured binding.</div><div>It is my understanding that due to time con=
straints the proposal was really bare bone and that some possible improveme=
nts should be checked in the future.</div><div><a href=3D"https://stackover=
flow.com/questions/41622896/why-cant-decomposition-declarations-be-constexp=
r" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https=
://www.google.com/url?q\x3dhttps%3A%2F%2Fstackoverflow.com%2Fquestions%2F41=
622896%2Fwhy-cant-decomposition-declarations-be-constexpr\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNHyukP5HQRTwtFiPJQuOPPZS85LXg&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fstack=
overflow.com%2Fquestions%2F41622896%2Fwhy-cant-decomposition-declarations-b=
e-constexpr\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHyukP5HQRTwtFiPJQuOPPZS=
85LXg&#39;;return true;">https://stackoverflow.com/<wbr>questions/41622896/=
why-cant-<wbr>decomposition-declarations-be-<wbr>constexpr</a><br></div><di=
v><br></div><div>This got me quite inspired and I&#39;m waiting for some fe=
edback.</div><div><b>Disclaimer</b>: Most of them depends on constexpr stru=
ctured binding.</div><div><font size=3D"4"><b><br></b></font></div><div><fo=
nt size=3D"4"><b>I. Declarator specifiers for structured binding </b>(usefu=
l, desirable)</font></div><div><div><br></div><div>allowing=C2=A0<span styl=
e=3D"background-color:rgb(250,250,250);color:rgb(0,0,136)">constexpr</span>=
<span style=3D"background-color:rgb(250,250,250);color:rgb(102,102,0)">,</s=
pan><span style=3D"background-color:rgb(250,250,250);color:rgb(0,0,0)"> </s=
pan><span style=3D"background-color:rgb(250,250,250);color:rgb(0,0,136)">st=
atic, thread_local=C2=A0</span><span style=3D"background-color:rgb(250,250,=
250);color:rgb(0,0,0)">specifiers.</span><br></div><div style=3D"border-wid=
th:1px;border-style:solid;border-color:rgb(187,187,187);background-color:rg=
b(250,250,250);word-wrap:break-word"><code><div><span style=3D"color:#008">=
if</span><span style=3D"color:#000"> </span><span style=3D"color:#008">cons=
texpr</span><span style=3D"color:#000"> </span><span style=3D"color:#660">(=
</span><span style=3D"color:#008">constexpr</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">auto</span><span style=3D"color:#660">=
[</span><span style=3D"color:#000">state</span><span style=3D"color:#660">,=
</span><span style=3D"color:#000"> value</span><span style=3D"color:#660">]=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">...;</spa=
n><span style=3D"color:#000"> =C2=A0state</span><span style=3D"color:#660">=
)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{}</s=
pan><span style=3D"color:#000"><br></span></div></code></div></div><div><br=
></div><div><font size=3D"4"><b>II.</b><span style=3D"font-weight:bold;colo=
r:rgb(0,0,0)">=C2=A0initialization=C2=A0</span><span style=3D"font-weight:b=
old"><font color=3D"#000000">from</font></span><span style=3D"font-weight:b=
old;color:rgb(0,0,0)">=C2=A0a braced</span><span style=3D"font-weight:bold;=
color:rgb(102,102,0)">-</span><span style=3D"font-weight:bold;color:rgb(0,0=
,0)">init</span><span style=3D"font-weight:bold;color:rgb(102,102,0)">-</sp=
an><span><b style=3D"color:rgb(0,0,0)">list </b><font color=3D"#000000">(tr=
ivial, one use case)</font></span></font></div><div><div><br></div><div>Whi=
le reading the old=C2=A0<b>P0144R0 </b>(<a href=3D"http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2015/p0144r0.pdf" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A=
%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0144r=
0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG1MKJjnldtN4lm6MvN4r0b6M0ewA&=
#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\=
x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F201=
5%2Fp0144r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG1MKJjnldtN4lm6MvN4=
r0b6M0ewA&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/do=
cs/papers/2015/<wbr>p0144r0.pdf</a>) the section 3.2 caught my attention.<b=
r></div><div style=3D"border-width:1px;border-style:solid;border-color:rgb(=
187,187,187);background-color:rgb(250,250,250);word-wrap:break-word"><code>=
<div><span style=3D"font-family:Arial,Helvetica,sans-serif;background-color=
:rgb(255,255,255)"><span style=3D"color:#066">3.2</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#606">Should</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#008">this</span><span style=3D"color:=
#000"> syntax support initialization </span><span style=3D"color:#008">from=
</span><span style=3D"color:#000"> a braced</span><span style=3D"color:#660=
">-</span><span style=3D"color:#000">init</span><span style=3D"color:#660">=
-</span><span style=3D"color:#000">list</span><span style=3D"color:#660">?<=
/span><span style=3D"color:#000"><br></span></span><span style=3D"color:#00=
0"><br></span><span style=3D"color:#606">For</span><span style=3D"color:#00=
0"> example</span><span style=3D"color:#660">:</span><span style=3D"color:#=
000"><br></span><span style=3D"color:#008">auto</span><span style=3D"color:=
#000"> </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">y</s=
pan><span style=3D"color:#660">,</span><span style=3D"color:#000">z</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"> </span><span sty=
le=3D"color:#660">{</span><span style=3D"color:#066">1</span><span style=3D=
"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">=E2=80=9C</span><span style=3D"color:#000">xyzzy</span><span style=
=3D"color:#660">=E2=80=9D</span><span style=3D"color:#000">s</span><span st=
yle=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">3.14159</span><span style=3D"color:#660">};</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#800">// NOT proposed We thi=
nk the answer should be no.</span><span style=3D"color:#000"><br><br></span=
><span style=3D"color:#606">This</span><span style=3D"color:#000"> would be=
 trivial to add</span><span style=3D"color:#660">,</span><span style=3D"col=
or:#000"> but should be well motivated </span><span style=3D"color:#008">an=
d</span><span style=3D"color:#000"> we know of </span><span style=3D"color:=
#008">no</span><span style=3D"color:#000"> </span><span style=3D"color:#008=
">use</span><span style=3D"color:#000"> cases </span><span style=3D"color:#=
008">where</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
08">this</span><span style=3D"color:#000"> offers additional expressive pow=
er </span><span style=3D"color:#008">not</span><span style=3D"color:#000"> =
already available </span><span style=3D"color:#660">(</span><span style=3D"=
color:#008">and</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#008">with</span><span style=3D"color:#000"> greater clarity</span><span=
 style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#008">using</span><span style=3D"color:#000"> individual variabl=
e declarations</span><span style=3D"color:#660">.</span><span style=3D"colo=
r:#080">&quot;</span></div></code></div><div><br></div><div>I think I&#39;v=
e found a use case. Not a big one, but still</div><div style=3D"border-widt=
h:1px;border-style:solid;border-color:rgb(187,187,187);background-color:rgb=
(250,250,250);word-wrap:break-word"><code><div><span style=3D"color:#008">f=
or</span><span style=3D"color:#000"> </span><span style=3D"color:#660">(</s=
pan><span style=3D"color:#008">auto</span><span style=3D"color:#660">[</spa=
n><span style=3D"color:#000">x</span><span style=3D"color:#660">,</span><sp=
an style=3D"color:#000"> y</span><span style=3D"color:#660">,</span><span s=
tyle=3D"color:#000"> z</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"> </span><span style=3D"color:#660">{</span><span style=3D"colo=
r:#066">1</span><span style=3D"color:#660">,</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#080">&quot;xyzzy&quot;</span><span style=
=3D"color:#000">s</span><span style=3D"color:#660">,</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#066">3.14159</span><span style=3D"=
color:#660">};</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">...;</span><span style=3D"color:#000"> </span><span style=3D"color:=
#660">...)</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">{}</span></div></code></div><div><br></div><div>Which would be the same=
 as:</div><div style=3D"border-width:1px;border-style:solid;border-color:rg=
b(187,187,187);background-color:rgb(250,250,250);word-wrap:break-word"><cod=
e><div><span style=3D"color:#008">for</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#008">auto</spa=
n><span style=3D"color:#660">[</span><span style=3D"color:#000">x</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> y</span><span s=
tyle=3D"color:#660">,</span><span style=3D"color:#000"> z</span><span style=
=3D"color:#660">]</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">=3D</span><span style=3D"color:#000"> std</span><span style=3D"c=
olor:#660">::</span><span style=3D"color:#000">tuple</span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#066">1</span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#080"=
>&quot;xyzzy&quot;</span><span style=3D"color:#000">s</span><span style=3D"=
color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color=
:#066">3.14159</span><span style=3D"color:#660">};</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">...;</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">...)</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">{}</span></div></code></div><div><b=
r></div><div>But without having to use std::tuple.</div></div></div></block=
quote><div><br>No.<br><br>First, the only reason to want this is to declare=
 multiple variables of different types in places where we currently only al=
low declaring variables of one type. And generally speaking, places where y=
ou&#39;re doing that have serious constraints on what you can do with those=
 variables.<br><br>We really don&#39;t need to see bloated `for` and `if` s=
tatements.<br><br>Second, if we&#39;re going to allow this, then it should =
<i>not</i> involve `std::tuple`. We would simply declare that a structured =
binding statement initialized with a braced-init-list simply creates multip=
le variables with types deduced from the appropriate locations in the brace=
d-init-list. We should not needlessly associate a language feature like thi=
s with a library type.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><br></div><div><font size=3D"4"><b>III. Paramet=
er pack through structured binding </b>(controversial?, useful, complex to =
implement?)</font></div></div></blockquote><div><br>No, we have other propo=
sals dealing with packs.</div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/50d1d935-03d2-47f7-836e-a8984db9f53d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/50d1d935-03d2-47f7-836e-a8984db9f53d=
%40isocpp.org</a>.<br />

------=_Part_1055_467475683.1500596400100--

------=_Part_1054_1178502103.1500596400099--

.

------=_Part_981_1847923518.1500600391419
Content-Type: multipart/alternative;
 boundary="----=_Part_982_1851170745.1500600391420"

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

Le vendredi 21 juillet 2017 02:20:00 UTC+2, Nicol Bolas a =C3=A9crit :
>
> Second, if we're going to allow this, then it should *not* involve=20
> `std::tuple`. We would simply declare that a structured binding statement=
=20
> initialized with a braced-init-list simply creates multiple variables wit=
h=20
> types deduced from the appropriate locations in the braced-init-list. We=
=20
> should not needlessly associate a language feature like this with a libra=
ry=20
> type.
>

This compiles, now. It's valid C++.
for (auto[x, y, z] =3D std::tuple{1, "xyzzy"s, 3.14159}; ...; ...) {}

This does not:
for (auto[x, y, z] =3D {1, "xyzzy"s, 3.14159}; ...; ...) {}

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

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

<div dir=3D"ltr">Le vendredi 21 juillet 2017 02:20:00 UTC+2, Nicol Bolas a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>Second, if we&#39;re going to allow this, then it should <i>not</i=
> involve `std::tuple`. We would simply declare that a structured binding s=
tatement initialized with a braced-init-list simply creates multiple variab=
les with types deduced from the appropriate locations in the braced-init-li=
st. We should not needlessly associate a language feature like this with a =
library type.</div></div></blockquote><div><div><br></div><div>This compile=
s, now. It&#39;s valid C++.</div><div style=3D"border-width: 1px; border-st=
yle: solid; border-color: rgb(187, 187, 187); background-color: rgb(250, 25=
0, 250); word-wrap: break-word;"><code><span style=3D"color: rgb(0, 0, 136)=
;">for</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=
=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 136);=
">auto</span><span style=3D"color: rgb(102, 102, 0);">[</span><span style=
=3D"color: rgb(0, 0, 0);">x</span><span style=3D"color: rgb(102, 102, 0);">=
,</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0y</span><span style=3D"c=
olor: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);">=C2=
=A0z</span><span style=3D"color: rgb(102, 102, 0);">]</span><span style=3D"=
color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102, 102, 0);"=
>=3D</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0std</span><span style=
=3D"color: rgb(102, 102, 0);">::</span><span style=3D"color: rgb(0, 0, 0);"=
>tuple</span><span style=3D"color: rgb(102, 102, 0);">{</span><span style=
=3D"color: rgb(0, 102, 102);">1</span><span style=3D"color: rgb(102, 102, 0=
);">,</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=
=3D"color: rgb(0, 136, 0);">&quot;xyzzy&quot;</span><span style=3D"color: r=
gb(0, 0, 0);">s</span><span style=3D"color: rgb(102, 102, 0);">,</span><spa=
n style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(0, =
102, 102);">3.14159</span><span style=3D"color: rgb(102, 102, 0);">};</span=
><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rg=
b(102, 102, 0);">...;</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</sp=
an><span style=3D"color: rgb(102, 102, 0);">...)</span><span style=3D"color=
: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102, 102, 0);">{}</=
span></code></div></div><div><code><span style=3D"color: rgb(102, 102, 0);"=
><br></span></code></div><div><code><span style=3D"color: rgb(102, 102, 0);=
">This does not:</span></code></div><div><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">for</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">auto</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> z</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">1</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: #080;" =
class=3D"styled-by-prettify">&quot;xyzzy&quot;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">s</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">3.14159</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">...;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">...)</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/69545339-ce40-4db2-bb6c-4e279674378a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/69545339-ce40-4db2-bb6c-4e279674378a=
%40isocpp.org</a>.<br />

------=_Part_982_1851170745.1500600391420--

------=_Part_981_1847923518.1500600391419--

.

------=_Part_1121_1580674306.1500602487719
Content-Type: multipart/alternative;
 boundary="----=_Part_1122_871628690.1500602487720"

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

Le vendredi 21 juillet 2017 02:20:00 UTC+2, Nicol Bolas a =C3=A9crit :
>
> No, we have other proposals dealing with packs.
>

     The last one to have a similar impact on the language was P0341R0 in=
=20
2016 and was not well received=20
(https://groups.google.com/a/isocpp.org/forum/#!topic/reflection/KWotU1R0UC=
I),
introduced a lot of grammar changes, new operators, "...x..." syntax, etc..=
..
     The auto[x...] idea would allow more generic structured binding and by=
=20
side effet would allow local variable packs with one grammatical change in=
=20
an isolated context.

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

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

<div dir=3D"ltr">Le vendredi 21 juillet 2017 02:20:00 UTC+2, Nicol Bolas a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>No, we have other proposals dealing with packs.</div></div></block=
quote><div><br></div><div>=C2=A0 =C2=A0 =C2=A0The last one to have a simila=
r impact on the language was=C2=A0P0341R0 in 2016 and was not well received=
 (https://groups.google.com/a/isocpp.org/forum/#!topic/reflection/KWotU1R0U=
CI),</div><div>introduced a lot of grammar changes, new operators, &quot;..=
..x...&quot; syntax, etc...</div><div>=C2=A0 =C2=A0 =C2=A0The=C2=A0<span cla=
ss=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250, 250); co=
lor: rgb(0, 0, 136);">auto</span><span class=3D"styled-by-prettify" style=
=3D"background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">[</span=
><span class=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250=
, 250); color: rgb(0, 0, 0);">x</span><span class=3D"styled-by-prettify" st=
yle=3D"background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">...]=
=C2=A0</span>idea would allow more generic structured binding and by side e=
ffet would allow local variable packs with one grammatical change in an iso=
lated context.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/102fc5ee-cd3b-4757-8464-7254c11efa97%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/102fc5ee-cd3b-4757-8464-7254c11efa97=
%40isocpp.org</a>.<br />

------=_Part_1122_871628690.1500602487720--

------=_Part_1121_1580674306.1500602487719--

.

------=_Part_1181_2146601918.1500609410615
Content-Type: multipart/alternative;
 boundary="----=_Part_1182_1433474604.1500609410616"

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



On Thursday, July 20, 2017 at 9:26:31 PM UTC-4, Daemon Snake wrote:
>
> Le vendredi 21 juillet 2017 02:20:00 UTC+2, Nicol Bolas a =C3=A9crit :
>>
>> Second, if we're going to allow this, then it should *not* involve=20
>> `std::tuple`. We would simply declare that a structured binding statemen=
t=20
>> initialized with a braced-init-list simply creates multiple variables wi=
th=20
>> types deduced from the appropriate locations in the braced-init-list. We=
=20
>> should not needlessly associate a language feature like this with a libr=
ary=20
>> type.
>>
>
> This compiles, now. It's valid C++.
> for (auto[x, y, z] =3D std::tuple{1, "xyzzy"s, 3.14159}; ...; ...) {}
>
> This does not:
> for (auto[x, y, z] =3D {1, "xyzzy"s, 3.14159}; ...; ...) {}
>

Yes, I'm aware of that. I'm not really sure what that's supposed to prove=
=20
though.

My point is that if you're making a language feature, it should *not* be a=
=20
simple shortcut to library stuff if there's a way to do better. And there's=
=20
no reason to have an intermediary `tuple`, so there is a way to do better.

On Thursday, July 20, 2017 at 10:01:27 PM UTC-4, Daemon Snake wrote:
>
> Le vendredi 21 juillet 2017 02:20:00 UTC+2, Nicol Bolas a =C3=A9crit :
>>
>> No, we have other proposals dealing with packs.
>>
>
>      The last one to have a similar impact on the language was P0341R0 in=
=20
> 2016 and was not well received (
> https://groups.google.com/a/isocpp.org/forum/#!topic/reflection/KWotU1R0U=
CI
> ),
>

Nonsense. P0535 <http://wg21.link/P0535> deals with something very similar,=
=20
and the committee didn't seem to dislike it. It doesn't let you name packs,=
=20
but you can use any type that can undergo structured binding as though it=
=20
were a pack. Which is the same thing, only far more powerful.

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

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

<div dir=3D"ltr"><br><br>On Thursday, July 20, 2017 at 9:26:31 PM UTC-4, Da=
emon Snake wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Le vendredi 21 juillet 2017 02:20:00 UTC+2, Nicol Bolas a =C3=A9crit=C2=
=A0:<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>Second, i=
f we&#39;re going to allow this, then it should <i>not</i>
 involve `std::tuple`. We would simply declare that a structured binding
 statement initialized with a braced-init-list simply creates multiple=20
variables with types deduced from the appropriate locations in the=20
braced-init-list. We should not needlessly associate a language feature=20
like this with a library type.</div></div></blockquote><div><div><br></div>=
<div>This compiles, now. It&#39;s valid C++.</div><div style=3D"border-widt=
h:1px;border-style:solid;border-color:rgb(187,187,187);background-color:rgb=
(250,250,250);word-wrap:break-word"><code><span style=3D"color:rgb(0,0,136)=
">for</span><span style=3D"color:rgb(0,0,0)">=C2=A0</span><span style=3D"co=
lor:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,136)">auto</span><=
span style=3D"color:rgb(102,102,0)">[</span><span style=3D"color:rgb(0,0,0)=
">x</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color=
:rgb(0,0,0)">=C2=A0y</span><span style=3D"color:rgb(102,102,0)">,</span><sp=
an style=3D"color:rgb(0,0,0)">=C2=A0z</span><span style=3D"color:rgb(102,10=
2,0)">]</span><span style=3D"color:rgb(0,0,0)">=C2=A0</span><span style=3D"=
color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)">=C2=A0std<=
/span><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rg=
b(0,0,0)">tupl<wbr>e</span><span style=3D"color:rgb(102,102,0)">{</span><sp=
an style=3D"color:rgb(0,102,102)">1</span><span style=3D"color:rgb(102,102,=
0)">,</span><span style=3D"color:rgb(0,0,0)">=C2=A0</span><span style=3D"co=
lor:rgb(0,136,0)">&quot;xyzzy&quot;</span><span style=3D"color:rgb(0,0,0)">=
s</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:r=
gb(0,0,0)">=C2=A0</span><span style=3D"color:rgb(0,102,102)">3.14159</span>=
<span style=3D"color:rgb(102,102,0)">};</span><span style=3D"color:rgb(0,0,=
0)">=C2=A0</span><span style=3D"color:rgb(102,102,0)">...;</span><span styl=
e=3D"color:rgb(0,0,0)">=C2=A0</span><span style=3D"color:rgb(102,102,0)"><w=
br>...)</span><span style=3D"color:rgb(0,0,0)">=C2=A0</span><span style=3D"=
color:rgb(102,102,0)">{}</span></code></div></div><div><code><span style=3D=
"color:rgb(102,102,0)"><br></span></code></div><div><code><span style=3D"co=
lor:rgb(102,102,0)">This does not:</span></code></div><div><div style=3D"ba=
ckground-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"colo=
r:#008">for</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">(</span><span style=3D"color:#008">auto</span><span style=3D"color:#66=
0">[</span><span style=3D"color:#000">x</span><span style=3D"color:#660">,<=
/span><span style=3D"color:#000"> y</span><span style=3D"color:#660">,</spa=
n><span style=3D"color:#000"> z</span><span style=3D"color:#660">]</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span styl=
e=3D"color:#066">1</span><span style=3D"color:#660">,</span><span style=3D"=
color:#000"> </span><span style=3D"color:#080">&quot;xyzzy&quot;</span><spa=
n style=3D"color:#000">s</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#066">3.14159</span><span st=
yle=3D"color:#660">};</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">...;</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">...)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{}</span><span style=3D"color:#000"><br></span></div></code=
></div></div></div></blockquote><br>Yes, I&#39;m aware of that. I&#39;m not=
 really sure what that&#39;s supposed to prove though.<br><br>My point is t=
hat if you&#39;re making a language feature, it should <i>not</i> be a simp=
le shortcut to library stuff if there&#39;s a way to do better. And there&#=
39;s no reason to have an intermediary `tuple`, so there is a way to do bet=
ter.<br><br>On Thursday, July 20, 2017 at 10:01:27 PM UTC-4, Daemon Snake w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Le vendr=
edi 21 juillet 2017 02:20:00 UTC+2, Nicol Bolas a =C3=A9crit=C2=A0:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>No, we have other pro=
posals dealing with packs.</div></div></blockquote><div><br></div><div>=C2=
=A0 =C2=A0 =C2=A0The last one to have a similar impact on the language was=
=C2=A0P0341R0 in 2016 and was not well received (<a href=3D"https://groups.=
google.com/a/isocpp.org/forum/#!topic/reflection/KWotU1R0UCI" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google=
..com/a/isocpp.org/forum/#!topic/reflection/KWotU1R0UCI&#39;;return true;" o=
nclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!t=
opic/reflection/KWotU1R0UCI&#39;;return true;">https://groups.google.com/a/=
<wbr>isocpp.org/forum/#!topic/<wbr>reflection/KWotU1R0UCI</a>),</div></div>=
</blockquote><div><br>Nonsense. <a href=3D"http://wg21.link/P0535">P0535</a=
> deals with something very similar, and the committee didn&#39;t seem to d=
islike it. It doesn&#39;t let you name packs, but you can use any type that=
 can undergo structured binding as though it were a pack. Which is the same=
 thing, only far more powerful.</div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f463e9ed-6a85-4a1d-8525-03e55be146e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f463e9ed-6a85-4a1d-8525-03e55be146e0=
%40isocpp.org</a>.<br />

------=_Part_1182_1433474604.1500609410616--

------=_Part_1181_2146601918.1500609410615--

.

On 2017-07-20 19:37, Daemon Snake wrote:
> *III. Parameter pack through structured binding *(controversial?, useful,
> complex to implement?)
>
> auto[x...] = something;

This was specifically mentioned in http://wg21.link/p0535. The short
version is, I'd rather have generalized unpacking; it tends to cover the
same use cases but without introducing an extra declaration.

> auto[values...] = func(...);
> print(values...);

  auto values = func();
  print([:]values...);

> template <class Tuple>
> constexpr auto reverse_tuple(Tuple&& tuple)

This example is also shown in P0535, albeit expressed differently. I
believe P0535 would also allow an expression nearly identical to yours,
however.

> Disclaimer: It would also require something like nested structured binding
> to be really useful with user types

Nested structured bindings would be nice, but they are syntactically
hard (due to ambiguities with attributes IIRC). There was talk a while
back about allowing nested bindings, and also allowing empty bindings:

  auto [] = acquire_lock(...);

(Hey, look; an anonymous variable!)

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3b4c272b-8393-bc70-d882-91573ce4a3ff%40gmail.com.

.

------=_Part_2273_1365462658.1501280546344
Content-Type: multipart/alternative;
 boundary="----=_Part_2274_1607726418.1501280546345"

------=_Part_2274_1607726418.1501280546345
Content-Type: text/plain; charset="UTF-8"

I Agree.

I only proposed III because I didn't know about P0535.
It's a way more interesting proposal and if I had to choose between the 2,
I would choose P0535.

As for anonymous variables I'm not sure that structured binding would be
the best way to achieve it.
auto [] = acquire_lock(); //not really self evident
auto = acquire_lock();//simpler

A good reason for it tough would be type specification which would be quite
useful for declarative coding.
I'm not quite sure the kind of syntax we would need to use though.
int fd = ...;
scope_exit [] = []() { close(fd); };
....
func_that_may_throw();
....

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

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

<div dir=3D"ltr">I Agree.<div><br></div><div>I only proposed III because I =
didn&#39;t know about P0535.</div><div>It&#39;s a way more interesting prop=
osal and if I had to choose between the 2, I would choose P0535.</div><div>=
<br></div><div>As for anonymous variables I&#39;m not sure that structured =
binding would be the best way to achieve it.<br></div><div class=3D"prettyp=
rint" 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"c=
olor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">[]</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> acquire_lock</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//not real=
ly self evident</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</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"> acquire_lock</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">//simpler</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><div><br></div><div>A good reason for it tough would be type specificatio=
n which would be quite useful for declarative coding.</div><div>I&#39;m not=
 quite sure the kind of syntax we would need to use though.</div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> fd </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">...;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>scope_exit </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[]</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]()</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> close</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">fd</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-pretti=
fy">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>func_that_may=
_throw</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">...</span></div><=
/code></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3fee9ce5-d672-435d-aede-5261e0700342%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3fee9ce5-d672-435d-aede-5261e0700342=
%40isocpp.org</a>.<br />

------=_Part_2274_1607726418.1501280546345--

------=_Part_2273_1365462658.1501280546344--

.

On 2017-07-28 18:22, Daemon Snake wrote:
> As for anonymous variables I'm not sure that structured binding would be
> the best way to achieve it.
> auto [] = acquire_lock(); //not really self evident
> auto = acquire_lock();//simpler

I understand that, but I believe that both have been suggested and
neither has gained traction. The latter has possible grammar issues that
the former can dodge. Also, the former, assuming we get nesting, will
also allow things like:

  auto [a, [], b] = some_3tuple(); // don't care about second part

....which is something else that seems wanted.

> I'm not quite sure the kind of syntax we would need to use though.
> scope_exit [] = []() { close(fd); };

  auto [] = scope_exit{[]() { ... }};

The type doesn't need to be on the LHS.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b147a2c4-132b-5fed-a0f3-532d0f226d1f%40gmail.com.

.

------=_Part_465_1083870625.1501532982689
Content-Type: multipart/alternative;
 boundary="----=_Part_466_1654666119.1501532982690"

------=_Part_466_1654666119.1501532982690
Content-Type: text/plain; charset="UTF-8"

What about overloading the `void` keyword for this purpose? IMO it makes
the intent quite a bit more obvious than empty square brackets do.

auto [a, void, c] = some_3tuple(); // don't care about second part

-Ray

On Monday, July 31, 2017 at 11:20:15 AM UTC-4, Matthew Woehlke wrote:
>
> On 2017-07-28 18:22, Daemon Snake wrote:
> > As for anonymous variables I'm not sure that structured binding would be
> > the best way to achieve it.
> > auto [] = acquire_lock(); //not really self evident
> > auto = acquire_lock();//simpler
>
> I understand that, but I believe that both have been suggested and
> neither has gained traction. The latter has possible grammar issues that
> the former can dodge. Also, the former, assuming we get nesting, will
> also allow things like:
>
>   auto [a, [], b] = some_3tuple(); // don't care about second part
>
> ...which is something else that seems wanted.
>
> > I'm not quite sure the kind of syntax we would need to use though.
> > scope_exit [] = []() { close(fd); };
>
>   auto [] = scope_exit{[]() { ... }};
>
> The type doesn't need to be on the LHS.
>
> --
> 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6592c3d5-9227-4964-9580-9a922b6f7c60%40isocpp.org.

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

<div dir=3D"ltr">What about overloading the `<font face=3D"courier new, mon=
ospace">void</font>` keyword for this purpose? IMO it makes the intent quit=
e a bit more obvious than empty square brackets do.<div><br></div><div><div=
 class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">a</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: #008;" class=3D"styled-by-prettify">voi=
d</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 sty=
le=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: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> some_3tuple</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// don&#39;t care about second part</span></font></div></code></d=
iv><br>-Ray<br><br>On Monday, July 31, 2017 at 11:20:15 AM UTC-4, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-07-28 18:=
22, Daemon Snake wrote:
<br>&gt; As for anonymous variables I&#39;m not sure that structured bindin=
g would be=20
<br>&gt; the best way to achieve it.
<br>&gt; auto [] =3D acquire_lock(); //not really self evident
<br>&gt; auto =3D acquire_lock();//simpler
<br>
<br>I understand that, but I believe that both have been suggested and
<br>neither has gained traction. The latter has possible grammar issues tha=
t
<br>the former can dodge. Also, the former, assuming we get nesting, will
<br>also allow things like:
<br>
<br>=C2=A0 auto [a, [], b] =3D some_3tuple(); // don&#39;t care about secon=
d part
<br>
<br>...which is something else that seems wanted.
<br>
<br>&gt; I&#39;m not quite sure the kind of syntax we would need to use tho=
ugh.
<br>&gt; scope_exit [] =3D []() { close(fd); };
<br>
<br>=C2=A0 auto [] =3D scope_exit{[]() { ... }};
<br>
<br>The type doesn&#39;t need to be on the LHS.
<br>
<br>--=20
<br>Matthew
<br></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6592c3d5-9227-4964-9580-9a922b6f7c60%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6592c3d5-9227-4964-9580-9a922b6f7c60=
%40isocpp.org</a>.<br />

------=_Part_466_1654666119.1501532982690--

------=_Part_465_1083870625.1501532982689--

.

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

On Mon, Jul 31, 2017 at 4:29 PM, Ray Hamel <rayghamel@gmail.com> wrote:

> What about overloading the `void` keyword for this purpose? IMO it makes
> the intent quite a bit more obvious than empty square brackets do.
>
> auto [a, void, c] = some_3tuple(); // don't care about second part
>
> -Ray
>
>
We can make _ work, and be backwards compatible with current usage:

auto [a, _, c] = some_3tuple(); // don't care about second part

int x = _; // ok, whatever, I guess it is a normal variable (backwards
compat!)

lock_guard _ = ...; // sure reuse _ - it is now anonymous

auto copy = _; // error: _ because anonymous, but was reused


Or make the first use (int x = _;) imply that it cannot become anonymous:

// scenario 1
int _ = f(); // might be anon?
int x = _; // OK, guess not
int _ = g(); // error: _ is not anon, can't be reused

// scenario 2 (in some other scope)
int _ = f(); // might be anon
int _ = g(); // OK, definitely anonymous
int _ = h(); // sure
int x = _; // error: _ was anonymous, ambiguous use

Tony




> On Monday, July 31, 2017 at 11:20:15 AM UTC-4, Matthew Woehlke wrote:
>>
>> On 2017-07-28 18:22, Daemon Snake wrote:
>> > As for anonymous variables I'm not sure that structured binding would
>> be
>> > the best way to achieve it.
>> > auto [] = acquire_lock(); //not really self evident
>> > auto = acquire_lock();//simpler
>>
>> I understand that, but I believe that both have been suggested and
>> neither has gained traction. The latter has possible grammar issues that
>> the former can dodge. Also, the former, assuming we get nesting, will
>> also allow things like:
>>
>>   auto [a, [], b] = some_3tuple(); // don't care about second part
>>
>> ...which is something else that seems wanted.
>>
>> > I'm not quite sure the kind of syntax we would need to use though.
>> > scope_exit [] = []() { close(fd); };
>>
>>   auto [] = scope_exit{[]() { ... }};
>>
>> The type doesn't need to be on the LHS.
>>
>> --
>> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/6592c3d5-9227-4964-
> 9580-9a922b6f7c60%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6592c3d5-9227-4964-9580-9a922b6f7c60%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
Be seeing you,
Tony

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

--94eb2c0672da56911f0555a65be4
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 Mon, Jul 31, 2017 at 4:29 PM, Ray Hamel <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:rayghamel@gmail.com" target=3D"_blank">rayghamel@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">What a=
bout overloading the `<font face=3D"courier new, monospace">void</font>` ke=
yword for this purpose? IMO it makes the intent quite a bit more obvious th=
an empty square brackets do.<div><br></div><div><div class=3D"m_97302400233=
9727641prettyprint" style=3D"background-color:rgb(250,250,250);border:1px s=
olid rgb(187,187,187);word-wrap:break-word"><code class=3D"m_97302400233972=
7641prettyprint"><div class=3D"m_973024002339727641subprettyprint"><font co=
lor=3D"#660066"><span style=3D"color:#008" class=3D"m_973024002339727641sty=
led-by-prettify">auto</span><span style=3D"color:#000" class=3D"m_973024002=
339727641styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_=
973024002339727641styled-by-prettify">[</span><span style=3D"color:#000" cl=
ass=3D"m_973024002339727641styled-by-prettify">a</span><span style=3D"color=
:#660" class=3D"m_973024002339727641styled-by-prettify">,</span><span style=
=3D"color:#000" class=3D"m_973024002339727641styled-by-prettify"> </span><s=
pan style=3D"color:#008" class=3D"m_973024002339727641styled-by-prettify">v=
oid</span><span style=3D"color:#660" class=3D"m_973024002339727641styled-by=
-prettify">,</span><span style=3D"color:#000" class=3D"m_973024002339727641=
styled-by-prettify"> c</span><span style=3D"color:#660" class=3D"m_97302400=
2339727641styled-by-prettify">]</span><span style=3D"color:#000" class=3D"m=
_973024002339727641styled-by-prettify"> </span><span style=3D"color:#660" c=
lass=3D"m_973024002339727641styled-by-prettify">=3D</span><span style=3D"co=
lor:#000" class=3D"m_973024002339727641styled-by-prettify"> some_3tuple</sp=
an><span style=3D"color:#660" class=3D"m_973024002339727641styled-by-pretti=
fy">();</span><span style=3D"color:#000" class=3D"m_973024002339727641style=
d-by-prettify"> </span><span style=3D"color:#800" class=3D"m_97302400233972=
7641styled-by-prettify">// don&#39;t care about second part</span></font></=
div></code></div><br>-Ray<span class=3D""><br><br></span></div></div></bloc=
kquote><div><br></div><div>We can make _ work, and be backwards compatible =
with current usage:</div><div><br></div><div>auto [a, _, c] =3D some_3tuple=
(); // don&#39;t care about second part</div><div><br></div><div>int x =3D =
_; // ok, whatever, I guess it is a normal variable (backwards compat!)</di=
v><div><br></div><div>lock_guard _ =3D ...; // sure reuse _ - it is now ano=
nymous</div><div><br></div><div>auto copy =3D _; // error: _ because anonym=
ous, but was reused</div><div><br></div><div><br></div><div>Or make the fir=
st use (int x =3D _;) imply that it cannot become anonymous:</div><div><br>=
</div><div>// scenario 1</div><div>int _ =3D f(); // might be anon?</div><d=
iv>int x =3D _; // OK, guess not</div><div>int _ =3D g(); // error: _ is no=
t anon, can&#39;t be reused</div><div><br></div><div>// scenario 2 (in some=
 other scope)</div><div>int _ =3D f(); // might be anon</div><div>int _ =3D=
 g(); // OK, definitely anonymous</div><div>int _ =3D h(); // sure</div><di=
v>int x =3D _; // error: _ was anonymous, ambiguous use</div><div><br></div=
><div>Tony</div><div><br></div><div><br></div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div><span class=3D"">On Monday, July 3=
1, 2017 at 11:20:15 AM UTC-4, Matthew Woehlke wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex">On 2017-07-28 18:22, Daemon Snake wrote:
<br>&gt; As for anonymous variables I&#39;m not sure that structured bindin=
g would be=20
<br>&gt; the best way to achieve it.
<br>&gt; auto [] =3D acquire_lock(); //not really self evident
<br>&gt; auto =3D acquire_lock();//simpler
<br>
<br>I understand that, but I believe that both have been suggested and
<br>neither has gained traction. The latter has possible grammar issues tha=
t
<br>the former can dodge. Also, the former, assuming we get nesting, will
<br>also allow things like:
<br>
<br>=C2=A0 auto [a, [], b] =3D some_3tuple(); // don&#39;t care about secon=
d part
<br>
<br>...which is something else that seems wanted.
<br>
<br>&gt; I&#39;m not quite sure the kind of syntax we would need to use tho=
ugh.
<br>&gt; scope_exit [] =3D []() { close(fd); };
<br>
<br>=C2=A0 auto [] =3D scope_exit{[]() { ... }};
<br>
<br>The type doesn&#39;t need to be on the LHS.
<br>
<br>--=20
<br>Matthew
<br></blockquote></span></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6592c3d5-9227-4964-9580-9a922b6f7c60%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/6592=
c3d5-9227-4964-<wbr>9580-9a922b6f7c60%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><d=
iv>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbisi4Q9UJ4B916FD4c5G6Y%2BqLJ91NY=
Udh_pFDE8uTW2c3A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbisi4Q9UJ4=
B916FD4c5G6Y%2BqLJ91NYUdh_pFDE8uTW2c3A%40mail.gmail.com</a>.<br />

--94eb2c0672da56911f0555a65be4--

.

On 1 August 2017 at 03:37, Tony V E <tvaneerd@gmail.com> wrote:
> We can make _ work, and be backwards compatible with current usage:
>
> auto [a, _, c] = some_3tuple(); // don't care about second part
>
> int x = _; // ok, whatever, I guess it is a normal variable (backwards
> compat!)
>
> lock_guard _ = ...; // sure reuse _ - it is now anonymous

How is that lock_guard definition backwards compatible?

> auto copy = _; // error: _ because anonymous, but was reused

How is that backwards compatible?

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

.

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

Most of my lock_guards are called _ today, as there's no point in using
them (explicitly) after declaration. I hope any change we make that uses _
does not prevent this very common use-case. From what I can see, the
suggestions floated here would not prove to be a problem, even if _ was
reused for other,
not-anonymous-but-not-usable-except-for-implicit-destruction cases, and I'm
fine with them as long as this situation persists :)

2017-07-31 20:49 GMT-04:00 Ville Voutilainen <ville.voutilainen@gmail.com>:

> On 1 August 2017 at 03:37, Tony V E <tvaneerd@gmail.com> wrote:
> > We can make _ work, and be backwards compatible with current usage:
> >
> > auto [a, _, c] = some_3tuple(); // don't care about second part
> >
> > int x = _; // ok, whatever, I guess it is a normal variable (backwards
> > compat!)
> >
> > lock_guard _ = ...; // sure reuse _ - it is now anonymous
>
> How is that lock_guard definition backwards compatible?
>
> > auto copy = _; // error: _ because anonymous, but was reused
>
> How is that backwards compatible?
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAFk2RUbXLjVw19GHP4E3f9wBOkz-
> RJaYu%2BxmXDk_Xrkibrv00Q%40mail.gmail.com.
>

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

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

<div dir=3D"ltr">Most of my lock_guards are called _ today, as there&#39;s =
no point in using them (explicitly) after declaration. I hope any change we=
 make that uses _ does not prevent this very common use-case. From what I c=
an see, the suggestions floated here would not prove to be a problem, even =
if _ was reused for other, not-anonymous-but-not-usable-except-for-implicit=
-destruction cases, and I&#39;m fine with them as long as this situation pe=
rsists :)<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">2017-07-31 20:49 GMT-04:00 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>:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On 1 August 2017 at 03:37, Tony V E &lt;<a href=3D"mailto:tvaneerd@gm=
ail.com">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt; We can make _ work, and be backwards compatible with current usage:<br=
>
&gt;<br>
&gt; auto [a, _, c] =3D some_3tuple(); // don&#39;t care about second part<=
br>
&gt;<br>
&gt; int x =3D _; // ok, whatever, I guess it is a normal variable (backwar=
ds<br>
&gt; compat!)<br>
&gt;<br>
&gt; lock_guard _ =3D ...; // sure reuse _ - it is now anonymous<br>
<br>
</span>How is that lock_guard definition backwards compatible?<br>
<span class=3D""><br>
&gt; auto copy =3D _; // error: _ because anonymous, but was reused<br>
<br>
</span>How is that backwards compatible?<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbXLjVw19GHP4E3f9wBOkz-R=
JaYu%2BxmXDk_Xrkibrv00Q%40mail.gmail.com" rel=3D"noreferrer" target=3D"_bla=
nk">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/=
<wbr>CAFk2RUbXLjVw19GHP4E3f9wBOkz-<wbr>RJaYu%2BxmXDk_Xrkibrv00Q%<wbr>40mail=
..gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2dBZ5ajxc7V6BBOx4zMbAA9KCjZxWD=
aRj6U0Z0tcUszw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2dBZ5ajxc7=
V6BBOx4zMbAA9KCjZxWDaRj6U0Z0tcUszw%40mail.gmail.com</a>.<br />

--001a114926a08d83ca0555a7670a--

.

------=_Part_4733_290012775.1501552428162
Content-Type: multipart/alternative;
 boundary="----=_Part_4734_1379610509.1501552428162"

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

Le mardi 1 ao=C3=BBt 2017 02:37:51 UTC+2, Tony V E a =C3=A9crit :
>
> We can make _ work, and be backwards compatible with current usage:
>

That could be quite dangerous as '_' is a legal C++ identifier.
One of the focus of the standard is still to maintain legacy code.

Imagine this:
some_type _;

void func()
{
   int _ =3D ...; //is now anonymous by side effect
}

Ray's proposal has at least clearness on its side but clashes with the=20
"regular void" proposal.

What about this ?
//making name optional for C-style struct/class variable declaration only=
=20
if initialized
//anonymous variables are only useful for struct/class types anyway
class type_name =3D ...; //declares an anonymous variable of type type_name
class auto =3D ...; //auto is a reserved keyword so why not

//Impact on the syntax ?
class double =3D...; //no changes, illegal double is not a struct/class
class type_name; //no changes, legal, declares a struct named t
class type_name id; //no changes, legal.
class type_name id =3D ...; //no changes, legal.

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

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

<div dir=3D"ltr">Le mardi 1 ao=C3=BBt 2017 02:37:51 UTC+2, Tony V E a =C3=
=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div class=3D"gmail_quote"><div>We can make _ work, and be backwards compa=
tible with current usage:</div></div></div></blockquote><div><br></div><div=
>That could be quite dangerous as &#39;_&#39; is a legal C++ identifier.</d=
iv><div>One of the focus of the standard is still to maintain legacy code.<=
/div><div><br></div><div>Imagine this:</div><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify">some_type _</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> func</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int=
</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 s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">...;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">//is now anonymous by side effect</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><div=
><br></div><div>Ray&#39;s proposal has at least clearness on its side but c=
lashes with the &quot;regular void&quot; proposal.</div><div><br></div><div=
>What about this ?</div><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: rgb(136, 0, 0);"><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">//making name optional f=
or C-style struct/class variable declaration only if initialized</span></sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">//anonymous variable=
s are only useful for struct/class types anyway</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> type_name </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">...;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//de=
clares an anonymous variable of type type_name</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">auto</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"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">...;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//auto is a reserved keyword=
 so why not</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/Impact on the syntax ?</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">double<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D...;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">//no changes, illegal double is =
not a struct/class</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ty=
pe_name</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">//no changes, legal, =
declares a struct named t</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> type</span><font color=3D"#666600"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">_name</span></font><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> id</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//no changes, legal.</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 type_name id </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">...;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">//no changes, legal.</span>=
</div></code></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/892d37ec-a397-4913-a29e-1ebab288f075%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/892d37ec-a397-4913-a29e-1ebab288f075=
%40isocpp.org</a>.<br />

------=_Part_4734_1379610509.1501552428162--

------=_Part_4733_290012775.1501552428162--

.

------=_Part_4735_536930602.1501553651114
Content-Type: multipart/alternative;
 boundary="----=_Part_4736_1328293773.1501553651114"

------=_Part_4736_1328293773.1501553651114
Content-Type: text/plain; charset="UTF-8"

One thing I've forgot though is that aliases and template deduction are not
currently allowed in C-style struct variable declaration.
That might be one thing that might be interesting to change also.

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

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

<div dir=3D"ltr">One thing I&#39;ve forgot though is that aliases and templ=
ate deduction are not currently allowed in C-style struct variable declarat=
ion.<div>That might be one thing that might be interesting to change also.<=
/div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/87ef20e6-38d6-4d02-9a45-37cfb86ff08a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/87ef20e6-38d6-4d02-9a45-37cfb86ff08a=
%40isocpp.org</a>.<br />

------=_Part_4736_1328293773.1501553651114--

------=_Part_4735_536930602.1501553651114--

.

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

On Mon, Jul 31, 2017 at 8:49 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 1 August 2017 at 03:37, Tony V E <tvaneerd@gmail.com> wrote:
> > We can make _ work, and be backwards compatible with current usage:
> >
> > auto [a, _, c] = some_3tuple(); // don't care about second part
> >
> > int x = _; // ok, whatever, I guess it is a normal variable (backwards
> > compat!)
> >
> > lock_guard _ = ...; // sure reuse _ - it is now anonymous
>
> How is that lock_guard definition backwards compatible?
>

Currently reusing a variable name in the same scope is an error, so I'm
saying - for _ only - don't make it an error. Make it mean "_ is now
anonymous for the rest of this scope"



>
> > auto copy = _; // error: _ because anonymous, but was reused
>
> How is that backwards compatible?
>
>
You currently can't have 2 _ variables in the same scope. That last line is
in the context of "doesn't compile today".


// 1. normal. today.
{
    int _ = 17;
    int x = _ * _;
}

// 2.
{
    int _ = 17;
    int _ = 24;  // error today, make OK, anonymous in proposal
    int x = _ * _; // proposal - error: ambiguous *use* of _
}

ie you can *declare* as many _ variables as you want in a scope, but if you
have more than 1, you can't *use* the variable in an expression (because it
would be obviously ambiguous as to which _ you were using).


There is only one design question - this case:
// 3.
{
   int _ = 17;
   int x = _ * _;  // *use* _, "normal" so far

   // should the next line be an error? (as _ was already *used*)
   // or does this just make it anonymous starting here:
   int _ = 24;

   int x = _ * _; // definitely error - ambiguous
}

I could go either way on that last decision.


--
Be seeing you,
Tony

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

--001a113771ba96ce0f0555af73f8
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 Mon, Jul 31, 2017 at 8:49 PM, Ville Voutilainen <span dir=3D"ltr">&l=
t;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vo=
utilainen@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"=
><span class=3D"">On 1 August 2017 at 03:37, Tony V E &lt;<a href=3D"mailto=
:tvaneerd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt; We can make _ work, and be backwards compatible with current usage:<br=
>
&gt;<br>
&gt; auto [a, _, c] =3D some_3tuple(); // don&#39;t care about second part<=
br>
&gt;<br>
&gt; int x =3D _; // ok, whatever, I guess it is a normal variable (backwar=
ds<br>
&gt; compat!)<br>
&gt;<br>
&gt; lock_guard _ =3D ...; // sure reuse _ - it is now anonymous<br>
<br>
</span>How is that lock_guard definition backwards compatible?<br></blockqu=
ote><div><br></div><div>Currently reusing a variable name in the same scope=
 is an error, so I&#39;m saying - for _ only - don&#39;t make it an error. =
Make it mean &quot;_ is now anonymous for the rest of this scope&quot;<br><=
br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D""><br>
&gt; auto copy =3D _; // error: _ because anonymous, but was reused<br>
<br>
</span>How is that backwards compatible?<br>
<span class=3D""><br></span></blockquote><div><br></div><div>You currently =
can&#39;t have 2 _ variables in the same scope. That last line is in the co=
ntext of &quot;doesn&#39;t compile today&quot;.<br></div><div><br><br></div=
><div>// 1. normal. today.<br></div><div>{<br></div><div>=C2=A0=C2=A0=C2=A0=
 int _ =3D 17;<br></div><div>=C2=A0=C2=A0=C2=A0 int x =3D _ * _;<br>}<br><b=
r>// 2. <br>{<br></div><div>=C2=A0=C2=A0=C2=A0 int _ =3D 17;<br></div><div>=
=C2=A0=C2=A0=C2=A0 int _ =3D 24;=C2=A0 // error today, make OK, anonymous i=
n proposal<br></div><div>=C2=A0=C2=A0=C2=A0 int x =3D _ * _; // proposal - =
error: ambiguous *use* of _<br></div><div>}<br><br></div><div>ie you can *d=
eclare* as many _ variables as you want in a scope, but if you have more th=
an 1, you can&#39;t *use* the variable in an expression (because it would b=
e obviously ambiguous as to which _ you were using).<br><br><br></div><div>=
There is only one design question - this case:<br>// 3.<br>{<br></div><div>=
=C2=A0=C2=A0 int _ =3D 17;<br></div><div>=C2=A0=C2=A0 int x =3D _ * _;=C2=
=A0 // *use* _, &quot;normal&quot; so far<br></div><div><br></div><div>=C2=
=A0=C2=A0 // should the next line be an error? (as _ was already *used*)<br=
></div><div>=C2=A0=C2=A0 // or does this just make it anonymous starting he=
re:<br></div><div>=C2=A0=C2=A0 int _ =3D 24;<br><br></div><div>=C2=A0=C2=A0=
 int x =3D _ * _; // definitely error - ambiguous<br></div><div>}<br><br>I =
could go either way on that last decision.<br><br></div></div><br>-- <br><d=
iv class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D=
"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitibrReok-cO3iCa401gp6SY7QXtPKB=
gWjmyyD6FQ0pow%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitibrReok-c=
O3iCa401gp6SY7QXtPKBgWjmyyD6FQ0pow%40mail.gmail.com</a>.<br />

--001a113771ba96ce0f0555af73f8--

.

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

On Mon, Jul 31, 2017 at 9:53 PM, Daemon Snake <swac31@gmail.com> wrote:

> Le mardi 1 ao=C3=BBt 2017 02:37:51 UTC+2, Tony V E a =C3=A9crit :
>>
>> We can make _ work, and be backwards compatible with current usage:
>>
>
> That could be quite dangerous as '_' is a legal C++ identifier.
> One of the focus of the standard is still to maintain legacy code.
>
> Imagine this:
> some_type _;
>
> void func()
> {
>    int _ =3D ...; //is now anonymous by side effect
> }
>
>
No, that would be normal code, as is today - we allow _ to be used once per
scope today.

I'm suggesting _ becomes anonymous *within a scope* when it is used to
declare more than one variable *within a scope*.

--=20
Be seeing you,
Tony

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

--001a113f4be4d152c50555af7616
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 Mon, Jul 31, 2017 at 9:53 PM, Daemon Snake <span dir=3D"ltr">&lt;<a =
href=3D"mailto:swac31@gmail.com" target=3D"_blank">swac31@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span cla=
ss=3D"">Le mardi 1 ao=C3=BBt 2017 02:37:51 UTC+2, Tony V E a =C3=A9crit=C2=
=A0:<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 class=3D"=
gmail_quote"><div>We can make _ work, and be backwards compatible with curr=
ent usage:</div></div></div></blockquote><div><br></div></span><div>That co=
uld be quite dangerous as &#39;_&#39; is a legal C++ identifier.</div><div>=
One of the focus of the standard is still to maintain legacy code.</div><di=
v><br></div><div>Imagine this:</div><div class=3D"m_2781810374195773195pret=
typrint" style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code clas=
s=3D"m_2781810374195773195prettyprint"><div class=3D"m_2781810374195773195s=
ubprettyprint"><span style=3D"color:#000" class=3D"m_2781810374195773195sty=
led-by-prettify">some_type _</span><span style=3D"color:#660" class=3D"m_27=
81810374195773195styled-by-prettify">;</span><span style=3D"color:#000" cla=
ss=3D"m_2781810374195773195styled-by-prettify"><br><br></span><span style=
=3D"color:#008" class=3D"m_2781810374195773195styled-by-prettify">void</spa=
n><span style=3D"color:#000" class=3D"m_2781810374195773195styled-by-pretti=
fy"> func</span><span style=3D"color:#660" class=3D"m_2781810374195773195st=
yled-by-prettify">()</span><span style=3D"color:#000" class=3D"m_2781810374=
195773195styled-by-prettify"><br></span><span style=3D"color:#660" class=3D=
"m_2781810374195773195styled-by-prettify">{</span><span style=3D"color:#000=
" class=3D"m_2781810374195773195styled-by-prettify"><br>=C2=A0 =C2=A0</span=
><span style=3D"color:#008" class=3D"m_2781810374195773195styled-by-prettif=
y">int</span><span style=3D"color:#000" class=3D"m_2781810374195773195style=
d-by-prettify"> _ </span><span style=3D"color:#660" class=3D"m_278181037419=
5773195styled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_=
2781810374195773195styled-by-prettify"> </span><span style=3D"color:#660" c=
lass=3D"m_2781810374195773195styled-by-prettify">...;</span><span style=3D"=
color:#000" class=3D"m_2781810374195773195styled-by-prettify"> </span><span=
 style=3D"color:#800" class=3D"m_2781810374195773195styled-by-prettify">//i=
s now anonymous by side effect</span><span style=3D"color:#000" class=3D"m_=
2781810374195773195styled-by-prettify"><br></span><span style=3D"color:#660=
" class=3D"m_2781810374195773195styled-by-prettify">}</span></div></code></=
div><div><br></div></div></blockquote><br></div><div class=3D"gmail_quote">=
No, that would be normal code, as is today - we allow _ to be used once per=
 scope today.<br clear=3D"all"></div><br></div><div class=3D"gmail_extra">I=
&#39;m suggesting _ becomes anonymous *within a scope* when it is used to d=
eclare more than one variable *within a scope*.<br><br></div><div class=3D"=
gmail_extra">-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_=
signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></di=
v>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiv8-%2B8j97rB2hxioKeLPNjWO7BBM8=
Wcx4tO_21kiyhcLg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiv8-%2B8j=
97rB2hxioKeLPNjWO7BBM8Wcx4tO_21kiyhcLg%40mail.gmail.com</a>.<br />

--001a113f4be4d152c50555af7616--

.

On 1 August 2017 at 14:28, Tony V E <tvaneerd@gmail.com> wrote:
>> > We can make _ work, and be backwards compatible with current usage:
>> >
>> > auto [a, _, c] = some_3tuple(); // don't care about second part
>> >
>> > int x = _; // ok, whatever, I guess it is a normal variable (backwards
>> > compat!)
>> >
>> > lock_guard _ = ...; // sure reuse _ - it is now anonymous
>>
>> How is that lock_guard definition backwards compatible?
>
>
> Currently reusing a variable name in the same scope is an error, so I'm
> saying - for _ only - don't make it an error. Make it mean "_ is now
> anonymous for the rest of this scope"

Woo hoo, context-specific semantics that silently change depending on
prior declarations
or lack of them in the same scope. NO.

>> > auto copy = _; // error: _ because anonymous, but was reused
>>
>> How is that backwards compatible?
>>
>
> You currently can't have 2 _ variables in the same scope. That last line is
> in the context of "doesn't compile today".

auto _ = whatever;
auto copy = _;

compiles fine, today.

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

.

On 2017-07-31 16:29, Ray Hamel wrote:
> What about overloading the `void` keyword for this purpose? IMO it makes
> the intent quite a bit more obvious than empty square brackets do.
>
> auto [a, void, c] = some_3tuple(); // don't care about second part

The main attraction for using `[]` is that it gives us anonymous
variables with only a slight tweak to SB.

That said... has anyone suggested using `void` as an anonymous variable
name before? What's wrong with it?

  auto void = get_scoped_thingy();
  lock_guard void = some_mutex;
  auto [a, void, b, void] = tuple; // optional bonus

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/faf04da9-7da3-def4-a40e-adaefa6d7a84%40gmail.com.

.

On 1 August 2017 at 20:44, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> That said... has anyone suggested using `void` as an anonymous variable
> name before? What's wrong with it?

It's a type, not an identifier.

>   auto void = get_scoped_thingy();
>   lock_guard void = some_mutex;
>   auto [a, void, b, void] = tuple; // optional bonus

Sure, that would work. It seems like shoehorning new special semantics
into void.
I'd rather seek some other solution.

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

.

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

Le 01/08/2017 =C3=A0 13:48, Ville Voutilainen a =C3=A9crit :
> On 1 August 2017 at 14:28, Tony V E <tvaneerd@gmail.com> wrote:
>>>> We can make _ work, and be backwards compatible with current usage:
>>>>
>>>> auto [a, _, c] =3D some_3tuple(); // don't care about second part
>>>>
>>>> int x =3D _; // ok, whatever, I guess it is a normal variable (backwar=
ds
>>>> compat!)
>>>>
>>>> lock_guard _ =3D ...; // sure reuse _ - it is now anonymous
>>> How is that lock_guard definition backwards compatible?
>>
>> Currently reusing a variable name in the same scope is an error, so I'm
>> saying - for _ only - don't make it an error. Make it mean "_ is now
>> anonymous for the rest of this scope"
> Woo hoo, context-specific semantics that silently change depending on
> prior declarations
> or lack of them in the same scope. NO.
>
>>>> auto copy =3D _; // error: _ because anonymous, but was reused
>>> How is that backwards compatible?
>>>
>> You currently can't have 2 _ variables in the same scope. That last line=
 is
>> in the context of "doesn't compile today".
> auto _ =3D whatever;
> auto copy =3D _;
>
> compiles fine, today.
>
What about using __ instead. This is more constrained as used only by=20
the standard library. The compiler should signal an error when used in=20
other contexts.

Vicente

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

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 01/08/2017 =C3=A0 13:48, Ville
      Voutilainen a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
cite=3D"mid:CAFk2RUaEA=3DLt0040kwNzwro9A6P7UrErfDsDrmACUvUyFgS0kA@mail.gmai=
l.com">
      <pre wrap=3D"">On 1 August 2017 at 14:28, Tony V E <a class=3D"moz-tx=
t-link-rfc2396E" href=3D"mailto:tvaneerd@gmail.com">&lt;tvaneerd@gmail.com&=
gt;</a> wrote:
</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <blockquote type=3D"cite">
            <pre wrap=3D"">We can make _ work, and be backwards compatible =
with current usage:

auto [a, _, c] =3D some_3tuple(); // don't care about second part

int x =3D _; // ok, whatever, I guess it is a normal variable (backwards
compat!)

lock_guard _ =3D ...; // sure reuse _ - it is now anonymous
</pre>
          </blockquote>
          <pre wrap=3D"">
How is that lock_guard definition backwards compatible?
</pre>
        </blockquote>
        <pre wrap=3D"">

Currently reusing a variable name in the same scope is an error, so I'm
saying - for _ only - don't make it an error. Make it mean "_ is now
anonymous for the rest of this scope"
</pre>
      </blockquote>
      <pre wrap=3D"">
Woo hoo, context-specific semantics that silently change depending on
prior declarations
or lack of them in the same scope. NO.

</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <blockquote type=3D"cite">
            <pre wrap=3D"">auto copy =3D _; // error: _ because anonymous, =
but was reused
</pre>
          </blockquote>
          <pre wrap=3D"">
How is that backwards compatible?

</pre>
        </blockquote>
        <pre wrap=3D"">
You currently can't have 2 _ variables in the same scope. That last line is
in the context of "doesn't compile today".
</pre>
      </blockquote>
      <pre wrap=3D"">
auto _ =3D whatever;
auto copy =3D _;

compiles fine, today.

</pre>
    </blockquote>
    <p><font size=3D"+1">What about using __ instead. This is more
        constrained as used only by the standard library. The compiler
        should signal an error when used in other contexts.<br>
      </font></p>
    <p><font size=3D"+1">Vicente</font><br>
    </p>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5a9e516e-b127-5c79-e790-ff67d156d3be%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5a9e516e-b127-5c79-e790-ff67d156d3be=
%40wanadoo.fr</a>.<br />

--------------958DB358BDD34CF72AA67598--

.

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

On Tue, Aug 1, 2017 at 7:48 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 1 August 2017 at 14:28, Tony V E <tvaneerd@gmail.com> wrote:
> >> > We can make _ work, and be backwards compatible with current usage:
> >> >
> >> > auto [a, _, c] = some_3tuple(); // don't care about second part
> >> >
> >> > int x = _; // ok, whatever, I guess it is a normal variable (backwards
> >> > compat!)
> >> >
> >> > lock_guard _ = ...; // sure reuse _ - it is now anonymous
> >>
> >> How is that lock_guard definition backwards compatible?
> >
> >
> > Currently reusing a variable name in the same scope is an error, so I'm
> > saying - for _ only - don't make it an error. Make it mean "_ is now
> > anonymous for the rest of this scope"
>
> Woo hoo, context-specific semantics that silently change depending on
> prior declarations
> or lack of them in the same scope. NO.
>

I'm not sure I'd use the words "semantics" - it becomes an error.  Just
like "int x" is an error depending on prior declarations - ie if x was
already declared.
Runtime behaviour doesn't change - it either compiles or doesn't.

#if FOO
int x = 17;
#endif
int x = 21; // Woo hoo "semantics" (compile or not) depends on prior
declarations

#if FOO
int _ = 17;
#endif
int _ = 18; // this is immune to prior declarations! better than x!
return _ * _; // Woo hoo "semantics" (compile or not) depends on prior
declarations






>
> >> > auto copy = _; // error: _ because anonymous, but was reused
> >>
> >> How is that backwards compatible?
> >>
> >
> > You currently can't have 2 _ variables in the same scope. That last line
> is
> > in the context of "doesn't compile today".
>
> auto _ = whatever;
> auto copy = _;
>
> compiles fine, today.
>
>
Sure.  My example was in this context:

int _ = f(); // might be anon
int _ = g(); // OK, definitely anonymous
int _ = h(); // sure
int x = _; // error: _ was anonymous, ambiguous us

There is no need/possibility for backwards compatibility here.  The three _
declarations already mean we aren't in Kansas anymore.

Maybe I'm not explaining this well?

Also, I'm not saying it is the best idea in the world, just that it is
possible to use _ as an anonymous variable in a way that is backwards
compatible.
So step 1 is agree or disagree on whether it really is BC.
Step 2 can be saying you just don't like it, even just because "_ shouldn't
be special".

--
Be seeing you,
Tony

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

--001a113d3aac991e020555d17296
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 Tue, Aug 1, 2017 at 7:48 AM, Ville Voutilainen <span dir=3D"ltr">&lt=
;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vou=
tilainen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><span class=3D"gmail-">On 1 August 2017 at 14:28, Tony V=
 E &lt;<a href=3D"mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>&gt; wro=
te:<br>
&gt;&gt; &gt; We can make _ work, and be backwards compatible with current =
usage:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; auto [a, _, c] =3D some_3tuple(); // don&#39;t care about sec=
ond part<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; int x =3D _; // ok, whatever, I guess it is a normal variable=
 (backwards<br>
&gt;&gt; &gt; compat!)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; lock_guard _ =3D ...; // sure reuse _ - it is now anonymous<b=
r>
&gt;&gt;<br>
&gt;&gt; How is that lock_guard definition backwards compatible?<br>
&gt;<br>
&gt;<br>
&gt; Currently reusing a variable name in the same scope is an error, so I&=
#39;m<br>
&gt; saying - for _ only - don&#39;t make it an error. Make it mean &quot;_=
 is now<br>
&gt; anonymous for the rest of this scope&quot;<br>
<br>
</span>Woo hoo, context-specific semantics that silently change depending o=
n<br>
prior declarations<br>
or lack of them in the same scope. NO.<br></blockquote><div><br></div>I&#39=
;m not sure I&#39;d use the words &quot;semantics&quot; - it becomes an err=
or.=C2=A0 Just like &quot;int x&quot; is an error depending on prior declar=
ations - ie if x was already declared.<br><div>Runtime behaviour doesn&#39;=
t change - it either compiles or doesn&#39;t.<br><br></div><div>#if FOO<br>=
int x =3D 17;<br></div><div>#endif<br>int x =3D 21; // Woo hoo &quot;semant=
ics&quot; (compile or not) depends on prior declarations<br><br></div><div>=
#if FOO<br>int _ =3D 17;<br></div><div>#endif<br></div><div>int _ =3D 18; /=
/ this is immune to prior declarations! better than x!<br></div><div>return=
 _ * _; // Woo hoo &quot;semantics&quot; (compile or not) depends on prior =
declarations<br><br><br></div><div><br><br>=C2=A0<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">
<span class=3D"gmail-"><br>
&gt;&gt; &gt; auto copy =3D _; // error: _ because anonymous, but was reuse=
d<br>
&gt;&gt;<br>
&gt;&gt; How is that backwards compatible?<br>
&gt;&gt;<br>
&gt;<br>
&gt; You currently can&#39;t have 2 _ variables in the same scope. That las=
t line is<br>
&gt; in the context of &quot;doesn&#39;t compile today&quot;.<br>
<br>
</span>auto _ =3D whatever;<br>
auto copy =3D _;<br>
<br>
compiles fine, today.<br>
<span class=3D"gmail-"><br></span></blockquote><div><br></div><div>Sure.=C2=
=A0 My example was in this context:<br><br>int _ =3D f(); // might be anon<=
div>int _ =3D g(); // OK, definitely anonymous</div><div>int _ =3D h(); // =
sure</div>int x =3D _; // error: _ was anonymous, ambiguous us<br><br></div=
><div>There is no need/possibility for backwards compatibility here.=C2=A0 =
The three _ declarations already mean we aren&#39;t in Kansas anymore.<br><=
br></div><div>Maybe I&#39;m not explaining this well?<br><br></div><div>Als=
o, I&#39;m not saying it is the best idea in the world, just that it is pos=
sible to use _ as an anonymous variable in a way that is backwards compatib=
le.<br></div><div>So step 1 is agree or disagree on whether it really is BC=
..<br>Step 2 can be saying you just don&#39;t like it, even just because &qu=
ot;_ shouldn&#39;t be special&quot;.<br></div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br>=
</div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu2z6CU4FxqHwBstra0L_e36u9h%2Br=
0V6tfXcAL9bVQ2Qw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu2z6CU4F=
xqHwBstra0L_e36u9h%2Br0V6tfXcAL9bVQ2Qw%40mail.gmail.com</a>.<br />

--001a113d3aac991e020555d17296--

.

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

Le 03/08/2017 =C3=A0 06:02, Tony V E a =C3=A9crit :
>
>
> On Tue, Aug 1, 2017 at 7:48 AM, Ville Voutilainen=20
> <ville.voutilainen@gmail.com <mailto:ville.voutilainen@gmail.com>> wrote:
>
>     On 1 August 2017 at 14:28, Tony V E <tvaneerd@gmail.com
>     <mailto:tvaneerd@gmail.com>> wrote:
>     >> > We can make _ work, and be backwards compatible with current
>     usage:
>     >> >
>     >> > auto [a, _, c] =3D some_3tuple(); // don't care about second par=
t
>     >> >
>     >> > int x =3D _; // ok, whatever, I guess it is a normal variable
>     (backwards
>     >> > compat!)
>     >> >
>     >> > lock_guard _ =3D ...; // sure reuse _ - it is now anonymous
>     >>
>     >> How is that lock_guard definition backwards compatible?
>     >
>     >
>     > Currently reusing a variable name in the same scope is an error,
>     so I'm
>     > saying - for _ only - don't make it an error. Make it mean "_ is no=
w
>     > anonymous for the rest of this scope"
>
>     Woo hoo, context-specific semantics that silently change depending on
>     prior declarations
>     or lack of them in the same scope. NO.
>
>
> I'm not sure I'd use the words "semantics" - it becomes an error. =20
> Just like "int x" is an error depending on prior declarations - ie if=20
> x was already declared.
> Runtime behaviour doesn't change - it either compiles or doesn't.
>
> #if FOO
> int x =3D 17;
> #endif
> int x =3D 21; // Woo hoo "semantics" (compile or not) depends on prior=20
> declarations
>
> #if FOO
> int _ =3D 17;
> #endif
> int _ =3D 18; // this is immune to prior declarations! better than x!
> return _ * _; // Woo hoo "semantics" (compile or not) depends on prior=20
> declarations
>
>
>
>
>
>
>     >> > auto copy =3D _; // error: _ because anonymous, but was reused
>     >>
>     >> How is that backwards compatible?
>     >>
>     >
>     > You currently can't have 2 _ variables in the same scope. That
>     last line is
>     > in the context of "doesn't compile today".
>
>     auto _ =3D whatever;
>     auto copy =3D _;
>
>     compiles fine, today.
>
>
> Sure.  My example was in this context:
>
> int _ =3D f(); // might be anon
> int _ =3D g(); // OK, definitely anonymous
> int _ =3D h(); // sure
> int x =3D _; // error: _ was anonymous, ambiguous us
>
> There is no need/possibility for backwards compatibility here.  The=20
> three _ declarations already mean we aren't in Kansas anymore.
>
> Maybe I'm not explaining this well?
>
> Also, I'm not saying it is the best idea in the world, just that it is=20
> possible to use _ as an anonymous variable in a way that is backwards=20
> compatible.
> So step 1 is agree or disagree on whether it really is BC.
> Step 2 can be saying you just don't like it, even just because "_=20
> shouldn't be special".
>
To be sure I understand. _ becomes anonymous once there are two=20
different declarations named _.
 From one side I like it because it allows some kind of anomymous=20
variables, however this means that the reader don't know that _ is=20
anonymous until the whole scope is inspected.
If we restrict __ as I proposed we don't have this downside. Onely the=20
standard library authors need to change any non-anonymous use of __.

Vicente

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

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 03/08/2017 =C3=A0 06:02, Tony V E a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
cite=3D"mid:CAOHCbiu2z6CU4FxqHwBstra0L_e36u9h+r0V6tfXcAL9bVQ2Qw@mail.gmail.=
com">
      <div dir=3D"ltr"><br>
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">On Tue, Aug 1, 2017 at 7:48 AM, Ville
            Voutilainen <span dir=3D"ltr">&lt;<a
                href=3D"mailto:ville.voutilainen@gmail.com"
                target=3D"_blank" moz-do-not-send=3D"true">ville.voutilaine=
n@gmail.com</a>&gt;</span>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">On
                1 August 2017 at 14:28, Tony V E &lt;<a
                  href=3D"mailto:tvaneerd@gmail.com"
                  moz-do-not-send=3D"true">tvaneerd@gmail.com</a>&gt;
                wrote:<br>
                &gt;&gt; &gt; We can make _ work, and be backwards
                compatible with current usage:<br>
                &gt;&gt; &gt;<br>
                &gt;&gt; &gt; auto [a, _, c] =3D some_3tuple(); // don't
                care about second part<br>
                &gt;&gt; &gt;<br>
                &gt;&gt; &gt; int x =3D _; // ok, whatever, I guess it is
                a normal variable (backwards<br>
                &gt;&gt; &gt; compat!)<br>
                &gt;&gt; &gt;<br>
                &gt;&gt; &gt; lock_guard _ =3D ...; // sure reuse _ - it
                is now anonymous<br>
                &gt;&gt;<br>
                &gt;&gt; How is that lock_guard definition backwards
                compatible?<br>
                &gt;<br>
                &gt;<br>
                &gt; Currently reusing a variable name in the same scope
                is an error, so I'm<br>
                &gt; saying - for _ only - don't make it an error. Make
                it mean "_ is now<br>
                &gt; anonymous for the rest of this scope"<br>
                <br>
              </span>Woo hoo, context-specific semantics that silently
              change depending on<br>
              prior declarations<br>
              or lack of them in the same scope. NO.<br>
            </blockquote>
            <div><br>
            </div>
            I'm not sure I'd use the words "semantics" - it becomes an
            error.=C2=A0 Just like "int x" is an error depending on prior
            declarations - ie if x was already declared.<br>
            <div>Runtime behaviour doesn't change - it either compiles
              or doesn't.<br>
              <br>
            </div>
            <div>#if FOO<br>
              int x =3D 17;<br>
            </div>
            <div>#endif<br>
              int x =3D 21; // Woo hoo "semantics" (compile or not)
              depends on prior declarations<br>
              <br>
            </div>
            <div>#if FOO<br>
              int _ =3D 17;<br>
            </div>
            <div>#endif<br>
            </div>
            <div>int _ =3D 18; // this is immune to prior declarations!
              better than x!<br>
            </div>
            <div>return _ * _; // Woo hoo "semantics" (compile or not)
              depends on prior declarations<br>
              <br>
              <br>
            </div>
            <div><br>
              <br>
              =C2=A0<br>
            </div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <span class=3D"gmail-"><br>
                &gt;&gt; &gt; auto copy =3D _; // error: _ because
                anonymous, but was reused<br>
                &gt;&gt;<br>
                &gt;&gt; How is that backwards compatible?<br>
                &gt;&gt;<br>
                &gt;<br>
                &gt; You currently can't have 2 _ variables in the same
                scope. That last line is<br>
                &gt; in the context of "doesn't compile today".<br>
                <br>
              </span>auto _ =3D whatever;<br>
              auto copy =3D _;<br>
              <br>
              compiles fine, today.<br>
              <span class=3D"gmail-"><br>
              </span></blockquote>
            <div><br>
            </div>
            <div>Sure.=C2=A0 My example was in this context:<br>
              <br>
              int _ =3D f(); // might be anon
              <div>int _ =3D g(); // OK, definitely anonymous</div>
              <div>int _ =3D h(); // sure</div>
              int x =3D _; // error: _ was anonymous, ambiguous us<br>
              <br>
            </div>
            <div>There is no need/possibility for backwards
              compatibility here.=C2=A0 The three _ declarations already me=
an
              we aren't in Kansas anymore.<br>
              <br>
            </div>
            <div>Maybe I'm not explaining this well?<br>
              <br>
            </div>
            <div>Also, I'm not saying it is the best idea in the world,
              just that it is possible to use _ as an anonymous variable
              in a way that is backwards compatible.<br>
            </div>
            <div>So step 1 is agree or disagree on whether it really is
              BC.<br>
              Step 2 can be saying you just don't like it, even just
              because "_ shouldn't be special".<br>
            </div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    To be sure I understand. _ becomes anonymous once there are two
    different declarations named _.<br>
    From one side I like it because it allows some kind of anomymous
    variables, however this means that the reader don't know that _ is
    anonymous until the whole scope is inspected. <br>
    If we restrict __ as I proposed we don't have this downside. Onely
    the standard library authors need to change any non-anonymous use of
    __.<br>
    <br>
    Vicente<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5a83ee4f-8193-78db-126f-d2f5c044526d%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5a83ee4f-8193-78db-126f-d2f5c044526d=
%40wanadoo.fr</a>.<br />

--------------2B704EB552BB3307639B9A8E--

.

On 3 August 2017 at 07:02, Tony V E <tvaneerd@gmail.com> wrote:
>> > Currently reusing a variable name in the same scope is an error, so I'm
>> > saying - for _ only - don't make it an error. Make it mean "_ is now
>> > anonymous for the rest of this scope"
>>
>> Woo hoo, context-specific semantics that silently change depending on
>> prior declarations
>> or lack of them in the same scope. NO.
>
>
> I'm not sure I'd use the words "semantics" - it becomes an error.  Just like

Yes, it conditionally becomes an error. Sometimes it doesn't. That is
not a sane solution
for programmers, even if we would be willing to stomach such a hack.
And an additional
part of the problem is this:

Handle _ = something();
// let's not actually use it much anywhere

Handle _ = something();
// now let's start using it:
f(_);

All good so far. Now, a tad differently:

Handle _ = something();
Handle _ = something_else();

"Great", still works. Now we add the call,

Handle _ = something();
Handle _ = something_else();
f(_);

and the program is ill-formed. Explaining that would be hard.

Find another solution.

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

.

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

On Thu, Aug 3, 2017 at 6:38 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 3 August 2017 at 07:02, Tony V E <tvaneerd@gmail.com> wrote:
> >> > Currently reusing a variable name in the same scope is an error, so
> I'm
> >> > saying - for _ only - don't make it an error. Make it mean "_ is now
> >> > anonymous for the rest of this scope"
> >>
> >> Woo hoo, context-specific semantics that silently change depending on
> >> prior declarations
> >> or lack of them in the same scope. NO.
> >
> >
> > I'm not sure I'd use the words "semantics" - it becomes an error.  Just
> like
>
> Yes, it conditionally becomes an error. Sometimes it doesn't. That is
> not a sane solution
> for programmers, even if we would be willing to stomach such a hack.
> And an additional
> part of the problem is this:
>
> Handle _ = something();
> // let's not actually use it much anywhere
>
> Handle _ = something();
> // now let's start using it:
> f(_);
>
> All good so far. Now, a tad differently:
>
> Handle _ = something();
> Handle _ = something_else();
>
> "Great", still works. Now we add the call,
>
> Handle _ = something();
> Handle _ = something_else();
> f(_);
>
> and the program is ill-formed. Explaining that would be hard.
>
> Find another solution.
>
>

I actually don't think it would be that hard.  I would probably
*eventually* make using _ as a variable (ie non-anonymous) deprecated.
ie teach it as only use it as anonymous (which is probably the typical case
already), and other usage is just there for old-times-sake.

But I see your point.


I don't like

    auto [] = foo();

because that might lead to

    auto [x,y] = Point3D(1,2,3); // drop Z

and then you lose the chance of catching an error there.
(In fact auto [] = foo(); should maybe imply foo() returns void)
I think

    auto [x,y,...] = Point3D(1,2,3);

is more clear.
That leads to

auto [...] = foo(); // anonymous variable



--
Be seeing you,
Tony

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

--94eb2c0672dadf17460555e35192
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 Thu, Aug 3, 2017 at 6:38 AM, Ville Voutilainen <span dir=3D"ltr">&lt=
;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vou=
tilainen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span class=3D"">On 3 August 2017 at 07:02, Tony V E &lt;<a href=3D"mailto:=
tvaneerd@gmail.com">tvaneerd@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; Currently reusing a variable name in the same scope is an err=
or, so I&#39;m<br>
&gt;&gt; &gt; saying - for _ only - don&#39;t make it an error. Make it mea=
n &quot;_ is now<br>
&gt;&gt; &gt; anonymous for the rest of this scope&quot;<br>
&gt;&gt;<br>
&gt;&gt; Woo hoo, context-specific semantics that silently change depending=
 on<br>
&gt;&gt; prior declarations<br>
&gt;&gt; or lack of them in the same scope. NO.<br>
&gt;<br>
&gt;<br>
&gt; I&#39;m not sure I&#39;d use the words &quot;semantics&quot; - it beco=
mes an error.=C2=A0 Just like<br>
<br>
</span>Yes, it conditionally becomes an error. Sometimes it doesn&#39;t. Th=
at is<br>
not a sane solution<br>
for programmers, even if we would be willing to stomach such a hack.<br>
And an additional<br>
part of the problem is this:<br>
<br>
Handle _ =3D something();<br>
// let&#39;s not actually use it much anywhere<br>
<br>
Handle _ =3D something();<br>
// now let&#39;s start using it:<br>
f(_);<br>
<br>
All good so far. Now, a tad differently:<br>
<br>
Handle _ =3D something();<br>
Handle _ =3D something_else();<br>
<br>
&quot;Great&quot;, still works. Now we add the call,<br>
<br>
Handle _ =3D something();<br>
Handle _ =3D something_else();<br>
f(_);<br>
<br>
and the program is ill-formed. Explaining that would be hard.<br>
<br>
Find another solution.<br>
<span class=3D""><br></span></blockquote><div><br><br></div><div>I actually=
 don&#39;t think it would be that hard.=C2=A0 I would probably *eventually*=
 make using _ as a variable (ie non-anonymous) deprecated.<br></div><div>ie=
 teach it as only use it as anonymous (which is probably the typical case a=
lready), and other usage is just there for old-times-sake.<br><br></div><di=
v>But I see your point.<br><br></div></div><br></div><div class=3D"gmail_ex=
tra">I don&#39;t like<br></div><div class=3D"gmail_extra"><br>=C2=A0=C2=A0=
=C2=A0 auto [] =3D foo();<br><br></div><div class=3D"gmail_extra">because t=
hat might lead to<br></div><div class=3D"gmail_extra"><br>=C2=A0=C2=A0=C2=
=A0 auto [x,y] =3D Point3D(1,2,3); // drop Z<br><br></div><div class=3D"gma=
il_extra">and then you lose the chance of catching an error there.<br></div=
><div class=3D"gmail_extra">(In fact auto [] =3D foo(); should maybe imply =
foo() returns void)<br></div><div class=3D"gmail_extra">I think<br><br></di=
v><div class=3D"gmail_extra">=C2=A0=C2=A0=C2=A0 auto [x,y,...] =3D Point3D(=
1,2,3); <br></div><div class=3D"gmail_extra"><br>is more clear.<br></div><d=
iv class=3D"gmail_extra">That leads to<br><br></div><div class=3D"gmail_ext=
ra">auto [...] =3D foo(); // anonymous variable<br><br><br></div><div class=
=3D"gmail_extra"><br>-- <br><div class=3D"gmail_signature" data-smartmail=
=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br>=
</div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbis2nEEzQoGQKRsJjj0qUYCgQ7VJgAjc=
dFzZ_3PB3TEJYQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbis2nEEzQoGQ=
KRsJjj0qUYCgQ7VJgAjcdFzZ_3PB3TEJYQ%40mail.gmail.com</a>.<br />

--94eb2c0672dadf17460555e35192--

.

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

Le 04/08/2017 =C3=A0 03:21, Tony V E a =C3=A9crit :
>
>
> On Thu, Aug 3, 2017 at 6:38 AM, Ville Voutilainen=20
> <ville.voutilainen@gmail.com <mailto:ville.voutilainen@gmail.com>> wrote:
>
>     On 3 August 2017 at 07:02, Tony V E <tvaneerd@gmail.com
>     <mailto:tvaneerd@gmail.com>> wrote:
>
>     Yes, it conditionally becomes an error. Sometimes it doesn't. That is
>     not a sane solution
>     for programmers, even if we would be willing to stomach such a hack.
>     And an additional
>     part of the problem is this:
>
>     Handle _ =3D something();
>     // let's not actually use it much anywhere
>
>     Handle _ =3D something();
>     // now let's start using it:
>     f(_);
>
>     All good so far. Now, a tad differently:
>
>     Handle _ =3D something();
>     Handle _ =3D something_else();
>
>     "Great", still works. Now we add the call,
>
>     Handle _ =3D something();
>     Handle _ =3D something_else();
>     f(_);
>
>     and the program is ill-formed. Explaining that would be hard.
>
>     Find another solution.
>
>
>
> I actually don't think it would be that hard.  I would probably=20
> *eventually* make using _ as a variable (ie non-anonymous) deprecated.
> ie teach it as only use it as anonymous (which is probably the typical=20
> case already), and other usage is just there for old-times-sake.
>
> But I see your point.
>
>
> I don't like
>
>     auto [] =3D foo();
>
> because that might lead to
>
>     auto [x,y] =3D Point3D(1,2,3); // drop Z
>
> and then you lose the chance of catching an error there.
> (In fact auto [] =3D foo(); should maybe imply foo() returns void)
> I think
>
>     auto [x,y,...] =3D Point3D(1,2,3);
>
> is more clear.
> That leads to
>
> auto [...] =3D foo(); // anonymous variable
>
>
Only if foo() returns a product-type. In order to make this a real=20
anonymous variable we need to extend structure binding to support any=20
type that is not a product type now as a product type of one element or=20
add a specific grammar for the case [...].

I really would prefer the use of '__' (two '_') as anonymous=20
variable/name and deprecate it as a valid variable as you suggested for '_'=
..
Are there any strong arguments against this?

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d5c8a5ba-72f3-1f6a-2c93-aa0bffdacfa3%40wanadoo.f=
r.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 04/08/2017 =C3=A0 03:21, Tony V E a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite"
cite=3D"mid:CAOHCbis2nEEzQoGQKRsJjj0qUYCgQ7VJgAjcdFzZ_3PB3TEJYQ@mail.gmail.=
com">
      <div dir=3D"ltr"><br>
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">On Thu, Aug 3, 2017 at 6:38 AM, Ville
            Voutilainen <span dir=3D"ltr">&lt;<a
                href=3D"mailto:ville.voutilainen@gmail.com"
                target=3D"_blank" moz-do-not-send=3D"true">ville.voutilaine=
n@gmail.com</a>&gt;</span>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
                class=3D"">On 3 August 2017 at 07:02, Tony V E &lt;<a
                  href=3D"mailto:tvaneerd@gmail.com"
                  moz-do-not-send=3D"true">tvaneerd@gmail.com</a>&gt;
                wrote:<br>
                <br>
              </span>Yes, it conditionally becomes an error. Sometimes
              it doesn't. That is<br>
              not a sane solution<br>
              for programmers, even if we would be willing to stomach
              such a hack.<br>
              And an additional<br>
              part of the problem is this:<br>
              <br>
              Handle _ =3D something();<br>
              // let's not actually use it much anywhere<br>
              <br>
              Handle _ =3D something();<br>
              // now let's start using it:<br>
              f(_);<br>
              <br>
              All good so far. Now, a tad differently:<br>
              <br>
              Handle _ =3D something();<br>
              Handle _ =3D something_else();<br>
              <br>
              "Great", still works. Now we add the call,<br>
              <br>
              Handle _ =3D something();<br>
              Handle _ =3D something_else();<br>
              f(_);<br>
              <br>
              and the program is ill-formed. Explaining that would be
              hard.<br>
              <br>
              Find another solution.<br>
              <span class=3D""><br>
              </span></blockquote>
            <div><br>
              <br>
            </div>
            <div>I actually don't think it would be that hard.=C2=A0 I woul=
d
              probably *eventually* make using _ as a variable (ie
              non-anonymous) deprecated.<br>
            </div>
            <div>ie teach it as only use it as anonymous (which is
              probably the typical case already), and other usage is
              just there for old-times-sake.<br>
              <br>
            </div>
            <div>But I see your point.<br>
              <br>
            </div>
          </div>
          <br>
        </div>
        <div class=3D"gmail_extra">I don't like<br>
        </div>
        <div class=3D"gmail_extra"><br>
          =C2=A0=C2=A0=C2=A0 auto [] =3D foo();<br>
          <br>
        </div>
        <div class=3D"gmail_extra">because that might lead to<br>
        </div>
        <div class=3D"gmail_extra"><br>
          =C2=A0=C2=A0=C2=A0 auto [x,y] =3D Point3D(1,2,3); // drop Z<br>
          <br>
        </div>
        <div class=3D"gmail_extra">and then you lose the chance of
          catching an error there.<br>
        </div>
        <div class=3D"gmail_extra">(In fact auto [] =3D foo(); should maybe
          imply foo() returns void)<br>
        </div>
        <div class=3D"gmail_extra">I think<br>
          <br>
        </div>
        <div class=3D"gmail_extra">=C2=A0=C2=A0=C2=A0 auto [x,y,...] =3D Po=
int3D(1,2,3); <br>
        </div>
        <div class=3D"gmail_extra"><br>
          is more clear.<br>
        </div>
        <div class=3D"gmail_extra">That leads to<br>
          <br>
        </div>
        <div class=3D"gmail_extra">auto [...] =3D foo(); // anonymous
          variable<br>
          <br>
          <br>
        </div>
      </div>
    </blockquote>
    Only if foo() returns a product-type. In order to make this a real
    anonymous variable we need to extend structure binding to support
    any type that is not a product type now as a product type of one
    element or add a specific grammar for the case [...].<br>
    <br>
    I really would prefer the use of '__' (two '_') as anonymous
    variable/name and deprecate it as a valid variable as you suggested
    for '_'.<br>
    Are there any strong arguments against this?<br>
    <br>
    Vicente <br>
    <br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d5c8a5ba-72f3-1f6a-2c93-aa0bffdacfa3%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d5c8a5ba-72f3-1f6a-2c93-aa0bffdacfa3=
%40wanadoo.fr</a>.<br />

--------------A252ECCB7753307C91988756--

.

On 4 August 2017 at 04:21, Tony V E <tvaneerd@gmail.com> wrote:
>> and the program is ill-formed. Explaining that would be hard.
>>
>> Find another solution.
>>
>
>
> I actually don't think it would be that hard.  I would probably *eventually*

It involves answering questions like "what kind of idiots are you
people who design this language?".
That's the hard part, especially trying to explain that they aren't
when the person doing the
explaining can't do so honestly.

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

.

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

On 08/03/2017 09:21 PM, Tony V E wrote:
>
> I don't like
>
>     auto [] = foo();
>
> because that might lead to
>
>     auto [x,y] = Point3D(1,2,3); // drop Z
>
> and then you lose the chance of catching an error there.

I've heard this argument before, but I don't really understand it. If
the user needs the undeclared binding, I would expect them to pretty
quickly notice its absence.  If the undeclared binding isn't needed,
then why should the user be forced to name it?  I appreciate that,
depending on how the feature is defined, there could be an observable
difference when binding tuple-like types if calls to get<>() were elided
for undeclared bindings (assuming that the call to get<>() had side
effects), but such eliding seems like it would be desirable in the
general case.

Tom.

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 08/03/2017 09:21 PM, Tony V E wrote:<=
br>
    </div>
    <blockquote
cite=3D"mid:CAOHCbis2nEEzQoGQKRsJjj0qUYCgQ7VJgAjcdFzZ_3PB3TEJYQ@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <div class=3D"gmail_extra">I don't like<br>
        </div>
        <div class=3D"gmail_extra"><br>
          =C2=A0=C2=A0=C2=A0 auto [] =3D foo();<br>
          <br>
        </div>
        <div class=3D"gmail_extra">because that might lead to<br>
        </div>
        <div class=3D"gmail_extra"><br>
          =C2=A0=C2=A0=C2=A0 auto [x,y] =3D Point3D(1,2,3); // drop Z<br>
          <br>
        </div>
        <div class=3D"gmail_extra">and then you lose the chance of
          catching an error there.<br>
        </div>
      </div>
    </blockquote>
    <br>
    I've heard this argument before, but I don't really understand it.=C2=
=A0
    If the user needs the undeclared binding, I would expect them to
    pretty quickly notice its absence.=C2=A0 If the undeclared binding isn'=
t
    needed, then why should the user be forced to name it?=C2=A0 I apprecia=
te
    that, depending on how the feature is defined, there could be an
    observable difference when binding tuple-like types if calls to
    get&lt;&gt;() were elided for undeclared bindings (assuming that the
    call to get&lt;&gt;() had side effects), but such eliding seems like
    it would be desirable in the general case.<br>
    <br>
    Tom.<br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/286128b6-119c-0946-4104-20282db2974a%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/286128b6-119c-0946-4104-20282db29=
74a%40honermann.net</a>.<br />

--------------FE14EB0D62DA41630A4D077A--

.

------=_Part_974_1576244886.1501867336689
Content-Type: multipart/alternative;
 boundary="----=_Part_975_852197466.1501867336689"

------=_Part_975_852197466.1501867336689
Content-Type: text/plain; charset="UTF-8"



On Friday, August 4, 2017 at 12:56:33 PM UTC-4, Tom Honermann wrote:
>
> On 08/03/2017 09:21 PM, Tony V E wrote:
>
>
> I don't like
>
>     auto [] = foo();
>
> because that might lead to
>
>     auto [x,y] = Point3D(1,2,3); // drop Z
>
> and then you lose the chance of catching an error there.
>
>
> I've heard this argument before, but I don't really understand it.  If the
> user needs the undeclared binding, I would expect them to pretty quickly
> notice its absence.  If the undeclared binding isn't needed, then why
> should the user be forced to name it?  I appreciate that, depending on how
> the feature is defined, there could be an observable difference when
> binding tuple-like types if calls to get<>() were elided for undeclared
> bindings (assuming that the call to get<>() had side effects), but such
> eliding seems like it would be desirable in the general case.
>

What if the user *actually* meant to call something different?

auto [x, y, z] = some_func(...);
vs
auto [x, y] = some_func(...);

Whether the user uses `z` is not relevant. What matters most is that the
user called a function that returns 3 values. If the latter compiles, then
there is an inconsistency between what the user specified (2 values) and
what the API specified (3 values).

Such inconsistencies are usually considered compile errors. They certainly
are when you call a function that takes 3 parameters, but you only provide
2. Why should return values be any different?

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

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

<div dir=3D"ltr"><br><br>On Friday, August 4, 2017 at 12:56:33 PM UTC-4, To=
m Honermann wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>On 08/03/2017 09:21 PM, Tony V E wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        <div>I don&#39;t like<br>
        </div>
        <div><br>
          =C2=A0=C2=A0=C2=A0 auto [] =3D foo();<br>
          <br>
        </div>
        <div>because that might lead to<br>
        </div>
        <div><br>
          =C2=A0=C2=A0=C2=A0 auto [x,y] =3D Point3D(1,2,3); // drop Z<br>
          <br>
        </div>
        <div>and then you lose the chance of
          catching an error there.<br>
        </div>
      </div>
    </blockquote>
    <br>
    I&#39;ve heard this argument before, but I don&#39;t really understand =
it.=C2=A0
    If the user needs the undeclared binding, I would expect them to
    pretty quickly notice its absence.=C2=A0 If the undeclared binding isn&=
#39;t
    needed, then why should the user be forced to name it?=C2=A0 I apprecia=
te
    that, depending on how the feature is defined, there could be an
    observable difference when binding tuple-like types if calls to
    get&lt;&gt;() were elided for undeclared bindings (assuming that the
    call to get&lt;&gt;() had side effects), but such eliding seems like
    it would be desirable in the general case.<br></div></blockquote><div><=
br>What if the user <i>actually</i> meant to call something different?<br><=
br><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-=
word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> z</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> some_func</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(...);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>vs<br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> y</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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> some_func</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(...);</span></div></code=
></div><br>Whether the user uses `z` is not relevant. What matters most is =
that the user called a function that returns 3 values. If the latter compil=
es, then there is an inconsistency between what the user specified (2 value=
s) and what the API specified (3 values).<br><br>Such inconsistencies are u=
sually considered compile errors. They certainly are when you call a functi=
on that takes 3 parameters, but you only provide 2. Why should return value=
s be any different?<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/845711ad-5876-4fbd-a264-ffdb140bb9ba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/845711ad-5876-4fbd-a264-ffdb140bb9ba=
%40isocpp.org</a>.<br />

------=_Part_975_852197466.1501867336689--

------=_Part_974_1576244886.1501867336689--

.

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

On 08/04/2017 01:22 PM, Nicol Bolas wrote:
>
>
> On Friday, August 4, 2017 at 12:56:33 PM UTC-4, Tom Honermann wrote:
>
>     On 08/03/2017 09:21 PM, Tony V E wrote:
>>
>>     I don't like
>>
>>         auto [] = foo();
>>
>>     because that might lead to
>>
>>         auto [x,y] = Point3D(1,2,3); // drop Z
>>
>>     and then you lose the chance of catching an error there.
>
>     I've heard this argument before, but I don't really understand
>     it.  If the user needs the undeclared binding, I would expect them
>     to pretty quickly notice its absence.  If the undeclared binding
>     isn't needed, then why should the user be forced to name it?  I
>     appreciate that, depending on how the feature is defined, there
>     could be an observable difference when binding tuple-like types if
>     calls to get<>() were elided for undeclared bindings (assuming
>     that the call to get<>() had side effects), but such eliding seems
>     like it would be desirable in the general case.
>
>
> What if the user /actually/ meant to call something different?
>
> |
> auto[x,y,z]=some_func(...);
> vs
> auto[x,y]=some_func(...);
> |
>
> Whether the user uses `z` is not relevant. What matters most is that
> the user called a function that returns 3 values. If the latter
> compiles, then there is an inconsistency between what the user
> specified (2 values) and what the API specified (3 values).
>
> Such inconsistencies are usually considered compile errors. They
> certainly are when you call a function that takes 3 parameters, but
> you only provide 2. Why should return values be any different?

Well, it isn't an error to call a function that takes 3 arguments when
only 2 are provided if the function declaration supplies a default
argument for the 3rd.

I don't find this argument compelling.  There is only one return type
and the return type does not influence overload resolution.  To me, this
sounds like an argument against use of the 'auto' type specifier at all
- what if the user meant to call a function returning some class type
instead of std::tuple?  The ability to omit declarations for unwanted
bindings seems more useful to me than the opportunity to catch cases
where an unintended function was called.

Tom.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/838b2785-853e-41ee-79f8-4de6b51b3185%40honermann.net.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 08/04/2017 01:22 PM, Nicol Bolas
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:845711ad-5876-4fbd-a264-ffdb140bb9ba@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        On Friday, August 4, 2017 at 12:56:33 PM UTC-4, Tom Honermann
        wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>On 08/03/2017 09:21 PM, Tony V E wrote:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <div>I don't like<br>
                </div>
                <div><br>
                  =C2=A0=C2=A0=C2=A0 auto [] =3D foo();<br>
                  <br>
                </div>
                <div>because that might lead to<br>
                </div>
                <div><br>
                  =C2=A0=C2=A0=C2=A0 auto [x,y] =3D Point3D(1,2,3); // drop=
 Z<br>
                  <br>
                </div>
                <div>and then you lose the chance of catching an error
                  there.<br>
                </div>
              </div>
            </blockquote>
            <br>
            I've heard this argument before, but I don't really
            understand it.=C2=A0 If the user needs the undeclared binding, =
I
            would expect them to pretty quickly notice its absence.=C2=A0 I=
f
            the undeclared binding isn't needed, then why should the
            user be forced to name it?=C2=A0 I appreciate that, depending o=
n
            how the feature is defined, there could be an observable
            difference when binding tuple-like types if calls to
            get&lt;&gt;() were elided for undeclared bindings (assuming
            that the call to get&lt;&gt;() had side effects), but such
            eliding seems like it would be desirable in the general
            case.<br>
          </div>
        </blockquote>
        <div><br>
          What if the user <i>actually</i> meant to call something
          different?<br>
          <br>
          <div style=3D"background-color: rgb(250, 250, 250);
            border-color: rgb(187, 187, 187); border-style: solid;
            border-width: 1px; overflow-wrap: break-word;"
            class=3D"prettyprint"><code class=3D"prettyprint">
              <div class=3D"subprettyprint"><span style=3D"color: #008;"
                  class=3D"styled-by-prettify">auto</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">[</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify">x</sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> y</s=
pan><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> z</s=
pan><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">]</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify">
                  some_func</span><span style=3D"color: #660;"
                  class=3D"styled-by-prettify">(...);</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"><br>
                  vs<br>
                </span><span style=3D"color: #008;"
                  class=3D"styled-by-prettify">auto</span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">[</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify">x</sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> y</s=
pan><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">]</sp=
an><span
                  style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
                  style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span
                  style=3D"color: #000;" class=3D"styled-by-prettify">
                  some_func</span><span style=3D"color: #660;"
                  class=3D"styled-by-prettify">(...);</span></div>
            </code></div>
          <br>
          Whether the user uses `z` is not relevant. What matters most
          is that the user called a function that returns 3 values. If
          the latter compiles, then there is an inconsistency between
          what the user specified (2 values) and what the API specified
          (3 values).<br>
          <br>
          Such inconsistencies are usually considered compile errors.
          They certainly are when you call a function that takes 3
          parameters, but you only provide 2. Why should return values
          be any different?</div>
      </div>
    </blockquote>
    <br>
    Well, it isn't an error to call a function that takes 3 arguments
    when only 2 are provided if the function declaration supplies a
    default argument for the 3rd.<br>
    <br>
    I don't find this argument compelling.=C2=A0 There is only one return
    type and the return type does not influence overload resolution.=C2=A0 =
To
    me, this sounds like an argument against use of the 'auto' type
    specifier at all - what if the user meant to call a function
    returning some class type instead of std::tuple?=C2=A0 The ability to
    omit declarations for unwanted bindings seems more useful to me than
    the opportunity to catch cases where an unintended function was
    called.<br>
    <br>
    Tom.<br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/838b2785-853e-41ee-79f8-4de6b51b3185%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/838b2785-853e-41ee-79f8-4de6b51b3=
185%40honermann.net</a>.<br />

--------------146D8DD23D8417CB804981AB--

.

------=_Part_243_1396644352.1501903918262
Content-Type: multipart/alternative;
 boundary="----=_Part_244_821205236.1501903918263"

------=_Part_244_821205236.1501903918263
Content-Type: text/plain; charset="UTF-8"

On Friday, August 4, 2017 at 6:04:05 PM UTC-4, Tom Honermann wrote:
>
> On 08/04/2017 01:22 PM, Nicol Bolas wrote:
>
> On Friday, August 4, 2017 at 12:56:33 PM UTC-4, Tom Honermann wrote:
>>
>> On 08/03/2017 09:21 PM, Tony V E wrote:
>>
>>
>> I don't like
>>
>>     auto [] = foo();
>>
>> because that might lead to
>>
>>     auto [x,y] = Point3D(1,2,3); // drop Z
>>
>> and then you lose the chance of catching an error there.
>>
>>
>> I've heard this argument before, but I don't really understand it.  If
>> the user needs the undeclared binding, I would expect them to pretty
>> quickly notice its absence.  If the undeclared binding isn't needed, then
>> why should the user be forced to name it?  I appreciate that, depending on
>> how the feature is defined, there could be an observable difference when
>> binding tuple-like types if calls to get<>() were elided for undeclared
>> bindings (assuming that the call to get<>() had side effects), but such
>> eliding seems like it would be desirable in the general case.
>>
>
> What if the user *actually* meant to call something different?
>
> auto [x, y, z] = some_func(...);
> vs
> auto [x, y] = some_func(...);
>
> Whether the user uses `z` is not relevant. What matters most is that the
> user called a function that returns 3 values. If the latter compiles, then
> there is an inconsistency between what the user specified (2 values) and
> what the API specified (3 values).
>
> Such inconsistencies are usually considered compile errors. They certainly
> are when you call a function that takes 3 parameters, but you only provide
> 2. Why should return values be any different?
>
>
> Well, it isn't an error to call a function that takes 3 arguments when
> only 2 are provided if the function declaration supplies a default argument
> for the 3rd.
>

Which requires explicit syntax to be used on the function declaration. By
your logic, to have a function return 3 values, but the caller only take
two should also require explicit syntax in the function declaration.

I don't find this argument compelling.  There is only one return type and
> the return type does not influence overload resolution. To me, this sounds
> like an argument against use of the 'auto' type specifier at all -
>

.... how?

My argument is that returning multiple values is conceptually identical to
*passing* multiple values. Therefore, if the compiler gives an error when
you pass 2 values to a function that takes 3, then by analogy, a function
which returns 3 values should give an error if you only accept 2.

This is not about which overload you take or that you're using `auto` or
anything of that sort.


> what if the user meant to call a function returning some class type
> instead of std::tuple?
>

I'm gonna ignore the fact that `std::tuple` is very much a class type.

By using `auto []`, you're conceptually saying that you *don't care* what
actual type a function returns. What you care about is that it returns a
type which is decomposable into a number of values, and it is those values
that you want access to.

So by saying `auto [a, b] = foo(c, d)`, you're creating a contract that
checks two things:

1) `foo` is a callable-thing that can take two values as arguments.
2) `foo`, when taking 2 values, returns a type that is decomposable into 2
values.

Note that this is not "decomposable into *at least* 2 values". Just like
`foo` is not "a callable-thing that can take *at least* two values as
arguments".

If you want to play your default-arguments game, then we should have some
decomposable machinery that *explicitly* has the type advertise that one or
more of the values can be ignored. But this would be an innate part of the
type itself.


> The ability to omit declarations for unwanted bindings seems more useful
> to me than the opportunity to catch cases where an unintended function was
> called.
>

I'm more concerned about why you're omitting values so frequently from a
multi-value return.

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

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

<div dir=3D"ltr">On Friday, August 4, 2017 at 6:04:05 PM UTC-4, Tom Honerma=
nn wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>On 08/04/2017 01:22 PM, Nicol Bolas
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">On Friday, August 4, 2017 at 12:56:33 PM UTC-4, Tom =
Honermann
        wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>On 08/03/2017 09:21 PM, Tony V E wrote:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
                <div>I don&#39;t like<br>
                </div>
                <div><br>
                  =C2=A0=C2=A0=C2=A0 auto [] =3D foo();<br>
                  <br>
                </div>
                <div>because that might lead to<br>
                </div>
                <div><br>
                  =C2=A0=C2=A0=C2=A0 auto [x,y] =3D Point3D(1,2,3); // drop=
 Z<br>
                  <br>
                </div>
                <div>and then you lose the chance of catching an error
                  there.<br>
                </div>
              </div>
            </blockquote>
            <br>
            I&#39;ve heard this argument before, but I don&#39;t really
            understand it.=C2=A0 If the user needs the undeclared binding, =
I
            would expect them to pretty quickly notice its absence.=C2=A0 I=
f
            the undeclared binding isn&#39;t needed, then why should the
            user be forced to name it?=C2=A0 I appreciate that, depending o=
n
            how the feature is defined, there could be an observable
            difference when binding tuple-like types if calls to
            get&lt;&gt;() were elided for undeclared bindings (assuming
            that the call to get&lt;&gt;() had side effects), but such
            eliding seems like it would be desirable in the general
            case.<br>
          </div>
        </blockquote>
        <div><br>
          What if the user <i>actually</i> meant to call something
          different?<br>
          <br>
          <div style=3D"background-color:rgb(250,250,250);border-color:rgb(=
187,187,187);border-style:solid;border-width:1px"><code>
              <div><span style=3D"color:#008">auto</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">[</span><span style=3D"color:#0=
00">x</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> =
y</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> z</s=
pan><span style=3D"color:#660">]</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">=3D</span><span style=3D"color:#000">
                  some_func</span><span style=3D"color:#660">(...);</span><=
span style=3D"color:#000"><br>
                  vs<br>
                </span><span style=3D"color:#008">auto</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">[</span><span style=3D"colo=
r:#000">x</span><span style=3D"color:#660">,</span><span style=3D"color:#00=
0"> y</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">
                  some_func</span><span style=3D"color:#660">(...);</span><=
/div>
            </code></div>
          <br>
          Whether the user uses `z` is not relevant. What matters most
          is that the user called a function that returns 3 values. If
          the latter compiles, then there is an inconsistency between
          what the user specified (2 values) and what the API specified
          (3 values).<br>
          <br>
          Such inconsistencies are usually considered compile errors.
          They certainly are when you call a function that takes 3
          parameters, but you only provide 2. Why should return values
          be any different?</div>
      </div>
    </blockquote>
    <br>
    Well, it isn&#39;t an error to call a function that takes 3 arguments
    when only 2 are provided if the function declaration supplies a
    default argument for the 3rd.<br></div></blockquote><div><br>Which requ=
ires explicit syntax to be used on the function declaration. By your logic,=
 to have a function return 3 values, but the caller only take two should al=
so require explicit syntax in the function declaration.<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#00=
0000">
   =20
    I don&#39;t find this argument compelling.=C2=A0 There is only one retu=
rn
    type and the return type does not influence overload resolution. To
    me, this sounds like an argument against use of the &#39;auto&#39; type
    specifier at all -</div></blockquote><div><br>... how?<br><br>My argume=
nt is that returning multiple values is conceptually identical to <i>passin=
g</i> multiple values. Therefore, if the compiler gives an error when you p=
ass 2 values to a function that takes 3, then by analogy, a function which =
returns 3 values should give an error if you only accept 2.<br><br>This is =
not about which overload you take or that you&#39;re using `auto` or anythi=
ng of that sort.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div bgcolor=3D"#FFFFFF" text=3D"#000000">what if the user meant to call =
a function
    returning some class type instead of std::tuple?</div></blockquote><div=
><br>I&#39;m gonna ignore the fact that `std::tuple` is very much a class t=
ype.<br><br>By using `auto []`, you&#39;re conceptually saying that you <i>=
don&#39;t care</i> what actual type a function returns. What you care about=
 is that it returns a type which is decomposable into a number of values, a=
nd it is those values that you want access to.<br><br>So by saying `auto [a=
, b] =3D foo(c, d)`, you&#39;re creating a contract that checks two things:=
<br><br>1) `foo` is a callable-thing that can take two values as arguments.=
<br>2) `foo`, when taking 2 values, returns a type that is decomposable int=
o 2 values.<br><br>Note that this is not &quot;decomposable into <i>at leas=
t</i> 2 values&quot;. Just like `foo` is not &quot;a callable-thing that ca=
n take <i>at least</i> two values as arguments&quot;.<br><br>If you want to=
 play your default-arguments game, then we should have some decomposable ma=
chinery that <i>explicitly</i> has the type advertise that one or more of t=
he values can be ignored. But this would be an innate part of the type itse=
lf.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolo=
r=3D"#FFFFFF" text=3D"#000000">The ability to
    omit declarations for unwanted bindings seems more useful to me than
    the opportunity to catch cases where an unintended function was
    called.<br></div></blockquote><div><br>I&#39;m more concerned about why=
 you&#39;re omitting values so frequently from a multi-value return. <br></=
div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a7835d7c-5354-4520-b5f5-acbd31697cbc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a7835d7c-5354-4520-b5f5-acbd31697cbc=
%40isocpp.org</a>.<br />

------=_Part_244_821205236.1501903918263--

------=_Part_243_1396644352.1501903918262--

.

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

What about:

auto [...] =3D product_type;
auto ... =3D any_type;

Literally, "..." following a type and preceding an assignment would mean an
anonymous variable.
As well as within structured binding, as suggested previously.

Just bickesheeding, not aware of possible implementation challenges. :)



On Fri, Aug 4, 2017 at 1:29 AM Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

> Le 04/08/2017 =C3=A0 03:21, Tony V E a =C3=A9crit :
>
> On Thu, Aug 3, 2017 at 6:38 AM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
> On 3 August 2017 at 07:02, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> Yes, it conditionally becomes an error. Sometimes it doesn't. That is
>> not a sane solution
>> for programmers, even if we would be willing to stomach such a hack.
>> And an additional
>> part of the problem is this:
>>
>> Handle _ =3D something();
>> // let's not actually use it much anywhere
>>
>> Handle _ =3D something();
>> // now let's start using it:
>> f(_);
>>
>> All good so far. Now, a tad differently:
>>
>> Handle _ =3D something();
>> Handle _ =3D something_else();
>>
>> "Great", still works. Now we add the call,
>>
>> Handle _ =3D something();
>> Handle _ =3D something_else();
>> f(_);
>>
>> and the program is ill-formed. Explaining that would be hard.
>>
>> Find another solution.
>>
>>
>
> I actually don't think it would be that hard.  I would probably
> *eventually* make using _ as a variable (ie non-anonymous) deprecated.
> ie teach it as only use it as anonymous (which is probably the typical
> case already), and other usage is just there for old-times-sake.
>
> But I see your point.
>
> I don't like
>
>     auto [] =3D foo();
>
> because that might lead to
>
>     auto [x,y] =3D Point3D(1,2,3); // drop Z
>
> and then you lose the chance of catching an error there.
> (In fact auto [] =3D foo(); should maybe imply foo() returns void)
> I think
>
>     auto [x,y,...] =3D Point3D(1,2,3);
>
> is more clear.
> That leads to
>
> auto [...] =3D foo(); // anonymous variable
>
>
> Only if foo() returns a product-type. In order to make this a real
> anonymous variable we need to extend structure binding to support any typ=
e
> that is not a product type now as a product type of one element or add a
> specific grammar for the case [...].
>
> I really would prefer the use of '__' (two '_') as anonymous variable/nam=
e
> and deprecate it as a valid variable as you suggested for '_'.
> Are there any strong arguments against this?
>
> Vicente
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d5c8a5ba-72f=
3-1f6a-2c93-aa0bffdacfa3%40wanadoo.fr
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d5c8a5ba-72=
f3-1f6a-2c93-aa0bffdacfa3%40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

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

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

<div dir=3D"auto">What about:</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">auto [...] =3D product_type;</div><div dir=3D"auto">auto ... =3D any_=
type;</div><div dir=3D"auto"><br></div><div dir=3D"auto">Literally, &quot;.=
...&quot; following a type and preceding an assignment would mean an anonymo=
us variable.</div><div dir=3D"auto">As well as within structured binding, a=
s suggested previously.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Just bickesheeding, not aware of possible implementation challenges. :)</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div><br><div cla=
ss=3D"gmail_quote"><div>On Fri, Aug 4, 2017 at 1:29 AM Vicente J. Botet Esc=
riba &lt;<a href=3D"mailto:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.=
fr</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text=3D"#000=
000" bgcolor=3D"#FFFFFF">
    <div class=3D"m_-8575700496523673894moz-cite-prefix">Le 04/08/2017 =C3=
=A0 03:21, Tony V E a
      =C3=A9crit=C2=A0:<br>
    </div>
    </div><div text=3D"#000000" bgcolor=3D"#FFFFFF"><blockquote type=3D"cit=
e"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Thu, Aug 3=
, 2017 at 6:38 AM, Ville
            Voutilainen <span>&lt;<a href=3D"mailto:ville.voutilainen@gmail=
..com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span>
            wrote:<br>
            </div></div></div></blockquote></div><div text=3D"#000000" bgco=
lor=3D"#FFFFFF"><blockquote type=3D"cite"><div><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 3 August =
2017 at 07:02, Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D=
"_blank">tvaneerd@gmail.com</a>&gt;
                wrote:<br>
                <br>
              </span></blockquote></div></div></div></blockquote></div><div=
 text=3D"#000000" bgcolor=3D"#FFFFFF"><blockquote type=3D"cite"><div><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">Yes, it conditionally becomes an error. Sometimes
              it doesn&#39;t. That is<br>
              not a sane solution<br>
              for programmers, even if we would be willing to stomach
              such a hack.<br>
              And an additional<br>
              part of the problem is this:<br>
              <br>
              Handle _ =3D something();<br>
              // let&#39;s not actually use it much anywhere<br>
              <br>
              Handle _ =3D something();<br>
              // now let&#39;s start using it:<br>
              f(_);<br>
              <br>
              All good so far. Now, a tad differently:<br>
              <br>
              Handle _ =3D something();<br>
              Handle _ =3D something_else();<br>
              <br>
              &quot;Great&quot;, still works. Now we add the call,<br>
              <br>
              Handle _ =3D something();<br>
              Handle _ =3D something_else();<br>
              f(_);<br>
              <br>
              and the program is ill-formed. Explaining that would be
              hard.<br>
              <br>
              Find another solution.<br>
              <span><br>
              </span></blockquote></div></div></div></blockquote></div><div=
 text=3D"#000000" bgcolor=3D"#FFFFFF"><blockquote type=3D"cite"><div><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote">
            <div><br>
              <br>
            </div>
            <div>I actually don&#39;t think it would be that hard.=C2=A0 I =
would
              probably *eventually* make using _ as a variable (ie
              non-anonymous) deprecated.<br>
            </div>
            <div>ie teach it as only use it as anonymous (which is
              probably the typical case already), and other usage is
              just there for old-times-sake.<br>
              <br>
            </div>
            <div>But I see your point.<br>
              <br>
            </div>
          </div></div></div></blockquote></div><div text=3D"#000000" bgcolo=
r=3D"#FFFFFF"><blockquote type=3D"cite"><div>
        <div class=3D"gmail_extra">I don&#39;t like<br>
        </div>
        <div class=3D"gmail_extra"><br>
          =C2=A0=C2=A0=C2=A0 auto [] =3D foo();<br>
          <br>
        </div>
        <div class=3D"gmail_extra">because that might lead to<br>
        </div>
        <div class=3D"gmail_extra"><br>
          =C2=A0=C2=A0=C2=A0 auto [x,y] =3D Point3D(1,2,3); // drop Z<br>
          <br>
        </div>
        <div class=3D"gmail_extra">and then you lose the chance of
          catching an error there.<br>
        </div>
        <div class=3D"gmail_extra">(In fact auto [] =3D foo(); should maybe
          imply foo() returns void)<br>
        </div>
        <div class=3D"gmail_extra">I think<br>
          <br>
        </div>
        <div class=3D"gmail_extra">=C2=A0=C2=A0=C2=A0 auto [x,y,...] =3D Po=
int3D(1,2,3); <br>
        </div>
        <div class=3D"gmail_extra"><br>
          is more clear.<br>
        </div>
        <div class=3D"gmail_extra">That leads to<br>
          <br>
        </div>
        <div class=3D"gmail_extra">auto [...] =3D foo(); // anonymous
          variable<br>
          <br>
          <br>
        </div>
      </div></blockquote></div><div text=3D"#000000" bgcolor=3D"#FFFFFF"><b=
lockquote type=3D"cite"><div></div>
    </blockquote>
    Only if foo() returns a product-type. In order to make this a real
    anonymous variable we need to extend structure binding to support
    any type that is not a product type now as a product type of one
    element or add a specific grammar for the case [...].<br>
    <br>
    I really would prefer the use of &#39;__&#39; (two &#39;_&#39;) as anon=
ymous
    variable/name and deprecate it as a valid variable as you suggested
    for &#39;_&#39;.<br>
    Are there any strong arguments against this?<br>
    <br>
    Vicente <br>
    <br>
  </div>


<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d5c8a5ba-72f3-1f6a-2c93-aa0bffdacfa3%=
40wanadoo.fr?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d5c8a5ba-72f3-=
1f6a-2c93-aa0bffdacfa3%40wanadoo.fr</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbMwKfBzZrKnRZr6P2%3DPjhg8Hs3W=
YCOz%3DHwun4bkm2TUiA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbMw=
KfBzZrKnRZr6P2%3DPjhg8Hs3WYCOz%3DHwun4bkm2TUiA%40mail.gmail.com</a>.<br />

--94eb2c149218cc947b055605ae71--

.

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

On 08/04/2017 11:31 PM, Nicol Bolas wrote:
> On Friday, August 4, 2017 at 6:04:05 PM UTC-4, Tom Honermann wrote:
>
>     On 08/04/2017 01:22 PM, Nicol Bolas wrote:
>>     On Friday, August 4, 2017 at 12:56:33 PM UTC-4, Tom Honermann wrote:
>>
>>         On 08/03/2017 09:21 PM, Tony V E wrote:
>>>
>>>         I don't like
>>>
>>>             auto [] = foo();
>>>
>>>         because that might lead to
>>>
>>>             auto [x,y] = Point3D(1,2,3); // drop Z
>>>
>>>         and then you lose the chance of catching an error there.
>>
>>         I've heard this argument before, but I don't really
>>         understand it.  If the user needs the undeclared binding, I
>>         would expect them to pretty quickly notice its absence.  If
>>         the undeclared binding isn't needed, then why should the user
>>         be forced to name it?  I appreciate that, depending on how
>>         the feature is defined, there could be an observable
>>         difference when binding tuple-like types if calls to get<>()
>>         were elided for undeclared bindings (assuming that the call
>>         to get<>() had side effects), but such eliding seems like it
>>         would be desirable in the general case.
>>
>>
>>     What if the user /actually/ meant to call something different?
>>
>>     |
>>     auto[x,y,z]=some_func(...);
>>     vs
>>     auto[x,y]=some_func(...);
>>     |
>>
>>     Whether the user uses `z` is not relevant. What matters most is
>>     that the user called a function that returns 3 values. If the
>>     latter compiles, then there is an inconsistency between what the
>>     user specified (2 values) and what the API specified (3 values).
>>
>>     Such inconsistencies are usually considered compile errors. They
>>     certainly are when you call a function that takes 3 parameters,
>>     but you only provide 2. Why should return values be any different?
>
>     Well, it isn't an error to call a function that takes 3 arguments
>     when only 2 are provided if the function declaration supplies a
>     default argument for the 3rd.
>
>
> Which requires explicit syntax to be used on the function declaration.
> By your logic, to have a function return 3 values, but the caller only
> take two should also require explicit syntax in the function declaration.

It was you that made the comparison between decomposing the return type
and function arguments, not me.  I was just pointing out that your
argument was incomplete; that arguments need not be provided if default
arguments are available.

>
>     I don't find this argument compelling.  There is only one return
>     type and the return type does not influence overload resolution.
>     To me, this sounds like an argument against use of the 'auto' type
>     specifier at all -
>
>
> ... how?

In the absence of decomposition, 'auto' imposes no constraints on the
return type.  You're arguing that, in the presence of decomposition,
constraints be added that exceed the minimum constraints necessary to
satisfy the binding list.  To me, that sounds similar to concerns I've
heard that using 'auto' removes convertibility constraints that would
otherwise be checked.

>
> My argument is that returning multiple values is conceptually
> identical to /passing/ multiple values. Therefore, if the compiler
> gives an error when you pass 2 values to a function that takes 3, then
> by analogy, a function which returns 3 values should give an error if
> you only accept 2.

I understand the argument, I just don't agree with it.  Again,
contrasting with default arguments, if a function can supply default
arguments for arguments not explicitly provided, why can a caller not
omit return values that it does not require?

>
> This is not about which overload you take or that you're using `auto`
> or anything of that sort.

That seems to be what your argument is though; that the binding list be
employed to diagnose potential issues with call resolution (including
overload resolution) beyond that which is strictly necessary.

>     what if the user meant to call a function returning some class
>     type instead of std::tuple?
>
>
> I'm gonna ignore the fact that `std::tuple` is very much a class type.

I thought the distinction was clear enough; decomposition works
differently for std::tuple vs non-customized class types.

>
> By using `auto []`, you're conceptually saying that you /don't care/
> what actual type a function returns. What you care about is that it
> returns a type which is decomposable into a number of values, and it
> is those values that you want access to.

Yes, that I agree with.

>
> So by saying `auto [a, b] = foo(c, d)`, you're creating a contract
> that checks two things:
>
> 1) `foo` is a callable-thing that can take two values as arguments.
> 2) `foo`, when taking 2 values, returns a type that is decomposable
> into 2 values.

I don't agree with the 2nd part.  Or, rather, I agree there is more than
one rational behavior.  I see there being a minimal constraint that the
return type be decomposable into *at least* 2 values. Constraining the
decomposition to exactly 2 values goes beyond what is minimally
necessary.  In my view, requiring the arity to match is over constraining.

>
> Note that this is not "decomposable into /at least/ 2 values". Just
> like `foo` is not "a callable-thing that can take /at least/ two
> values as arguments".

'foo' may be an invokable that takes more than two values if it defines
default arguments or is variadic.

>
> If you want to play your default-arguments game, then we should have
> some decomposable machinery that /explicitly/ has the type advertise
> that one or more of the values can be ignored. But this would be an
> innate part of the type itself.

I don't see motivation for that.  Nor would I want that to be part of
the type.  It might be reasonable to impose a same-arity constraint if
the function is declared with [[nodiscard]] though.

>     The ability to omit declarations for unwanted bindings seems more
>     useful to me than the opportunity to catch cases where an
>     unintended function was called.
>
>
> I'm more concerned about why you're omitting values so frequently from
> a multi-value return.

Consider insertion into a container where one is unconcerned with
whether the insertion was successful.  I'd rather not have to name the
2nd binding.

void f(my_set s, my_value v) {
   auto [it] = s.insert(v);
}

That is just one example of a class of functions that returns values
that are not always applicable to the caller.  There are many such
functions.

Tom.

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 08/04/2017 11:31 PM, Nicol Bolas
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:a7835d7c-5354-4520-b5f5-acbd31697cbc@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">On Friday, August 4, 2017 at 6:04:05 PM UTC-4, Tom
        Honermann wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>On 08/04/2017 01:22 PM, Nicol Bolas wrote:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr">On Friday, August 4, 2017 at 12:56:33 PM
                UTC-4, Tom Honermann wrote:
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                    <div>On 08/03/2017 09:21 PM, Tony V E wrote:<br>
                    </div>
                    <blockquote type=3D"cite">
                      <div dir=3D"ltr"><br>
                        <div>I don't like<br>
                        </div>
                        <div><br>
                          =C2=A0=C2=A0=C2=A0 auto [] =3D foo();<br>
                          <br>
                        </div>
                        <div>because that might lead to<br>
                        </div>
                        <div><br>
                          =C2=A0=C2=A0=C2=A0 auto [x,y] =3D Point3D(1,2,3);=
 // drop Z<br>
                          <br>
                        </div>
                        <div>and then you lose the chance of catching an
                          error there.<br>
                        </div>
                      </div>
                    </blockquote>
                    <br>
                    I've heard this argument before, but I don't really
                    understand it.=C2=A0 If the user needs the undeclared
                    binding, I would expect them to pretty quickly
                    notice its absence.=C2=A0 If the undeclared binding isn=
't
                    needed, then why should the user be forced to name
                    it?=C2=A0 I appreciate that, depending on how the featu=
re
                    is defined, there could be an observable difference
                    when binding tuple-like types if calls to
                    get&lt;&gt;() were elided for undeclared bindings
                    (assuming that the call to get&lt;&gt;() had side
                    effects), but such eliding seems like it would be
                    desirable in the general case.<br>
                  </div>
                </blockquote>
                <div><br>
                  What if the user <i>actually</i> meant to call
                  something different?<br>
                  <br>
                  <div
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px"><code>
                      <div><span style=3D"color:#008">auto</span><span
                          style=3D"color:#000"> </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"> y</span><span
                          style=3D"color:#660">,</span><span
                          style=3D"color:#000"> z</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"> some_func</span><span
                          style=3D"color:#660">(...);</span><span
                          style=3D"color:#000"><br>
                          vs<br>
                        </span><span style=3D"color:#008">auto</span><span
                          style=3D"color:#000"> </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"> y</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"> some_func</span><span
                          style=3D"color:#660">(...);</span></div>
                    </code></div>
                  <br>
                  Whether the user uses `z` is not relevant. What
                  matters most is that the user called a function that
                  returns 3 values. If the latter compiles, then there
                  is an inconsistency between what the user specified (2
                  values) and what the API specified (3 values).<br>
                  <br>
                  Such inconsistencies are usually considered compile
                  errors. They certainly are when you call a function
                  that takes 3 parameters, but you only provide 2. Why
                  should return values be any different?</div>
              </div>
            </blockquote>
            <br>
            Well, it isn't an error to call a function that takes 3
            arguments when only 2 are provided if the function
            declaration supplies a default argument for the 3rd.<br>
          </div>
        </blockquote>
        <div><br>
          Which requires explicit syntax to be used on the function
          declaration. By your logic, to have a function return 3
          values, but the caller only take two should also require
          explicit syntax in the function declaration.<br>
        </div>
      </div>
    </blockquote>
    <br>
    It was you that made the comparison between decomposing the return
    type and function arguments, not me.=C2=A0 I was just pointing out that
    your argument was incomplete; that arguments need not be provided if
    default arguments are available.<br>
    <br>
    <blockquote
      cite=3D"mid:a7835d7c-5354-4520-b5f5-acbd31697cbc@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000"> I don't find this
            argument compelling.=C2=A0 There is only one return type and th=
e
            return type does not influence overload resolution. To me,
            this sounds like an argument against use of the 'auto' type
            specifier at all -</div>
        </blockquote>
        <div><br>
          ... how?<br>
        </div>
      </div>
    </blockquote>
    <br>
    In the absence of decomposition, 'auto' imposes no constraints on
    the return type.=C2=A0 You're arguing that, in the presence of
    decomposition, constraints be added that exceed the minimum
    constraints necessary to satisfy the binding list.=C2=A0 To me, that
    sounds similar to concerns I've heard that using 'auto' removes
    convertibility constraints that would otherwise be checked.<br>
    <br>
    <blockquote
      cite=3D"mid:a7835d7c-5354-4520-b5f5-acbd31697cbc@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          My argument is that returning multiple values is conceptually
          identical to <i>passing</i> multiple values. Therefore, if
          the compiler gives an error when you pass 2 values to a
          function that takes 3, then by analogy, a function which
          returns 3 values should give an error if you only accept 2.<br>
        </div>
      </div>
    </blockquote>
    <br>
    I understand the argument, I just don't agree with it.=C2=A0 Again,
    contrasting with default arguments, if a function can supply default
    arguments for arguments not explicitly provided, why can a caller
    not omit return values that it does not require?<br>
    <br>
    <blockquote
      cite=3D"mid:a7835d7c-5354-4520-b5f5-acbd31697cbc@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          This is not about which overload you take or that you're using
          `auto` or anything of that sort.<br>
        </div>
      </div>
    </blockquote>
    <br>
    That seems to be what your argument is though; that the binding list
    be employed to diagnose potential issues with call resolution
    (including overload resolution) beyond that which is strictly
    necessary.<br>
    <br>
    <blockquote
      cite=3D"mid:a7835d7c-5354-4520-b5f5-acbd31697cbc@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>=C2=A0</div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">what if the user meant
            to call a function returning some class type instead of
            std::tuple?</div>
        </blockquote>
        <div><br>
          I'm gonna ignore the fact that `std::tuple` is very much a
          class type.<br>
        </div>
      </div>
    </blockquote>
    <br>
    I thought the distinction was clear enough; decomposition works
    differently for std::tuple vs non-customized class types.<br>
    <br>
    <blockquote
      cite=3D"mid:a7835d7c-5354-4520-b5f5-acbd31697cbc@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          By using `auto []`, you're conceptually saying that you <i>don't
            care</i> what actual type a function returns. What you care
          about is that it returns a type which is decomposable into a
          number of values, and it is those values that you want access
          to.<br>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, that I agree with.<br>
    <br>
    <blockquote
      cite=3D"mid:a7835d7c-5354-4520-b5f5-acbd31697cbc@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          So by saying `auto [a, b] =3D foo(c, d)`, you're creating a
          contract that checks two things:<br>
          <br>
          1) `foo` is a callable-thing that can take two values as
          arguments.<br>
          2) `foo`, when taking 2 values, returns a type that is
          decomposable into 2 values.<br>
        </div>
      </div>
    </blockquote>
    <br>
    I don't agree with the 2nd part.=C2=A0 Or, rather, I agree there is mor=
e
    than one rational behavior.=C2=A0 I see there being a minimal constrain=
t
    that the return type be decomposable into *at least* 2 values.=C2=A0
    Constraining the decomposition to exactly 2 values goes beyond what
    is minimally necessary.=C2=A0 In my view, requiring the arity to match =
is
    over constraining.<br>
    <br>
    <blockquote
      cite=3D"mid:a7835d7c-5354-4520-b5f5-acbd31697cbc@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          Note that this is not "decomposable into <i>at least</i> 2
          values". Just like `foo` is not "a callable-thing that can
          take <i>at least</i> two values as arguments".<br>
        </div>
      </div>
    </blockquote>
    <br>
    'foo' may be an invokable that takes more than two values if it
    defines default arguments or is variadic.<br>
    <br>
    <blockquote
      cite=3D"mid:a7835d7c-5354-4520-b5f5-acbd31697cbc@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
          If you want to play your default-arguments game, then we
          should have some decomposable machinery that <i>explicitly</i>
          has the type advertise that one or more of the values can be
          ignored. But this would be an innate part of the type itself.<br>
        </div>
      </div>
    </blockquote>
    <br>
    I don't see motivation for that.=C2=A0 Nor would I want that to be part
    of the type.=C2=A0 It might be reasonable to impose a same-arity
    constraint if the function is declared with [[nodiscard]] though.<br>
    <br>
    <blockquote
      cite=3D"mid:a7835d7c-5354-4520-b5f5-acbd31697cbc@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>=C2=A0</div>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">The ability to omit
            declarations for unwanted bindings seems more useful to me
            than the opportunity to catch cases where an unintended
            function was called.<br>
          </div>
        </blockquote>
        <div><br>
          I'm more concerned about why you're omitting values so
          frequently from a multi-value return. <br>
        </div>
      </div>
    </blockquote>
    <br>
    Consider insertion into a container where one is unconcerned with
    whether the insertion was successful.=C2=A0 I'd rather not have to name
    the 2nd binding.<br>
    <br>
    void f(my_set s, my_value v) {<br>
    =C2=A0 auto [it] =3D s.insert(v);<br>
    }<br>
    <br>
    That is just one example of a class of functions that returns values
    that are not always applicable to the caller.=C2=A0 There are many such
    functions.<br>
    <br>
    Tom.<br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f57e1d5e-16a5-26e1-c014-441ff82ec6d4%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/f57e1d5e-16a5-26e1-c014-441ff82ec=
6d4%40honermann.net</a>.<br />

--------------00F3A63CAB941F156B97D77B--

.

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

On 08/03/2017 09:21 PM, Tony V E wrote:
>
> I don't like
>
>     auto [] = foo();
>
> because that might lead to
>
>     auto [x,y] = Point3D(1,2,3); // drop Z
>
> and then you lose the chance of catching an error there.
> (In fact auto [] = foo(); should maybe imply foo() returns void)

There is an additional trade off here.  Since callers are currently
required to name each binding, compilers can't (reasonably) warn about
unused bindings.  P0609R0 [1] proposed allowing attributes in binding
declarations and that would have enabled specifying [[maybe_unused]] for
particular cases, but EWG declined to move that forward in Toronto.  The
ability to elide names for unneeded bindings would allow compilers to
issue warnings:

void f() {
   auto [w, [], y] = get_wxyz(); // ignore x and z.
   w;
} // warn that y is unused.

Tom.

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0609r0.pdf

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 08/03/2017 09:21 PM, Tony V E wrote:<=
br>
    </div>
    <blockquote
cite=3D"mid:CAOHCbis2nEEzQoGQKRsJjj0qUYCgQ7VJgAjcdFzZ_3PB3TEJYQ@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <div class=3D"gmail_extra">I don't like<br>
        </div>
        <div class=3D"gmail_extra"><br>
          =C2=A0=C2=A0=C2=A0 auto [] =3D foo();<br>
          <br>
        </div>
        <div class=3D"gmail_extra">because that might lead to<br>
        </div>
        <div class=3D"gmail_extra"><br>
          =C2=A0=C2=A0=C2=A0 auto [x,y] =3D Point3D(1,2,3); // drop Z<br>
          <br>
        </div>
        <div class=3D"gmail_extra">and then you lose the chance of
          catching an error there.<br>
        </div>
        <div class=3D"gmail_extra">(In fact auto [] =3D foo(); should maybe
          imply foo() returns void)</div>
      </div>
    </blockquote>
    <br>
    There is an additional trade off here.=C2=A0 Since callers are currentl=
y
    required to name each binding, compilers can't (reasonably) warn
    about unused bindings.=C2=A0 P0609R0 [1] proposed allowing attributes i=
n
    binding declarations and that would have enabled specifying
    [[maybe_unused]] for particular cases, but EWG declined to move that
    forward in Toronto.=C2=A0 The ability to elide names for unneeded
    bindings would allow compilers to issue warnings:<br>
    <br>
    void f() {<br>
    =C2=A0 auto [w, [], y] =3D get_wxyz(); // ignore x and z.<br>
    =C2=A0 w;<br>
    } // warn that y is unused.<br>
    <br>
    Tom.<br>
    <br>
    [1]:
    <a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2017/p0609r0.pdf">http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2017/p0609r0.pdf</a><br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f89b3a1e-b876-0ceb-d2af-a8d908ae7a73%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/f89b3a1e-b876-0ceb-d2af-a8d908ae7=
a73%40honermann.net</a>.<br />

--------------3798C6318B0FCBF564B10586--

.

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

On Sun, Aug 6, 2017 at 8:08 PM, Tom Honermann <tom@honermann.net> wrote:

> On 08/03/2017 09:21 PM, Tony V E wrote:
>
>
> I don't like
>
>     auto [] = foo();
>
> because that might lead to
>
>     auto [x,y] = Point3D(1,2,3); // drop Z
>
> and then you lose the chance of catching an error there.
> (In fact auto [] = foo(); should maybe imply foo() returns void)
>
>
> There is an additional trade off here.  Since callers are currently
> required to name each binding, compilers can't (reasonably) warn about
> unused bindings.  P0609R0 [1] proposed allowing attributes in binding
> declarations and that would have enabled specifying [[maybe_unused]] for
> particular cases, but EWG declined to move that forward in Toronto.  The
> ability to elide names for unneeded bindings would allow compilers to issue
> warnings:
>
> void f() {
>   auto [w, [], y] = get_wxyz(); // ignore x and z.
>   w;
> } // warn that y is unused.
>
> Tom.
>
> [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0609r0.pdf
>
>
>

Speaking of w,

// thing.h
Point3D getPoint();

// user.cpp
auto [x,y] = getPoint(); // just want x,y, don't care about z

.....
later

// thing.h
Point4D getPoint(); // update: now also returns w

// user.cpp
auto [x,y] = getPoint(); // just want x, y, but I got w,x


As a library writer, I've lost some ability to change API, because what was
a compile time error is now a run time error.

Not sure if that's a big issue, but it does open up a new wrinkle.

Yes, I also find this similar to 'auto' vs constrained (and I prefer
constrained)

auto foo = getFoo();
auto total = foo + bar;

Did you mean that to work with strings, or just Numbers?  Is it OK if '/'
means concatenate (for paths)? (of course I doubt getFoo() will change one
day from Number to path)

Just like Concepts expose the requirements on types for templates,
Concepts can also expose the requirements on types for the code that
follows the declaration.
Now, I doubt auto is as problematic as T is in unconstrained templates, but
it is basically the same thing.

--
Be seeing you,
Tony

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

--94eb2c0701ae5b4f7505561f1ac9
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 Sun, Aug 6, 2017 at 8:08 PM, Tom Honermann <span dir=3D"ltr">&lt;<a =
href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@honermann.net</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    <div class=3D"m_1771962484749336057moz-cite-prefix">On 08/03/2017 09:21=
 PM, Tony V E wrote:<br>
    </div>
    </span><span class=3D""><blockquote type=3D"cite">
      <div dir=3D"ltr"><br>
        <div class=3D"gmail_extra">I don&#39;t like<br>
        </div>
        <div class=3D"gmail_extra"><br>
          =C2=A0=C2=A0=C2=A0 auto [] =3D foo();<br>
          <br>
        </div>
        <div class=3D"gmail_extra">because that might lead to<br>
        </div>
        <div class=3D"gmail_extra"><br>
          =C2=A0=C2=A0=C2=A0 auto [x,y] =3D Point3D(1,2,3); // drop Z<br>
          <br>
        </div>
        <div class=3D"gmail_extra">and then you lose the chance of
          catching an error there.<br>
        </div>
        <div class=3D"gmail_extra">(In fact auto [] =3D foo(); should maybe
          imply foo() returns void)</div>
      </div>
    </blockquote>
    <br></span>
    There is an additional trade off here.=C2=A0 Since callers are currentl=
y
    required to name each binding, compilers can&#39;t (reasonably) warn
    about unused bindings.=C2=A0 P0609R0 [1] proposed allowing attributes i=
n
    binding declarations and that would have enabled specifying
    [[maybe_unused]] for particular cases, but EWG declined to move that
    forward in Toronto.=C2=A0 The ability to elide names for unneeded
    bindings would allow compilers to issue warnings:<br>
    <br>
    void f() {<br>
    =C2=A0 auto [w, [], y] =3D get_wxyz(); // ignore x and z.<br>
    =C2=A0 w;<br>
    } // warn that y is unused.<br>
    <br>
    Tom.<br>
    <br>
    [1]:
    <a class=3D"m_1771962484749336057moz-txt-link-freetext" href=3D"http://=
www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0609r0.pdf" target=3D"_bl=
ank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2017/<wbr>p060=
9r0.pdf</a><br>
  </div><span class=3D"">


<p></p>

<br></span></blockquote><div><br><br></div><div>Speaking of w,<br><br></div=
><div>// thing.h<br></div><div>Point3D getPoint();<br><br></div><div>// use=
r.cpp<br></div><div>auto [x,y] =3D getPoint(); // just want x,y, don&#39;t =
care about z<br><br>....<br></div><div>later <br></div></div><br></div><div=
 class=3D"gmail_extra">// thing.h<br></div><div class=3D"gmail_extra">Point=
4D getPoint(); // update: now also returns w<br><br></div><div class=3D"gma=
il_extra">// user.cpp<br></div><div class=3D"gmail_extra">auto [x,y] =3D ge=
tPoint(); // just want x, y, but I got w,x<br clear=3D"all"></div><div clas=
s=3D"gmail_extra"><br><br></div><div class=3D"gmail_extra">As a library wri=
ter, I&#39;ve lost some ability to change API, because what was a compile t=
ime error is now a run time error.<br><br></div><div class=3D"gmail_extra">=
Not sure if that&#39;s a big issue, but it does open up a new wrinkle.<br><=
br></div><div class=3D"gmail_extra">Yes, I also find this similar to &#39;a=
uto&#39; vs constrained (and I prefer constrained)<br><br></div><div class=
=3D"gmail_extra">auto foo =3D getFoo();<br></div><div class=3D"gmail_extra"=
>auto total =3D foo + bar;<br><br></div><div class=3D"gmail_extra">Did you =
mean that to work with strings, or just Numbers?=C2=A0 Is it OK if &#39;/&#=
39; means concatenate (for paths)? (of course I doubt getFoo() will change =
one day from Number to path)<br><br></div><div class=3D"gmail_extra">Just l=
ike Concepts expose the requirements on types for templates,<br></div><div =
class=3D"gmail_extra">Concepts can also expose the requirements on types fo=
r the code that follows the declaration.<br></div><div class=3D"gmail_extra=
">Now, I doubt auto is as problematic as T is in unconstrained templates, b=
ut it is basically the same thing.<br><br></div><div class=3D"gmail_extra">=
-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><d=
iv dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitBtOpidq9TWVUF7zM2Mw7KpR3CoC%2=
Bk8o2%2BoAeyACELJA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitBtOpi=
dq9TWVUF7zM2Mw7KpR3CoC%2Bk8o2%2BoAeyACELJA%40mail.gmail.com</a>.<br />

--94eb2c0701ae5b4f7505561f1ac9--

.

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

On 08/06/2017 08:41 PM, Tony V E wrote:
>
>
> On Sun, Aug 6, 2017 at 8:08 PM, Tom Honermann <tom@honermann.net
> <mailto:tom@honermann.net>> wrote:
>
>     On 08/03/2017 09:21 PM, Tony V E wrote:
>>
>>     I don't like
>>
>>         auto [] = foo();
>>
>>     because that might lead to
>>
>>         auto [x,y] = Point3D(1,2,3); // drop Z
>>
>>     and then you lose the chance of catching an error there.
>>     (In fact auto [] = foo(); should maybe imply foo() returns void)
>
>     There is an additional trade off here.  Since callers are
>     currently required to name each binding, compilers can't
>     (reasonably) warn about unused bindings.  P0609R0 [1] proposed
>     allowing attributes in binding declarations and that would have
>     enabled specifying [[maybe_unused]] for particular cases, but EWG
>     declined to move that forward in Toronto.  The ability to elide
>     names for unneeded bindings would allow compilers to issue warnings:
>
>     void f() {
>       auto [w, [], y] = get_wxyz(); // ignore x and z.
>       w;
>     } // warn that y is unused.
>
>     Tom.
>
>     [1]:
>     http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0609r0.pdf
>     <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0609r0.pdf>
>
>
>
> Speaking of w,
>
> // thing.h
> Point3D getPoint();
>
> // user.cpp
> auto [x,y] = getPoint(); // just want x,y, don't care about z
>
> ....
> later
>
> // thing.h
> Point4D getPoint(); // update: now also returns w
>
> // user.cpp
> auto [x,y] = getPoint(); // just want x, y, but I got w,x
>
>
> As a library writer, I've lost some ability to change API, because
> what was a compile time error is now a run time error.
>
> Not sure if that's a big issue, but it does open up a new wrinkle.

That's certainly fair.  I'm likewise unsure how big a deal that is. My
gut tells me that, in most cases, a change in which value a declaration
binds to will also result in a change in type that is likely to produce
later errors; though that is unlikely to be the case with the example
above.  Regardless, the ability to change API in this way depends on the
ability to inflict compile time errors on callers and therefore already
has limits.

>
> Yes, I also find this similar to 'auto' vs constrained (and I prefer
> constrained)
>
> auto foo = getFoo();
> auto total = foo + bar;
>
> Did you mean that to work with strings, or just Numbers?  Is it OK if
> '/' means concatenate (for paths)? (of course I doubt getFoo() will
> change one day from Number to path)
>
> Just like Concepts expose the requirements on types for templates,
> Concepts can also expose the requirements on types for the code that
> follows the declaration.
> Now, I doubt auto is as problematic as T is in unconstrained
> templates, but it is basically the same thing.

Yup.  I generally restrict my use of auto to cases where the deduced
type is determined by an expression involving types that I've already
constrained.

Tom.

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 08/06/2017 08:41 PM, Tony V E wrote:<=
br>
    </div>
    <blockquote
cite=3D"mid:CAOHCbitBtOpidq9TWVUF7zM2Mw7KpR3CoC+k8o2+oAeyACELJA@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">On Sun, Aug 6, 2017 at 8:08 PM, Tom
            Honermann <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:tom@honermann.net" target=3D"_blank">tom@hon=
ermann.net</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 bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
                  <div class=3D"m_1771962484749336057moz-cite-prefix">On
                    08/03/2017 09:21 PM, Tony V E wrote:<br>
                  </div>
                </span><span class=3D"">
                  <blockquote type=3D"cite">
                    <div dir=3D"ltr"><br>
                      <div class=3D"gmail_extra">I don't like<br>
                      </div>
                      <div class=3D"gmail_extra"><br>
                        =C2=A0=C2=A0=C2=A0 auto [] =3D foo();<br>
                        <br>
                      </div>
                      <div class=3D"gmail_extra">because that might lead
                        to<br>
                      </div>
                      <div class=3D"gmail_extra"><br>
                        =C2=A0=C2=A0=C2=A0 auto [x,y] =3D Point3D(1,2,3); /=
/ drop Z<br>
                        <br>
                      </div>
                      <div class=3D"gmail_extra">and then you lose the
                        chance of catching an error there.<br>
                      </div>
                      <div class=3D"gmail_extra">(In fact auto [] =3D foo()=
;
                        should maybe imply foo() returns void)</div>
                    </div>
                  </blockquote>
                  <br>
                </span> There is an additional trade off here.=C2=A0 Since
                callers are currently required to name each binding,
                compilers can't (reasonably) warn about unused
                bindings.=C2=A0 P0609R0 [1] proposed allowing attributes in
                binding declarations and that would have enabled
                specifying [[maybe_unused]] for particular cases, but
                EWG declined to move that forward in Toronto.=C2=A0 The
                ability to elide names for unneeded bindings would allow
                compilers to issue warnings:<br>
                <br>
                void f() {<br>
                =C2=A0 auto [w, [], y] =3D get_wxyz(); // ignore x and z.<b=
r>
                =C2=A0 w;<br>
                } // warn that y is unused.<br>
                <br>
                Tom.<br>
                <br>
                [1]: <a moz-do-not-send=3D"true"
                  class=3D"m_1771962484749336057moz-txt-link-freetext"
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0609r0.pdf=
"
                  target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/=
wg21/docs/papers/2017/<wbr>p0609r0.pdf</a><br>
              </div>
              <span class=3D"">
                <br>
              </span></blockquote>
            <div><br>
              <br>
            </div>
            <div>Speaking of w,<br>
              <br>
            </div>
            <div>// thing.h<br>
            </div>
            <div>Point3D getPoint();<br>
              <br>
            </div>
            <div>// user.cpp<br>
            </div>
            <div>auto [x,y] =3D getPoint(); // just want x,y, don't care
              about z<br>
              <br>
              ....<br>
            </div>
            <div>later <br>
            </div>
          </div>
          <br>
        </div>
        <div class=3D"gmail_extra">// thing.h<br>
        </div>
        <div class=3D"gmail_extra">Point4D getPoint(); // update: now also
          returns w<br>
          <br>
        </div>
        <div class=3D"gmail_extra">// user.cpp<br>
        </div>
        <div class=3D"gmail_extra">auto [x,y] =3D getPoint(); // just want
          x, y, but I got w,x<br clear=3D"all">
        </div>
        <div class=3D"gmail_extra"><br>
          <br>
        </div>
        <div class=3D"gmail_extra">As a library writer, I've lost some
          ability to change API, because what was a compile time error
          is now a run time error.<br>
          <br>
        </div>
        <div class=3D"gmail_extra">Not sure if that's a big issue, but it
          does open up a new wrinkle.<br>
        </div>
      </div>
    </blockquote>
    <br>
    That's certainly fair.=C2=A0 I'm likewise unsure how big a deal that is=
..=C2=A0
    My gut tells me that, in most cases, a change in which value a
    declaration binds to will also result in a change in type that is
    likely to produce later errors; though that is unlikely to be the
    case with the example above.=C2=A0 Regardless, the ability to change AP=
I
    in this way depends on the ability to inflict compile time errors on
    callers and therefore already has limits.<br>
    <br>
    <blockquote
cite=3D"mid:CAOHCbitBtOpidq9TWVUF7zM2Mw7KpR3CoC+k8o2+oAeyACELJA@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra"><br>
        </div>
        <div class=3D"gmail_extra">Yes, I also find this similar to 'auto'
          vs constrained (and I prefer constrained)<br>
          <br>
        </div>
        <div class=3D"gmail_extra">auto foo =3D getFoo();<br>
        </div>
        <div class=3D"gmail_extra">auto total =3D foo + bar;<br>
          <br>
        </div>
        <div class=3D"gmail_extra">Did you mean that to work with strings,
          or just Numbers?=C2=A0 Is it OK if '/' means concatenate (for
          paths)? (of course I doubt getFoo() will change one day from
          Number to path)<br>
          <br>
        </div>
        <div class=3D"gmail_extra">Just like Concepts expose the
          requirements on types for templates,<br>
        </div>
        <div class=3D"gmail_extra">Concepts can also expose the
          requirements on types for the code that follows the
          declaration.<br>
        </div>
        <div class=3D"gmail_extra">Now, I doubt auto is as problematic as
          T is in unconstrained templates, but it is basically the same
          thing.</div>
      </div>
    </blockquote>
    <br>
    Yup.=C2=A0 I generally restrict my use of auto to cases where the deduc=
ed
    type is determined by an expression involving types that I've
    already constrained.<br>
    <br>
    Tom.<br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1b2e466c-728e-f9f7-4a20-c2282128f54a%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/1b2e466c-728e-f9f7-4a20-c2282128f=
54a%40honermann.net</a>.<br />

--------------0B53CCE5137B5B68C64AF28B--

.

On 2017-08-05 14:21, Ricardo Fabiano de Andrade wrote:
> What about:
>
> auto [...] = product_type;
> auto ... = any_type;
>
> Literally, "..." following a type and preceding an assignment would mean an
> anonymous variable.
> As well as within structured binding, as suggested previously.
>
> Just bickesheeding, not aware of possible implementation challenges. :)

I think this would be confusing with people expecting it to have some
relation to parameter packs. I think just `.` with otherwise the same
semantics has been suggested; I'd be in favor of that. Or possibly `..`.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2aef34b4-282a-07cf-794e-73b8e50eaf96%40gmail.com.

.