------=_Part_24_8736225.1484184847281
Content-Type: multipart/alternative;
 boundary="----=_Part_25_1835957559.1484184847281"

------=_Part_25_1835957559.1484184847281
Content-Type: text/plain; charset=UTF-8

Basically, just allow us to do this:

auto [] = whatever;

If you make that legal for all types, then what you effectively have is an
unnamed variable. Structured binding/decomposition declarations already
require that ability as a side effect of their primary work. We would just
be using that side effect directly.

Lazy decomposition already ensures that `get<I>` will only be called when a
decomposed name is used. So the idea of allowing any type to have zero
decompositions effectively allows any type to work here.

I'm not entirely sure about the grammar for this. If `auto[]` is useful in
some way, then that would make this idea non-functional.

So long as the grammar works out, I believe that we would need only two
changes to the standard:

1: The ability to specify a decomposition declaration with no names to
decompose to. The `identifier-list` in the grammer would simply be made
optional.

2: If there are no names in the decomposition declaration, then it skips
everything after [dcl.decomp]/1.

And presto: we allow people to have unnamed variables.

--
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/dae03b23-a771-4844-90dc-d3de39c03d47%40isocpp.org.

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

<div dir=3D"ltr">Basically, just allow us to do this:<br><br><div style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"p=
rettyprint"><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"> </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"> whatever</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span></div></code></div><br>If you make that legal for all =
types, then what you effectively have is an unnamed variable. Structured bi=
nding/decomposition declarations already require that ability as a side eff=
ect of their primary work. We would just be using that side effect directly=
..<br><br>Lazy decomposition already ensures that `get&lt;I&gt;` will only b=
e=20
called when a decomposed name is used. So the idea of allowing any type=20
to have zero decompositions effectively allows any type to work here.<br><b=
r>I&#39;m not entirely sure about the grammar for this. If `auto[]` is usef=
ul in some way, then that would make this idea non-functional.<br><br>So lo=
ng as the grammar works out, I believe that we would need only two changes =
to the standard:<br><br>1: The ability to specify a decomposition declarati=
on with no names to decompose to. The `identifier-list` in the grammer woul=
d simply be made optional.<br><br>2: If there are no names in the decomposi=
tion declaration, then it skips everything after [dcl.decomp]/1.<br><br>And=
 presto: we allow people to have unnamed variables.<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/dae03b23-a771-4844-90dc-d3de39c03d47%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dae03b23-a771-4844-90dc-d3de39c03d47=
%40isocpp.org</a>.<br />

------=_Part_25_1835957559.1484184847281--

------=_Part_24_8736225.1484184847281--

.

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

Can you provide an example on how you would use the unnamed variable?

On Wed, Jan 11, 2017 at 5:34 PM Nicol Bolas <jmckesson@gmail.com> wrote:

> Basically, just allow us to do this:
>
> auto [] = whatever;
>
> If you make that legal for all types, then what you effectively have is an
> unnamed variable. Structured binding/decomposition declarations already
> require that ability as a side effect of their primary work. We would just
> be using that side effect directly.
>
> Lazy decomposition already ensures that `get<I>` will only be
>
> called when a decomposed name is used. So the idea of allowing any type
>
> to have zero decompositions effectively allows any type to work here.
>
> I'm not entirely sure about the grammar for this. If `auto[]` is useful in
> some way, then that would make this idea non-functional.
>
> So long as the grammar works out, I believe that we would need only two
> changes to the standard:
>
> 1: The ability to specify a decomposition declaration with no names to
> decompose to. The `identifier-list` in the grammer would simply be made
> optional.
>
> 2: If there are no names in the decomposition declaration, then it skips
> everything after [dcl.decomp]/1.
>
> And presto: we allow people to have unnamed variables.
>
>
>
>
>
>
>
>
> --
>
>
> 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/dae03b23-a771-4844-90dc-d3de39c03d47%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dae03b23-a771-4844-90dc-d3de39c03d47%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
>
>

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

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

<div>Can you provide an example on how you would use the unnamed variable?=
=C2=A0</div><div><br><div class=3D"gmail_quote"><div>On Wed, Jan 11, 2017 a=
t 5:34 PM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@=
gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div cla=
ss=3D"gmail_msg">Basically, just allow us to do this:<br class=3D"gmail_msg=
"><br class=3D"gmail_msg"><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px" class=3D"=
m_-3832585184160196864prettyprint gmail_msg"><code class=3D"m_-383258518416=
0196864prettyprint gmail_msg"><div class=3D"m_-3832585184160196864subpretty=
print gmail_msg"><span style=3D"color:#008" class=3D"m_-3832585184160196864=
styled-by-prettify gmail_msg">auto</span><span style=3D"color:#000" class=
=3D"m_-3832585184160196864styled-by-prettify gmail_msg"> </span><span style=
=3D"color:#660" class=3D"m_-3832585184160196864styled-by-prettify gmail_msg=
">[]</span><span style=3D"color:#000" class=3D"m_-3832585184160196864styled=
-by-prettify gmail_msg"> </span><span style=3D"color:#660" class=3D"m_-3832=
585184160196864styled-by-prettify gmail_msg">=3D</span><span style=3D"color=
:#000" class=3D"m_-3832585184160196864styled-by-prettify gmail_msg"> whatev=
er</span><span style=3D"color:#660" class=3D"m_-3832585184160196864styled-b=
y-prettify gmail_msg">;</span></div></code></div><br class=3D"gmail_msg">If=
 you make that legal for all types, then what you effectively have is an un=
named variable. Structured binding/decomposition declarations already requi=
re that ability as a side effect of their primary work. We would just be us=
ing that side effect directly.<br class=3D"gmail_msg"><br class=3D"gmail_ms=
g">Lazy decomposition already ensures that `get&lt;I&gt;` will only be <br>=
<br>called when a decomposed name is used. So the idea of allowing any type=
 <br><br>to have zero decompositions effectively allows any type to work he=
re.<br class=3D"gmail_msg"><br class=3D"gmail_msg">I&#39;m not entirely sur=
e about the grammar for this. If `auto[]` is useful in some way, then that =
would make this idea non-functional.<br class=3D"gmail_msg"><br class=3D"gm=
ail_msg">So long as the grammar works out, I believe that we would need onl=
y two changes to the standard:<br class=3D"gmail_msg"><br class=3D"gmail_ms=
g">1: The ability to specify a decomposition declaration with no names to d=
ecompose to. The `identifier-list` in the grammer would simply be made opti=
onal.<br class=3D"gmail_msg"><br class=3D"gmail_msg">2: If there are no nam=
es in the decomposition declaration, then it skips everything after [dcl.de=
comp]/1.<br class=3D"gmail_msg"><br class=3D"gmail_msg">And presto: we allo=
w people to have unnamed variables.<br class=3D"gmail_msg"></div><br><br><b=
r><br><p class=3D"gmail_msg"></p><br><br><br><br>-- <br class=3D"gmail_msg"=
><br><br>You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br class=3D"=
gmail_msg"><br><br>To unsubscribe from this group and stop receiving emails=
 from it, send an email to <a href=3D"mailto:std-proposals+unsubscribe@isoc=
pp.org" class=3D"gmail_msg" target=3D"_blank">std-proposals+unsubscribe@iso=
cpp.org</a>.<br class=3D"gmail_msg"><br><br>To post to this group, send ema=
il to <a href=3D"mailto:std-proposals@isocpp.org" class=3D"gmail_msg" targe=
t=3D"_blank">std-proposals@isocpp.org</a>.<br class=3D"gmail_msg"><br><br>T=
o view this discussion on the web visit <a href=3D"https://groups.google.co=
m/a/isocpp.org/d/msgid/std-proposals/dae03b23-a771-4844-90dc-d3de39c03d47%4=
0isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"gmail_msg"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/dae03b23-a771-4844-90dc-d3de39c03d47%40isocpp.org</a>.<br class=3D"gma=
il_msg"><br><br></blockquote></div></div>

<p></p>

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

--001a11c10d7c7d06490545dc6306--

.

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

2017-01-12 9:34 GMT+08:00 Nicol Bolas <jmckesson@gmail.com>:

> Basically, just allow us to do this:
>
> auto [] = whatever;
>
> If you make that legal for all types, then what you effectively have is an
> unnamed variable. Structured binding/decomposition declarations already
> require that ability as a side effect of their primary work. We would just
> be using that side effect directly.
>

I'm not against the idea but it's not a general solution for unnamed
variable, e.g. "whatever" may not be moveable/copyable.

--
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/CANCwVhfns%3Davbs_pjoE-P7X2wUpXzhHavSvYyhYwbkZye8qCuA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-01-12 9:34 GMT+08:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Basica=
lly, just allow us to do this:<br><br><div style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x" class=3D"gmail-m_-4524495742533098356prettyprint"><code class=3D"gmail-m=
_-4524495742533098356prettyprint"><div class=3D"gmail-m_-452449574253309835=
6subprettyprint"><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-45244=
95742533098356styled-by-prettify">auto</span><span style=3D"color:rgb(0,0,0=
)" class=3D"gmail-m_-4524495742533098356styled-by-prettify"> </span><span s=
tyle=3D"color:rgb(102,102,0)" class=3D"gmail-m_-4524495742533098356styled-b=
y-prettify">[]</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-452=
4495742533098356styled-by-prettify"> </span><span style=3D"color:rgb(102,10=
2,0)" class=3D"gmail-m_-4524495742533098356styled-by-prettify">=3D</span><s=
pan style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-4524495742533098356styled-=
by-prettify"> whatever</span><span style=3D"color:rgb(102,102,0)" class=3D"=
gmail-m_-4524495742533098356styled-by-prettify">;</span></div></code></div>=
<br>If you make that legal for all types, then what you effectively have is=
 an unnamed variable. Structured binding/decomposition declarations already=
 require that ability as a side effect of their primary work. We would just=
 be using that side effect directly.<br></div></blockquote><div><br></div><=
div>I&#39;m not against the idea but it&#39;s not a general solution for un=
named variable, e.g. &quot;<span style=3D"background-color:rgb(250,250,250)=
;color:rgb(0,0,0);font-family:monospace">whatever</span>&quot; may not be m=
oveable/copyable.<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/CANCwVhfns%3Davbs_pjoE-P7X2wUpXzhHavS=
vYyhYwbkZye8qCuA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVhfns%3Dav=
bs_pjoE-P7X2wUpXzhHavSvYyhYwbkZye8qCuA%40mail.gmail.com</a>.<br />

--001a114dc4da3a16d80545dee341--

.

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

On Thu, Jan 12, 2017 at 2:22 AM, Ion Todirel <iontodirel@gmail.com> wrote:

> Can you provide an example on how you would use the unnamed variable?
>

I think the idea is that you *don't*, and that such variables are for
locking or other tasks where one needs some object to control RAII until
the current scope ends, but doesn't need to refer to that object again.

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 12, 2017 at 2:22 AM, Ion Todirel <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:iontodirel@gmail.com" target=3D"_blank">iontodirel@gmail.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div>Can you provide an exa=
mple on how you would use the unnamed variable? <br></div></blockquote><div=
><br></div><div>I think the idea is that you <i>don&#39;t</i>, and that suc=
h variables are for locking or other tasks where one needs some object to c=
ontrol RAII until the current scope ends, but doesn&#39;t need to refer to =
that object again. <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/CACGiwhEr5M50qP0uL8R2Bu8CHqBqxNYo6nVr=
Jqw7b1kg47BVKw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEr5M50qP0u=
L8R2Bu8CHqBqxNYo6nVrJqw7b1kg47BVKw%40mail.gmail.com</a>.<br />

--001a1136a422cec35e0545df63f6--

.

------=_Part_217_1207636621.1484202274985
Content-Type: multipart/alternative;
 boundary="----=_Part_218_1626061162.1484202274985"

------=_Part_218_1626061162.1484202274985
Content-Type: text/plain; charset=UTF-8



On Thursday, January 12, 2017 at 12:51:30 AM UTC-5, TONGARI J wrote:
>
> 2017-01-12 9:34 GMT+08:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
>
>> Basically, just allow us to do this:
>>
>> auto [] = whatever;
>>
>> If you make that legal for all types, then what you effectively have is
>> an unnamed variable. Structured binding/decomposition declarations already
>> require that ability as a side effect of their primary work. We would just
>> be using that side effect directly.
>>
>
> I'm not against the idea but it's not a general solution for unnamed
> variable, e.g. "whatever" may not be moveable/copyable.
>

.... so?

We're talking post-C++17. Which means post-*guaranteed elision*. It doesn't
matter if "whatever" is copyable or moveable. If it's a prvalue, then that *will
work*. And if it's not a prvalue... then what is it you're trying to do? Or
at the very least, you can do `auto &&[]`.

--
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/7a6b8ca1-311f-49e1-bbf3-e60efc6df202%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, January 12, 2017 at 12:51:30 AM UTC-5=
, TONGARI J wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote">2017-01-12 9:34 GMT+08:00 Nicol Bolas =
<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"LAkYUD1wBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">jmck...@gmail.com</a>&gt;</span>:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr">Basically, just allow us to d=
o this:<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 sty=
le=3D"color:rgb(0,0,136)">auto</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(102,102,0)">[]</span><span style=3D"color:rgb(0=
,0,0)"> </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=
=3D"color:rgb(0,0,0)"> whatever</span><span style=3D"color:rgb(102,102,0)">=
;</span></div></code></div><br>If you make that legal for all types, then w=
hat you effectively have is an unnamed variable. Structured binding/decompo=
sition declarations already require that ability as a side effect of their =
primary work. We would just be using that side effect directly.<br></div></=
blockquote><div><br></div><div>I&#39;m not against the idea but it&#39;s no=
t a general solution for unnamed variable, e.g. &quot;<span style=3D"backgr=
ound-color:rgb(250,250,250);color:rgb(0,0,0);font-family:monospace">whateve=
r</span>&quot; may not be moveable/copyable.<br></div></div></div></div></b=
lockquote><div><br>... so?<br><br>We&#39;re talking post-C++17. Which means=
 post-<i>guaranteed elision</i>. It doesn&#39;t matter if &quot;whatever&qu=
ot; is copyable or moveable. If it&#39;s a prvalue, then that <i>will work<=
/i>. And if it&#39;s not a prvalue... then what is it you&#39;re trying to =
do? Or at the very least, you can do `auto &amp;&amp;[]`.<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/7a6b8ca1-311f-49e1-bbf3-e60efc6df202%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a6b8ca1-311f-49e1-bbf3-e60efc6df202=
%40isocpp.org</a>.<br />

------=_Part_218_1626061162.1484202274985--

------=_Part_217_1207636621.1484202274985--

.

------=_Part_14_214865012.1484202791447
Content-Type: multipart/alternative;
 boundary="----=_Part_15_471119717.1484202791448"

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



=E5=9C=A8 2017=E5=B9=B41=E6=9C=8812=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8A=E5=8D=889:34:07=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
>
> And presto: we allow people to have unnamed variables.
>

The resolution of CWG 1769 had already introduced the concept of "unnamed=
=20
variable" normatively (but not as a clearly defined term); though I don't=
=20
think it is a serious and correct design in terminology. Besides the=20
confusion of the meaning about "mutable state" among other languages, the=
=20
change made it more confusing with the notion of a variable in traditional=
=20
mathematics (which is *always named* to be an instance of *binding *in some=
=20
*context* in some usual formal systems as well as composing an *environment=
=20
*in flavor of Lisp dialects). Note that ISO C carefully avoids the noun=20
"variable" and using "object" instead.

--=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/848c5aea-15ba-4b2d-878c-ce104529b007%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B41=E6=9C=8812=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=889:34:07=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><br>And presto: we allow people to have unnamed variables.<br></=
div></blockquote><div><br>The resolution of CWG 1769 had already introduced=
 the concept of &quot;unnamed variable&quot; normatively (but not as a clea=
rly defined term); though I don&#39;t think it is a serious and correct des=
ign in terminology. Besides the confusion of the meaning about &quot;mutabl=
e state&quot; among other languages, the change made it more confusing with=
 the notion of a variable in traditional mathematics (which is <i>always na=
med</i> to be an instance of <i>binding </i>in some <i>context</i> in some =
usual formal systems as well as composing an <i>environment </i>in flavor o=
f Lisp dialects). Note that ISO C carefully avoids the noun &quot;variable&=
quot; and using &quot;object&quot; instead.<br><br></div></div>

<p></p>

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

------=_Part_15_471119717.1484202791448--

------=_Part_14_214865012.1484202791447--

.

On Wed, Jan 11, 2017 at 7:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> auto [] = whatever;

I see 2 problems this suggestion.

1. It has to be a full statement because it is a definition,
  so it cannot appear in an expression to extend the lifetime
  of the result of a sub-expression, which is an often wanted
  feature.

2. If in the future we allow an explicit type T to appear in
  place of the `auto` in structured binding, `T [] = expr`
  may produce meaningless effects, banning them
  will make your seemly natural suggestion unnatural.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

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

.

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

Le 12/01/2017 =C3=A0 02:34, Nicol Bolas a =C3=A9crit :
> Basically, just allow us to do this:
>
> |
> auto[]=3Dwhatever;
> |
>
> If you make that legal for all types, then what you effectively have=20
> is an unnamed variable. Structured binding/decomposition declarations=20
> already require that ability as a side effect of their primary work.=20
> We would just be using that side effect directly.
>
> Lazy decomposition already ensures that `get<I>` will only be called=20
> when a decomposed name is used. So the idea of allowing any type to=20
> have zero decompositions effectively allows any type to work here.
>
> I'm not entirely sure about the grammar for this. If `auto[]` is=20
> useful in some way, then that would make this idea non-functional.
>
> So long as the grammar works out, I believe that we would need only=20
> two changes to the standard:
>
> 1: The ability to specify a decomposition declaration with no names to=20
> decompose to. The `identifier-list` in the grammer would simply be=20
> made optional.
>
> 2: If there are no names in the decomposition declaration, then it=20
> skips everything after [dcl.decomp]/1.
>
> And presto: we allow people to have unnamed variables.
I want unnamed variables and your idea seems a good one as struture=20
binding introduces one.

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/a3de4704-5c02-26c8-a521-53cf6570cad6%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 12/01/2017 =C3=A0 02:34, Nicol Bolas =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:dae03b23-a771-4844-90dc-d3de39c03d47@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">Basically, just allow us to do this:<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"> </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
                style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span
                style=3D"color: #000;" class=3D"styled-by-prettify">
                whatever</span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">;</span></div>
          </code></div>
        <br>
        If you make that legal for all types, then what you effectively
        have is an unnamed variable. Structured binding/decomposition
        declarations already require that ability as a side effect of
        their primary work. We would just be using that side effect
        directly.<br>
        <br>
        Lazy decomposition already ensures that `get&lt;I&gt;` will only
        be called when a decomposed name is used. So the idea of
        allowing any type to have zero decompositions effectively allows
        any type to work here.<br>
        <br>
        I'm not entirely sure about the grammar for this. If `auto[]` is
        useful in some way, then that would make this idea
        non-functional.<br>
        <br>
        So long as the grammar works out, I believe that we would need
        only two changes to the standard:<br>
        <br>
        1: The ability to specify a decomposition declaration with no
        names to decompose to. The `identifier-list` in the grammer
        would simply be made optional.<br>
        <br>
        2: If there are no names in the decomposition declaration, then
        it skips everything after [dcl.decomp]/1.<br>
        <br>
        And presto: we allow people to have unnamed variables.<br>
      </div>
    </blockquote>
    I want unnamed variables and your idea seems a good one as struture
    binding introduces one.<br>
    <br>
    Vicente<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/a3de4704-5c02-26c8-a521-53cf6570cad6%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a3de4704-5c02-26c8-a521-53cf6570cad6=
%40wanadoo.fr</a>.<br />

--------------7244FCB3B205F9F01621A70E--

.

On 12 January 2017 at 09:50, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Basically, just allow us to do this:
> auto [] = whatever;
> I want unnamed variables and your idea seems a good one as struture binding
> introduces one.

Related previous discussions: https://cplusplus.github.io/EWG/ewg-active.html#35

--
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/CAFk2RUYSvrGOL3ytMBWfA8CHfweRy5%3Dm%2B-s3cZU_LxR%2B8FTGEA%40mail.gmail.com.

.

Le 12/01/2017 =C3=A0 08:14, Zhihao Yuan a =C3=A9crit :
> On Wed, Jan 11, 2017 at 7:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> auto [] =3D whatever;
> I see 2 problems this suggestion.
>
> 1. It has to be a full statement because it is a definition,
>    so it cannot appear in an expression to extend the lifetime
>    of the result of a sub-expression, which is an often wanted
>    feature.
Could you show an example?
> 2. If in the future we allow an explicit type T to appear in
>    place of the `auto` in structured binding, `T [] =3D expr`
>    may produce meaningless effects, banning them
>    will make your seemly natural suggestion unnatural.
>
These are syntactical issues, that could be important, but what I like=20
of this proposal is the idea of reusing the unnamed variable of=20
strucutre binding.

If we adopted ... to mean ignore the others

`T [a, ...] =3D pt`

then

     T [...] =3D expr;

could already be less confusing.

Of course structutre binding requires some constraints on the rhs, but=20
nothing forbids us to change it and request in this case the use of ...=20
as pattern.

In the absence of a better syntax I believe

     T [...] =3D expr;

is the best I have found up to now for unnamed C++ variables.

Vicente

P.S. I prefer to use __ for unnamed variables

     T __ =3D expr;

but this is not backward compatible.

--=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/e0d4144c-421e-d89f-10ce-155e16ee5db2%40wanadoo.f=
r.

.

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

Why is `__` not backwards compatible? Isn't anything containing `__`
reserved?

Jonathan

On Jan 12, 2017 09:08, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr=
>
wrote:

> Le 12/01/2017 =C3=A0 08:14, Zhihao Yuan a =C3=A9crit :
>
>> On Wed, Jan 11, 2017 at 7:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote=
:
>>
>>> auto [] =3D whatever;
>>>
>> I see 2 problems this suggestion.
>>
>> 1. It has to be a full statement because it is a definition,
>>    so it cannot appear in an expression to extend the lifetime
>>    of the result of a sub-expression, which is an often wanted
>>    feature.
>>
> Could you show an example?
>
>> 2. If in the future we allow an explicit type T to appear in
>>    place of the `auto` in structured binding, `T [] =3D expr`
>>    may produce meaningless effects, banning them
>>    will make your seemly natural suggestion unnatural.
>>
>> These are syntactical issues, that could be important, but what I like o=
f
> this proposal is the idea of reusing the unnamed variable of strucutre
> binding.
>
> If we adopted ... to mean ignore the others
>
> `T [a, ...] =3D pt`
>
> then
>
>     T [...] =3D expr;
>
> could already be less confusing.
>
> Of course structutre binding requires some constraints on the rhs, but
> nothing forbids us to change it and request in this case the use of ... a=
s
> pattern.
>
> In the absence of a better syntax I believe
>
>     T [...] =3D expr;
>
> is the best I have found up to now for unnamed C++ variables.
>
> Vicente
>
> P.S. I prefer to use __ for unnamed variables
>
>     T __ =3D expr;
>
> but this is not backward 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/is
> ocpp.org/d/msgid/std-proposals/e0d4144c-421e-d89f-10ce-
> 155e16ee5db2%40wanadoo.fr.
>

--=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/CAEddoJaJaQ-cC24KA5OTaMejkh1qrxLYiKxYj75ESuSJwfp=
f4w%40mail.gmail.com.

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

<div dir=3D"auto">Why is `__` not backwards compatible? Isn&#39;t anything =
containing `__` reserved?<br><br><div data-smartmail=3D"gmail_signature">Jo=
nathan</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Jan 12, 2017 09:08, &quot;Vicente J. Botet Escriba&quot; &lt;<a href=3D=
"mailto:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.fr</a>&gt; wrote:<b=
r type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 12/01/2017 =C3=A0 =
08:14, Zhihao Yuan a =C3=A9crit :<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Wed, Jan 11, 2017 at 7:34 PM, Nicol Bolas &lt;<a href=3D"mailto:jmckesso=
n@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt; wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
auto [] =3D whatever;<br>
</blockquote>
I see 2 problems this suggestion.<br>
<br>
1. It has to be a full statement because it is a definition,<br>
=C2=A0 =C2=A0so it cannot appear in an expression to extend the lifetime<br=
>
=C2=A0 =C2=A0of the result of a sub-expression, which is an often wanted<br=
>
=C2=A0 =C2=A0feature.<br>
</blockquote>
Could you show an example?<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
2. If in the future we allow an explicit type T to appear in<br>
=C2=A0 =C2=A0place of the `auto` in structured binding, `T [] =3D expr`<br>
=C2=A0 =C2=A0may produce meaningless effects, banning them<br>
=C2=A0 =C2=A0will make your seemly natural suggestion unnatural.<br>
<br>
</blockquote>
These are syntactical issues, that could be important, but what I like of t=
his proposal is the idea of reusing the unnamed variable of strucutre bindi=
ng.<br>
<br>
If we adopted ... to mean ignore the others<br>
<br>
`T [a, ...] =3D pt`<br>
<br>
then<br>
<br>
=C2=A0 =C2=A0 T [...] =3D expr;<br>
<br>
could already be less confusing.<br>
<br>
Of course structutre binding requires some constraints on the rhs, but noth=
ing forbids us to change it and request in this case the use of ... as patt=
ern.<br>
<br>
In the absence of a better syntax I believe<br>
<br>
=C2=A0 =C2=A0 T [...] =3D expr;<br>
<br>
is the best I have found up to now for unnamed C++ variables.<br>
<br>
Vicente<br>
<br>
P.S. I prefer to use __ for unnamed variables<br>
<br>
=C2=A0 =C2=A0 T __ =3D expr;<br>
<br>
but this is not backward compatible.<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.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/e0d4144c-421e-d89f-10ce-155e16ee5db2%=
40wanadoo.fr" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/e0d4144c-421e-d89f-10ce-<wbr=
>155e16ee5db2%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/CAEddoJaJaQ-cC24KA5OTaMejkh1qrxLYiKxY=
j75ESuSJwfpf4w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJaJaQ-cC24K=
A5OTaMejkh1qrxLYiKxYj75ESuSJwfpf4w%40mail.gmail.com</a>.<br />

--001a1142c5e0d018560545e1ab49--

.

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

2017-01-12 14:24 GMT+08:00 Nicol Bolas <jmckesson@gmail.com>:
>
> On Thursday, January 12, 2017 at 12:51:30 AM UTC-5, TONGARI J wrote:
>>
>> 2017-01-12 9:34 GMT+08:00 Nicol Bolas <jmck...@gmail.com>:
>>
>>> Basically, just allow us to do this:
>>>
>>> auto [] = whatever;
>>>
>>> If you make that legal for all types, then what you effectively have is
>>> an unnamed variable. Structured binding/decomposition declarations already
>>> require that ability as a side effect of their primary work. We would just
>>> be using that side effect directly.
>>>
>>
>> I'm not against the idea but it's not a general solution for unnamed
>> variable, e.g. "whatever" may not be moveable/copyable.
>>
>
> ... so?
>
> We're talking post-C++17. Which means post-*guaranteed elision*.
>

Good to know that guaranteed elision is a thing.

--
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/CANCwVheK7%2BJhfte275Ho3Lpe0nFNcpmMcFKqcSpS6Esq%2BOncMw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-01-12 14:24 GMT+08:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:=
jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>:<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Thursd=
ay, January 12, 2017 at 12:51:30 AM UTC-5, TONGARI J wrote:<span class=3D"g=
mail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote">2017-01-12 9:34 GMT+08:00 Nicol Bolas <span =
dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span>:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Basically,=
 just allow us to do this:<br><br><div style=3D"background-color:rgb(250,25=
0,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><=
code><div><span style=3D"color:rgb(0,0,136)">auto</span><span style=3D"colo=
r:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">[]</span><span s=
tyle=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">=3D<=
/span><span style=3D"color:rgb(0,0,0)"> whatever</span><span style=3D"color=
:rgb(102,102,0)">;</span></div></code></div><br>If you make that legal for =
all types, then what you effectively have is an unnamed variable. Structure=
d binding/decomposition declarations already require that ability as a side=
 effect of their primary work. We would just be using that side effect dire=
ctly.<br></div></blockquote><div><br></div><div>I&#39;m not against the ide=
a but it&#39;s not a general solution for unnamed variable, e.g. &quot;<spa=
n style=3D"background-color:rgb(250,250,250);color:rgb(0,0,0);font-family:m=
onospace">whatever</span>&quot; may not be moveable/copyable.<br></div></di=
v></div></div></blockquote></span><div><br>... so?<br><br>We&#39;re talking=
 post-C++17. Which means post-<i>guaranteed elision</i>.<br></div></div></b=
lockquote><div><br></div><div>Good to know=C2=A0that guaranteed elision is =
a thing.</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/CANCwVheK7%2BJhfte275Ho3Lpe0nFNcpmMcF=
KqcSpS6Esq%2BOncMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVheK7%2B=
Jhfte275Ho3Lpe0nFNcpmMcFKqcSpS6Esq%2BOncMw%40mail.gmail.com</a>.<br />

--f403045f3fe4c0733e0545e5e346--

.

------=_Part_711_145603365.1484234380438
Content-Type: multipart/alternative;
 boundary="----=_Part_712_445309564.1484234380438"

------=_Part_712_445309564.1484234380438
Content-Type: text/plain; charset=UTF-8



On Thursday, January 12, 2017 at 2:14:34 AM UTC-5, Zhihao Yuan wrote:
>
> On Wed, Jan 11, 2017 at 7:34 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> > auto [] = whatever;
>
> I see 2 problems this suggestion.
>
> 1. It has to be a full statement because it is a definition,
>   so it cannot appear in an expression to extend the lifetime
>   of the result of a sub-expression, which is an often wanted
>   feature.
>

This idea is not intending to solve those cases. I brought this up because
structured binding has 99% of the infrastructure needed for a
commonly-asked-for feature: declaring variables with no accessible/visible
names.

The case of extending the lifetime of some sub-expression is a different
problem requiring a different solution.

2. If in the future we allow an explicit type T to appear in
>   place of the `auto` in structured binding, `T [] = expr`
>   may produce meaningless effects, banning them
>   will make your seemly natural suggestion unnatural.
>

What "meaningless effects" would `T [] = expr` produce?

--
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/34922299-ac54-4d6b-90a0-03ab3072e783%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, January 12, 2017 at 2:14:34 AM UTC-5,=
 Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jan=
 11, 2017 at 7:34 PM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"zy9RzMV0BgAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#3=
9;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; auto [] =3D whatever;
<br>
<br>I see 2 problems this suggestion.
<br>
<br>1. It has to be a full statement because it is a definition,
<br>=C2=A0 so it cannot appear in an expression to extend the lifetime
<br>=C2=A0 of the result of a sub-expression, which is an often wanted
<br>=C2=A0 feature.<br></blockquote><div><br>This idea is not intending to =
solve those cases. I brought this up because structured binding has 99% of =
the infrastructure needed for a commonly-asked-for feature: declaring varia=
bles with no accessible/visible names.<br><br>The case of extending the lif=
etime of some sub-expression is a different problem requiring a different s=
olution.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2. If in=
 the future we allow an explicit type T to appear in
<br>=C2=A0 place of the `auto` in structured binding, `T [] =3D expr`
<br>=C2=A0 may produce meaningless effects, banning them
<br>=C2=A0 will make your seemly natural suggestion unnatural.<br></blockqu=
ote><div><br></div>What &quot;meaningless effects&quot; would `T [] =3D exp=
r` produce?<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/34922299-ac54-4d6b-90a0-03ab3072e783%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/34922299-ac54-4d6b-90a0-03ab3072e783=
%40isocpp.org</a>.<br />

------=_Part_712_445309564.1484234380438--

------=_Part_711_145603365.1484234380438--

.

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

On Jan 12, 2017 9:19 AM, "Nicol Bolas" <jmckesson@gmail.com> wrote:



On Thursday, January 12, 2017 at 2:14:34 AM UTC-5, Zhihao Yuan wrote:

> On Wed, Jan 11, 2017 at 7:34 PM, Nicol Bolas <jmck...@gmail.com> wrote:
> > auto [] = whatever;
>
> I see 2 problems this suggestion.
>
> 1. It has to be a full statement because it is a definition,
>   so it cannot appear in an expression to extend the lifetime
>   of the result of a sub-expression, which is an often wanted
>   feature.
>

This idea is not intending to solve those cases. I brought this up because
structured binding has 99% of the infrastructure needed for a
commonly-asked-for feature: declaring variables with no accessible/visible
names.

The case of extending the lifetime of some sub-expression is a different
problem requiring a different solution.


But any solution which can extend the lifetime of a sub-expression
(to match the lifetime of a named variable) can smoothly extend
the lifetime of an expression as initializer, making your solution
redundant.


2. If in the future we allow an explicit type T to appear in
>   place of the `auto` in structured binding, `T [] = expr`
>   may produce meaningless effects, banning them
>   will make your seemly natural suggestion unnatural.
>

What "meaningless effects" would `T [] = expr` produce?


bool [] = expr; where expr returns a RAII object convertible
to bool, then the RAII effort loses in vain.

--
Zhihao

--
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/CAGsORuBJZ6-HX7AstwPbUXSPS%3D9H437nz_j-JeG89F%2BfCU7H-A%40mail.gmail.com.

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

<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On Jan 12, 2017 9:19 AM, &quot;Nicol Bolas&quot; &lt;<a href=3D"mailto:jm=
ckesson@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br type=3D"attributio=
n"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Thursday, January 1=
2, 2017 at 2:14:34 AM UTC-5, Zhihao Yuan wrote:<div class=3D"quoted-text"><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex">On Wed, Jan 11, 2017 at 7:34 PM, Nic=
ol Bolas &lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; auto [] =3D whatever;
<br>
<br>I see 2 problems this suggestion.
<br>
<br>1. It has to be a full statement because it is a definition,
<br>=C2=A0 so it cannot appear in an expression to extend the lifetime
<br>=C2=A0 of the result of a sub-expression, which is an often wanted
<br>=C2=A0 feature.<br></blockquote></div><div><br>This idea is not intendi=
ng to solve those cases. I brought this up because structured binding has 9=
9% of the infrastructure needed for a commonly-asked-for feature: declaring=
 variables with no accessible/visible names.<br><br>The case of extending t=
he lifetime of some sub-expression is a different problem requiring a diffe=
rent solution.<br></div></div></blockquote></div></div></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">But any solution which can extend the lifet=
ime of a sub-expression</div><div dir=3D"auto">(to match the lifetime of a =
named variable) can smoothly extend</div><div dir=3D"auto">the lifetime of =
an expression as initializer, making your solution</div><div dir=3D"auto">r=
edundant.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><br></div><div class=3D"quoted-text"><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">2. If in the future we allow an explicit type T to appear i=
n
<br>=C2=A0 place of the `auto` in structured binding, `T [] =3D expr`
<br>=C2=A0 may produce meaningless effects, banning them
<br>=C2=A0 will make your seemly natural suggestion unnatural.<br></blockqu=
ote><div><br></div></div>What &quot;meaningless effects&quot; would `T [] =
=3D expr` produce?<br></div></blockquote></div></div></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">bool [] =3D expr; where expr returns a RAII o=
bject convertible</div><div dir=3D"auto">to bool, then the RAII effort lose=
s in vain.</div><div dir=3D"auto"><br></div><div dir=3D"auto">--</div><div =
dir=3D"auto">Zhihao</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/CAGsORuBJZ6-HX7AstwPbUXSPS%3D9H437nz_=
j-JeG89F%2BfCU7H-A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBJZ6-H=
X7AstwPbUXSPS%3D9H437nz_j-JeG89F%2BfCU7H-A%40mail.gmail.com</a>.<br />

--f403045e7dbc23f7a40545e99338--

.

------=_Part_986_1745215427.1484245791937
Content-Type: multipart/alternative;
 boundary="----=_Part_987_781982880.1484245791937"

------=_Part_987_781982880.1484245791937
Content-Type: text/plain; charset=UTF-8

On Thursday, January 12, 2017 at 1:06:24 PM UTC-5, Zhihao Yuan wrote:
>
> On Jan 12, 2017 9:19 AM, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
>
> On Thursday, January 12, 2017 at 2:14:34 AM UTC-5, Zhihao Yuan wrote:
>
>> On Wed, Jan 11, 2017 at 7:34 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>> > auto [] = whatever;
>>
>> I see 2 problems this suggestion.
>>
>> 1. It has to be a full statement because it is a definition,
>>   so it cannot appear in an expression to extend the lifetime
>>   of the result of a sub-expression, which is an often wanted
>>   feature.
>>
>
> This idea is not intending to solve those cases. I brought this up because
> structured binding has 99% of the infrastructure needed for a
> commonly-asked-for feature: declaring variables with no accessible/visible
> names.
>
> The case of extending the lifetime of some sub-expression is a different
> problem requiring a different solution.
>
>
> But any solution which can extend the lifetime of a sub-expression
> (to match the lifetime of a named variable) can smoothly extend
> the lifetime of an expression as initializer, making your solution
> redundant.
>

The principle advantage of what I'm talking about is that we almost have it
already. The wording and so forth for the most complex part has been worked
out, and there is viable syntax which *already exists*. Therefore, the
syntactic and standardization burden is minimal.

By contrast, what you're talking about is a completely new construct:
arbitrary expression lifetime extension. If that new construct were
something that was on the cusp of standardization, I probably wouldn't have
made this suggestion. But I don't recall any proposals about generalized
expression lifetime extension. I don't even recall any threads on it here.

Whereas we have had several threads about unnamed variables.

2. If in the future we allow an explicit type T to appear in
>>   place of the `auto` in structured binding, `T [] = expr`
>>   may produce meaningless effects, banning them
>>   will make your seemly natural suggestion unnatural.
>>
>
> What "meaningless effects" would `T [] = expr` produce?
>
>
> bool [] = expr; where expr returns a RAII object convertible
> to bool, then the RAII effort loses in vain.
>

Right, but the results of that would be no different from you doing `bool b
= expr;`. So there's no "meaningless effect"; you just did the *wrong thing*
..

Remember: the goal is not to extend the lifetime of `expr`; the goal is to
have an unnamed variable.

--
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/719bbf0c-44d1-414e-9e72-7a8514954b64%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, January 12, 2017 at 1:06:24 PM UTC-5, Zhihao =
Yuan 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"auto"><=
div><div><div class=3D"gmail_quote">On Jan 12, 2017 9:19 AM, &quot;Nicol Bo=
las&quot; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"tAiDtFeYBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;">jmck...@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquo=
te style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">On Thursday, January 12, 2017 at 2:14:34 AM UTC-5, Zhihao =
Yuan wrote:<div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Jan 11, 201=
7 at 7:34 PM, Nicol Bolas &lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;=
 wrote:
<br>&gt; auto [] =3D whatever;
<br>
<br>I see 2 problems this suggestion.
<br>
<br>1. It has to be a full statement because it is a definition,
<br>=C2=A0 so it cannot appear in an expression to extend the lifetime
<br>=C2=A0 of the result of a sub-expression, which is an often wanted
<br>=C2=A0 feature.<br></blockquote></div><div><br>This idea is not intendi=
ng to solve those cases. I brought this up because structured binding has 9=
9% of the infrastructure needed for a commonly-asked-for feature: declaring=
 variables with no accessible/visible names.<br><br>The case of extending t=
he lifetime of some sub-expression is a different problem requiring a diffe=
rent solution.<br></div></div></blockquote></div></div></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">But any solution which can extend the lifet=
ime of a sub-expression</div><div dir=3D"auto">(to match the lifetime of a =
named variable) can smoothly extend</div><div dir=3D"auto">the lifetime of =
an expression as initializer, making your solution</div><div dir=3D"auto">r=
edundant.</div></div></blockquote><div><br>The principle advantage of what =
I&#39;m talking about is that we almost have it already. The wording and so=
 forth for the most complex part has been worked out, and there is viable s=
yntax which <i>already exists</i>. Therefore, the syntactic and standardiza=
tion burden is minimal.<br><br>By contrast, what you&#39;re talking about i=
s a completely new construct: arbitrary expression lifetime extension. If t=
hat new construct were something that was on the cusp of standardization, I=
 probably wouldn&#39;t have made this suggestion. But I don&#39;t recall an=
y proposals about generalized expression lifetime extension. I don&#39;t ev=
en recall any threads on it here.<br><br>Whereas we have had several thread=
s about unnamed variables.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"auto"><div dir=3D"auto"><div><div class=3D"gmail_quot=
e"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div></div><div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">2. If in the future we allow an explicit type T to appear in
<br>=C2=A0 place of the `auto` in structured binding, `T [] =3D expr`
<br>=C2=A0 may produce meaningless effects, banning them
<br>=C2=A0 will make your seemly natural suggestion unnatural.<br></blockqu=
ote><div><br></div></div>What &quot;meaningless effects&quot; would `T [] =
=3D expr` produce?<br></div></blockquote></div></div></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">bool [] =3D expr; where expr returns a RAII o=
bject convertible</div><div dir=3D"auto">to bool, then the RAII effort lose=
s in vain.</div></div></blockquote><div><br>Right, but the results of that =
would be no different from you doing `bool b =3D expr;`. So there&#39;s no =
&quot;meaningless effect&quot;; you just did the <i>wrong thing</i>.<br><br=
>Remember: the goal is not to extend the lifetime of `expr`; the goal is to=
 have an unnamed variable.<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/719bbf0c-44d1-414e-9e72-7a8514954b64%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/719bbf0c-44d1-414e-9e72-7a8514954b64=
%40isocpp.org</a>.<br />

------=_Part_987_781982880.1484245791937--

------=_Part_986_1745215427.1484245791937--

.

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

On Jan 12, 2017 12:29 PM, "Nicol Bolas" <jmckesson@gmail.com> wrote:


The principle advantage of what I'm talking about is that we almost have it
already. The wording and so forth for the most complex part has been worked
out, and there is viable syntax which *already exists*. Therefore, the
syntactic and standardization burden is minimal.

By contrast, what you're talking about is a completely new construct:
arbitrary expression lifetime extension. If that new construct were
something that was on the cusp of standardization, I probably wouldn't have
made this suggestion. But I don't recall any proposals about generalized
expression lifetime extension. I don't even recall any threads on it here.

[...]

Right, but the results of that would be no different from you doing `bool b
= expr;`. So there's no "meaningless effect"; you just did the *wrong thing*
..


The principle advantage losses when we
discovered meaningless combinations,
meaningless combinations imply
artificial orthogonality, hence high
degree coupling.

And in principle there is a high degree
coupling: unnamed variable will be
coupled with structured binding, can only
be used at where structured binding
may be used, and has to be extended to
everywhere structured binding being
extended.


Remember: the goal is not to extend the lifetime of `expr`; the goal is to
have an unnamed variable.


C++ already has true unnamed object
that is temporary object, and difference
between

  f();
  auto [] = f();

is merely whether the lifetime of the
return value of f() is long enough to
reach the end of the scope.  So why not
call it out?

  __extend_me f();
  T a = g(__extend_me f());

Very straightforward, right?  Attacking
the core of the problem.

--
Zhihao

--
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/CAGsORuBhBnbLseCtXJ_tafHv-_7L7VaEh%2BWaqQ5adTOpJ7E3QQ%40mail.gmail.com.

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

<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gma=
il_quote">On Jan 12, 2017 12:29 PM, &quot;Nicol Bolas&quot; &lt;<a href=3D"=
mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br type=3D"a=
ttribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>The principl=
e advantage of what I&#39;m talking about is that we almost have it already=
.. The wording and so forth for the most complex part has been worked out, a=
nd there is viable syntax which <i>already exists</i>. Therefore, the synta=
ctic and standardization burden is minimal.<br><br>By contrast, what you&#3=
9;re talking about is a completely new construct: arbitrary expression life=
time extension. If that new construct were something that was on the cusp o=
f standardization, I probably wouldn&#39;t have made this suggestion. But I=
 don&#39;t recall any proposals about generalized expression lifetime exten=
sion. I don&#39;t even recall any threads on it here.<br><br>[...]</div><di=
v><br>Right, but the results of that would be no different from you doing `=
bool b =3D expr;`. So there&#39;s no &quot;meaningless effect&quot;; you ju=
st did the <i>wrong thing</i>.<br></div></div></blockquote></div></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">The principle advantage losses wh=
en we</div><div dir=3D"auto">discovered meaningless combinations,</div><div=
 dir=3D"auto">meaningless combinations imply</div><div dir=3D"auto">artific=
ial orthogonality, hence high</div><div dir=3D"auto">degree coupling.</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">And in principle there is a h=
igh degree</div><div dir=3D"auto">coupling: unnamed variable will be</div><=
div dir=3D"auto">coupled with structured binding, can only</div><div dir=3D=
"auto">be used at where structured binding</div><div dir=3D"auto">may be us=
ed, and has to be extended to</div><div dir=3D"auto">everywhere structured =
binding being</div><div dir=3D"auto">extended.</div><div dir=3D"auto"><br><=
/div><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote"><bl=
ockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div><br>Remember: the goal is not t=
o extend the lifetime of `expr`; the goal is to have an unnamed variable.<b=
r></div></div></blockquote></div><br></div><div class=3D"gmail_extra" dir=
=3D"auto">C++ already has true unnamed object</div><div class=3D"gmail_extr=
a" dir=3D"auto">that is temporary object, and difference</div><div class=3D=
"gmail_extra" dir=3D"auto">between</div><div class=3D"gmail_extra" dir=3D"a=
uto"><br></div><div class=3D"gmail_extra" dir=3D"auto">=C2=A0 f();</div><di=
v class=3D"gmail_extra" dir=3D"auto">=C2=A0 auto [] =3D f();</div><div clas=
s=3D"gmail_extra" dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"=
auto">is merely whether the lifetime of the</div><div class=3D"gmail_extra"=
 dir=3D"auto">return value of f() is long enough to</div><div class=3D"gmai=
l_extra" dir=3D"auto">reach the end of the scope.=C2=A0 So why not</div><di=
v class=3D"gmail_extra" dir=3D"auto">call it out?</div><div class=3D"gmail_=
extra" dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto">=C2=
=A0 __extend_me f();</div><div class=3D"gmail_extra" dir=3D"auto">=C2=A0 T =
a =3D g(__extend_me f());</div><div class=3D"gmail_extra" dir=3D"auto"><br>=
</div><div class=3D"gmail_extra" dir=3D"auto">Very straightforward, right?=
=C2=A0 Attacking</div><div class=3D"gmail_extra" dir=3D"auto">the core of t=
he problem.</div><div class=3D"gmail_extra" dir=3D"auto"><br></div><div cla=
ss=3D"gmail_extra" dir=3D"auto">--</div><div class=3D"gmail_extra" dir=3D"a=
uto">Zhihao</div><div class=3D"gmail_extra" dir=3D"auto"><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/CAGsORuBhBnbLseCtXJ_tafHv-_7L7VaEh%2B=
WaqQ5adTOpJ7E3QQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBhBnbLse=
CtXJ_tafHv-_7L7VaEh%2BWaqQ5adTOpJ7E3QQ%40mail.gmail.com</a>.<br />

--001a114723fadfd10f0545ea460c--

.

------=_Part_1015_96426695.1484251013940
Content-Type: multipart/alternative;
 boundary="----=_Part_1016_1939408064.1484251013940"

------=_Part_1016_1939408064.1484251013940
Content-Type: text/plain; charset=UTF-8

On Thursday, January 12, 2017 at 1:56:41 PM UTC-5, Zhihao Yuan wrote:
>
> On Jan 12, 2017 12:29 PM, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
>
>
> The principle advantage of what I'm talking about is that we almost have
> it already. The wording and so forth for the most complex part has been
> worked out, and there is viable syntax which *already exists*. Therefore,
> the syntactic and standardization burden is minimal.
>
> By contrast, what you're talking about is a completely new construct:
> arbitrary expression lifetime extension. If that new construct were
> something that was on the cusp of standardization, I probably wouldn't have
> made this suggestion. But I don't recall any proposals about generalized
> expression lifetime extension. I don't even recall any threads on it here.
>
> [...]
>
> Right, but the results of that would be no different from you doing `bool
> b = expr;`. So there's no "meaningless effect"; you just did the *wrong
> thing*.
>
>
> The principle advantage losses when we
> discovered meaningless combinations,
> meaningless combinations imply
> artificial orthogonality, hence high
> degree coupling.
>

.... I'm not sure I understand what you're saying. Because it sounds like
you're saying that the existence of `bool b = expr` is a problem with the
language. Because that's a perfectly valid "meaningless combination". So
does that "imply artificial orthogonality, hence high degree coupling?"
Where does this "artificial orthogonality" come from, and what is being
coupled to what?

Because the only difference between `bool [] = expr` and `bool b = expr` is
that you gave it a name. So if one of these is wrong, then the other must
be wrong for the same reasons. Accordingly, if one of these is fine, then
the other must also be fine.

You cannot be fine with one while claiming that the other is wrong.

And in principle there is a high degree
> coupling: unnamed variable will be
> coupled with structured binding, can only
> be used at where structured binding
> may be used, and has to be extended to
> everywhere structured binding being
> extended.
>

Right, but I don't care. Using structured binding syntax for this causes no
problems *which would not already be present* when using a named variable
in the same circumstances.

Unnamed variable definitions were always going to have some syntax of the
form "<typename/placeholder> <syntax to use in lieu of a name>
<initializer>".

Remember: the goal is not to extend the lifetime of `expr`; the goal is to
> have an unnamed variable.
>
>
> C++ already has true unnamed object
> that is temporary object,
>

No, I said unnamed *variable*, not unnamed object.


> and difference
> between
>
>   f();
>   auto [] = f();
>
> is merely whether the lifetime of the
> return value of f() is long enough to
> reach the end of the scope.  So why not
> call it out?
>
>   __extend_me f();
>   T a = g(__extend_me f());
>
> Very straightforward, right?  Attacking
> the core of the problem.
>

That's great. Feel free to write up a proposal for that; it'll have my
support.

But that's proposal will not be *this*. Why? Because I rather suspect that
it doesn't let you do this, for example:

for(auto [] : ints(5))
  //Do this 5 times.

My idea does.

I also don't know how `__extend_me` would impact globals, while I'm fairly
sure decomposition declarations can be at global scope. And therefore,
global unnamed variables are totally legal.

Can `__extend_me` work with `constexpr` things? Because decomposition
declarations can (or if not now, they certainly will once that gets fixed).
Can `__extend_me` temporaries have attributes? Because decomposition
declarations can. And so forth.

Do you see now why using structured binding here works so well? It already
has answered all of the questions that need to be answered. Your idea is in
its infancy, and may never cover all the bases that structured binding
does. Because yours is solving a different problem.

Declaring a temporary to be `constexpr` makes no sense. Adding attributes
to a temporary makes no sense. But applying both to *variables* does make
sense, even if those variables do not have names.

Your idea has merit. But it is ultimately solving a different problem.

However, when you do write up that proposal, you may want to note how it
interacts with guaranteed elision. For example, your inner `__extend_me`
syntax. That requires that `f()` manifest a temporary, whose lifetime will
then be extended. Without that `__extend_me` syntax, a temporary might not
be needed. The prvalue returned could directly initialize the function's
parameter.

Therefore, using `__extend_me` in various cases can require copy/move
constructors.

--
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/0f92c6b7-46f6-4a0f-a092-bb364c54b42b%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, January 12, 2017 at 1:56:41 PM UTC-5, Zhihao =
Yuan 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"auto"><=
div dir=3D"auto"><div class=3D"gmail_quote">On Jan 12, 2017 12:29 PM, &quot=
;Nicol Bolas&quot; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"M19_LhabBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#=
39;;return true;">jmck...@gmail.com</a>&gt; wrote:<br type=3D"attribution">=
<blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><br>The principle advantage of what I&#39;m =
talking about is that we almost have it already. The wording and so forth f=
or the most complex part has been worked out, and there is viable syntax wh=
ich <i>already exists</i>. Therefore, the syntactic and standardization bur=
den is minimal.<br><br>By contrast, what you&#39;re talking about is a comp=
letely new construct: arbitrary expression lifetime extension. If that new =
construct were something that was on the cusp of standardization, I probabl=
y wouldn&#39;t have made this suggestion. But I don&#39;t recall any propos=
als about generalized expression lifetime extension. I don&#39;t even recal=
l any threads on it here.<br><br>[...]</div><div><br>Right, but the results=
 of that would be no different from you doing `bool b =3D expr;`. So there&=
#39;s no &quot;meaningless effect&quot;; you just did the <i>wrong thing</i=
>.<br></div></div></blockquote></div></div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">The principle advantage losses when we</div><div dir=3D"auto"=
>discovered meaningless combinations,</div><div dir=3D"auto">meaningless co=
mbinations imply</div><div dir=3D"auto">artificial orthogonality, hence hig=
h</div><div dir=3D"auto">degree coupling.</div></div></blockquote><div><br>=
.... I&#39;m not sure I understand what you&#39;re saying. Because it sounds=
 like you&#39;re saying that the existence of `bool b =3D expr` is a proble=
m with the language. Because that&#39;s a perfectly valid &quot;meaningless=
 combination&quot;. So does that &quot;imply artificial orthogonality, henc=
e high degree coupling?&quot; Where does this &quot;artificial orthogonalit=
y&quot; come from, and what is being coupled to what?<br><br>Because the on=
ly difference between `bool [] =3D expr` and `bool b =3D expr` is that you =
gave it a name. So if one of these is wrong, then the other must be wrong f=
or the same reasons. Accordingly, if one of these is fine, then the other m=
ust also be fine.<br><br>You cannot be fine with one while claiming that th=
e other is wrong.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"auto"><div dir=3D"auto"></div><div dir=3D"auto">And in princip=
le there is a high degree</div><div dir=3D"auto">coupling: unnamed variable=
 will be</div><div dir=3D"auto">coupled with structured binding, can only</=
div><div dir=3D"auto">be used at where structured binding</div><div dir=3D"=
auto">may be used, and has to be extended to</div><div dir=3D"auto">everywh=
ere structured binding being</div><div dir=3D"auto">extended.</div></div></=
blockquote><div><br>Right, but I don&#39;t care. Using structured binding s=
yntax for this causes no problems <i>which would not already be present</i>=
 when using a named variable in the same circumstances.<br><br>Unnamed vari=
able definitions were always going to have some syntax of the form &quot;&l=
t;typename/placeholder&gt; &lt;syntax to use in lieu of a name&gt; &lt;init=
ializer&gt;&quot;.<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"auto"><div dir=3D"auto"></div><div dir=3D"auto"><div class=3D=
"gmail_quote"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>Remember: the goal is not to e=
xtend the lifetime of `expr`; the goal is to have an unnamed variable.<br><=
/div></div></blockquote></div><br></div><div dir=3D"auto">C++ already has t=
rue unnamed object</div><div dir=3D"auto">that is temporary object,</div></=
div></blockquote><div><br>No, I said unnamed <i>variable</i>, not unnamed o=
bject.<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 dir=
=3D"auto"><div dir=3D"auto"> and difference</div><div dir=3D"auto">between<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">=C2=A0 f();</div><div di=
r=3D"auto">=C2=A0 auto [] =3D f();</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">is merely whether the lifetime of the</div><div dir=3D"auto">ret=
urn value of f() is long enough to</div><div dir=3D"auto">reach the end of =
the scope.=C2=A0 So why not</div><div dir=3D"auto">call it out?</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">=C2=A0 __extend_me f();</div><div d=
ir=3D"auto">=C2=A0 T a =3D g(__extend_me f());</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Very straightforward, right?=C2=A0 Attacking</div><d=
iv dir=3D"auto">the core of the problem.</div></div></blockquote><div><br>T=
hat&#39;s great. Feel free to write up a proposal for that; it&#39;ll have =
my support.<br><br>But that&#39;s proposal will not be <i>this</i>. Why? Be=
cause I rather suspect that it doesn&#39;t let you do this, for example:<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: brea=
k-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">for=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </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: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> ints</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>5</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 </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">//Do this 5 tim=
es.</span></div></code></div><br>My idea does.<br><br>I also don&#39;t know=
 how `__extend_me` would impact globals, while I&#39;m fairly sure decompos=
ition declarations can be at global scope. And therefore, global unnamed va=
riables are totally legal.<br><br>Can `__extend_me` work with `constexpr` t=
hings? Because decomposition declarations can (or if not now, they certainl=
y will once that gets fixed). Can `__extend_me` temporaries have attributes=
? Because decomposition declarations can. And so forth.<br><br>Do you see n=
ow why using structured binding here works so well? It already has answered=
 all of the questions that need to be answered. Your idea is in its infancy=
, and may never cover all the bases that structured binding does. Because y=
ours is solving a different problem.<br><br>Declaring a temporary to be `co=
nstexpr` makes no sense. Adding attributes to a temporary makes no sense. B=
ut applying both to <i>variables</i> does make sense, even if those variabl=
es do not have names.<br><br>Your idea has merit. But it is ultimately solv=
ing a different problem.<br><br>However, when you do write up that proposal=
, you may want to note how it interacts with guaranteed elision. For exampl=
e, your inner `__extend_me` syntax. That requires that `f()` manifest a tem=
porary, whose lifetime will then be extended. Without that `__extend_me` sy=
ntax, a temporary might not be needed. The prvalue returned could directly =
initialize the function&#39;s parameter.<br><br>Therefore, using `__extend_=
me` in various cases can require copy/move constructors.<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/0f92c6b7-46f6-4a0f-a092-bb364c54b42b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0f92c6b7-46f6-4a0f-a092-bb364c54b42b=
%40isocpp.org</a>.<br />

------=_Part_1016_1939408064.1484251013940--

------=_Part_1015_96426695.1484251013940--

.

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

On Jan 12, 2017 1:57 PM, "Nicol Bolas" <jmckesson@gmail.com> wrote:

On Thursday, January 12, 2017 at 1:56:41 PM UTC-5, Zhihao Yuan wrote:

>
> Right, but the results of that would be no different from you doing `bool
> b = expr;`. So there's no "meaningless effect"; you just did the *wrong
> thing*.
>
>
> The principle advantage losses when we
> discovered meaningless combinations,
> meaningless combinations imply
> artificial orthogonality, hence high
> degree coupling.
>

.... I'm not sure I understand what you're saying. Because it sounds like
you're saying that the existence of `bool b = expr` is a problem with the
language. [...]


Because the only difference between `bool [] = expr` and `bool b = expr` is
that you gave it a name. So if one of these is wrong, then the other must
be wrong for the same reasons. Accordingly, if one of these is fine, then
the other must also be fine.

You cannot be fine with one while claiming that the other is wrong.


bool b = expr is right and bool [] = expr
is wrong, because the goal of the former
is to transfer value, the side effect is
a non-goal, while the goal of the later is
RAII, but it lost RAII, so it's wrong.


for(auto [] : ints(5))
  //Do this 5 times.

My idea does.


Here with or without a name has much
less importance than the RAII cases, but
I can accept it as a valid plus.


I also don't know how `__extend_me` would impact globals, [...]


As usual, end of scope.


Can `__extend_me` work with `constexpr` things? Because decomposition
declarations can (or if not now, they certainly will once that gets fixed).


constexpr auto [] = an excellent example
of meaningless combinations because
objects with nontrival destructor does
not work with constexpr.

Can `__extend_me` temporaries have attributes?


Yes if being proven useful.


Do you see now why using structured binding here works so well?


I didn't see, 2 cases down, 1 alive.


Therefore, using `__extend_me` in various cases can require copy/move
constructors.

Not in the cases doing your solution's
work though, but thanks for your insight
on this.

--
Zhihao

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

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

<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gma=
il_quote">On Jan 12, 2017 1:57 PM, &quot;Nicol Bolas&quot; &lt;<a href=3D"m=
ailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br type=3D"at=
tribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, January 1=
2, 2017 at 1:56:41 PM UTC-5, Zhihao Yuan wrote:<div class=3D"quoted-text"><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">=
<div class=3D"gmail_quote"><blockquote style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>Right, but th=
e results of that would be no different from you doing `bool b =3D expr;`. =
So there&#39;s no &quot;meaningless effect&quot;; you just did the <i>wrong=
 thing</i>.<br></div></div></blockquote></div></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">The principle advantage losses when we</div><div dir=
=3D"auto">discovered meaningless combinations,</div><div dir=3D"auto">meani=
ngless combinations imply</div><div dir=3D"auto">artificial orthogonality, =
hence high</div><div dir=3D"auto">degree coupling.</div></div></blockquote>=
</div><div><br>... I&#39;m not sure I understand what you&#39;re saying. Be=
cause it sounds like you&#39;re saying that the existence of `bool b =3D ex=
pr` is a problem with the language. [...]</div></div></blockquote></div></d=
iv><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote"><bloc=
kquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div><br>Because the only difference b=
etween `bool [] =3D expr` and `bool b =3D expr` is that you gave it a name.=
 So if one of these is wrong, then the other must be wrong for the same rea=
sons. Accordingly, if one of these is fine, then the other must also be fin=
e.<br><br>You cannot be fine with one while claiming that the other is wron=
g.<br></div></div></blockquote></div></div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">bool b =3D expr is right and bool [] =3D expr</div><div dir=
=3D"auto">is wrong, because the goal of the former</div><div dir=3D"auto">i=
s to transfer value, the side effect is</div><div dir=3D"auto">a non-goal, =
while the goal of the later is</div><div dir=3D"auto">RAII, but it lost RAI=
I, so it&#39;s wrong.</div><div dir=3D"auto"><br></div><div class=3D"gmail_=
extra" dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><br><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px" class=3D"m_9=
048316662866628255prettyprint"><code class=3D"m_9048316662866628255prettypr=
int"><div class=3D"m_9048316662866628255subprettyprint"><span style=3D"colo=
r:#008" class=3D"m_9048316662866628255styled-by-prettify">for</span><span s=
tyle=3D"color:#660" class=3D"m_9048316662866628255styled-by-prettify">(</sp=
an><span style=3D"color:#008" class=3D"m_9048316662866628255styled-by-prett=
ify">auto</span><span style=3D"color:#000" class=3D"m_9048316662866628255st=
yled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_90483166628=
66628255styled-by-prettify">[]</span><span style=3D"color:#000" class=3D"m_=
9048316662866628255styled-by-prettify"> </span><span style=3D"color:#660" c=
lass=3D"m_9048316662866628255styled-by-prettify">:</span><span style=3D"col=
or:#000" class=3D"m_9048316662866628255styled-by-prettify"> ints</span><spa=
n style=3D"color:#660" class=3D"m_9048316662866628255styled-by-prettify">(<=
/span><span style=3D"color:#066" class=3D"m_9048316662866628255styled-by-pr=
ettify">5</span><span style=3D"color:#660" class=3D"m_9048316662866628255st=
yled-by-prettify">))</span><span style=3D"color:#000" class=3D"m_9048316662=
866628255styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:#800" c=
lass=3D"m_9048316662866628255styled-by-prettify">//Do this 5 times.</span><=
/div></code></div><br>My idea does.<br></div></div></blockquote></div></div=
><div dir=3D"auto"><br></div><div dir=3D"auto">Here with or without a name =
has much</div><div dir=3D"auto">less importance than the RAII cases, but</d=
iv><div dir=3D"auto">I can accept it as a valid plus.</div><div dir=3D"auto=
"><br></div><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quo=
te"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>I also don&#39;t kno=
w how `__extend_me` would impact globals, [...]</div></div></blockquote></d=
iv></div><div dir=3D"auto"><br></div><div dir=3D"auto">As usual, end of sco=
pe.</div><div dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto=
"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
><br>Can `__extend_me` work with `constexpr` things? Because decomposition =
declarations can (or if not now, they certainly will once that gets fixed).=
</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">constexpr auto [] =3D an excellent example</div><div dir=3D"auto"=
>of meaningless combinations because</div><div dir=3D"auto">objects with no=
ntrival destructor does</div><div dir=3D"auto">not work with constexpr.</di=
v><div dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto"><div =
class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Can `_=
_extend_me` temporaries have attributes?<br></div></div></blockquote></div>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">Yes if being proven use=
ful.</div><div dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"aut=
o"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><br>Do you see now why using structured binding here works so well?</div>=
</div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto=
">I didn&#39;t see, 2 cases down, 1 alive.</div><div dir=3D"auto"><br></div=
><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote"><blockq=
uote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><br>Therefore, using `__extend_me` =
in various cases can require copy/move constructors.<br></div></div><div cl=
ass=3D"quoted-text">

<p></p></div></blockquote></div>Not in the cases doing your solution&#39;s<=
/div><div class=3D"gmail_extra" dir=3D"auto">work though, but thanks for yo=
ur insight</div><div class=3D"gmail_extra" dir=3D"auto">on this.</div><div =
class=3D"gmail_extra" dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=
=3D"auto">--</div><div class=3D"gmail_extra" dir=3D"auto">Zhihao</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/CAGsORuBsjsP5q%3DuinbdOJBXV88SVQHbpYy=
nXMrR8ZEOWyhMwLg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBsjsP5q%=
3DuinbdOJBXV88SVQHbpYynXMrR8ZEOWyhMwLg%40mail.gmail.com</a>.<br />

--001a114449765e76850545ebb5cf--

.

On Thu, Jan 12, 2017 at 1:56 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Do you see now why using structured binding here works so well? It already
> has answered all of the questions that need to be answered.

One more question: why `auto [] = f();` is different from `f();`?
"Oh, because the former defines a uniquely named variable..."
Well, consider the following thought experiment:

  What happens if we redefine the lifetime of the uniquely named
  variable `e` in structured binding `auto [a, b, ...] = expr;` as follows:
  The lifetime of `e` is no shorter than the full expression where
  the last time any name introduced (a, b, ...) being referred to.

So that in

  auto [a, b] = f();
  g(a);
  g2(b);
  // e is now destructed
  g3();

Sounds like an optimization, but the problem is quite big: one can
take a reference to `a`:

  auto& c = a;
  // e is destructed

then `c` becomes dangling.

This idea doesn't work because the names in C++ do not work
that way.  The lifetime of a name in C++ lasts until the end of
the scope, therefore you expect `a` and `b` are valid until
the end of the scope, and that is why `e` is defined to be a
uniquely named variable, because in that way `e`'s lifetime
will be long enough to support `a` and `b`.

Recall that in the early design papers of structured binding,
there was no such implicit variable, `a` and `b` were individual
copies of the parts from the return value of `f()`.  We added
the implicit variable to make `a` and `b` more flexible.
`e` is the result, not the cause.

So what is `auto [] = f();`'s semantics?  There is no `a` and
`b`, no name is referring to the return value of f(), so why
the return value cannot be immediately destroyed?  Why
the whole thing is different from `f();`?

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
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/CAGsORuCt9M6igdBO04uw-4g2hFASCxy4eON6A%2B4Knys4REd3_g%40mail.gmail.com.

.

------=_Part_1276_206233824.1484263869345
Content-Type: multipart/alternative;
 boundary="----=_Part_1277_1522858024.1484263869346"

------=_Part_1277_1522858024.1484263869346
Content-Type: text/plain; charset=UTF-8

On Thursday, January 12, 2017 at 3:39:10 PM UTC-5, Zhihao Yuan wrote:
>
> On Jan 12, 2017 1:57 PM, "Nicol Bolas" <jmck...@gmail.com
> <javascript:void(0)>> wrote:
>
> On Thursday, January 12, 2017 at 1:56:41 PM UTC-5, Zhihao Yuan wrote:
>
>>
>> Right, but the results of that would be no different from you doing `bool
>> b = expr;`. So there's no "meaningless effect"; you just did the *wrong
>> thing*.
>>
>>
>> The principle advantage losses when we
>> discovered meaningless combinations,
>> meaningless combinations imply
>> artificial orthogonality, hence high
>> degree coupling.
>>
>
> ... I'm not sure I understand what you're saying. Because it sounds like
> you're saying that the existence of `bool b = expr` is a problem with the
> language. [...]
>
>
> Because the only difference between `bool [] = expr` and `bool b = expr`
> is that you gave it a name. So if one of these is wrong, then the other
> must be wrong for the same reasons. Accordingly, if one of these is fine,
> then the other must also be fine.
>
> You cannot be fine with one while claiming that the other is wrong.
>
>
> bool b = expr is right and bool [] = expr
> is wrong, because the goal of the former
> is to transfer value,
>

.... I don't understand.

I'm a user. I have an expression <expr>. That expression results in a
prvalue of a RAII type that I want to extend over a particular scope of
code.

If I type `bool [] = <expr>`, with the above expectation, then I have made
a mistake. If I type `bool b = <expr>`, with the same expectation, then I
have *made the exact same mistake*. The only difference is that in the
latter case, I introduced a name I don't care about. But the mistake is the
same either way: using the wrong type to capture the return of the
expression.

Why do you structure your argument such that if I type `bool b = <expr>;`
then I clearly wanted "to transfer value", while if I type `bool [] =
<expr>;` then I wanted scoping for the object? It sounds like you're
assuming your own conclusion, rather than looking at these cases as they
are.


> the side effect is
> a non-goal, while the goal of the later is
> RAII, but it lost RAII, so it's wrong.
>

If your goal really is RAII, you wouldn't type `bool []`, since `bool` *has
no destructor*. You keep missing that part of the issue: *nobody will type
this*. They will either use `auto []` or they will use `std::lock_guard []`
or whatever the actual type they get from the expression.

You're concerned about someone making a mistake that is highly unlikely to
actually happen. I don't see why we should be concerned that someone could
type the wrong thing, so long as:

1: They can type the right thing.

2: Typing the right thing requires less effort than the wrong thing.

3: It will be immediately obvious upon reading the code when they've typed
the wrong thing.

I've proposed a mechanism that solves the problem it is intended to solve,
that is simple to use, that is easily understood, that follows existing
constructs in the language, and that requires minimal effort to standardize
(in terms of wording).

I don't understand why that is somehow a bad thing. It doesn't even
interfere with your `__extend_me` idea, because there are plenty of use
cases for that which *don't* revolve around unnamed variable circumstances.

It's like someone looking at `if constexpr` and saying, "why do we need
that, when we have concepts?"

Can `__extend_me` work with `constexpr` things? Because decomposition
> declarations can (or if not now, they certainly will once that gets fixed).
>
>
> constexpr auto [] = an excellent example
> of meaningless combinations because
> objects with nontrival destructor does
> not work with constexpr.
>

I was actually thinking of the side effects of executing the constant
expression. You need to store the result in a `constexpr` variable to have
greater assurance that the function is executed at compile-time.

But now I realize that it would be difficult to have side-effects if all of
the parameters are `constexpr` too. So never mind.

On Thursday, January 12, 2017 at 5:37:23 PM UTC-5, Zhihao Yuan wrote:
>
> On Thu, Jan 12, 2017 at 1:56 PM, Nicol Bolas <jmck...@gmail.com> wrote:
> > Do you see now why using structured binding here works so well? It
> already
> > has answered all of the questions that need to be answered.
>
> ...
>

> So what is `auto [] = f();`'s semantics?  There is no `a` and
> `b`, no name is referring to the return value of f(), so why
> the return value cannot be immediately destroyed?  Why
> the whole thing is different from `f();`?
>

Because it looks very much like a variable definition, so nobody will be
surprised that it introduces a variable. And most importantly, because the
specification says so.

--
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/9ffa2e2d-c9fc-4b85-8c01-ab10e51fa434%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, January 12, 2017 at 3:39:10 PM UTC-5, Zhihao =
Yuan 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"auto"><=
div dir=3D"auto"><div class=3D"gmail_quote">On Jan 12, 2017 1:57 PM, &quot;=
Nicol Bolas&quot; &lt;<a href=3D"javascript:void(0)" target=3D"_blank" gdf-=
obfuscated-mailto=3D"36YtBq6gBgAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:<br type=3D"attribu=
tion"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">On Thursday, January 12, 2017 at 1:56:41 PM=
 UTC-5, Zhihao Yuan wrote:<div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"auto"><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div><br>Right, but the results of that would be no different fro=
m you doing `bool b =3D expr;`. So there&#39;s no &quot;meaningless effect&=
quot;; you just did the <i>wrong thing</i>.<br></div></div></blockquote></d=
iv></div><div dir=3D"auto"><br></div><div dir=3D"auto">The principle advant=
age losses when we</div><div dir=3D"auto">discovered meaningless combinatio=
ns,</div><div dir=3D"auto">meaningless combinations imply</div><div dir=3D"=
auto">artificial orthogonality, hence high</div><div dir=3D"auto">degree co=
upling.</div></div></blockquote></div><div><br>... I&#39;m not sure I under=
stand what you&#39;re saying. Because it sounds like you&#39;re saying that=
 the existence of `bool b =3D expr` is a problem with the language. [...]</=
div></div></blockquote></div></div><div dir=3D"auto"><div class=3D"gmail_qu=
ote"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><br>Because the only difference between=
 `bool [] =3D expr` and `bool b =3D expr` is that you gave it a name. So if=
 one of these is wrong, then the other must be wrong for the same reasons. =
Accordingly, if one of these is fine, then the other must also be fine.<br>=
<br>You cannot be fine with one while claiming that the other is wrong.<br>=
</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">bool b =3D expr is right and bool [] =3D expr</div><div dir=3D"au=
to">is wrong, because the goal of the former</div><div dir=3D"auto">is to t=
ransfer value,</div></div></blockquote><div><br>... I don&#39;t understand.=
<br><br>I&#39;m a user. I have an expression &lt;expr&gt;. That expression =
results in a prvalue of a RAII type that I want to extend over a particular=
 scope of code.<br><br>If I type `bool [] =3D &lt;expr&gt;`, with the above=
 expectation, then I have made a mistake. If I type `bool b =3D &lt;expr&gt=
;`, with the same expectation, then I have <i>made the exact same mistake</=
i>. The only difference is that in the latter case, I introduced a name I d=
on&#39;t care about. But the mistake is the same either way: using the wron=
g type to capture the return of the expression.<br><br>Why do you structure=
 your argument such that if I type `bool b =3D &lt;expr&gt;;` then I clearl=
y wanted &quot;to transfer value&quot;, while if I type `bool [] =3D &lt;ex=
pr&gt;;` then I wanted scoping for the object? It sounds like you&#39;re as=
suming your own conclusion, rather than looking at these cases as they are.=
<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 dir=3D"au=
to"><div dir=3D"auto">the side effect is</div><div dir=3D"auto">a non-goal,=
 while the goal of the later is</div><div dir=3D"auto">RAII, but it lost RA=
II, so it&#39;s wrong.</div></div></blockquote><div><br>If your goal really=
 is RAII, you wouldn&#39;t type `bool []`, since `bool` <i>has no destructo=
r</i>. You keep missing that part of the issue: <i>nobody will type this</i=
>. They will either use `auto []` or they will use `std::lock_guard []` or =
whatever the actual type they get from the expression.<br><br>You&#39;re co=
ncerned about someone making a mistake that is highly unlikely to actually =
happen. I don&#39;t see why we should be concerned that someone could type =
the wrong thing, so long as:<br><br>1: They can type the right thing.<br><b=
r>2: Typing the right thing requires less effort than the wrong thing.<br><=
br>3: It will be immediately obvious upon reading the code when they&#39;ve=
 typed the wrong thing.<br><br>I&#39;ve proposed a mechanism that solves th=
e problem it is intended to solve, that is simple to use, that is easily un=
derstood, that follows existing constructs in the language, and that requir=
es minimal effort to standardize (in terms of wording).<br><br>I don&#39;t =
understand why that is somehow a bad thing. It doesn&#39;t even interfere w=
ith your `__extend_me` idea, because there are plenty of use cases for that=
 which <i>don&#39;t</i> revolve around unnamed variable circumstances.<br><=
br>It&#39;s like someone looking at `if constexpr` and saying, &quot;why do=
 we need that, when we have concepts?&quot;<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"auto"><div dir=3D"auto"></div><div =
dir=3D"auto"><div class=3D"gmail_quote"><blockquote style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Can =
`__extend_me` work with `constexpr` things? Because decomposition declarati=
ons can (or if not now, they certainly will once that gets fixed).</div></d=
iv></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">c=
onstexpr auto [] =3D an excellent example</div><div dir=3D"auto">of meaning=
less combinations because</div><div dir=3D"auto">objects with nontrival des=
tructor does</div><div dir=3D"auto">not work with constexpr.</div></div></b=
lockquote><div><br>I was actually thinking of the side effects of executing=
 the constant expression. You need to store the result in a `constexpr` var=
iable to have greater assurance that the function is executed at compile-ti=
me.<br><br>But now I realize that it would be difficult to have side-effect=
s if all of the parameters are `constexpr` too. So never mind.<br></div><di=
v><br>On Thursday, January 12, 2017 at 5:37:23 PM UTC-5, Zhihao Yuan wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 12, 2017 at 1:56 P=
M, Nicol Bolas &lt;<a target=3D"_blank" rel=3D"nofollow">jmck...@gmail.com<=
/a>&gt; wrote:
<br>&gt; Do you see now why using structured binding here works so well? It=
 already
<br>&gt; has answered all of the questions that need to be answered.
<br>
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
<div>... <br></div></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">
<br>So what is `auto [] =3D f();`&#39;s semantics? =C2=A0There is no `a` an=
d
<br>`b`, no name is referring to the return value of f(), so why
<br>the return value cannot be immediately destroyed? =C2=A0Why
<br>the whole thing is different from `f();`?<br></blockquote><div><br></di=
v>Because it looks very much like a variable definition, so nobody will be =
surprised that it introduces a variable. And most importantly, because the =
specification says so.<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/9ffa2e2d-c9fc-4b85-8c01-ab10e51fa434%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9ffa2e2d-c9fc-4b85-8c01-ab10e51fa434=
%40isocpp.org</a>.<br />

------=_Part_1277_1522858024.1484263869346--

------=_Part_1276_206233824.1484263869345--

.

On Thu, Jan 12, 2017 at 5:31 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> You're concerned about someone making a mistake that is highly unlikely to
> actually happen. I don't see why we should be concerned that someone could
> type the wrong thing, so long as:
>
> 1: They can type the right thing.
>
> 2: Typing the right thing requires less effort than the wrong thing.
>
> 3: It will be immediately obvious upon reading the code when they've typed
> the wrong thing.
>

Yes, real person is not going to write that, but it is still true that
your solution opens a whole can of meaningless thingy.
`bool b = true;` is meaningful, but `bool [] = true;` is meaningless
and `bool [] = f();` is meaningless -- there is no `bool [] = ...;` that
is meaningful.

> I've proposed a mechanism that solves the problem it is intended to solve,
> that is simple to use, that is easily understood, that follows existing
> constructs in the language, and that requires minimal effort to standardize
> (in terms of wording).
>

And I showed that:

  1. Coupling your solution to structured binding may be risky, and
  2. Designing based on existing specification may be missing the
     point of the existing facility.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
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/CAGsORuAyb9Go3na_hTWFWV1Ks-ofH6nDxV9ZwGCiJ7%3DU%2B58wfA%40mail.gmail.com.

.

------=_Part_418_856279986.1484282189957
Content-Type: multipart/alternative;
 boundary="----=_Part_419_1713039130.1484282189958"

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



=E5=9C=A8 2017=E5=B9=B41=E6=9C=8813=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8A=E5=8D=886:37:23=EF=BC=8CZhihao Yuan=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thu, Jan 12, 2017 at 1:56 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:=20
> > Do you see now why using structured binding here works so well? It=20
> already=20
> > has answered all of the questions that need to be answered.=20
>
> One more question: why `auto [] =3D f();` is different from `f();`?=20
> "Oh, because the former defines a uniquely named variable..."=20
> Well, consider the following thought experiment:=20
>
>   What happens if we redefine the lifetime of the uniquely named=20
>   variable `e` in structured binding `auto [a, b, ...] =3D expr;` as=20
> follows:=20
>   The lifetime of `e` is no shorter than the full expression where=20
>   the last time any name introduced (a, b, ...) being referred to.=20
>
> So that in=20
>
>   auto [a, b] =3D f();=20
>   g(a);=20
>   g2(b);=20
>   // e is now destructed=20
>   g3();=20
>
> Sounds like an optimization, but the problem is quite big: one can=20
> take a reference to `a`:=20
>
>   auto& c =3D a;=20
>   // e is destructed=20
>
> then `c` becomes dangling.=20
>
> This idea doesn't work because the names in C++ do not work=20
> that way.  The lifetime of a name in C++ lasts until the end of=20
> the scope, therefore you expect `a` and `b` are valid until=20
> the end of the scope, and that is why `e` is defined to be a=20
> uniquely named variable, because in that way `e`'s lifetime=20
> will be long enough to support `a` and `b`.=20
>
=20
Lifetime is not a property of names.
The lifetime of a static object are not bound with the block scope. The=20
lifetime of reference is (mostly) unspecified.
I probably know what you were meaning, but those misuses of terms are=20
obfuscating.
=20

>
> Recall that in the early design papers of structured binding,=20
> there was no such implicit variable, `a` and `b` were individual=20
> copies of the parts from the return value of `f()`.  We added=20
> the implicit variable to make `a` and `b` more flexible.=20
> `e` is the result, not the cause.=20
>
> So what is `auto [] =3D f();`'s semantics?  There is no `a` and=20
> `b`, no name is referring to the return value of f(), so why=20
> the return value cannot be immediately destroyed?  Why=20
> the whole thing is different from `f();`?=20
>
> --=20
> Zhihao Yuan, ID lichray=20
> The best way to predict the future is to invent it.=20
> ___________________________________________________=20
> 4BSD -- http://blog.miator.net/=20
>

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

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B41=E6=9C=8813=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=886:37:23=EF=BC=8CZhihao Yuan=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu=
, Jan 12, 2017 at 1:56 PM, Nicol Bolas &lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"Vh9JbCGnBgAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; Do you see now why using structured binding here works so well? It=
 already
<br>&gt; has answered all of the questions that need to be answered.
<br>
<br>One more question: why `auto [] =3D f();` is different from `f();`?
<br>&quot;Oh, because the former defines a uniquely named variable...&quot;
<br>Well, consider the following thought experiment:
<br>
<br>=C2=A0 What happens if we redefine the lifetime of the uniquely named
<br>=C2=A0 variable `e` in structured binding `auto [a, b, ...] =3D expr;` =
as follows:
<br>=C2=A0 The lifetime of `e` is no shorter than the full expression where
<br>=C2=A0 the last time any name introduced (a, b, ...) being referred to.
<br>
<br>So that in
<br>
<br>=C2=A0 auto [a, b] =3D f();
<br>=C2=A0 g(a);
<br>=C2=A0 g2(b);
<br>=C2=A0 // e is now destructed
<br>=C2=A0 g3();
<br>
<br>Sounds like an optimization, but the problem is quite big: one can
<br>take a reference to `a`:
<br>
<br>=C2=A0 auto&amp; c =3D a;
<br>=C2=A0 // e is destructed
<br>
<br>then `c` becomes dangling.
<br>
<br>This idea doesn&#39;t work because the names in C++ do not work
<br>that way. =C2=A0The lifetime of a name in C++ lasts until the end of
<br>the scope, therefore you expect `a` and `b` are valid until
<br>the end of the scope, and that is why `e` is defined to be a
<br>uniquely named variable, because in that way `e`&#39;s lifetime
<br>will be long enough to support `a` and `b`.
<br></blockquote><div>=C2=A0<br>Lifetime is not a property of names.<br></d=
iv><div>The lifetime of a static object are not bound with the block scope.=
 The lifetime of reference is (mostly) unspecified.<br>I probably know what=
 you were meaning, but those misuses of terms are <span class=3D"op_dict3_f=
ont24 op_dict3_marginRight">obfuscating</span>.<br>=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">
<br>Recall that in the early design papers of structured binding,
<br>there was no such implicit variable, `a` and `b` were individual
<br>copies of the parts from the return value of `f()`. =C2=A0We added
<br>the implicit variable to make `a` and `b` more flexible.
<br>`e` is the result, not the cause.
<br>
<br>So what is `auto [] =3D f();`&#39;s semantics? =C2=A0There is no `a` an=
d
<br>`b`, no name is referring to the return value of f(), so why
<br>the return value cannot be immediately destroyed? =C2=A0Why
<br>the whole thing is different from `f();`?
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://blog.miator.net/" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp=
%3A%2F%2Fblog.miator.net%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHmWTsHV=
Z1D7s1tahvZikRjgaSh7g&#39;;return true;" onclick=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fblog.miator.net%2F\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNHmWTsHVZ1D7s1tahvZikRjgaSh7g&#39;;return true;">http:=
//blog.miator.net/</a>
<br></blockquote></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/1776e7bb-7872-4463-8dea-4ec7c57cafcc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1776e7bb-7872-4463-8dea-4ec7c57cafcc=
%40isocpp.org</a>.<br />

------=_Part_419_1713039130.1484282189958--

------=_Part_418_856279986.1484282189957--

.

On Thu, Jan 12, 2017 at 10:36 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>>
>> The lifetime of a name in C++ lasts until the end of
>> the scope, therefore you expect `a` and `b` are valid until
>> the end of the scope, [...]
>
> Lifetime is not a property of names.
> The lifetime of a static object are not bound with the block scope. The
> lifetime of reference is (mostly) unspecified.
> I probably know what you were meaning, but those misuses of terms are
> obfuscating.

Yea, not "lifetime", maybe just "valid until".  Thanks.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

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

.

------=_Part_556_126100445.1484321771464
Content-Type: multipart/alternative;
 boundary="----=_Part_557_177213992.1484321771464"

------=_Part_557_177213992.1484321771464
Content-Type: text/plain; charset=UTF-8

On Thursday, January 12, 2017 at 8:54:46 PM UTC-5, Zhihao Yuan wrote:
>
> On Thu, Jan 12, 2017 at 5:31 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> >
> > You're concerned about someone making a mistake that is highly unlikely
> to
> > actually happen. I don't see why we should be concerned that someone
> could
> > type the wrong thing, so long as:
> >
> > 1: They can type the right thing.
> >
> > 2: Typing the right thing requires less effort than the wrong thing.
> >
> > 3: It will be immediately obvious upon reading the code when they've
> typed
> > the wrong thing.
> >
>
> Yes, real person is not going to write that, but it is still true that
> your solution opens a whole can of meaningless thingy.
> `bool b = true;` is meaningful, but `bool [] = true;` is meaningless
> and `bool [] = f();` is meaningless -- there is no `bool [] = ...;` that
> is meaningful.
>

First, let's assume you're right, that `bool [] = ...` is never meaningful.

.... so what?

There are other types for which `Typename [] = ...` *will* be meaningful.
You're basically saying we can't have an unnamed variable syntax that
includes a specific typename, just because a user *could* use it with types
that aren't meaningful. That makes no sense to me.

Second, what about [[nodiscard]]? If an expression results in a
`[[nodiscard]] bool` (perhaps an error code), and you really do choose to
disregard it, `bool [] = <expr>` has meaning. It means "Yes, I know this
thing told me not to discard this `bool`, but I really do want to discard
it."

Third, *and most important*... decomposition declarations must start with
`auto`. They are not allowed to use arbitrary typenames. You might say
"yet", but until "yet" becomes "now", all your criticisms in this regard
are *purely speculative*. You're castigating my idea based on syntax that
both doesn't exist and hasn't been proposed.

> I've proposed a mechanism that solves the problem it is intended to
> solve,
> > that is simple to use, that is easily understood, that follows existing
> > constructs in the language, and that requires minimal effort to
> standardize
> > (in terms of wording).
> >
>
> And I showed that:
>
>   1. Coupling your solution to structured binding may be risky


But it doesn't risk anything. The biggest risk you point out is that there
are some forms of `typename []` which might have no meaning. Which I remind
you, is not a syntax that is at this point legal.

  2. Designing based on existing specification may be missing the
>      point of the existing facility.
>

Yes, we're not using the decomposition syntax for decomposition. So what?

Any form of unnamed variable feature needs to look like a variable
declaration. So it's going to be of the form:

<typename/placeholder> <unnamed-syntax> <initializer>

For a user of the language, `[]` seems like a reasonable "unnamed-syntax".
`auto [] = ...` looks like a variable declaration. So there is little
chance for confusion by the user as to what's going on.

If a couple of minor syntactic and semantic changes allow people to get a
useful feature, in a way that doesn't look like a hack, then what does it
matter if it is piggy-backing off of a different feature?

To me, it's no different from one of the more recent forms of the
`operator-dot` proposal, which suggests using base classes as the means of
conversion. That is, your class is not technically derived from that class,
but for the purposes of name lookup and conversion, your class looks like
it is. Beyond that, all it provides is a user-defined mechanism for doing
the derived-to-base instance conversion that had been compiler-defined
before.

It is using existing syntactic and semantic infrastructure for a new
purpose. Just like my idea here.

--
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/4f73c380-682b-446c-8310-fa6b0ae816ff%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, January 12, 2017 at 8:54:46 PM UTC-5, Zhihao =
Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 12, 201=
7 at 5:31 PM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"ieNpseaxBgAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; You&#39;re concerned about someone making a mistake that is highly=
 unlikely to
<br>&gt; actually happen. I don&#39;t see why we should be concerned that s=
omeone could
<br>&gt; type the wrong thing, so long as:
<br>&gt;
<br>&gt; 1: They can type the right thing.
<br>&gt;
<br>&gt; 2: Typing the right thing requires less effort than the wrong thin=
g.
<br>&gt;
<br>&gt; 3: It will be immediately obvious upon reading the code when they&=
#39;ve typed
<br>&gt; the wrong thing.
<br>&gt;
<br>
<br>Yes, real person is not going to write that, but it is still true that
<br>your solution opens a whole can of meaningless thingy.
<br>`bool b =3D true;` is meaningful, but `bool [] =3D true;` is meaningles=
s
<br>and `bool [] =3D f();` is meaningless -- there is no `bool [] =3D ...;`=
 that
<br>is meaningful.<br></blockquote><div><br>First, let&#39;s assume you&#39=
;re right, that `bool [] =3D ...` is never meaningful.<br><br>... so what?<=
br><br>There are other types for which `Typename [] =3D ...` <i>will</i> be=
 meaningful. You&#39;re basically saying we can&#39;t have an unnamed varia=
ble syntax that includes a specific typename, just because a user <i>could<=
/i> use it with types that aren&#39;t meaningful. That makes no sense to me=
..<br><br>Second, what about [[nodiscard]]? If an expression results in a `[=
[nodiscard]] bool` (perhaps an error code), and you really do choose to dis=
regard it, `bool [] =3D &lt;expr&gt;` has meaning. It means &quot;Yes, I kn=
ow this thing told me not to discard this `bool`, but I really do want to d=
iscard it.&quot;<br><br>Third, <i>and most important</i>... decomposition d=
eclarations must start with `auto`. They are not allowed to use arbitrary t=
ypenames. You might say &quot;yet&quot;, but until &quot;yet&quot; becomes =
&quot;now&quot;, all your criticisms in this regard are <i>purely speculati=
ve</i>. You&#39;re castigating my idea based on syntax that both doesn&#39;=
t exist and hasn&#39;t been proposed.<br><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">
&gt; I&#39;ve proposed a mechanism that solves the problem it is intended t=
o solve,
<br>&gt; that is simple to use, that is easily understood, that follows exi=
sting
<br>&gt; constructs in the language, and that requires minimal effort to st=
andardize
<br>&gt; (in terms of wording).
<br>&gt;
<br>
<br>And I showed that:
<br>
<br>=C2=A0 1. Coupling your solution to structured binding may be risky</bl=
ockquote><div><br>But it doesn&#39;t risk anything. The biggest risk you po=
int out is that there are some forms of `typename []` which might have no m=
eaning. Which I remind you, is not a syntax that is at this point legal.<br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=C2=A0 2. Designing=
 based on existing specification may be missing the
<br>=C2=A0 =C2=A0 =C2=A0point of the existing facility.<br></blockquote><di=
v><br></div>Yes, we&#39;re not using the decomposition syntax for decomposi=
tion. So what?<br><br>Any form of unnamed variable feature needs to look li=
ke a variable declaration. So it&#39;s going to be of the form:<br><br>&lt;=
typename/placeholder&gt; &lt;unnamed-syntax&gt; &lt;initializer&gt;<br><br>=
For a user of the language, `[]` seems like a reasonable &quot;unnamed-synt=
ax&quot;. `auto [] =3D ...` looks like a variable declaration. So there is =
little chance for confusion by the user as to what&#39;s going on.<br><br>I=
f a couple of minor syntactic and semantic changes allow people to get a us=
eful feature, in a way that doesn&#39;t look like a hack, then what does it=
 matter if it is piggy-backing off of a different feature?<br><br>To me, it=
&#39;s no different from one of the more recent forms of the `operator-dot`=
 proposal, which suggests using base classes as the means of conversion. Th=
at is, your class is not technically derived from that class, but for the p=
urposes of name lookup and conversion, your class looks like it is. Beyond =
that, all it provides is a user-defined mechanism for doing the derived-to-=
base instance conversion that had been compiler-defined before.<br><br>It i=
s using existing syntactic and semantic infrastructure for a new purpose. J=
ust like my idea here.<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/4f73c380-682b-446c-8310-fa6b0ae816ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f73c380-682b-446c-8310-fa6b0ae816ff=
%40isocpp.org</a>.<br />

------=_Part_557_177213992.1484321771464--

------=_Part_556_126100445.1484321771464--

.

On 2017-01-12 18:31, Nicol Bolas wrote:
> You're concerned about someone making a mistake that is highly unlikely to
> actually happen. I don't see why we should be concerned that someone could
> type the wrong thing, so long as:
>
> 1: They can type the right thing.
>
> 2: Typing the right thing requires less effort than the wrong thing.
>
> 3: It will be immediately obvious upon reading the code when they've typed
> the wrong thing.

It may not be obvious:

  // miraculously compiles, but does the wrong thing
  std::lock_guard [] = i_return_a_foo_lock_guard();

....but it wouldn't be obvious if you named the variable either. I agree
that I don't understand what Zhihao Yuan sees as a problem.

Of course, you could argue that you really meant to use `auto` :-).

> I don't understand why that is somehow a bad thing. It doesn't even
> interfere with your `__extend_me` idea, because there are plenty of use
> cases for that which *don't* revolve around unnamed variable circumstances.

....in particular, it would be nice for this to finally work:

  for (auto i : std::add_const(__extend_me make_me_a_list())

> On Thursday, January 12, 2017 at 5:37:23 PM UTC-5, Zhihao Yuan wrote:
>> So what is `auto [] = f();`'s semantics?  There is no `a` and
>> `b`, no name is referring to the return value of f(), so why
>> the return value cannot be immediately destroyed?  Why
>> the whole thing is different from `f();`?
>
> Because it looks very much like a variable definition, so nobody will be
> surprised that it introduces a variable. And most importantly, because the
> specification says so.

In particular, because the specification of S.B. is that it creates a
hidden temporary and then binds aliases to "parts" of that temporary.
Only the second half of that is being omitted in the proposal.

--
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/5878FEE9.4060109%40gmail.com.

.

On 2017-01-13 10:36, Nicol Bolas wrote:
> Second, what about [[nodiscard]]? If an expression results in a=20
> `[[nodiscard]] bool` (perhaps an error code), and you really do choose to=
=20
> disregard it, `bool [] =3D <expr>` has meaning. It means "Yes, I know thi=
s=20
> thing told me not to discard this `bool`, but I really do want to discard=
=20
> it."

I was just talking about this in a thread=C2=B9 on std-discussion, and I ve=
ry
much hope assignment to an anonymous variable *will* warn. I don't think
that assignment to anonymous sufficiently indicates intent here. Use
[[maybe_unused]] or a cast-to-void.

(=C2=B9
https://groups.google.com/a/isocpp.org/d/msg/std-discussion/dE1ubDI3--c/c6G=
XlO9yCAAJ)

(On a related note, this use of [[maybe_unused]] makes me wonder if we
really ought to have an actual [[unused]], perhaps that warns if the
value is used after all.)

--=20
Matthew

--=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/58790082.7050306%40gmail.com.

.

On 2017-01-12 17:37, Zhihao Yuan wrote:
> One more question: why `auto [] = f();` is different from `f();`?
> "Oh, because the former defines a uniquely named variable..."

No; it's different because the return value enters the current scope and
is destroyed at the end of said scope, rather than (as in `f();`) the
end of the statement.

> So what is `auto [] = f();`'s semantics?  There is no `a` and
> `b`, no name is referring to the return value of f(), so why
> the return value cannot be immediately destroyed?  Why
> the whole thing is different from `f();`?

....because that's not how S.B. is defined? Because having this
difference in semantics is _the whole point_?

This reminds me of a similar point I made in my generalized unpacking paper:

  Consider `pt`, a product type of size 2 whose `get<N>(pt)` have side
  effects. Now consider `auto x = [1]pt`. The result of this is to
  assign `get<1>(pt)` to `auto x`... but what of `get<0>(pt)`; is it
  ever called?

If we just write `[1]pt`, it seems obvious that `get<0>(pt)` should not
be called. However, what if we had written `[1][:]pt` instead? What
about `[1]{[:]pt...}`?

This sort of thing is why we allow different phrasings to produce
different side effects; it allows the user to express different intents.
(I propose that only the third calls `get<0>(pt)`. It "has" to, because
`[1]` operates on a temporary object which must first be constructed,
whose construction entails calling `get<0>(pt). Similarly, `auto [] =
f()` specifies the creation of a hidden temporary whose lifetime is the
current scope to receive the value from `f()`. In both cases, that we
subsequently ignore part or all of the values is beside the point; if we
wanted them to be elided entirely, we would have written different code.)

--
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/587907A8.1030706%40gmail.com.

.

On Fri, Jan 13, 2017 at 11:00 AM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
> On 2017-01-12 17:37, Zhihao Yuan wrote:
>> One more question: why `auto [] = f();` is different from `f();`?
>> "Oh, because the former defines a uniquely named variable..."
>
> No; it's different because the return value enters the current scope and
> is destroyed at the end of said scope, rather than (as in `f();`) the
> end of the statement.
>

I asked a design question.  It's a 'why', not 'what'.  And
your later reply showed that you didn't read my comments
that were removed in your reply.

On Fri, Jan 13, 2017 at 10:23 AM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
>
> ...in particular, it would be nice for this to finally work:
>
>   for (auto i : std::add_const(__extend_me make_me_a_list())

`add_const` banned rvalue.  But in general, yes, things
like this work, because the prvalue is now materialized
on the stack by `__extend_me` (or a real keyword, like
`register`).

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
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/CAGsORuAbEPhzOE1%2BnehoqmdkT8jtQr%2BkUkCWb7sY_wuN-HyDyQ%40mail.gmail.com.

.

On 2017-01-13 13:43, Zhihao Yuan wrote:
> On Fri, Jan 13, 2017 at 11:00 AM, Matthew Woehlke wrote:
>> On 2017-01-12 17:37, Zhihao Yuan wrote:
>>> One more question: why `auto [] = f();` is different from `f();`?
>>> "Oh, because the former defines a uniquely named variable..."
>>
>> No; it's different because the return value enters the current scope and
>> is destroyed at the end of said scope, rather than (as in `f();`) the
>> end of the statement.
>
> I asked a design question.  It's a 'why', not 'what'.  And
> your later reply showed that you didn't read my comments
> that were removed in your reply.

I did read your comments. Maybe I don't understand your point? You
concluded that there is no reason that lifetime extension should happen
here, because the thing being lifetime extended is inaccessible. I
assert that lifetime extension happens anyway, because you wrote
something different whose intent *is lifetime extension*.

See also everything else I wrote in my previous message.

There is no reason why you would ever write `auto [] = f();` instead of
just `f();` except because you *specifically want* the different
semantics of lifetime extending the return value. Just like, in my
alternate example, you would write `[1]{[:]pt...}` instead of `[1]pt`
only because you *specifically want* the different semantics of a call
to `get<0>(pt)` being executed. In both cases, you could argue that
aggressive optimization should make the two equivalent, but also in both
cases there is no sane reason why you would write the second form except
that you *specifically do not* want* such optimization.

IOW, it's different because a) it's useful that way, and b) there is no
reason for it to be the same.

>> ...in particular, it would be nice for this to finally work:
>>
>>   for (auto i : std::add_const(__extend_me make_me_a_list())
>
> `add_const` banned rvalue.

....because it is broken without lifetime extension. If we had your
`__extend_me`, that restriction *could* be lifted. (Ideally, we would
want to only lift it if we *know* the lifetime has been extended...
there's something for you to think about...)

--
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/587927DF.5030706%40gmail.com.

.

On Fri, Jan 13, 2017 at 1:17 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
> There is no reason why you would ever write `auto [] = f();` instead of
> just `f();` except because you *specifically want* the different
> semantics of lifetime extending the return value. Just like, in my
> alternate example, you would write `[1]{[:]pt...}` instead of `[1]pt`
> only because you *specifically want* the different semantics of a call
> to `get<0>(pt)` being executed.
>

People see things then assign meanings, for good or bad
I don't do that.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
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/CAGsORuBAXXcgD1x5hQF9LzHGWfiVYgDjkLNLZpmT3PJ00-Q%3DCA%40mail.gmail.com.

.

------=_Part_15_390655618.1484792661784
Content-Type: multipart/alternative;
 boundary="----=_Part_16_1535727906.1484792661784"

------=_Part_16_1535727906.1484792661784
Content-Type: text/plain; charset=UTF-8

I have formalized the idea into a more proposal like form.

While composing this, I came to the realization that the `auto []` syntax
actually makes more sense than I thought. For example, consider one of the
oft-requested features of decompositions: not specifying a name.

Well, you could (in theory; the proposal doesn't include this) allow `[]`
to be used to not specify a name. And it would work naturally:

auto [first, [], third] = expr;

Users would come to see `[]` as meaning "unnamed" or "unspecified".

It would *also* work out naturally if we expand decompositions into
multiple levels:

auto [ [], [inner_first, inner_second], third ] = expr;

So the syntax is not really as much of a hack as I thought.

--
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/cd42dbf2-5876-4462-98bb-5547fedbd62c%40isocpp.org.

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

<div dir=3D"ltr">I have formalized the idea into a more proposal like form.=
<br><br>While composing this, I came to the realization that the `auto []` =
syntax actually makes more sense than I thought. For example, consider one =
of the oft-requested features of decompositions: not specifying a name.<br>=
<br>Well, you could (in theory; the proposal doesn&#39;t include this) allo=
w `[]` to be used to not specify a name. And it would work naturally:<br><b=
r><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187=
, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-w=
ord;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">first</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[],</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> third</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">]</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> expr</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span></div></c=
ode></div><br>Users would come to see `[]` as meaning &quot;unnamed&quot; o=
r &quot;unspecified&quot;.<br><br>It would <i>also</i> work out naturally i=
f we expand decompositions into multiple levels:<br><br><div style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pretty=
print"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">auto</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: #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-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">inner_firs=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> inner_second</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">],</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> third </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"> expr</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span></div></code></div><br>So the syntax is not real=
ly as much of a hack as I thought.<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/cd42dbf2-5876-4462-98bb-5547fedbd62c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cd42dbf2-5876-4462-98bb-5547fedbd62c=
%40isocpp.org</a>.<br />

------=_Part_16_1535727906.1484792661784--

------=_Part_15_390655618.1484792661784
Content-Type: text/html; charset=US-ASCII; name="Unnamed Variables.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Unnamed Variables.html"
X-Attachment-Id: e28a2772-27a3-4e99-b03e-90489202e524
Content-ID: <e28a2772-27a3-4e99-b03e-90489202e524>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta http-equiv="Content-Style-Type" content="text/css" />
  <meta name="generator" content="pandoc" />
  <title>Unnamed Variables</title>
  <style type="text/css">code{white-space: pre;}</style>
</head>
<body>
<div id="header">
<h1 class="title">Unnamed Variables</h1>
</div>
<div id="TOC">
<ul>
<li><a href="#motivation">Motivation</a></li>
<li><a href="#design">Design</a><ul>
<li><a href="#potential-problems">Potential Problems</a></li>
<li><a href="#possible-extensions">Possible Extensions</a></li>
</ul></li>
<li><a href="#impact-on-the-standard">Impact on the Standard</a></li>
<li><a href="#acknowledgements">Acknowledgements</a></li>
</ul>
</div>
<p><a href="https://cplusplus.github.io/EWG/ewg-active.html#35">EWG issue #35</a> presents a problem that C++ has had need to solve for some time: declaring a variable without a name, which is used only for its constructor and (mainly) destructor. This proposal presents a way to make a small modification to an existing feature that makes this possible.</p>
<h1 id="motivation">Motivation</h1>
<p>With RAII becoming more and more prevalent in C++ code, the need to create variables that are used only for their constructor and destructor increases. Scope guard types like <code>scope_exit</code>, <code>scope_fail</code>, and <code>scope_success</code> make this even more important. Consider the following simple boilerplate:</p>
<pre><code>#define SCOPE_EXIT(f) auto _some_name_ = std::make_scope_exit(f);</code></pre>
<p>Such a macro cannot be used multiple times in the same scope, as it would redefine the same variable name. Also, there is always the possibility that <code>_some_name_</code> is used elsewhere, creating a conflict there.</p>
<h1 id="design">Design</h1>
<p><a href="https://cplusplus.github.io/EWG/ewg-active.html#35">EWG issue #35</a> outlines some of the issues about the uniqueness of the name. Since that time, C++ gained a feature which is contingent on having variables with unique names within their contexts: <a href="http://wg21.link/P0144">structured binding</a>, which is standardized under the concept of decomposition declarations.</p>
<p>Decomposition works by creating an unnamed variable, then introducing a number of names that represent operations on that variable: accessing one of its members or calling <code>get&lt;N&gt;</code> on it. As such, the standard problem of having a variable with a unique name in its context has already been solved.</p>
<p>Indeed, even the syntax for such a concept seems adequate and easily identifiable for the needs of just creating an unnamed variable:</p>
<pre><code>auto [] = &lt;expr&gt;;</code></pre>
<p>So the design for this feature involves making two changes to the existing standard:</p>
<ol style="list-style-type: decimal">
<li><p>Change the grammar to make the <em>identifier-list</em> in a decomposition declaration optional rather than mandatory. This should include the grammar for <em>simple-declaration</em> as well as in <em>for-range-declaration</em>.</p></li>
<li><p>Change [dcl.decomp] to recognize the possibility of an empty <em>identifier-list</em>. In such a case, it only introduces a uniquely named variable <code>e</code>, with none of the other decomposition machinery. So [dcl.decomp]/2-4 would not apply.</p></li>
</ol>
<h2 id="potential-problems">Potential Problems</h2>
<p>At present, [dcl.decomp] has a compile-time prohibition on using a decomposition declaration if the number of elements in the type do not match the number of names. By adding this feature, we would effectively permit the use of such a declaration in a mis-matched fashion, but only by providing no identifiers.</p>
<p>In practice, this should not be too much of a problem. A user who writes <code>auto []</code> is far more likely to genuinely want to make an unnamed variable than they are to have done so accidentally.</p>
<h2 id="possible-extensions">Possible Extensions</h2>
<p>At present, one problem with decomposition declarations is that you cannot discard one of the names. If you want to skip one of the elements of the object, you still have to name it.</p>
<p>But we could change things to permit the following:</p>
<pre><code>auto [first, [], third] = expr;</code></pre>
<p>Since <code>auto []</code> already means &quot;unnamed variable&quot;, it makes sense to a user that using <code>[]</code> in such a context would mean to not name that member.</p>
<p>This would also be a natural step towards multi-level decomposition:</p>
<pre><code>auto [first, [first_first, first_second], third] = expr;</code></pre>
<p>These are not part of the proposal; they are just notations for future directions of decomposition. They also point out how well this meshes with decomposition.</p>
<h1 id="impact-on-the-standard">Impact on the Standard</h1>
<p>This should be a backwards compatible change. Implementing it ought to be easy, since the hard work is fielded by decomposition declarations.</p>
<h1 id="acknowledgements">Acknowledgements</h1>
</body>
</html>

------=_Part_15_390655618.1484792661784--

.

------=_Part_246_340837120.1484846700676
Content-Type: multipart/alternative;
 boundary="----=_Part_247_593135094.1484846700676"

------=_Part_247_593135094.1484846700676
Content-Type: text/plain; charset=UTF-8

On Thursday, 19 January 2017 02:24:21 UTC, Nicol Bolas wrote:
>
> It would *also* work out naturally if we expand decompositions into
> multiple levels:
>
> auto [ [], [inner_first, inner_second], third ] = expr;
>
> So the syntax is not really as much of a hack as I thought.
>

 Isn't that an ill-formed *attribute-specifier-seq*? You say it works out
naturally; have you implemented this?

--
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/86a3a7c4-3ae2-487c-b593-dd32fb3e88cb%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, 19 January 2017 02:24:21 UTC, Nicol Bolas  wr=
ote:<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">It would =
<i>also</i> work out naturally if we expand decompositions into multiple le=
vels:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-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"> </span><span style=3D"c=
olor:#660">[],</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">[</span><span style=3D"color:#000">inner_first</span><span style=3D=
"color:#660">,</span><span style=3D"color:#000"> inner_second</span><span s=
tyle=3D"color:#660">],</span><span style=3D"color:#000"> third </span><span=
 style=3D"color:#660">]</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">=3D</span><span style=3D"color:#000"> expr</span><span sty=
le=3D"color:#660">;</span></div></code></div><br>So the syntax is not reall=
y as much of a hack as I thought.<br></div></blockquote><div><br></div><div=
>=C2=A0Isn&#39;t that an ill-formed <i>attribute-specifier-seq</i>? You say=
 it works out naturally; have you implemented this?</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/86a3a7c4-3ae2-487c-b593-dd32fb3e88cb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/86a3a7c4-3ae2-487c-b593-dd32fb3e88cb=
%40isocpp.org</a>.<br />

------=_Part_247_593135094.1484846700676--

------=_Part_246_340837120.1484846700676--

.

------=_Part_309_1214630144.1484849476476
Content-Type: multipart/alternative;
 boundary="----=_Part_310_709333809.1484849476476"

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

On Thursday, January 19, 2017 at 12:25:00 PM UTC-5, Thomas K=C3=B6ppe wrote=
:
>
> On Thursday, 19 January 2017 02:24:21 UTC, Nicol Bolas wrote:
>>
>> It would *also* work out naturally if we expand decompositions into=20
>> multiple levels:
>>
>> auto [ [], [inner_first, inner_second], third ] =3D expr;
>>
>> So the syntax is not really as much of a hack as I thought.
>>
>
>  Isn't that an ill-formed *attribute-specifier-seq*? You say it works out=
=20
> naturally; have you implemented this?
>

It works out naturally *visually*; I have no idea how it works out=20
grammatically. However, any grammatical issues would have to be solved if=
=20
we're going to have multi-level decompositions of any kind. So any such=20
parsing issues are not specifically the fault of using `[]` to be a=20
placeholder for an unspecified name.

Also, I'm not proposing that. My main point in bringing it up is that, if=
=20
you add multi-level decomposition, then you can essentially get `[]` to be=
=20
a placeholder for an unspecified name. And therefore using `[]` to mean=20
"unnamed" doesn't seem as arbitrary.

--=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/c9954da8-6dca-4aad-98ca-69d56d702578%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, January 19, 2017 at 12:25:00 PM UTC-5, Thomas=
 K=C3=B6ppe wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Thursday, 19 January 2017 02:24:21 UTC, Nicol Bolas  wrote:<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">It would <i>also</i> work =
out naturally if we expand decompositions into multiple levels:<br><br><div=
 style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);b=
order-style:solid;border-width:1px"><code><div><span style=3D"color:#008">a=
uto</span><span style=3D"color:#000"> </span><span style=3D"color:#660">[</=
span><span style=3D"color:#000"> </span><span style=3D"color:#660">[],</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660">[</span><sp=
an style=3D"color:#000">inner_first</span><span style=3D"color:#660">,</spa=
n><span style=3D"color:#000"> inner_second</span><span style=3D"color:#660"=
>],</span><span style=3D"color:#000"> third </span><span style=3D"color:#66=
0">]</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> expr</span><span style=3D"color:#660"=
>;</span></div></code></div><br>So the syntax is not really as much of a ha=
ck as I thought.<br></div></blockquote><div><br></div><div>=C2=A0Isn&#39;t =
that an ill-formed <i>attribute-specifier-seq</i>? You say it works out nat=
urally; have you implemented this?</div></div></blockquote><div><br>It work=
s out naturally <i>visually</i>; I have no idea how it works out grammatica=
lly. However, any grammatical issues would have to be solved if we&#39;re g=
oing to have multi-level decompositions of any kind. So any such parsing is=
sues are not specifically the fault of using `[]` to be a placeholder for a=
n unspecified name.<br><br>Also, I&#39;m not proposing that. My main point =
in bringing it up is that, if you add multi-level decomposition, then you c=
an essentially get `[]` to be a placeholder for an unspecified name. And th=
erefore using `[]` to mean &quot;unnamed&quot; doesn&#39;t seem as arbitrar=
y.<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/c9954da8-6dca-4aad-98ca-69d56d702578%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c9954da8-6dca-4aad-98ca-69d56d702578=
%40isocpp.org</a>.<br />

------=_Part_310_709333809.1484849476476--

------=_Part_309_1214630144.1484849476476--

.

On 2017-01-19 13:11, Nicol Bolas wrote:
> My main point in bringing it up is that, if you add multi-level
> decomposition, then you can essentially get `[]` to be a placeholder
> for an unspecified name. And therefore using `[]` to mean "unnamed"
> doesn't seem as arbitrary.

Actually, I don't think I agree with that logic. Let's say, instead,
that we used '_' for anonymous variables:

  auto _ = foo();
  auto [_, [ia, ib], c] = bar();

This proceeds just as naturally.

That's not to say that I disagree with the logic of implementing
anonymous variables by redefining `auto []` to mean "a decomposition
declaration where I don't actually want to bind anything", nor that
doing so logically extends that feature to ignoring some values if we
subsequently get nested decomposition. I just don't agree with the
converse; that this feature logically falls out of nested decomposition.

Also, while your proposal strengthens a case for nested decomposition,
because being able to ignore a value in a decomposition - which is
something folks seem to want - naturally falls out of combining the
features, that would (as shown above) be true regardless of the syntax.

If anything, this might be an argument *against* your proposed syntax,
because using nested []'s for nested decomposition has the potential of
being grammatically ambiguous (as noted). If we do get nested
decomposition, but it looks like e.g. `auto [{a, b}, c] = ...`, then we
lose the ability to combine the features.

--
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/58810A73.6030003%40gmail.com.

.

But you can't use _ to mean an anonymous variable. _ is already a
valid name and used by some for various purposes.

/Peter

On Thu, Jan 19, 2017 at 7:50 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
> On 2017-01-19 13:11, Nicol Bolas wrote:
>> My main point in bringing it up is that, if you add multi-level
>> decomposition, then you can essentially get `[]` to be a placeholder
>> for an unspecified name. And therefore using `[]` to mean "unnamed"
>> doesn't seem as arbitrary.
>
> Actually, I don't think I agree with that logic. Let's say, instead,
> that we used '_' for anonymous variables:
>
>   auto _ = foo();
>   auto [_, [ia, ib], c] = bar();
>
> This proceeds just as naturally.
>
> That's not to say that I disagree with the logic of implementing
> anonymous variables by redefining `auto []` to mean "a decomposition
> declaration where I don't actually want to bind anything", nor that
> doing so logically extends that feature to ignoring some values if we
> subsequently get nested decomposition. I just don't agree with the
> converse; that this feature logically falls out of nested decomposition.
>
> Also, while your proposal strengthens a case for nested decomposition,
> because being able to ignore a value in a decomposition - which is
> something folks seem to want - naturally falls out of combining the
> features, that would (as shown above) be true regardless of the syntax.
>
> If anything, this might be an argument *against* your proposed syntax,
> because using nested []'s for nested decomposition has the potential of
> being grammatically ambiguous (as noted). If we do get nested
> decomposition, but it looks like e.g. `auto [{a, b}, c] = ...`, then we
> lose the ability to combine the features.
>
> --
> 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/58810A73.6030003%40gmail.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/CANPtknyL19qA%2BLPOVy8x0AzrQi9n-viWzcbTv3-VENBLNZ6R0A%40mail.gmail.com.

.

Le 19/01/2017 =C3=A0 23:51, Peter Koch Larsen a =C3=A9crit :
> But you can't use _ to mean an anonymous variable. _ is already a
> valid name and used by some for various purposes.
>
Maybe it is no to late to say that _ is not a valid name when used on a=20
structure binding context.
In this way we could use it later to mean an name that is ignored.

Of course this wouldn't help us to have unnamed variables yet.

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/1ce02dde-d0c5-37ea-1219-e5e97fd329ee%40wanadoo.f=
r.

.

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

Le 19/01/2017 =C3=A0 03:24, Nicol Bolas a =C3=A9crit :
> I have formalized the idea into a more proposal like form.
>
> While composing this, I came to the realization that the `auto []`=20
> syntax actually makes more sense than I thought. For example, consider=20
> one of the oft-requested features of decompositions: not specifying a=20
> name.
>
> Well, you could (in theory; the proposal doesn't include this) allow=20
> `[]` to be used to not specify a name. And it would work naturally:
>
> |
> auto[first,[],third]=3Dexpr;
> |
>
> Users would come to see `[]` as meaning "unnamed" or "unspecified".
>
> It would /also/ work out naturally if we expand decompositions into=20
> multiple levels:
>
> |
> auto[[],[inner_first,inner_second],third ]=3Dexpr;
> |
>
> So the syntax is not really as much of a hack as I thought.

I know it is a extreme case, but wondering if matching tuple<> would be=20
a case to consider.

     auto [] =3D tuple<>{};

if [a, b, c] is used to match a product type of size 3, it seems natural=20
that [] would be used to match a product type of size 0.


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/ece5b60a-da5f-e0f1-cf09-8936ab7bd629%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 19/01/2017 =C3=A0 03:24, Nicol Bolas =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:cd42dbf2-5876-4462-98bb-5547fedbd62c@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">I have formalized the idea into a more proposal
        like form.<br>
        <br>
        While composing this, I came to the realization that the `auto
        []` syntax actually makes more sense than I thought. For
        example, consider one of the oft-requested features of
        decompositions: not specifying a name.<br>
        <br>
        Well, you could (in theory; the proposal doesn't include this)
        allow `[]` to be used to not specify a name. And it would work
        naturally:<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"> </span=
><span
                style=3D"color: #660;" class=3D"styled-by-prettify">[</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify">first</=
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">[],</sp=
an><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> third<=
/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</sp=
an><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> expr</=
span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
></div>
          </code></div>
        <br>
        Users would come to see `[]` as meaning "unnamed" or
        "unspecified".<br>
        <br>
        It would <i>also</i> work out naturally if we expand
        decompositions into multiple levels:<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"> </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">[],</sp=
an><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">inner_f=
irst</span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span
                style=3D"color: #000;" class=3D"styled-by-prettify">
                inner_second</span><span style=3D"color: #660;"
                class=3D"styled-by-prettify">],</span><span style=3D"color:
                #000;" class=3D"styled-by-prettify"> third </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</sp=
an><span
                style=3D"color: #000;" class=3D"styled-by-prettify"> expr</=
span><span
                style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
></div>
          </code></div>
        <br>
        So the syntax is not really as much of a hack as I thought.<br>
      </div>
    </blockquote>
    <br>
    I know it is a extreme case, but wondering if matching=C2=A0
    tuple&lt;&gt; would be a case to consider.<br>
    <br>
    =C2=A0=C2=A0=C2=A0 auto [] =3D tuple&lt;&gt;{};<br>
    <br>
    if [a, b, c] is used to match a product type of size 3, it seems
    natural that [] would be used to match a product type of size 0.<br>
    <br>
    <br>
    Vicente<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/ece5b60a-da5f-e0f1-cf09-8936ab7bd629%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ece5b60a-da5f-e0f1-cf09-8936ab7bd629=
%40wanadoo.fr</a>.<br />

--------------7F5A926073092115F267EF99--

.

------=_Part_394_1289892409.1484867476072
Content-Type: multipart/alternative;
 boundary="----=_Part_395_403673987.1484867476072"

------=_Part_395_403673987.1484867476072
Content-Type: text/plain; charset=UTF-8

On Thursday, January 19, 2017 at 5:51:36 PM UTC-5, Peter Koch Larsen wrote:
>
> But you can't use _ to mean an anonymous variable. _ is already a
> valid name and used by some for various purposes.
>

He was proposing a hypothetical to make a point. Nothing more.

--
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/ea357a9f-807d-40e1-b54b-0b6597351568%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, January 19, 2017 at 5:51:36 PM UTC-5, Peter K=
och Larsen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">But you can&#=
39;t use _ to mean an anonymous variable. _ is already a
<br>valid name and used by some for various purposes.<br></blockquote><div>=
<br>He was proposing a hypothetical to make a point. Nothing more.<br></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/ea357a9f-807d-40e1-b54b-0b6597351568%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ea357a9f-807d-40e1-b54b-0b6597351568=
%40isocpp.org</a>.<br />

------=_Part_395_403673987.1484867476072--

------=_Part_394_1289892409.1484867476072--

.

On Fri, Jan 20, 2017 at 12:04 AM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 19/01/2017 =C3=A0 23:51, Peter Koch Larsen a =C3=A9crit :
>>
>> But you can't use _ to mean an anonymous variable. _ is already a
>> valid name and used by some for various purposes.
>>
> Maybe it is no to late to say that _ is not a valid name when used on a
> structure binding context.
> In this way we could use it later to mean an name that is ignored.
>
> Of course this wouldn't help us to have unnamed variables yet.
>
> 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/1ce02dde-d0c=
5-37ea-1219-e5e97fd329ee%40wanadoo.fr.

--=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/CANPtknzn8RdX6HZm1ozoX4mrp_ggCcTacTXFv6reWQFm-iL=
TrQ%40mail.gmail.com.

.

On Fri, Jan 20, 2017 at 12:04 AM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 19/01/2017 =C3=A0 23:51, Peter Koch Larsen a =C3=A9crit :
>>
>> But you can't use _ to mean an anonymous variable. _ is already a
>> valid name and used by some for various purposes.
>>
> Maybe it is no to late to say that _ is not a valid name when used on a
> structure binding context.
> In this way we could use it later to mean an name that is ignored.
>
> Of course this wouldn't help us to have unnamed variables yet.
>

Perhaps not. But I believe that using _ for an unnamed variable is
more confusing than Nicols proposal.
After some reflection, I actually consider Nicols proposal as not
confusing at all provided you need anonymous variables in the first
place.

/Peter

--=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/CANPtknwweFtDX9HXJP5yz7_bO%2BcCTQz2B1EMBZGHXiOMN=
JngWw%40mail.gmail.com.

.

------=_Part_389_1296081616.1484868664588
Content-Type: multipart/alternative;
 boundary="----=_Part_390_1096247204.1484868664588"

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

Maybe the square bracket is starting to get too overloaded, we also have=20
the prefix [] to create pack slices in another proposal.

In the context of structured binding such an unnamed variable would always=
=20
be the only token between two commas so it seems that * or ? could be used=
=20
to mimic glob patterns, and it might even be useful to define that ? means=
=20
one and * means any number of. For instance this would allow picking up the=
=20
two first elements of an arbirary tuple into two separate variables while=
=20
ignoring the rest:

auto [ int a, int b, * ] =3D my_tuple;

Or to just pick up the second member of a pair:

auto [ ?, int s ] =3D my_pair;

I think this would carry over nicely to a future nested-decomposition=20
proposal.


Den fredag 20 januari 2017 kl. 00:15:51 UTC+1 skrev Peter Koch Larsen:
>
> On Fri, Jan 20, 2017 at 12:04 AM, Vicente J. Botet Escriba=20
> <vicent...@wanadoo.fr <javascript:>> wrote:=20
> > Le 19/01/2017 =C3=A0 23:51, Peter Koch Larsen a =C3=A9crit :=20
> >>=20
> >> But you can't use _ to mean an anonymous variable. _ is already a=20
> >> valid name and used by some for various purposes.=20
> >>=20
> > Maybe it is no to late to say that _ is not a valid name when used on a=
=20
> > structure binding context.=20
> > In this way we could use it later to mean an name that is ignored.=20
> >=20
> > Of course this wouldn't help us to have unnamed variables yet.=20
> >=20
>
> Perhaps not. But I believe that using _ for an unnamed variable is=20
> more confusing than Nicols proposal.=20
> After some reflection, I actually consider Nicols proposal as not=20
> confusing at all provided you need anonymous variables in the first=20
> place.=20
>
> /Peter=20
>

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

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

<div dir=3D"ltr">Maybe the square bracket is starting to get too overloaded=
, we also have the prefix [] to create pack slices in another proposal.<div=
><br></div><div>In the context of structured binding such an unnamed variab=
le would always be the only token between two commas so it seems that * or =
? could be used to mimic glob patterns, and it might even be useful to defi=
ne that ? means one and * means any number of. For instance this would allo=
w picking up the two first elements of an arbirary tuple into two separate =
variables while ignoring the rest:</div><div><br></div><div>auto [ int a, i=
nt b, * ] =3D my_tuple;</div><div><br></div><div>Or to just pick up the sec=
ond member of a pair:</div><div><br></div><div>auto [ ?, int s ] =3D my_pai=
r;</div><div><br></div><div>I think this would carry over nicely to a futur=
e nested-decomposition proposal.</div><div><br><br>Den fredag 20 januari 20=
17 kl. 00:15:51 UTC+1 skrev Peter Koch Larsen:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">On Fri, Jan 20, 2017 at 12:04 AM, Vicente J. Botet Escriba
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
mnuVFvalAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">vicent...@wanadoo.fr</a>&gt; wrote:
<br>&gt; Le 19/01/2017 =C3=A0 23:51, Peter Koch Larsen a =C3=A9crit :
<br>&gt;&gt;
<br>&gt;&gt; But you can&#39;t use _ to mean an anonymous variable. _ is al=
ready a
<br>&gt;&gt; valid name and used by some for various purposes.
<br>&gt;&gt;
<br>&gt; Maybe it is no to late to say that _ is not a valid name when used=
 on a
<br>&gt; structure binding context.
<br>&gt; In this way we could use it later to mean an name that is ignored.
<br>&gt;
<br>&gt; Of course this wouldn&#39;t help us to have unnamed variables yet.
<br>&gt;
<br>
<br>Perhaps not. But I believe that using _ for an unnamed variable is
<br>more confusing than Nicols proposal.
<br>After some reflection, I actually consider Nicols proposal as not
<br>confusing at all provided you need anonymous variables in the first
<br>place.
<br>
<br>/Peter
<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/c8e0907f-d256-430a-b3bc-7981f150f661%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c8e0907f-d256-430a-b3bc-7981f150f661=
%40isocpp.org</a>.<br />

------=_Part_390_1096247204.1484868664588--

------=_Part_389_1296081616.1484868664588--

.

------=_Part_403_1986354051.1484874471301
Content-Type: multipart/alternative;
 boundary="----=_Part_404_1296570905.1484874471301"

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



On Thursday, January 19, 2017 at 6:10:44 PM UTC-5, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 19/01/2017 =C3=A0 03:24, Nicol Bolas a =C3=A9crit :
>
> I have formalized the idea into a more proposal like form.
>
> While composing this, I came to the realization that the `auto []` syntax=
=20
> actually makes more sense than I thought. For example, consider one of th=
e=20
> oft-requested features of decompositions: not specifying a name.
>
> Well, you could (in theory; the proposal doesn't include this) allow `[]`=
=20
> to be used to not specify a name. And it would work naturally:
>
> auto [first, [], third] =3D expr;
>
> Users would come to see `[]` as meaning "unnamed" or "unspecified".
>
> It would *also* work out naturally if we expand decompositions into=20
> multiple levels:
>
> auto [ [], [inner_first, inner_second], third ] =3D expr;
>
> So the syntax is not really as much of a hack as I thought.
>
>
> I know it is a extreme case, but wondering if matching  tuple<> would be =
a=20
> case to consider.
>
>     auto [] =3D tuple<>{};
>
> if [a, b, c] is used to match a product type of size 3, it seems natural=
=20
> that [] would be used to match a product type of size 0.
>

I don't see how that would cause a problem, since it shouldn't be checking=
=20
`tuple_size` at all.
=20

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

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

<div dir=3D"ltr"><br><br>On Thursday, January 19, 2017 at 6:10:44 PM UTC-5,=
 Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 19/01/2017 =C3=A0 03:24, Nicol Bolas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">I have formalized the idea into a more proposal
        like form.<br>
        <br>
        While composing this, I came to the realization that the `auto
        []` syntax actually makes more sense than I thought. For
        example, consider one of the oft-requested features of
        decompositions: not specifying a name.<br>
        <br>
        Well, you could (in theory; the proposal doesn&#39;t include this)
        allow `[]` to be used to not specify a name. And it would work
        naturally:<br>
        <br>
        <div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-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=
">first</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">[],</span><span style=3D"color:#000"> t=
hird</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"> expr=
</span><span style=3D"color:#660">;</span></div>
          </code></div>
        <br>
        Users would come to see `[]` as meaning &quot;unnamed&quot; or
        &quot;unspecified&quot;.<br>
        <br>
        It would <i>also</i> work out naturally if we expand
        decompositions into multiple levels:<br>
        <br>
        <div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-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=
"> </span><span style=3D"color:#660">[],</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">[</span><span style=3D"color:#000">inner_=
first</span><span style=3D"color:#660">,</span><span style=3D"color:#000">
                inner_second</span><span style=3D"color:#660">],</span><spa=
n style=3D"color:#000"> third </span><span style=3D"color:#660">]</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span =
style=3D"color:#000"> expr</span><span style=3D"color:#660">;</span></div>
          </code></div>
        <br>
        So the syntax is not really as much of a hack as I thought.<br>
      </div>
    </blockquote>
    <br>
    I know it is a extreme case, but wondering if matching=C2=A0
    tuple&lt;&gt; would be a case to consider.<br>
    <br>
    =C2=A0=C2=A0=C2=A0 auto [] =3D tuple&lt;&gt;{};<br>
    <br>
    if [a, b, c] is used to match a product type of size 3, it seems
    natural that [] would be used to match a product type of size 0.<br></d=
iv></blockquote><div><br>I don&#39;t see how that would cause a problem, si=
nce it shouldn&#39;t be checking `tuple_size` at all.<br>=C2=A0</div></div>

<p></p>

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

------=_Part_404_1296570905.1484874471301--

------=_Part_403_1986354051.1484874471301--

.

------=_Part_1661_764329775.1484887689996
Content-Type: multipart/alternative;
 boundary="----=_Part_1662_214628241.1484887689996"

------=_Part_1662_214628241.1484887689996
Content-Type: text/plain; charset=UTF-8

Maybe some combination of keywords can be used for anonymous variables.
"auto auto = foo()" sorta makes sense... an automatic type followed by an
automatic name. Or maybe "auto default = foo()".

On Thursday, January 19, 2017 at 4:51:36 PM UTC-6, Peter Koch Larsen wrote:
>
> But you can't use _ to mean an anonymous variable. _ is already a
> valid name and used by some for various purposes.
>
> /Peter
>
> On Thu, Jan 19, 2017 at 7:50 PM, Matthew Woehlke
> <mwoehlk...@gmail.com <javascript:>> wrote:
> > On 2017-01-19 13:11, Nicol Bolas wrote:
> >> My main point in bringing it up is that, if you add multi-level
> >> decomposition, then you can essentially get `[]` to be a placeholder
> >> for an unspecified name. And therefore using `[]` to mean "unnamed"
> >> doesn't seem as arbitrary.
> >
> > Actually, I don't think I agree with that logic. Let's say, instead,
> > that we used '_' for anonymous variables:
> >
> >   auto _ = foo();
> >   auto [_, [ia, ib], c] = bar();
> >
> > This proceeds just as naturally.
> >
> > That's not to say that I disagree with the logic of implementing
> > anonymous variables by redefining `auto []` to mean "a decomposition
> > declaration where I don't actually want to bind anything", nor that
> > doing so logically extends that feature to ignoring some values if we
> > subsequently get nested decomposition. I just don't agree with the
> > converse; that this feature logically falls out of nested decomposition.
> >
> > Also, while your proposal strengthens a case for nested decomposition,
> > because being able to ignore a value in a decomposition - which is
> > something folks seem to want - naturally falls out of combining the
> > features, that would (as shown above) be true regardless of the syntax.
> >
> > If anything, this might be an argument *against* your proposed syntax,
> > because using nested []'s for nested decomposition has the potential of
> > being grammatically ambiguous (as noted). If we do get nested
> > decomposition, but it looks like e.g. `auto [{a, b}, c] = ...`, then we
> > lose the ability to combine the features.
> >
> > --
> > 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-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58810A73.6030003%40gmail.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/2cf62cdf-dcd3-463c-aff5-a8df8adeab85%40isocpp.org.

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

<div dir=3D"ltr">Maybe some combination of keywords can be used for anonymo=
us variables. &quot;auto auto =3D foo()&quot; sorta makes sense... an autom=
atic type followed by an automatic name. Or maybe &quot;auto default =3D fo=
o()&quot;. <br><br>On Thursday, January 19, 2017 at 4:51:36 PM UTC-6, Peter=
 Koch Larsen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">But you can=
&#39;t use _ to mean an anonymous variable. _ is already a
<br>valid name and used by some for various purposes.
<br>
<br>/Peter
<br>
<br>On Thu, Jan 19, 2017 at 7:50 PM, Matthew Woehlke
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
OfjoaaOkAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">mwoehlk...@gmail.com</a>&gt; wrote:
<br>&gt; On 2017-01-19 13:11, Nicol Bolas wrote:
<br>&gt;&gt; My main point in bringing it up is that, if you add multi-leve=
l
<br>&gt;&gt; decomposition, then you can essentially get `[]` to be a place=
holder
<br>&gt;&gt; for an unspecified name. And therefore using `[]` to mean &quo=
t;unnamed&quot;
<br>&gt;&gt; doesn&#39;t seem as arbitrary.
<br>&gt;
<br>&gt; Actually, I don&#39;t think I agree with that logic. Let&#39;s say=
, instead,
<br>&gt; that we used &#39;_&#39; for anonymous variables:
<br>&gt;
<br>&gt; =C2=A0 auto _ =3D foo();
<br>&gt; =C2=A0 auto [_, [ia, ib], c] =3D bar();
<br>&gt;
<br>&gt; This proceeds just as naturally.
<br>&gt;
<br>&gt; That&#39;s not to say that I disagree with the logic of implementi=
ng
<br>&gt; anonymous variables by redefining `auto []` to mean &quot;a decomp=
osition
<br>&gt; declaration where I don&#39;t actually want to bind anything&quot;=
, nor that
<br>&gt; doing so logically extends that feature to ignoring some values if=
 we
<br>&gt; subsequently get nested decomposition. I just don&#39;t agree with=
 the
<br>&gt; converse; that this feature logically falls out of nested decompos=
ition.
<br>&gt;
<br>&gt; Also, while your proposal strengthens a case for nested decomposit=
ion,
<br>&gt; because being able to ignore a value in a decomposition - which is
<br>&gt; something folks seem to want - naturally falls out of combining th=
e
<br>&gt; features, that would (as shown above) be true regardless of the sy=
ntax.
<br>&gt;
<br>&gt; If anything, this might be an argument *against* your proposed syn=
tax,
<br>&gt; because using nested []&#39;s for nested decomposition has the pot=
ential of
<br>&gt; being grammatically ambiguous (as noted). If we do get nested
<br>&gt; decomposition, but it looks like e.g. `auto [{a, b}, c] =3D ...`, =
then we
<br>&gt; lose the ability to combine the features.
<br>&gt;
<br>&gt; --
<br>&gt; Matthew
<br>&gt;
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"OfjoaaOkAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"OfjoaaOkAAAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>&gt; To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/58810A73.6030003%40gmail.com=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https:=
//groups.google.com/a/isocpp.org/d/msgid/std-proposals/58810A73.6030003%40g=
mail.com&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/58810A73.6030003%40gmail.com&#39;=
;return true;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr=
>proposals/58810A73.6030003%<wbr>40gmail.com</a>.
<br></blockquote></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/2cf62cdf-dcd3-463c-aff5-a8df8adeab85%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2cf62cdf-dcd3-463c-aff5-a8df8adeab85=
%40isocpp.org</a>.<br />

------=_Part_1662_214628241.1484887689996--

------=_Part_1661_764329775.1484887689996--

.

------=_Part_392_851852966.1484890671389
Content-Type: multipart/alternative;
 boundary="----=_Part_393_1642955773.1484890671389"

------=_Part_393_1642955773.1484890671389
Content-Type: text/plain; charset=UTF-8

On Thursday, January 19, 2017 at 11:48:10 PM UTC-5, Derek Ross wrote:
>
> Maybe some combination of keywords can be used for anonymous variables.
> "auto auto = foo()" sorta makes sense... an automatic type followed by an
> automatic name. Or maybe "auto default = foo()".
>

The whole point of my idea, the reason I choose that syntax, is that it's
piggybacking off of decomposition declarations. Making it work, in terms of
standard changes, requires a minimum of effort: two minor grammar tweaks
and modifying at most 4 paragraphs.

Using a different syntax, whatever that may be, loses that advantage.

--
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/a7af0aa3-7119-4080-a94c-978bb9bcd96d%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, January 19, 2017 at 11:48:10 PM UTC-5, Derek =
Ross 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">Ma=
ybe some combination of keywords can be used for anonymous variables. &quot=
;auto auto =3D foo()&quot; sorta makes sense... an automatic type followed =
by an automatic name. Or maybe &quot;auto default =3D foo()&quot;.</div></b=
lockquote><div><br>The whole point of my idea, the reason I choose that syn=
tax, is that it&#39;s piggybacking off of decomposition declarations. Makin=
g it work, in terms of standard changes, requires a minimum of effort: two =
minor grammar tweaks and modifying at most 4 paragraphs.<br><br>Using a dif=
ferent syntax, whatever that may be, loses that advantage.<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/a7af0aa3-7119-4080-a94c-978bb9bcd96d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a7af0aa3-7119-4080-a94c-978bb9bcd96d=
%40isocpp.org</a>.<br />

------=_Part_393_1642955773.1484890671389--

------=_Part_392_851852966.1484890671389--

.

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

2017-01-20 0:15 GMT+01:00 Peter Koch Larsen <peter.koch.larsen@gmail.com>:

> On Fri, Jan 20, 2017 at 12:04 AM, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
> > Le 19/01/2017 =C3=A0 23:51, Peter Koch Larsen a =C3=A9crit :
> >>
> >> But you can't use _ to mean an anonymous variable. _ is already a
> >> valid name and used by some for various purposes.
> >>
> > Maybe it is no to late to say that _ is not a valid name when used on a
> > structure binding context.
> > In this way we could use it later to mean an name that is ignored.
> >
> > Of course this wouldn't help us to have unnamed variables yet.
> >
>
> Perhaps not. But I believe that using _ for an unnamed variable is
> more confusing than Nicols proposal.
> After some reflection, I actually consider Nicols proposal as not
> confusing at all provided you need anonymous variables in the first
> place.
>

+1 with difference that I liked it from the start and liked it even more
with the future suggestions part added. It looks and feels consistent and
also [] is far more visible than the usual suggested underscore. In my mind
it's marked as variable capture without the possibility to access it since
the name was not specified - more or less anonymous variable but thought of
as capture group so the syntax really fits the purpose.

I also have a possibly terrible idea for future extension of the idea.
Usual proposal for skipping the captured variables is a wildcard - I've
usually seen proposals of ? or _ for skipping one and ... for skipping the
rest of variables.

Let's say we have function foo() returning a tuple of 5 elements and we
don't care about the first three:
auto [?, ?, ?, int x, float y] =3D foo();

alternative with this proposal could be:

auto [[3], int x, float y] =3D foo(); // now the brackets really shine
compared to alternative single character suggestions

Skipping the rest could either still be ... or [2] where the number
represents the rest of the elements (the control freak version of skipping
the rest ;).

Anyhow for me the brackets are consistent, visually appealing and also
extendable more than the rest of the alternative suggestions that I've
heard of.

Regards,
Domen

--=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/CAKgx6BKs7KkbOHU80-ZqNMDjWUHymkvn4Baidkj1yQeHsop=
GvQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-01-20 0:15 GMT+01:00 Peter Koch Larsen <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:peter.koch.larsen@gmail.com" target=3D"_blank">peter.koch.larsen@gmail=
..com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
span class=3D"gmail-">On Fri, Jan 20, 2017 at 12:04 AM, Vicente J. Botet Es=
criba<br>
&lt;<a href=3D"mailto:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.fr</a=
>&gt; wrote:<br>
</span><span class=3D"gmail-">&gt; Le 19/01/2017 =C3=A0 23:51, Peter Koch L=
arsen a =C3=A9crit :<br>
&gt;&gt;<br>
&gt;&gt; But you can&#39;t use _ to mean an anonymous variable. _ is alread=
y a<br>
&gt;&gt; valid name and used by some for various purposes.<br>
&gt;&gt;<br>
&gt; Maybe it is no to late to say that _ is not a valid name when used on =
a<br>
&gt; structure binding context.<br>
&gt; In this way we could use it later to mean an name that is ignored.<br>
&gt;<br>
&gt; Of course this wouldn&#39;t help us to have unnamed variables yet.<br>
&gt;<br>
<br>
</span>Perhaps not. But I believe that using _ for an unnamed variable is<b=
r>
more confusing than Nicols proposal.<br>
After some reflection, I actually consider Nicols proposal as not<br>
confusing at all provided you need anonymous variables in the first<br>
place.<br></blockquote><div><br></div><div>+1 with difference that I liked =
it from the start and liked it even more with the future suggestions part a=
dded. It looks and feels consistent and also [] is far more visible than th=
e usual suggested underscore. In my mind it&#39;s marked as variable captur=
e without the possibility to=20
access it since the name was not specified - more or less anonymous=20
variable but thought of as capture group so the syntax really fits the purp=
ose.<br><br></div><div>I also have a possibly terrible idea for future exte=
nsion of the idea. Usual proposal for skipping the captured variables is a =
wildcard - I&#39;ve usually seen proposals of ? or _ for skipping one and .=
... for skipping the rest of variables.<br><br></div><div>Let&#39;s say we h=
ave function foo() returning a tuple of 5 elements and we don&#39;t care ab=
out the first three:<br></div><div>auto [?, ?, ?, int x, float y] =3D foo()=
;<br><br></div><div>alternative with this proposal could be:<br><br></div><=
div>auto [[3], int x, float y] =3D foo(); // now the brackets really shine =
compared to alternative single character suggestions<br><br></div><div>Skip=
ping the rest could either still be ... or [2] where the number represents =
the rest of the elements (the control freak version of skipping the rest ;)=
..<br><br></div><div>Anyhow for me the brackets are consistent, visually app=
ealing and also extendable more than the rest of the alternative suggestion=
s that I&#39;ve heard of.<br></div><div><br></div><div>Regards,<br></div><d=
iv>Domen<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/CAKgx6BKs7KkbOHU80-ZqNMDjWUHymkvn4Bai=
dkj1yQeHsopGvQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BKs7KkbOHU8=
0-ZqNMDjWUHymkvn4Baidkj1yQeHsopGvQ%40mail.gmail.com</a>.<br />

--94eb2c061a1c2578ba0546820705--

.

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

2017-01-20 8:58 GMT+01:00 Domen Vrankar <domen.vrankar@gmail.com>:

> 2017-01-20 0:15 GMT+01:00 Peter Koch Larsen <peter.koch.larsen@gmail.com>=
:
>
>> On Fri, Jan 20, 2017 at 12:04 AM, Vicente J. Botet Escriba
>> <vicente.botet@wanadoo.fr> wrote:
>> > Le 19/01/2017 =C3=A0 23:51, Peter Koch Larsen a =C3=A9crit :
>> >>
>> >> But you can't use _ to mean an anonymous variable. _ is already a
>> >> valid name and used by some for various purposes.
>> >>
>> > Maybe it is no to late to say that _ is not a valid name when used on =
a
>> > structure binding context.
>> > In this way we could use it later to mean an name that is ignored.
>> >
>> > Of course this wouldn't help us to have unnamed variables yet.
>> >
>>
>> Perhaps not. But I believe that using _ for an unnamed variable is
>> more confusing than Nicols proposal.
>> After some reflection, I actually consider Nicols proposal as not
>> confusing at all provided you need anonymous variables in the first
>> place.
>>
>
> +1 with difference that I liked it from the start and liked it even more
> with the future suggestions part added. It looks and feels consistent and
> also [] is far more visible than the usual suggested underscore. In my mi=
nd
> it's marked as variable capture without the possibility to access it sinc=
e
> the name was not specified - more or less anonymous variable but thought =
of
> as capture group so the syntax really fits the purpose.
>
> I also have a possibly terrible idea for future extension of the idea.
> Usual proposal for skipping the captured variables is a wildcard - I've
> usually seen proposals of ? or _ for skipping one and ... for skipping th=
e
> rest of variables.
>
> Let's say we have function foo() returning a tuple of 5 elements and we
> don't care about the first three:
> auto [?, ?, ?, int x, float y] =3D foo();
>
> alternative with this proposal could be:
>
> auto [[3], int x, float y] =3D foo(); // now the brackets really shine
> compared to alternative single character suggestions
>
> Skipping the rest could either still be ... or [2] where the number
> represents the rest of the elements (the control freak version of skippin=
g
> the rest ;).
>
> Anyhow for me the brackets are consistent, visually appealing and also
> extendable more than the rest of the alternative suggestions that I've
> heard of.
>

Hm just thought of one extra future extension on top of that - just a
random not thought through idea... (haven't even checked if array syntax
could cause issues in parameter pack section).

(Ab)using structured binding and unnamed variables for array/tuple/string
slicing:

auto [x[3], y[2]] =3D foo(); // get two slices
auto [x[3], [2]] =3D foo(); // ignore the rest
auto [[2], x[2], []] =3D foo(); // get the middle
auto [[3], x[2], ...] =3D foo(); // get some elements from a large template
parameter pack of which we don't know the length
auto [[3], x[...]] =3D foo(); // skip some elements from a large template
parameter pack and create a tuple from the rest

IMHO extensibility and visual consistency of [] as unnamed variables
proposal looks promising.

Regards,
Domen

--=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/CAKgx6BJc5-cTQ2-Mi60KUnf93LCXa5TXjQ8O9v1uoXwYxKp=
PwQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-01-20 8:58 GMT+01:00 Domen Vrankar <span dir=3D"ltr">&lt;<a href=3D"mailto=
:domen.vrankar@gmail.com" target=3D"_blank">domen.vrankar@gmail.com</a>&gt;=
</span>:<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"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"gm=
ail-">2017-01-20 0:15 GMT+01:00 Peter Koch Larsen <span dir=3D"ltr">&lt;<a =
href=3D"mailto:peter.koch.larsen@gmail.com" target=3D"_blank">peter.koch.la=
rsen@gmail.com</a>&gt;</span>:<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-m_-2236317559718802866gmail-">On Fri, Jan 2=
0, 2017 at 12:04 AM, Vicente J. Botet Escriba<br>
&lt;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.b=
otet@wanadoo.fr</a>&gt; wrote:<br>
</span><span class=3D"gmail-m_-2236317559718802866gmail-">&gt; Le 19/01/201=
7 =C3=A0 23:51, Peter Koch Larsen a =C3=A9crit :<br>
&gt;&gt;<br>
&gt;&gt; But you can&#39;t use _ to mean an anonymous variable. _ is alread=
y a<br>
&gt;&gt; valid name and used by some for various purposes.<br>
&gt;&gt;<br>
&gt; Maybe it is no to late to say that _ is not a valid name when used on =
a<br>
&gt; structure binding context.<br>
&gt; In this way we could use it later to mean an name that is ignored.<br>
&gt;<br>
&gt; Of course this wouldn&#39;t help us to have unnamed variables yet.<br>
&gt;<br>
<br>
</span>Perhaps not. But I believe that using _ for an unnamed variable is<b=
r>
more confusing than Nicols proposal.<br>
After some reflection, I actually consider Nicols proposal as not<br>
confusing at all provided you need anonymous variables in the first<br>
place.<br></blockquote><div><br></div></span><div>+1 with difference that I=
 liked it from the start and liked it even more with the future suggestions=
 part added. It looks and feels consistent and also [] is far more visible =
than the usual suggested underscore. In my mind it&#39;s marked as variable=
 capture without the possibility to=20
access it since the name was not specified - more or less anonymous=20
variable but thought of as capture group so the syntax really fits the purp=
ose.<br><br></div><div>I also have a possibly terrible idea for future exte=
nsion of the idea. Usual proposal for skipping the captured variables is a =
wildcard - I&#39;ve usually seen proposals of ? or _ for skipping one and .=
... for skipping the rest of variables.<br><br></div><div>Let&#39;s say we h=
ave function foo() returning a tuple of 5 elements and we don&#39;t care ab=
out the first three:<br></div><div>auto [?, ?, ?, int x, float y] =3D foo()=
;<br><br></div><div>alternative with this proposal could be:<br><br></div><=
div>auto [[3], int x, float y] =3D foo(); // now the brackets really shine =
compared to alternative single character suggestions<br><br></div><div>Skip=
ping the rest could either still be ... or [2] where the number represents =
the rest of the elements (the control freak version of skipping the rest ;)=
..<br><br></div><div>Anyhow for me the brackets are consistent, visually app=
ealing and also extendable more than the rest of the alternative suggestion=
s that I&#39;ve heard of.<br></div></div></div></div></blockquote><div><br>=
</div><div>Hm just thought of one extra future extension on top of that - j=
ust a random not thought through idea... (haven&#39;t even checked if array=
 syntax could cause issues in parameter pack section).<br><br></div><div>(A=
b)using structured binding and unnamed variables for array/tuple/string sli=
cing:<br></div><div><br></div><div>auto [x[3], y[2]] =3D foo(); // get two =
slices<br></div><div>auto [x[3], [2]] =3D foo(); // ignore the rest<br></di=
v><div>auto [[2], x[2], []] =3D foo(); // get the middle<br></div><div>auto=
 [[3], x[2], ...] =3D foo(); // get some elements from a large template par=
ameter pack of which we don&#39;t know the length<br></div><div>auto [[3], =
x[...]] =3D foo(); // skip some elements from a large template parameter pa=
ck and create a tuple from the rest<br><br></div><div>IMHO <span class=3D"g=
mail-_Tgc">extensibility</span> and visual consistency of [] as unnamed var=
iables proposal looks promising.<br></div><div><br></div><div>Regards,<br><=
/div><div>Domen<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/CAKgx6BJc5-cTQ2-Mi60KUnf93LCXa5TXjQ8O=
9v1uoXwYxKpPwQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BJc5-cTQ2-M=
i60KUnf93LCXa5TXjQ8O9v1uoXwYxKpPwQ%40mail.gmail.com</a>.<br />

--001a1144b0d0fe51bc054682ac11--

.

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

Ups... For these two:
auto [[3], x[2], ...] = foo(); // get some elements from a large template
parameter pack of which we don't know the length
auto [[3], x[...]] = foo(); // skip some elements from a large template
parameter pack and create a tuple from the rest

I meant:

auto [[3], x[2], ...] = args...;
auto [[3], x[...]] = args...;

Too much copy pasting :D

Regards,
Domen

>

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

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

<div dir=3D"ltr">Ups... For these two:<br><div><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div>auto [[3], x[2], ...] =3D foo(); // get some=
 elements from a large template parameter pack of which we don&#39;t know t=
he length<br></div><div>auto [[3], x[...]] =3D foo(); // skip some elements=
 from a large template parameter pack and create a tuple from the rest<br><=
br></div><div>I meant:<br><br></div><div>auto [[3], x[2], ...] =3D args...;=
<br></div><div>auto [[3], x[...]] =3D args...;<br><br></div><div>Too much c=
opy pasting :D<br></div><div><br></div><div>Regards,<br></div><div>Domen<br=
></div></div></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
</blockquote></div><br></div></div></div>

<p></p>

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

--001a1144b0d0132a29054682c926--

.

------=_Part_606_243898773.1484932787419
Content-Type: multipart/alternative;
 boundary="----=_Part_607_2013176113.1484932787419"

------=_Part_607_2013176113.1484932787419
Content-Type: text/plain; charset=UTF-8



On Thursday, January 19, 2017 at 3:24:21 AM UTC+1, Nicol Bolas wrote:
>
> I have formalized the idea into a more proposal like form.
>
> While composing this, I came to the realization that the `auto []` syntax
> actually makes more sense than I thought. For example, consider one of the
> oft-requested features of decompositions: not specifying a name.
>
> Well, you could (in theory; the proposal doesn't include this) allow `[]`
> to be used to not specify a name. And it would work naturally:
>
> auto [first, [], third] = expr;
>
> Users would come to see `[]` as meaning "unnamed" or "unspecified".
>
> It would *also* work out naturally if we expand decompositions into
> multiple levels:
>
> auto [ [], [inner_first, inner_second], third ] = expr;
>
> So the syntax is not really as much of a hack as I thought.
>

Small detail, as `[[` start attribute maybe we need prefix nested one by
`auto`?

auto[ auto [], b, auto [c, d]] = foo();

--
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/c1893d72-8ecb-4066-9784-0395142ec25a%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, January 19, 2017 at 3:24:21 AM UTC+1,=
 Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">I have formalized the idea into a more proposal like form.<br><br>Whi=
le composing this, I came to the realization that the `auto []` syntax actu=
ally makes more sense than I thought. For example, consider one of the oft-=
requested features of decompositions: not specifying a name.<br><br>Well, y=
ou could (in theory; the proposal doesn&#39;t include this) allow `[]` to b=
e used to not specify a name. And it would work naturally:<br><br><div styl=
e=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"color:#000"> </span><span style=3D"color:#660">[</span>=
<span style=3D"color:#000">first</span><span style=3D"color:#660">,</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">[],</span><spa=
n style=3D"color:#000"> third</span><span style=3D"color:#660">]</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span s=
tyle=3D"color:#000"> expr</span><span style=3D"color:#660">;</span></div></=
code></div><br>Users would come to see `[]` as meaning &quot;unnamed&quot; =
or &quot;unspecified&quot;.<br><br>It would <i>also</i> work out naturally =
if we expand decompositions into multiple levels:<br><br><div style=3D"back=
ground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:so=
lid;border-width:1px"><code><div><span style=3D"color:#008">auto</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">[</span><span sty=
le=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"c=
olor:#000">inner_first</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> inner_second</span><span style=3D"color:#660">],</span><sp=
an style=3D"color:#000"> third </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"> expr</span><span style=3D"color:#660">;</span></div>=
</code></div><br>So the syntax is not really as much of a hack as I thought=
..<br></div></blockquote><div>=C2=A0<br>Small detail, as `[[` start attribut=
e maybe we need prefix nested one by `auto`?<br><br><div style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprin=
t"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #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"> </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 style=3D"color: #660;" class=3D"styled-by-prett=
ify">[],</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan 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"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">c</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]]=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span></div></code></div><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/c1893d72-8ecb-4066-9784-0395142ec25a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c1893d72-8ecb-4066-9784-0395142ec25a=
%40isocpp.org</a>.<br />

------=_Part_607_2013176113.1484932787419--

------=_Part_606_243898773.1484932787419--

.

On 2017-01-20 03:45, Domen Vrankar wrote:
> 2017-01-20 8:58 GMT+01:00 Domen Vrankar <domen.vrankar@gmail.com>:
>> I also have a possibly terrible idea for future extension of the idea.
>> Usual proposal for skipping the captured variables is a wildcard - I've
>> usually seen proposals of ? or _ for skipping one and ... for skipping t=
he
>> rest of variables.
>>
>> Let's say we have function foo() returning a tuple of 5 elements and we
>> don't care about the first three:
>> auto [?, ?, ?, int x, float y] =3D foo();

I'd really rather see `auto [x, y] =3D [3:]foo();` for this sort of thing,
at least as opposed to extending the "placeholder" syntax past the
original proposal.

> Hm just thought of one extra future extension on top of that - just a
> random not thought through idea... (haven't even checked if array syntax
> could cause issues in parameter pack section).
>=20
> (Ab)using structured binding and unnamed variables for array/tuple/string
> slicing:
>=20
> auto [x[3], y[2]] =3D foo(); // get two slices

Just... no... Leaving aside my opinion on the aesthetics of that, what
is the type of `x` or `y`? Do you just enforce that it is `std::tuple`
always? What if `foo()` returns a `std::array`?

This is why P0535=C2=B9 specifies that you get a *parameter pack*. That way=
,
if you want the values reassembled into another product type, you get to
choose which one you want.

I also don't think DD should be abused like this to create a product
type from a slice of another product type. You lose the "decomposition"
part doing that...

(=C2=B9 Not published yet, but see
https://github.com/mwoehlke/cpp-proposals/blob/master/p0535r0-generalized-u=
npacking.rst)

--=20
Matthew

--=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/58826A64.40904%40gmail.com.

.

On 2017-01-19 18:31, Bengt Gustafsson wrote:
> Maybe the square bracket is starting to get too overloaded, we also have
> the prefix [] to create pack slices in another proposal.

Fortunately, that does not interfere in this case; you have already seen
'auto', so unpacking/slicing cannot appear next.

> In the context of structured binding such an unnamed variable would always
> be the only token between two commas so it seems that * or ? could be used
> to mimic glob patterns, and it might even be useful to define that ? means
> one and * means any number of. For instance this would allow picking up the
> two first elements of an arbirary tuple into two separate variables while
> ignoring the rest:
>
> auto [ int a, int b, * ] = my_tuple;
>
> Or to just pick up the second member of a pair:
>
> auto [ ?, int s ] = my_pair;

....or `auto s = [1]my_pair;` :-).

The down side is that this is much harder to specify than the original
proposal. I *do* like the original proposal for that reason. If it could
be non-ambiguous with attributes, that would be ideal.

S.B. was originally going to use a syntax other than []s... I'm starting
to wonder if maybe we should have stuck to that...

Actually... I think it *is* non-ambiguous, but requires (possibly
significant) look-ahead, which compiler authors never like. An attribute
is always of the form `[[stuff]]` (plus optional whitespace), where I
believe `stuff` never contains an unquoted `]` or `[`, whereas an
ambiguous nested DD is of the form `[[...],...]`; that is, there will
always occur at least a `,` between the inner and outer closing `]`s.
(We could require e.g. `[[a],]` for the degenerate - and probably very,
very rare - case of binding `a` to `get<0>(get<0>(rhs))`.)

--
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/58826AC0.60505%40gmail.com.

.

------=_Part_689_340297753.1484954318249
Content-Type: multipart/alternative;
 boundary="----=_Part_690_1210401622.1484954318249"

------=_Part_690_1210401622.1484954318249
Content-Type: text/plain; charset=UTF-8

Its not only about compilers being able to interpret (!) the source code,
it is more about humans being able to do so (and write it correctly). The
rule that one construct should do the same or at least similar things is a
good thing, so as square brackets are already used for indexing, attributes
and structured binding whereas, with pack slicing as runner up ? is only an
infix operator I thought it could be a better choice for the unnamed
variable use. You could throw in a "step over defaulted parameter" use as
it has similar semantics (at least superficially).

Does the current definition of structured binding always allow trailing
elements in the rhs to be ignored? If so the use of * or ... to mean the
rest seems less important. Picking the first and last elements is a
possible use case but this is probably very seldom useful in practice.


Den fredag 20 januari 2017 kl. 20:53:38 UTC+1 skrev Matthew Woehlke:
>
> On 2017-01-19 18:31, Bengt Gustafsson wrote:
> > Maybe the square bracket is starting to get too overloaded, we also have
> > the prefix [] to create pack slices in another proposal.
>
> Fortunately, that does not interfere in this case; you have already seen
> 'auto', so unpacking/slicing cannot appear next.
>
> > In the context of structured binding such an unnamed variable would
> always
> > be the only token between two commas so it seems that * or ? could be
> used
> > to mimic glob patterns, and it might even be useful to define that ?
> means
> > one and * means any number of. For instance this would allow picking up
> the
> > two first elements of an arbirary tuple into two separate variables
> while
> > ignoring the rest:
> >
> > auto [ int a, int b, * ] = my_tuple;
> >
> > Or to just pick up the second member of a pair:
> >
> > auto [ ?, int s ] = my_pair;
>
> ...or `auto s = [1]my_pair;` :-).
>
> The down side is that this is much harder to specify than the original
> proposal. I *do* like the original proposal for that reason. If it could
> be non-ambiguous with attributes, that would be ideal.
>
> S.B. was originally going to use a syntax other than []s... I'm starting
> to wonder if maybe we should have stuck to that...
>
> Actually... I think it *is* non-ambiguous, but requires (possibly
> significant) look-ahead, which compiler authors never like. An attribute
> is always of the form `[[stuff]]` (plus optional whitespace), where I
> believe `stuff` never contains an unquoted `]` or `[`, whereas an
> ambiguous nested DD is of the form `[[...],...]`; that is, there will
> always occur at least a `,` between the inner and outer closing `]`s.
> (We could require e.g. `[[a],]` for the degenerate - and probably very,
> very rare - case of binding `a` to `get<0>(get<0>(rhs))`.)
>
> --
> 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/cd2ad240-0f47-4681-91fa-1600cd349bb7%40isocpp.org.

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

<div dir=3D"ltr">Its not only about compilers being able to interpret (!) t=
he source code, it is more about humans being able to do so (and write it c=
orrectly). The rule that one construct should do the same or at least simil=
ar things is a good thing, so as square brackets are already used for index=
ing, attributes and structured binding whereas, with pack slicing as runner=
 up ? is only an infix operator I thought it could be a better choice for t=
he unnamed variable use. You could throw in a &quot;step over defaulted par=
ameter&quot; use as it has similar semantics (at least superficially).<div>=
<br></div><div>Does the current definition of structured binding always all=
ow trailing elements in the rhs to be ignored? If so the use of * or ... to=
 mean the rest seems less important. Picking the first and last elements is=
 a possible use case but this is probably very seldom useful in practice.</=
div><div><br><br>Den fredag 20 januari 2017 kl. 20:53:38 UTC+1 skrev Matthe=
w Woehlke:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-01-19 18:31,=
 Bengt Gustafsson wrote:
<br>&gt; Maybe the square bracket is starting to get too overloaded, we als=
o have=20
<br>&gt; the prefix [] to create pack slices in another proposal.
<br>
<br>Fortunately, that does not interfere in this case; you have already see=
n
<br>&#39;auto&#39;, so unpacking/slicing cannot appear next.
<br>
<br>&gt; In the context of structured binding such an unnamed variable woul=
d always=20
<br>&gt; be the only token between two commas so it seems that * or ? could=
 be used=20
<br>&gt; to mimic glob patterns, and it might even be useful to define that=
 ? means=20
<br>&gt; one and * means any number of. For instance this would allow picki=
ng up the=20
<br>&gt; two first elements of an arbirary tuple into two separate variable=
s while=20
<br>&gt; ignoring the rest:
<br>&gt;=20
<br>&gt; auto [ int a, int b, * ] =3D my_tuple;
<br>&gt;=20
<br>&gt; Or to just pick up the second member of a pair:
<br>&gt;=20
<br>&gt; auto [ ?, int s ] =3D my_pair;
<br>
<br>...or `auto s =3D [1]my_pair;` :-).
<br>
<br>The down side is that this is much harder to specify than the original
<br>proposal. I *do* like the original proposal for that reason. If it coul=
d
<br>be non-ambiguous with attributes, that would be ideal.
<br>
<br>S.B. was originally going to use a syntax other than []s... I&#39;m sta=
rting
<br>to wonder if maybe we should have stuck to that...
<br>
<br>Actually... I think it *is* non-ambiguous, but requires (possibly
<br>significant) look-ahead, which compiler authors never like. An attribut=
e
<br>is always of the form `[[stuff]]` (plus optional whitespace), where I
<br>believe `stuff` never contains an unquoted `]` or `[`, whereas an
<br>ambiguous nested DD is of the form `[[...],...]`; that is, there will
<br>always occur at least a `,` between the inner and outer closing `]`s.
<br>(We could require e.g. `[[a],]` for the degenerate - and probably very,
<br>very rare - case of binding `a` to `get&lt;0&gt;(get&lt;0&gt;(rhs))`.)
<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/cd2ad240-0f47-4681-91fa-1600cd349bb7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cd2ad240-0f47-4681-91fa-1600cd349bb7=
%40isocpp.org</a>.<br />

------=_Part_690_1210401622.1484954318249--

------=_Part_689_340297753.1484954318249--

.

On 2017-01-20 18:18, Bengt Gustafsson wrote:
> ? is only an infix operator I thought it could be a better choice for
> the unnamed variable use.

I could live with it... we might then write:

  auto ?= get_raii(); // space between '?' and '=' intentionally omitted

I think it's interesting to present the proposal in its current form,
but possibly we could extend DD to allow `?` instead of the
identifier-list (in square brackets) if folks strongly prefer that syntax.

> You could throw in a "step over defaulted parameter" use as
> it has similar semantics (at least superficially).

I think I'd prefer to either seem support for specifying named arguments
when calling a function, or use `default` for that purpose.

> Does the current definition of structured binding always allow trailing
> elements in the rhs to be ignored?

No; the number of names being bound must match the tuple-size of the RHS.

> Picking the first and last elements is a
> possible use case but this is probably very seldom useful in practice.

I'd rather have D0535 for that :-).

--
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/58829FC8.6050704%40gmail.com.

.

------=_Part_744_1425883486.1484989839534
Content-Type: multipart/alternative;
 boundary="----=_Part_745_159077433.1484989839535"

------=_Part_745_159077433.1484989839535
Content-Type: text/plain; charset=UTF-8

Maybe we are talking about different things, I was refering to the
suggested use of nested empty brackets to skip binding individual elements
in a structured binding assignment so your raii example would be:

auto [?] = get_raii();

or if get_raii can return any number of things:

auto [*] = get_raii();

or maybe:

auto [...] = get_raii();


But now that you put it forth it does seem logical to allow your case too
if get_raii returns a single value thus separating the ideas of using ? as
a unnamed variable from the structured binding concept, the ? becomes just
a reusable anonymous name, which is something that awkward and often unsafe
macros have been used for so far.


At this point and given the fact that the element counts in structured
binding must match my interpretation of the [] suggestion as a degenerate
case of nested structured binding does not work, and it seems very hard to
explain this difference:

auto [] = get_raii();    // Fails as get_raii does not return 0 values.

auto [ [] ] = get_raii()   // Succeeds as the inner empty brace goes by
some other rule?

So my understanding must be that as no function can return no values the []
as such is not usable in structured binding so we can grab that syntax for
this other purpose. Then I must refer back to my initial complaint about
excessive overloading of the square bracket.

Can you produce a link to D0535?

--
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/19922402-2fcf-4abb-abde-f60660c9e166%40isocpp.org.

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

<div dir=3D"ltr">Maybe we are talking about different things, I was referin=
g to the suggested use of nested empty brackets to skip binding individual =
elements in a structured binding assignment so your raii example would be:<=
div><br></div><div>auto [?] =3D get_raii();</div><div><br></div><div>or if =
get_raii can return any number of things:</div><div><br></div><div>auto [*]=
 =3D get_raii();</div><div><br></div><div>or maybe:</div><div><br></div><di=
v>auto [...] =3D get_raii();</div><div><br></div><div><br></div><div>But no=
w that you put it forth it does seem logical to allow your case too if get_=
raii returns a single value thus separating the ideas of using ? as a unnam=
ed variable from the structured binding concept, the ? becomes just a reusa=
ble anonymous name, which is something that awkward and often unsafe macros=
 have been used for so far.</div><div><br></div><div><br></div><div>At this=
 point and given the fact that the element counts in structured binding mus=
t match my interpretation of the [] suggestion as a degenerate case of nest=
ed structured binding does not work, and it seems very hard to explain this=
 difference:</div><div><br></div><div>auto [] =3D get_raii(); =C2=A0 =C2=A0=
// Fails as get_raii does not return 0 values.</div><div><br></div><div>aut=
o [ [] ] =3D get_raii() =C2=A0 // Succeeds as the inner empty brace goes by=
 some other rule?</div><div><br></div><div>So my understanding must be that=
 as no function can return no values the [] as such is not usable in struct=
ured binding so we can grab that syntax for this other purpose. Then I must=
 refer back to my initial complaint about excessive overloading of the squa=
re bracket.</div><div><br></div><div>Can you produce a link to D0535?</div>=
<div><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/19922402-2fcf-4abb-abde-f60660c9e166%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/19922402-2fcf-4abb-abde-f60660c9e166=
%40isocpp.org</a>.<br />

------=_Part_745_159077433.1484989839535--

------=_Part_744_1425883486.1484989839534--

.

------=_Part_753_2119985968.1485007985108
Content-Type: multipart/alternative;
 boundary="----=_Part_754_92142891.1485007985108"

------=_Part_754_92142891.1485007985108
Content-Type: text/plain; charset=UTF-8

On Saturday, January 21, 2017 at 4:10:39 AM UTC-5, Bengt Gustafsson wrote:
>
> Maybe we are talking about different things, I was refering to the
> suggested use of nested empty brackets to skip binding individual elements
> in a structured binding assignment so your raii example would be:
>
> auto [?] = get_raii();
>
> or if get_raii can return any number of things:
>
> auto [*] = get_raii();
>
> or maybe:
>
> auto [...] = get_raii();
>
>
> But now that you put it forth it does seem logical to allow your case too
> if get_raii returns a single value thus separating the ideas of using ? as
> a unnamed variable from the structured binding concept, the ? becomes just
> a reusable anonymous name, which is something that awkward and often unsafe
> macros have been used for so far.
>
>
> At this point and given the fact that the element counts in structured
> binding must match my interpretation of the [] suggestion as a degenerate
> case of nested structured binding does not work, and it seems very hard to
> explain this difference:
>
> auto [] = get_raii();    // Fails as get_raii does not return 0 values.
>
> auto [ [] ] = get_raii()   // Succeeds as the inner empty brace goes by
> some other rule?
>

But the first one isn't supposed to fail. My point in bringing up this
possibility (and again, I'm not proposing it, I'm just showing it as a
possible future direction) is to show that the idea isn't as crazy as it
sounds.

By doing what I've suggested, `[]` effectively means "there's a variable
with no name". So if you do `auto [] = ...`, then you create a variable
with no name from the expression. If you do `auto [ [] ] = ...`, then you
create a variable with no name from the expression, then decompose it into
one member which has no name.

In so doing, the meaning of `[]` is somewhat normalized.

--
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/0f0ef2a5-c4f3-41a2-b978-057afed1eeb3%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, January 21, 2017 at 4:10:39 AM UTC-5, Bengt G=
ustafsson 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"lt=
r">Maybe we are talking about different things, I was refering to the sugge=
sted use of nested empty brackets to skip binding individual elements in a =
structured binding assignment so your raii example would be:<div><br></div>=
<div>auto [?] =3D get_raii();</div><div><br></div><div>or if get_raii can r=
eturn any number of things:</div><div><br></div><div>auto [*] =3D get_raii(=
);</div><div><br></div><div>or maybe:</div><div><br></div><div>auto [...] =
=3D get_raii();</div><div><br></div><div><br></div><div>But now that you pu=
t it forth it does seem logical to allow your case too if get_raii returns =
a single value thus separating the ideas of using ? as a unnamed variable f=
rom the structured binding concept, the ? becomes just a reusable anonymous=
 name, which is something that awkward and often unsafe macros have been us=
ed for so far.</div><div><br></div><div><br></div><div>At this point and gi=
ven the fact that the element counts in structured binding must match my in=
terpretation of the [] suggestion as a degenerate case of nested structured=
 binding does not work, and it seems very hard to explain this difference:<=
/div><div><br></div><div>auto [] =3D get_raii(); =C2=A0 =C2=A0// Fails as g=
et_raii does not return 0 values.</div><div><br></div><div>auto [ [] ] =3D =
get_raii() =C2=A0 // Succeeds as the inner empty brace goes by some other r=
ule?</div></div></blockquote><div><br>But the first one isn&#39;t supposed =
to fail. My point in bringing up this possibility (and again, I&#39;m not p=
roposing it, I&#39;m just showing it as a possible future direction) is to =
show that the idea isn&#39;t as crazy as it sounds.<br><br>By doing what I&=
#39;ve suggested, `[]` effectively means &quot;there&#39;s a variable with =
no name&quot;. So if you do `auto [] =3D ...`, then you create a variable w=
ith no name from the expression. If you do `auto [ [] ] =3D ...`, then you =
create a variable with no name from the expression, then decompose it into =
one member which has no name.<br><br>In so doing, the meaning of `[]` is so=
mewhat normalized.</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/0f0ef2a5-c4f3-41a2-b978-057afed1eeb3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0f0ef2a5-c4f3-41a2-b978-057afed1eeb3=
%40isocpp.org</a>.<br />

------=_Part_754_92142891.1485007985108--

------=_Part_753_2119985968.1485007985108--

.

------=_Part_1013_1912384480.1485123185783
Content-Type: multipart/alternative;
 boundary="----=_Part_1014_57787818.1485123185783"

------=_Part_1014_57787818.1485123185783
Content-Type: text/plain; charset=UTF-8

Going back to your original proposal it seems that you want to use a rule
of implicitly throwing away excessive RHS elements, in this case the one
and only.

But according to Matthew Woehlke a few posts up the number of elements on
the LHS and RHS of a structured binding assignment must match.

So it seems that if this rule was changed your proposal would be a natural
consequence, but with the rule as stated I don't find in particularly
logical, and would prefer the ? syntax as I suggested, with the more
general interpretation of introducing a unnamed variable, (which has little
to do with structural binding). You can then write:

unique_lock ?(mMutex);

which I guess would be a common pattern, and just as if ? was a real
identifier identical with:

auto ? = unique_lock(mMutex);


You could also write:

void func(int ?) override { do_something; }

To emphatize that you are not using this parameter in this override.




--
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/1a54e6f3-cc5a-42cf-b169-e5320cedf0c9%40isocpp.org.

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

<div dir=3D"ltr">Going back to your original proposal it seems that you wan=
t to use a rule of implicitly throwing away excessive RHS elements, in this=
 case the one and only.<div><br></div><div>But according to Matthew Woehlke=
 a few posts up the number of elements on the LHS and RHS of a structured b=
inding assignment must match.</div><div><br></div><div>So it seems that if =
this rule was changed your proposal would be a natural consequence, but wit=
h the rule as stated I don&#39;t find in particularly logical, and would pr=
efer the ? syntax as I suggested, with the more general interpretation of i=
ntroducing a unnamed variable, (which has little to do with structural bind=
ing). You can then write:</div><div><br></div><div>unique_lock ?(mMutex);</=
div><div><br></div><div>which I guess would be a common pattern, and just a=
s if ? was a real identifier identical with:</div><div><br></div><div>auto =
? =3D unique_lock(mMutex);</div><div><br></div><div><br></div><div>You coul=
d also write:</div><div><br></div><div>void func(int ?) override { do_somet=
hing; }</div><div><br></div><div>To emphatize that you are not using this p=
arameter in this override.=C2=A0</div><div><br></div><div><br></div><div><b=
r></div><div><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/1a54e6f3-cc5a-42cf-b169-e5320cedf0c9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1a54e6f3-cc5a-42cf-b169-e5320cedf0c9=
%40isocpp.org</a>.<br />

------=_Part_1014_57787818.1485123185783--

------=_Part_1013_1912384480.1485123185783--

.

------=_Part_929_797934593.1485131652068
Content-Type: multipart/alternative;
 boundary="----=_Part_930_1708645520.1485131652068"

------=_Part_930_1708645520.1485131652068
Content-Type: text/plain; charset=UTF-8

On Sunday, January 22, 2017 at 5:13:05 PM UTC-5, Bengt Gustafsson wrote:
>
> Going back to your original proposal it seems that you want to use a rule
> of implicitly throwing away excessive RHS elements, in this case the one
> and only.
>
> But according to Matthew Woehlke a few posts up the number of elements on
> the LHS and RHS of a structured binding assignment must match.
>

Yes that's normally true, and I mentioned that in the proposal. It's item
#2 in the changes to the standard that would be needed for this to work.

So it seems that if this rule was changed your proposal would be a natural
> consequence, but with the rule as stated I don't find in particularly
> logical,
>

I find it perfectly logical from a decomposition standpoint. `auto []`
doesn't perform decomposition. So it doesn't matter if the expression
*could* be decomposed, since you didn't ask for it to be decomposed.

--
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/0cf7f64c-cc8a-42d3-ac30-407b7703df80%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, January 22, 2017 at 5:13:05 PM UTC-5, Bengt Gus=
tafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Going back =
to your original proposal it seems that you want to use a rule of implicitl=
y throwing away excessive RHS elements, in this case the one and only.<br><=
br></div></blockquote><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></div><div>But according to Matthew Woehlke a few posts up th=
e number of elements on the LHS and RHS of a structured binding assignment =
must match.</div></div></blockquote><div><br>Yes that&#39;s normally true, =
and I mentioned that in the proposal. It&#39;s item #2 in the changes to th=
e standard that would be needed for this to work.<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>So it seems that if =
this rule was changed your proposal would be a natural consequence, but wit=
h the rule as stated I don&#39;t find in particularly logical,</div></div><=
/blockquote><div><br>I find it perfectly logical from a decomposition stand=
point. `auto []` doesn&#39;t perform decomposition. So it doesn&#39;t matte=
r if the expression <i>could</i> be decomposed, since you didn&#39;t ask fo=
r it to be decomposed.<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/0cf7f64c-cc8a-42d3-ac30-407b7703df80%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0cf7f64c-cc8a-42d3-ac30-407b7703df80=
%40isocpp.org</a>.<br />

------=_Part_930_1708645520.1485131652068--

------=_Part_929_797934593.1485131652068--

.

On Sun, Jan 22, 2017 at 02:13:05PM -0800, Bengt Gustafsson wrote:
> Going back to your original proposal it seems that you want to use a rule
> of implicitly throwing away excessive RHS elements, in this case the one
> and only.
>
> But according to Matthew Woehlke a few posts up the number of elements on
> the LHS and RHS of a structured binding assignment must match.
>
> So it seems that if this rule was changed your proposal would be a natural
> consequence, but with the rule as stated I don't find in particularly
> logical, and would prefer the ? syntax as I suggested, with the more
> general interpretation of introducing a unnamed variable, (which has little
> to do with structural binding). You can then write:
>
> unique_lock ?(mMutex);
>
> which I guess would be a common pattern, and just as if ? was a real
> identifier identical with:
>
> auto ? = unique_lock(mMutex);
>
>
> You could also write:
>
> void func(int ?) override { do_something; }
>
> To emphatize that you are not using this parameter in this override.

This does actually suggest another spelling of the anonymous variable, namely
nothing at all,

auto = unique_lock...
void func(int) { ... }

Now, I will admit to not having thought much about this at all but using
nothing would be in line with how you declare unnamed function arguments.

One con of this idea is obviously that the distance from

auto someting = ...

to

auto = ...

is smaller than the distance to

auto ? = ...

or

auto [] = ...

/MF

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

.

On 2017-01-21 04:10, Bengt Gustafsson wrote:
> Maybe we are talking about different things, I was refering to the
> suggested use of nested empty brackets to skip binding individual elements
> in a structured binding assignment so your raii example would be:
>
> auto [?] = get_raii();
>
> or if get_raii can return any number of things:
>
> auto [*] = get_raii();
>
> or maybe:
>
> auto [...] = get_raii();
>
> But now that you put it forth it does seem logical to allow your case too
> if get_raii returns a single value thus separating the ideas of using ? as
> a unnamed variable from the structured binding concept, the ? becomes just
> a reusable anonymous name, which is something that awkward and often unsafe
> macros have been used for so far.

Another way of looking at this that might work: if the identifier-list
of a decomposition declaration is `?`, then *at that level*, no attempt
to decompose the value is made (i.e. the original proposal). Note that
this explicitly permits that the value is not a product type, e.g.:

  int foo();
  auto [?] = foo(); // okay

This would naturally extend to nested decompositions, regardless of how
those end up being formatted.

> At this point and given the fact that the element counts in structured
> binding must match my interpretation of the [] suggestion as a degenerate
> case of nested structured binding does not work, and it seems very hard to
> explain this difference:
>
> auto [] = get_raii();    // Fails as get_raii does not return 0 values.
>
> auto [ [] ] = get_raii()   // Succeeds as the inner empty brace goes by
> some other rule?

If an empty identifier-list is used for anonymous binding, the first
matches anything at all (no checks performed), while the second
(assuming that is a nested decomposition syntax) would match a product
type of size 1.

I have to admit, this is making me inclined to like `[?]` as the syntax.
This still requires minimal change (a small grammar addition to
identifier-list for DD's, plus the original proposed change), and has
much the same benefits for nested decomposition, but dodges the question
of syntax for nested decomposition. For example:

  auto [<a, b>, <c, d>, e] = pt(); // let's say NDD looks like this
  auto [<?>, <c, d>, <?>] = pt(); // like above, but only bind c, d
  auto [<a, <?>>, <c, d>, <?>] = pt(); // ...or bind a, c, d

....so in effect there is a superfluous set of DD brackets around an
unnamed binding site, but it allows us to achieve the feature with less
grammar change.

Of course, this also suggests that an empty identifier-list could mean
the same thing:

  auto [<>, <c, d>, <>] = pt(); // same as above
  auto [<a, <>>, <c, d>, <>] = pt(); // same as above

....so we're not talking about literal `[]` as the placeholder, we're
talking about a DD (nested or otherwise) with an empty identifier-list.
Looked at that way, my original concern of this not scaling to nested
decompositions is moot.

> So my understanding must be that as no function can return no values

`void`? `struct {}`?

I can also trivially make tuple_size<T>() be 0 for some user type.

That said...

> the [] as such is not usable in structured binding so we can grab
> that syntax for
> this other purpose. Then I must refer back to my initial complaint
> about excessive overloading of the square bracket.

....I don't see overriding `[]` for this purpose to be a problem; you can
still use it to bind to a 0-tuple, since it binds to anything at all,
and the only expressiveness you lose is the assertion that what you are
binding to really is a 0-tuple. But those are likely rare anyway.

> Can you produce a link to D0535?

https://github.com/mwoehlke/cpp-proposals/blob/master/p0535r0-generalized-unpacking.rst
(it will be in the next mailing).

--
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/5886344F.6000303%40gmail.com.

.