On 10 July 2016 at 21:51, Francisco Lopes
<francisco.mailing.lists@oblita.com> wrote:
> Initially I was thinking about using ... instead of _ to avoid such naming
> issue. If adopting ...

Don't go there, that idea clashes badly with packs.

Also, this is 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/CAFk2RUbtFt23WscTwKq%2B7g0jVdT4x0-A2bjriAgDQNfyQLzPyQ%40mail.gmail.com.

.

------=_Part_90_1466301897.1468178079147
Content-Type: multipart/alternative;
 boundary="----=_Part_91_1952410321.1468178079147"

------=_Part_91_1952410321.1468178079147
Content-Type: text/plain; charset=UTF-8

Many thanks for that reference Ville. I see there was invitation for a
paper, but
no more information about it going forward, is there anything going forward
already?

I think as demonstrated, with the current and future additions to the
standard,
more usecases are showing up in favor of such feature.

Em domingo, 10 de julho de 2016 15:55:22 UTC-3, Ville Voutilainen escreveu:
>
> On 10 July 2016 at 21:51, Francisco Lopes
> <francisco.m...@oblita.com <javascript:>> wrote:
> > Initially I was thinking about using ... instead of _ to avoid such
> naming
> > issue. If adopting ...
>
> Don't go there, that idea clashes badly with packs.
>
> Also, this is 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/59564597-3a43-4af3-be77-aeed72c7a5d8%40isocpp.org.

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

<div dir=3D"ltr">Many thanks for that reference Ville. I see there was invi=
tation for a paper, but<br>no more information about it going forward, is t=
here anything going forward already?<br><br>I think as demonstrated, with t=
he current and future additions to the standard,<br>more usecases are showi=
ng up in favor of such feature.<br><br>Em domingo, 10 de julho de 2016 15:5=
5:22 UTC-3, Ville Voutilainen  escreveu:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">On 10 July 2016 at 21:51, Francisco Lopes
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
K1LyFBEdCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">francisco.m...@<wbr>oblita.com</a>&gt; wrote:
<br>&gt; Initially I was thinking about using ... instead of _ to avoid suc=
h naming
<br>&gt; issue. If adopting ...
<br>
<br>Don&#39;t go there, that idea clashes badly with packs.
<br>
<br>Also, this is <a href=3D"https://cplusplus.github.io/EWG/ewg-active.htm=
l#35" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ht=
tps://www.google.com/url?q\x3dhttps%3A%2F%2Fcplusplus.github.io%2FEWG%2Fewg=
-active.html%2335\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEVcyzwXESmmKmnu7P=
EiQjK0qkfPQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goog=
le.com/url?q\x3dhttps%3A%2F%2Fcplusplus.github.io%2FEWG%2Fewg-active.html%2=
335\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEVcyzwXESmmKmnu7PEiQjK0qkfPQ&#3=
9;;return true;">https://cplusplus.github.io/<wbr>EWG/ewg-active.html#35</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/59564597-3a43-4af3-be77-aeed72c7a5d8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/59564597-3a43-4af3-be77-aeed72c7a5d8=
%40isocpp.org</a>.<br />

------=_Part_91_1952410321.1468178079147--

------=_Part_90_1466301897.1468178079147--

.

On 10 July 2016 at 22:14, Francisco Lopes
<francisco.mailing.lists@oblita.com> wrote:
> Many thanks for that reference Ville. I see there was invitation for a
> paper, but
> no more information about it going forward, is there anything going forward
> already?
>
> I think as demonstrated, with the current and future additions to the
> standard,
> more usecases are showing up in favor of such feature.


There hasn't been recent work on it, none after that invitation to
write a paper, as far as I'm aware of.

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

.

On Sun, Jul 10, 2016 at 6:44 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Wait a minute. Let's think about what we just added to C++: structured
> binding:
>
> auto [a, b] = ...;

Currently this syntax is outlawed, but I expect that
in the future we extend the identifier-list inside
structured binding to support pack expansion:

  auto [a...] = expr;

where an empty pack naturally decompose an
empty product type.  Sooner or later you will
find that smoothly and consistently handle the
zero cases will reward you back.

--
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/CAGsORuAVffVz7PhzcAZGDz1n5JgE-y5-K2nBjTQW-59vfjzrrg%40mail.gmail.com.

.

------=_Part_296_469151704.1468199516906
Content-Type: multipart/alternative;
 boundary="----=_Part_297_60582500.1468199516906"

------=_Part_297_60582500.1468199516906
Content-Type: text/plain; charset=UTF-8



On Sunday, July 10, 2016 at 8:49:07 PM UTC-4, Zhihao Yuan wrote:
>
> On Sun, Jul 10, 2016 at 6:44 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> > Wait a minute. Let's think about what we just added to C++: structured
> > binding:
> >
> > auto [a, b] = ...;
>
> Currently this syntax is outlawed,


I didn't mean `...` as in parameter pack. I meant `...` as in `something`.

--
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/dcff2c4e-d614-4115-b5be-3dc6f5eaf297%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Sunday, July 10, 2016 at 8:49:07 PM UTC-4, Zhih=
ao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Jul 10, =
2016 at 6:44 PM, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"rFlx5l4wCgAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; Wait a minute. Let&#39;s think about what we just added to C++: st=
ructured
<br>&gt; binding:
<br>&gt;
<br>&gt; auto [a, b] =3D ...;
<br>
<br>Currently this syntax is outlawed,</blockquote><div><br>I didn&#39;t me=
an `...` as in parameter pack. I meant `...` as in `something`.</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/dcff2c4e-d614-4115-b5be-3dc6f5eaf297%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dcff2c4e-d614-4115-b5be-3dc6f5eaf297=
%40isocpp.org</a>.<br />

------=_Part_297_60582500.1468199516906--

------=_Part_296_469151704.1468199516906--

.

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

I've been following this with great interest but I disagree with using _,
__, @, etc.

If the goal of a future proposal is having unnamed variables IMHO they
should not use any character or sequence of characters to be... well ...
named.

The examples where a member function needs to be called on a unnamed
variable is just something that could be done by another function which the
return is assigned to a unnamed variable.
Or other cases, another RAII class could wrap this and calling
whatever member functions on its constructor/destructor.

Nicol's suggestion:
auto[] = foo();
It seems to me a better direction.

For the cases where named and unnamed variables are needed, may we just
skip declaring a name?
auto [a,,c] = foo();
Or would that be too error prone?

A few other thoughts:
- Should unnamed variables should also be allowed whenever a structured
binding is possible?
  I'm thinking unnamed statics/globals here.

- It was also mentioned that structured binding creates references... but
which kind of references are they?
  const& and && are known to extend the lifetime of the assigned object
until the end of the scope.

- Regarding structured binding type deduction and conversions: there was
some discussion around allowing specifying the types of individual
variables.
  How that would apply to unnamed variables?
  Wrap conversions in other functions or classes (as suggested above for
when member function calls are needed)?
  Or just don't for now...
  If structured binding ever gets this ability in the future, then types
for unnamed variables could be specified: auto[int a, int, int b] = foo();

- Is there a use case for unnamed class data members?
  Maybe for some crazy future use of parameter pack expansion?
  Then auto[] would not work.

- I'm trying to find similarities with other situations where an entity can
be unnamed as a case for consistency ...
  anonymous unions/structs or namespaces, type of a lambda...
  Well, maybe those are different beasts.


On Sun, Jul 10, 2016 at 9:23 PM, Francisco Lopes <
francisco.mailing.lists@oblita.com> wrote:

>
>
> Em domingo, 10 de julho de 2016 23:12:32 UTC-3, Francisco Lopes escreveu:
>>
>>
>>
>> Em domingo, 10 de julho de 2016 23:08:39 UTC-3, Francisco Lopes escreveu:
>>>
>>> Besides _ or __ I'm thinking of other possibilities...
>>>
>>>  @: I know of its presence solely in mangled names but I suspect it
>>> won't be an issue.
>>>
>>> I dunno, maybe the range of special characters may be of some use here
>>> too.
>>>
>>
>> If adopting such alternative characters, it would be placeholder only,
>> without referentiability.
>>
>
> My preferred choices are _, @ or ?
>
>
>>> Em domingo, 10 de julho de 2016 22:53:11 UTC-3, Francisco Lopes escreveu:
>>>>
>>>>
>>>> Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:
>>>>>
>>>>> On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>>>>>>
>>>>>> That's interesting Nicol, but what about the other cases? For
>>>>>> structured binding itself
>>>>>> for example, how would I let bindings unnamed?
>>>>>>
>>>>>
>>>>> Remember the goal: you want an *object* to be unnamed, because you
>>>>> want to use its construction and destruction only. The variables created by
>>>>> structured binding are not objects; they're *references*. Their
>>>>> destructors are irrelevant, so making them unnamed is equally irrelevant to
>>>>> this particular goal.
>>>>>
>>>>
>>>> That may look like the *original* goal in the previous thread, but to
>>>> tell the truth it's not my goal. The rationale
>>>> here is for unnamed variables. It's just about to cover the intention
>>>> of not providing names for things
>>>> that doesn't need them, as frequently happen (and will happen) in the
>>>> cases presented.
>>>>
>>>>
>>>>> Don't try to solve every problem at once.
>>>>>
>>>>
>>>> Why not? It's a simple solution that covers the relevant problem:
>>>> having a placeholder. It ends up
>>>> solving all in an understandable manner, in a uniform way. I ask why
>>>> solve it in a case by case form?
>>>> or solving one special case while leaving the others for the future or
>>>> plain unsolved, when in truth,
>>>> they all refer to the same core subject.
>>>>
>>>>
>>>> --
> 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/69941075-9183-403b-86ac-3e37b7ddfae1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69941075-9183-403b-86ac-3e37b7ddfae1%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/CA%2BfGSbP1x-_cA6NW5RPXNnzddzL3NKh0m2%3D3yEKt30NqPc9eng%40mail.gmail.com.

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

<div dir=3D"ltr"><div>I&#39;ve been following this with great interest but =
I disagree with using _, __, @, etc.</div><div><br></div>If the goal of a f=
uture proposal is having unnamed variables IMHO they should not use any cha=
racter or sequence of characters to be... well ... named.<div><br></div><di=
v>The examples where a=C2=A0member function=C2=A0needs to be called on a un=
named variable is just something that could be done by another function whi=
ch the return is assigned to a unnamed variable.</div><div>Or other cases,=
=C2=A0another=C2=A0RAII class could wrap this and calling whatever=C2=A0mem=
ber functions=C2=A0on its constructor/destructor.</div><div><div><br><div>N=
icol&#39;s suggestion:</div><div>auto[] =3D foo();</div><div>It seems to me=
 a better direction.<br></div><div><br></div><div>For the cases where named=
 and unnamed variables are needed, may we just skip declaring a name?</div>=
<div>auto [a,,c] =3D foo();</div><div>Or would that be too error prone?<br>=
</div><div><br></div><div>A few other thoughts:</div><div>- Should unnamed =
variables should also be allowed whenever a structured binding is possible?=
<br>=C2=A0 I&#39;m thinking unnamed statics/globals here.</div><div><br></d=
iv><div>- It was also mentioned that structured binding creates references.=
... but which kind of references are they?</div><div>=C2=A0 const&amp; and &=
amp;&amp; are known to extend the lifetime of the assigned object until the=
 end of the scope.<br></div><div><br></div><div>- Regarding structured bind=
ing type deduction and conversions: there was some discussion around allowi=
ng specifying the types of individual variables.<br>=C2=A0 How that would a=
pply to unnamed variables?<br>=C2=A0 Wrap conversions in other functions or=
 classes (as suggested above for when member function calls are needed)?<br=
>=C2=A0 Or just don&#39;t for now...<br>=C2=A0 If structured binding ever g=
ets this ability in the future, then types for unnamed variables could be s=
pecified: auto[int a, int, int b] =3D foo();</div><div><div><br></div><div>=
- Is there a use case for unnamed class data members?<br>=C2=A0 Maybe for s=
ome crazy future use of parameter pack expansion?<br>=C2=A0 Then auto[] wou=
ld not work.</div><div><br></div><div>- I&#39;m trying to find similarities=
 with other situations where an entity can be unnamed as a case for consist=
ency ...</div><div>=C2=A0 anonymous unions/structs or namespaces, type of a=
 lambda...</div><div>=C2=A0 Well, maybe those are different beasts.</div></=
div></div><div><div><br></div></div></div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Sun, Jul 10, 2016 at 9:23 PM, Francisco L=
opes <span dir=3D"ltr">&lt;<a href=3D"mailto:francisco.mailing.lists@oblita=
..com" target=3D"_blank">francisco.mailing.lists@oblita.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>Em domingo=
, 10 de julho de 2016 23:12:32 UTC-3, Francisco Lopes  escreveu:<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"><br><br>Em domingo, 10 de jul=
ho de 2016 23:08:39 UTC-3, Francisco Lopes  escreveu:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">Besides _ or __ I&#39;m thinking of othe=
r possibilities...<br><br>=C2=A0@: I know of its presence solely in mangled=
 names but I suspect it won&#39;t be an issue.<br><br>I dunno, maybe the ra=
nge of special characters may be of some use here too.<br></div></blockquot=
e><div><br>If adopting such alternative characters, it would be placeholder=
 only, without referentiability.<br></div></div></blockquote><div><br>My pr=
eferred choices are _, @ or ? <br><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><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"><br>Em domingo, 10 de julho de 2016 22:53:11 UTC-3, Francisco Lope=
s  escreveu:<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"><br>Em=
 domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas  escreveu:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, July 10, 2016 =
at 7:59:33 PM UTC-4, Francisco Lopes wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">That&#39;s interesting Nicol, but what about the o=
ther cases? For structured binding itself<br>for example, how would I let b=
indings unnamed?</div></blockquote><div><br>Remember the goal: you want an =
<i>object</i> to be unnamed, because you want to use its construction and d=
estruction only. The variables created by structured binding are not object=
s; they&#39;re <i>references</i>. Their destructors are irrelevant, so maki=
ng them unnamed is equally irrelevant to this particular goal.<br></div></d=
iv></blockquote><div>=C2=A0<br>That may look like the <i>original</i> goal =
in the previous thread, but to tell the truth it&#39;s not my goal. The rat=
ionale<br>here is for unnamed variables. It&#39;s just about to cover the i=
ntention of not providing names for things<br>that doesn&#39;t need them, a=
s frequently happen (and will happen) in the cases presented.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>Don&#39;t=
 try to solve every problem at once.</div></div></blockquote><div>=C2=A0<br=
>Why not? It&#39;s a simple solution that covers the relevant problem: havi=
ng a placeholder. It ends up<br>solving all in an understandable manner, in=
 a uniform way. I ask why solve it in a case by case form?<br>or solving on=
e special case while leaving the others for the future or plain unsolved, w=
hen in truth,<br>they all refer to the same core subject.<br><br><br></div>=
</div></blockquote></div></blockquote></div></blockquote></div><span class=
=3D"HOEnZb"><font color=3D"#888888">

<p></p>

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

<p></p>

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

--001a11375df875742c0537537225--

.

------=_Part_125_2101008213.1468208311723
Content-Type: multipart/alternative;
 boundary="----=_Part_126_502731697.1468208311723"

------=_Part_126_502731697.1468208311723
Content-Type: text/plain; charset=UTF-8

On Sunday, July 10, 2016 at 11:07:07 PM UTC-4, Ricardo Andrade wrote:
>
> I've been following this with great interest but I disagree with using _,
> __, @, etc.
>
> If the goal of a future proposal is having unnamed variables IMHO they
> should not use any character or sequence of characters to be... well ...
> named.
>

@ is not even in the C++ basic character set. So it cannot be a valid
identifier.

That being said, I dislike using @ for 2 reasons:

1: It requires adding `@` to the basic character set.
2: After having gone through the effort to add a character to the basic
character set, we would then use up all of the possible syntactic potential
of the character, just to get unnamed identifiers. Better to preserve the
possibilities for `@` for something more worthwhile.

--
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/ab22ec88-1ae5-40b1-90ab-7324d7f9cb23%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, July 10, 2016 at 11:07:07 PM UTC-4, Ricardo And=
rade 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"><d=
iv>I&#39;ve been following this with great interest but I disagree with usi=
ng _, __, @, etc.</div><div><br></div>If the goal of a future proposal is h=
aving unnamed variables IMHO they should not use any character or sequence =
of characters to be... well ... named.</div></blockquote><div><br>@ is not =
even in the C++ basic character set. So it cannot be a valid identifier.<br=
><br>That being said, I dislike using @ for 2 reasons:<br><br>1: It require=
s adding `@` to the basic character set.<br>2: After having gone through th=
e effort to add a character to the basic character set, we would then use u=
p all of the possible syntactic potential of the character, just to get unn=
amed identifiers. Better to preserve the possibilities for `@` for somethin=
g more worthwhile.<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/ab22ec88-1ae5-40b1-90ab-7324d7f9cb23%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ab22ec88-1ae5-40b1-90ab-7324d7f9cb23=
%40isocpp.org</a>.<br />

------=_Part_126_502731697.1468208311723--

------=_Part_125_2101008213.1468208311723--

.

------=_Part_559_417607775.1468208733177
Content-Type: multipart/alternative;
 boundary="----=_Part_560_341721466.1468208733178"

------=_Part_560_341721466.1468208733178
Content-Type: text/plain; charset=UTF-8

Hi Ricardo, maybe the topic name is improper. First, I'm advocating that if
any special character
is to be used besides _ and __, which are already usable as indentifiers,
then it would
not be possible to explicitly call member functions on them, they would
simpler serve the purpose
of a placeholder name at declaration.

I like this idea of a placeholder variable name better than the current
propositions. It's not the
same as truly anonymous for which you don't even give it a name at all, but
it's better IMO.
I see no reason for tackling it solely by extending syntax of structure
binding and missing the
oportunity for all the possible remaining usecases where the presence of a
placeholder name would
solve it. A placeholder doesn't even need to tweak structure binding
specification at all, it would be
solved as a consequence of a more general solution about variable naming.

Em segunda-feira, 11 de julho de 2016 00:07:07 UTC-3, Ricardo Andrade
escreveu:
>
> I've been following this with great interest but I disagree with using _,
> __, @, etc.
>
> If the goal of a future proposal is having unnamed variables IMHO they
> should not use any character or sequence of characters to be... well ...
> named.
>
> The examples where a member function needs to be called on a unnamed
> variable is just something that could be done by another function which the
> return is assigned to a unnamed variable.
> Or other cases, another RAII class could wrap this and calling
> whatever member functions on its constructor/destructor.
>
> Nicol's suggestion:
> auto[] = foo();
> It seems to me a better direction.
>
> For the cases where named and unnamed variables are needed, may we just
> skip declaring a name?
> auto [a,,c] = foo();
> Or would that be too error prone?
>
> A few other thoughts:
> - Should unnamed variables should also be allowed whenever a structured
> binding is possible?
>   I'm thinking unnamed statics/globals here.
>
> - It was also mentioned that structured binding creates references... but
> which kind of references are they?
>   const& and && are known to extend the lifetime of the assigned object
> until the end of the scope.
>
> - Regarding structured binding type deduction and conversions: there was
> some discussion around allowing specifying the types of individual
> variables.
>   How that would apply to unnamed variables?
>   Wrap conversions in other functions or classes (as suggested above for
> when member function calls are needed)?
>   Or just don't for now...
>   If structured binding ever gets this ability in the future, then types
> for unnamed variables could be specified: auto[int a, int, int b] = foo();
>
> - Is there a use case for unnamed class data members?
>   Maybe for some crazy future use of parameter pack expansion?
>   Then auto[] would not work.
>
> - I'm trying to find similarities with other situations where an entity
> can be unnamed as a case for consistency ...
>   anonymous unions/structs or namespaces, type of a lambda...
>   Well, maybe those are different beasts.
>
>
> On Sun, Jul 10, 2016 at 9:23 PM, Francisco Lopes <
> francisco.m...@oblita.com <javascript:>> wrote:
>
>>
>>
>> Em domingo, 10 de julho de 2016 23:12:32 UTC-3, Francisco Lopes escreveu:
>>>
>>>
>>>
>>> Em domingo, 10 de julho de 2016 23:08:39 UTC-3, Francisco Lopes escreveu:
>>>>
>>>> Besides _ or __ I'm thinking of other possibilities...
>>>>
>>>>  @: I know of its presence solely in mangled names but I suspect it
>>>> won't be an issue.
>>>>
>>>> I dunno, maybe the range of special characters may be of some use here
>>>> too.
>>>>
>>>
>>> If adopting such alternative characters, it would be placeholder only,
>>> without referentiability.
>>>
>>
>> My preferred choices are _, @ or ?
>>
>>
>>>> Em domingo, 10 de julho de 2016 22:53:11 UTC-3, Francisco Lopes
>>>> escreveu:
>>>>>
>>>>>
>>>>> Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:
>>>>>>
>>>>>> On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>>>>>>>
>>>>>>> That's interesting Nicol, but what about the other cases? For
>>>>>>> structured binding itself
>>>>>>> for example, how would I let bindings unnamed?
>>>>>>>
>>>>>>
>>>>>> Remember the goal: you want an *object* to be unnamed, because you
>>>>>> want to use its construction and destruction only. The variables created by
>>>>>> structured binding are not objects; they're *references*. Their
>>>>>> destructors are irrelevant, so making them unnamed is equally irrelevant to
>>>>>> this particular goal.
>>>>>>
>>>>>
>>>>> That may look like the *original* goal in the previous thread, but to
>>>>> tell the truth it's not my goal. The rationale
>>>>> here is for unnamed variables. It's just about to cover the intention
>>>>> of not providing names for things
>>>>> that doesn't need them, as frequently happen (and will happen) in the
>>>>> cases presented.
>>>>>
>>>>>
>>>>>> Don't try to solve every problem at once.
>>>>>>
>>>>>
>>>>> Why not? It's a simple solution that covers the relevant problem:
>>>>> having a placeholder. It ends up
>>>>> solving all in an understandable manner, in a uniform way. I ask why
>>>>> solve it in a case by case form?
>>>>> or solving one special case while leaving the others for the future or
>>>>> plain unsolved, when in truth,
>>>>> they all refer to the same core subject.
>>>>>
>>>>>
>>>>> --
>> 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/69941075-9183-403b-86ac-3e37b7ddfae1%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69941075-9183-403b-86ac-3e37b7ddfae1%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/dd3ec780-537c-4167-8947-4c23238554cf%40isocpp.org.

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

<div dir=3D"ltr">Hi Ricardo, maybe the topic name is improper. First, I&#39=
;m advocating that if any special character<br>is to be used besides _ and =
__, which are already usable as indentifiers, then it would<br>not be possi=
ble to explicitly call member functions on them, they would simpler serve t=
he purpose<br>of a placeholder name at declaration.<br><br>I like this idea=
 of a placeholder variable name better than the current propositions. It&#3=
9;s not the<br>same as truly anonymous for which you don&#39;t even give it=
 a name at all, but it&#39;s better IMO.<br>I see no reason for tackling it=
 solely by extending syntax of structure binding and missing the<br>oportun=
ity for all the possible remaining usecases where the presence of a placeho=
lder name would<br>solve it. A placeholder doesn&#39;t even need to tweak s=
tructure binding specification at all, it would be<br>solved as a consequen=
ce of a more general solution about variable naming.<br><br>Em segunda-feir=
a, 11 de julho de 2016 00:07:07 UTC-3, Ricardo Andrade  escreveu:<blockquot=
e 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>I&#39;ve been foll=
owing this with great interest but I disagree with using _, __, @, etc.</di=
v><div><br></div>If the goal of a future proposal is having unnamed variabl=
es IMHO they should not use any character or sequence of characters to be..=
.. well ... named.<div><br></div><div>The examples where a=C2=A0member funct=
ion=C2=A0needs to be called on a unnamed variable is just something that co=
uld be done by another function which the return is assigned to a unnamed v=
ariable.</div><div>Or other cases,=C2=A0another=C2=A0RAII class could wrap =
this and calling whatever=C2=A0member functions=C2=A0on its constructor/des=
tructor.</div><div><div><br><div>Nicol&#39;s suggestion:</div><div>auto[] =
=3D foo();</div><div>It seems to me a better direction.<br></div><div><br><=
/div><div>For the cases where named and unnamed variables are needed, may w=
e just skip declaring a name?</div><div>auto [a,,c] =3D foo();</div><div>Or=
 would that be too error prone?<br></div><div><br></div><div>A few other th=
oughts:</div><div>- Should unnamed variables should also be allowed wheneve=
r a structured binding is possible?<br>=C2=A0 I&#39;m thinking unnamed stat=
ics/globals here.</div><div><br></div><div>- It was also mentioned that str=
uctured binding creates references... but which kind of references are they=
?</div><div>=C2=A0 const&amp; and &amp;&amp; are known to extend the lifeti=
me of the assigned object until the end of the scope.<br></div><div><br></d=
iv><div>- Regarding structured binding type deduction and conversions: ther=
e was some discussion around allowing specifying the types of individual va=
riables.<br>=C2=A0 How that would apply to unnamed variables?<br>=C2=A0 Wra=
p conversions in other functions or classes (as suggested above for when me=
mber function calls are needed)?<br>=C2=A0 Or just don&#39;t for now...<br>=
=C2=A0 If structured binding ever gets this ability in the future, then typ=
es for unnamed variables could be specified: auto[int a, int, int b] =3D fo=
o();</div><div><div><br></div><div>- Is there a use case for unnamed class =
data members?<br>=C2=A0 Maybe for some crazy future use of parameter pack e=
xpansion?<br>=C2=A0 Then auto[] would not work.</div><div><br></div><div>- =
I&#39;m trying to find similarities with other situations where an entity c=
an be unnamed as a case for consistency ...</div><div>=C2=A0 anonymous unio=
ns/structs or namespaces, type of a lambda...</div><div>=C2=A0 Well, maybe =
those are different beasts.</div></div></div><div><div><br></div></div></di=
v></div><div><br><div class=3D"gmail_quote">On Sun, Jul 10, 2016 at 9:23 PM=
, Francisco Lopes <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"x2zru-Y3CgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">francisco.m...@<wbr>oblita.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 dir=3D"ltr"><br><br>Em=
 domingo, 10 de julho de 2016 23:12:32 UTC-3, Francisco Lopes  escreveu:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>Em domingo, 1=
0 de julho de 2016 23:08:39 UTC-3, Francisco Lopes  escreveu:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">Besides _ or __ I&#39;m thinking=
 of other possibilities...<br><br>=C2=A0@: I know of its presence solely in=
 mangled names but I suspect it won&#39;t be an issue.<br><br>I dunno, mayb=
e the range of special characters may be of some use here too.<br></div></b=
lockquote><div><br>If adopting such alternative characters, it would be pla=
ceholder only, without referentiability.<br></div></div></blockquote><div><=
br>My preferred choices are _, @ or ? <br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><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"><br>Em domingo, 10 de julho de 2016 22:53:11 UTC-3, Franc=
isco Lopes  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><br>Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas  escreve=
u:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, July =
10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">That&#39;s interesting Nicol, but what ab=
out the other cases? For structured binding itself<br>for example, how woul=
d I let bindings unnamed?</div></blockquote><div><br>Remember the goal: you=
 want an <i>object</i> to be unnamed, because you want to use its construct=
ion and destruction only. The variables created by structured binding are n=
ot objects; they&#39;re <i>references</i>. Their destructors are irrelevant=
, so making them unnamed is equally irrelevant to this particular goal.<br>=
</div></div></blockquote><div>=C2=A0<br>That may look like the <i>original<=
/i> goal in the previous thread, but to tell the truth it&#39;s not my goal=
.. The rationale<br>here is for unnamed variables. It&#39;s just about to co=
ver the intention of not providing names for things<br>that doesn&#39;t nee=
d them, as frequently happen (and will happen) in the cases presented.<br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>=
Don&#39;t try to solve every problem at once.</div></div></blockquote><div>=
=C2=A0<br>Why not? It&#39;s a simple solution that covers the relevant prob=
lem: having a placeholder. It ends up<br>solving all in an understandable m=
anner, in a uniform way. I ask why solve it in a case by case form?<br>or s=
olving one special case while leaving the others for the future or plain un=
solved, when in truth,<br>they all refer to the same core subject.<br><br><=
br></div></div></blockquote></div></blockquote></div></blockquote></div><sp=
an><font color=3D"#888888">

<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
x2zru-Y3CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"x2zru-Y3CgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@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/69941075-9183-403b-86ac-3e37b7ddfae1%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/69941075-9183-403b-86ac-3e37b7ddfae1%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/69941075-9183-403b-86ac-3e37b7ddfae1%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/69941075-9183-403b-<wbr>86ac-=
3e37b7ddfae1%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
</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/dd3ec780-537c-4167-8947-4c23238554cf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dd3ec780-537c-4167-8947-4c23238554cf=
%40isocpp.org</a>.<br />

------=_Part_560_341721466.1468208733178--

------=_Part_559_417607775.1468208733177--

.

On Sun, Jul 10, 2016 at 10:47 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Indeed, I would go so far as to say that any placeholder which is currently
> a valid identifier is not a solution at all.

How about

  register lock_guard(lk);

Not a currently valid identifier, correct English :)

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

.

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

If I'm following Francisco's line of thought that would not work for:
auto [a, register, c] = foo();

Or for:
[a, register = b, c]() { ... }

The suggestion is for something that can be used during the variable
declaration which make it valid but inaccessible since it does not have a
name.


On Sun, Jul 10, 2016 at 10:53 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Sun, Jul 10, 2016 at 10:47 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> > Indeed, I would go so far as to say that any placeholder which is
> currently
> > a valid identifier is not a solution at all.
>
> How about
>
>   register lock_guard(lk);
>
> Not a currently valid identifier, correct English :)
>
> --
> 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/CAGsORuBVUC1ezm7POV8YzDuzTc0Qn6s0amdfbQq_Di1gAxSwYg%40mail.gmail.com
> .
>

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

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

<div dir=3D"ltr">If I&#39;m following Francisco&#39;s line of thought that =
would not work for:<div>auto [a, register, c] =3D foo();</div><div><br></di=
v><div>Or for:</div><div>[a, register =3D b, c]() { ... }</div><div><br></d=
iv><div>The suggestion is for something that can be used during the variabl=
e declaration which make it valid but inaccessible since it does not have a=
 name.</div><div><br></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Sun, Jul 10, 2016 at 10:53 PM, Zhihao Yuan <span dir=3D"ltr">&=
lt;<a href=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Jul 10, 2016 at 10=
:47 PM, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gm=
ail.com</a>&gt; wrote:<br>
&gt; Indeed, I would go so far as to say that any placeholder which is curr=
ently<br>
&gt; a valid identifier is not a solution at all.<br>
<br>
How about<br>
<br>
=C2=A0 register lock_guard(lk);<br>
<br>
Not a currently valid identifier, correct English :)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://blog.miator.net/" rel=3D"noreferrer" target=3D"_b=
lank">http://blog.miator.net/</a><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">std-propo=
sals+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/CAGsORuBVUC1ezm7POV8YzDuzTc0Qn6s0amdf=
bQq_Di1gAxSwYg%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBVUC1ezm7POV=
8YzDuzTc0Qn6s0amdfbQq_Di1gAxSwYg%40mail.gmail.com</a>.<br>
</font></span></blockquote></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/CA%2BfGSbMb2tNhMGzWBuCfWZ0cgtJaBjMNs2=
f%2BxUtMFpLJ5iVKCg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbMb2t=
NhMGzWBuCfWZ0cgtJaBjMNs2f%2BxUtMFpLJ5iVKCg%40mail.gmail.com</a>.<br />

--001a113c24ca9da2c80537542ca4--

.

------=_Part_62_1520263082.1468210185423
Content-Type: multipart/alternative;
 boundary="----=_Part_63_24464605.1468210185424"

------=_Part_63_24464605.1468210185424
Content-Type: text/plain; charset=UTF-8

On Sunday, July 10, 2016 at 11:59:10 PM UTC-4, Ricardo Andrade wrote:
>
> If I'm following Francisco's line of thought that would not work for:
> auto [a, register, c] = foo();
>

Why wouldn't that work? `register` is a valid keyword but currently has no
meaning. Therefore, its usage in structured binding has no meaning.

Which means we can *make* it work however we want.

>

--
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/b49da70c-9e69-4a19-8e1e-0afb26e38aeb%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, July 10, 2016 at 11:59:10 PM UTC-4, Ricardo And=
rade 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">If=
 I&#39;m following Francisco&#39;s line of thought that would not work for:=
<div>auto [a, register, c] =3D foo();</div></div></blockquote><div dir=3D"l=
tr"><br>Why wouldn&#39;t that work? `register` is a valid keyword but curre=
ntly has no meaning. Therefore, its usage in structured binding has no mean=
ing.<br><br>Which means we can <i>make</i> it work however we want.</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">
</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/b49da70c-9e69-4a19-8e1e-0afb26e38aeb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b49da70c-9e69-4a19-8e1e-0afb26e38aeb=
%40isocpp.org</a>.<br />

------=_Part_63_24464605.1468210185424--

------=_Part_62_1520263082.1468210185423--

.

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

Well, if that's the case, the idea is not half bad. :)
"register"ing a variable sounds even reasonable.

On Sun, Jul 10, 2016 at 11:09 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Sunday, July 10, 2016 at 11:59:10 PM UTC-4, Ricardo Andrade wrote:
>>
>> If I'm following Francisco's line of thought that would not work for:
>> auto [a, register, c] = foo();
>>
>
> Why wouldn't that work? `register` is a valid keyword but currently has no
> meaning. Therefore, its usage in structured binding has no meaning.
>
> Which means we can *make* it work however we want.
>
>> --
> 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/b49da70c-9e69-4a19-8e1e-0afb26e38aeb%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b49da70c-9e69-4a19-8e1e-0afb26e38aeb%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/CA%2BfGSbORWXxFhnQ4V8ZiqqAS2rwFG%3D_QPJUHviSB8F0FfWnV8A%40mail.gmail.com.

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

<div dir=3D"ltr">Well, if that&#39;s the case, the idea is not half bad. :)=
<div>&quot;register&quot;ing a variable sounds even reasonable.</div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Jul 10, 2=
016 at 11:09 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckes=
son@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, July 10, 2016=
 at 11:59:10 PM UTC-4, Ricardo Andrade wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">If I&#39;m following Francisco&#39;s line of tho=
ught that would not work for:<div>auto [a, register, c] =3D foo();</div></d=
iv></blockquote><div dir=3D"ltr"><br>Why wouldn&#39;t that work? `register`=
 is a valid keyword but currently has no meaning. Therefore, its usage in s=
tructured binding has no meaning.<br><br>Which means we can <i>make</i> it =
work however we want.</div><span class=3D"HOEnZb"><font color=3D"#888888"><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex">
</blockquote></font></span></div><span class=3D"HOEnZb"><font color=3D"#888=
888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b49da70c-9e69-4a19-8e1e-0afb26e38aeb%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b49da70c-9e69-=
4a19-8e1e-0afb26e38aeb%40isocpp.org</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--001a1141136e100aa90537545dd5--

.

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

On Sun, Jul 10, 2016 at 10:45 PM, Francisco Lopes <
francisco.mailing.lists@oblita.com> wrote:

> Hi Ricardo, maybe the topic name is improper. First, I'm advocating that
> if any special character
> is to be used besides _ and __, which are already usable as indentifiers,
> then it would
> not be possible to explicitly call member functions on them, they would
> simpler serve the purpose
> of a placeholder name at declaration.
>
>
Now I think I understand the reach of your suggestion. Any variable,
anywhere, could be unnamed.
As long as it becomes inaccessible after being "declared" I can see some
benefit.


> I like this idea of a placeholder variable name better than the current
> propositions. It's not the
> same as truly anonymous for which you don't even give it a name at all,
> but it's better IMO.
>

I can also see some problems.
- I'm not quite sure if I want unnamed variables everywhere.
  At the local scope, it seems pretty straightforward. Global, namespace,
static and class scopes I'm not so sure.
  In the other hand, I'm also against artificial constraints to prevent
such uses if this suggestion ever becomes a proposal.
- I was about to say that finding such placeholder "name" sounded
difficult. But it seems we got a candidate "register".


> I see no reason for tackling it solely by extending syntax of structure
> binding and missing the
> oportunity for all the possible remaining usecases where the presence of a
> placeholder name would
> solve it. A placeholder doesn't even need to tweak structure binding
> specification at all, it would be
> solved as a consequence of a more general solution about variable naming.
>
>
Sounds reasonable. :)


> Em segunda-feira, 11 de julho de 2016 00:07:07 UTC-3, Ricardo Andrade
> escreveu:
>>
>> I've been following this with great interest but I disagree with using _,
>> __, @, etc.
>>
>> If the goal of a future proposal is having unnamed variables IMHO they
>> should not use any character or sequence of characters to be... well ...
>> named.
>>
>> The examples where a member function needs to be called on a unnamed
>> variable is just something that could be done by another function which the
>> return is assigned to a unnamed variable.
>> Or other cases, another RAII class could wrap this and calling
>> whatever member functions on its constructor/destructor.
>>
>> Nicol's suggestion:
>> auto[] = foo();
>> It seems to me a better direction.
>>
>> For the cases where named and unnamed variables are needed, may we just
>> skip declaring a name?
>> auto [a,,c] = foo();
>> Or would that be too error prone?
>>
>> A few other thoughts:
>> - Should unnamed variables should also be allowed whenever a structured
>> binding is possible?
>>   I'm thinking unnamed statics/globals here.
>>
>> - It was also mentioned that structured binding creates references... but
>> which kind of references are they?
>>   const& and && are known to extend the lifetime of the assigned object
>> until the end of the scope.
>>
>> - Regarding structured binding type deduction and conversions: there was
>> some discussion around allowing specifying the types of individual
>> variables.
>>   How that would apply to unnamed variables?
>>   Wrap conversions in other functions or classes (as suggested above for
>> when member function calls are needed)?
>>   Or just don't for now...
>>   If structured binding ever gets this ability in the future, then types
>> for unnamed variables could be specified: auto[int a, int, int b] = foo();
>>
>> - Is there a use case for unnamed class data members?
>>   Maybe for some crazy future use of parameter pack expansion?
>>   Then auto[] would not work.
>>
>> - I'm trying to find similarities with other situations where an entity
>> can be unnamed as a case for consistency ...
>>   anonymous unions/structs or namespaces, type of a lambda...
>>   Well, maybe those are different beasts.
>>
>>
>> On Sun, Jul 10, 2016 at 9:23 PM, Francisco Lopes <
>> francisco.m...@oblita.com> wrote:
>>
>>>
>>>
>>> Em domingo, 10 de julho de 2016 23:12:32 UTC-3, Francisco Lopes escreveu:
>>>>
>>>>
>>>>
>>>> Em domingo, 10 de julho de 2016 23:08:39 UTC-3, Francisco Lopes
>>>> escreveu:
>>>>>
>>>>> Besides _ or __ I'm thinking of other possibilities...
>>>>>
>>>>>  @: I know of its presence solely in mangled names but I suspect it
>>>>> won't be an issue.
>>>>>
>>>>> I dunno, maybe the range of special characters may be of some use here
>>>>> too.
>>>>>
>>>>
>>>> If adopting such alternative characters, it would be placeholder only,
>>>> without referentiability.
>>>>
>>>
>>> My preferred choices are _, @ or ?
>>>
>>>
>>>>> Em domingo, 10 de julho de 2016 22:53:11 UTC-3, Francisco Lopes
>>>>> escreveu:
>>>>>>
>>>>>>
>>>>>> Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:
>>>>>>>
>>>>>>> On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>>>>>>>>
>>>>>>>> That's interesting Nicol, but what about the other cases? For
>>>>>>>> structured binding itself
>>>>>>>> for example, how would I let bindings unnamed?
>>>>>>>>
>>>>>>>
>>>>>>> Remember the goal: you want an *object* to be unnamed, because you
>>>>>>> want to use its construction and destruction only. The variables created by
>>>>>>> structured binding are not objects; they're *references*. Their
>>>>>>> destructors are irrelevant, so making them unnamed is equally irrelevant to
>>>>>>> this particular goal.
>>>>>>>
>>>>>>
>>>>>> That may look like the *original* goal in the previous thread, but
>>>>>> to tell the truth it's not my goal. The rationale
>>>>>> here is for unnamed variables. It's just about to cover the intention
>>>>>> of not providing names for things
>>>>>> that doesn't need them, as frequently happen (and will happen) in the
>>>>>> cases presented.
>>>>>>
>>>>>>
>>>>>>> Don't try to solve every problem at once.
>>>>>>>
>>>>>>
>>>>>> Why not? It's a simple solution that covers the relevant problem:
>>>>>> having a placeholder. It ends up
>>>>>> solving all in an understandable manner, in a uniform way. I ask why
>>>>>> solve it in a case by case form?
>>>>>> or solving one special case while leaving the others for the future
>>>>>> or plain unsolved, when in truth,
>>>>>> they all refer to the same core subject.
>>>>>>
>>>>>>
>>>>>> --
>>> 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.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69941075-9183-403b-86ac-3e37b7ddfae1%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69941075-9183-403b-86ac-3e37b7ddfae1%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/dd3ec780-537c-4167-8947-4c23238554cf%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dd3ec780-537c-4167-8947-4c23238554cf%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/CA%2BfGSbNt_mxQDr4_S4jiD%3DsrixbsqW%3Dyn9Q76Q1KN-zbO4YZAA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sun, Jul 10, 2016 at 10:45 PM, Francisco Lopes <span dir=3D"ltr">&lt;<a =
href=3D"mailto:francisco.mailing.lists@oblita.com" target=3D"_blank">franci=
sco.mailing.lists@oblita.com</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">Hi Ricardo, maybe the topic name is improper. Fi=
rst, I&#39;m advocating that if any special character<br>is to be used besi=
des _ and __, which are already usable as indentifiers, then it would<br>no=
t be possible to explicitly call member functions on them, they would simpl=
er serve the purpose<br>of a placeholder name at declaration.<br><br></div>=
</blockquote><div><br></div><div>Now I think I understand the reach of your=
 suggestion. Any variable, anywhere, could be unnamed.</div><div>As long as=
 it becomes inaccessible after being &quot;declared&quot; I can see some be=
nefit.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">I like this idea of a placeholder variable name better than the current p=
ropositions. It&#39;s not the<br>same as truly anonymous for which you don&=
#39;t even give it a name at all, but it&#39;s better IMO.<br></div></block=
quote><div><br></div><div>I can also see some problems.</div><div>- I&#39;m=
 not quite sure if I want unnamed variables everywhere.<br>=C2=A0 At the lo=
cal scope, it seems pretty straightforward. Global, namespace, static and c=
lass scopes I&#39;m not so sure.</div><div>=C2=A0 In the other hand, I&#39;=
m also against artificial constraints to prevent such uses if this suggesti=
on ever becomes a proposal.</div><div>- I was about to say that finding suc=
h placeholder &quot;name&quot; sounded difficult. But it seems we got a can=
didate &quot;register&quot;.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">I see no reason for tackling it solely by extending=
 syntax of structure binding and missing the<br>oportunity for all the poss=
ible remaining usecases where the presence of a placeholder name would<br>s=
olve it. A placeholder doesn&#39;t even need to tweak structure binding spe=
cification at all, it would be<br>solved as a consequence of a more general=
 solution about variable naming.<br><br></div></blockquote><div><br></div><=
div>Sounds reasonable. :)</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">Em segunda-feira, 11 de julho de 2016 00:07:07 UTC-3, =
Ricardo Andrade  escreveu:<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>I&#39;ve been following this with great interest but I disagr=
ee with using _, __, @, etc.</div><div><br></div>If the goal of a future pr=
oposal is having unnamed variables IMHO they should not use any character o=
r sequence of characters to be... well ... named.<div><br></div><div>The ex=
amples where a=C2=A0member function=C2=A0needs to be called on a unnamed va=
riable is just something that could be done by another function which the r=
eturn is assigned to a unnamed variable.</div><div>Or other cases,=C2=A0ano=
ther=C2=A0RAII class could wrap this and calling whatever=C2=A0member funct=
ions=C2=A0on its constructor/destructor.</div><div><div><br><div>Nicol&#39;=
s suggestion:</div><div>auto[] =3D foo();</div><div>It seems to me a better=
 direction.<br></div><div><br></div><div>For the cases where named and unna=
med variables are needed, may we just skip declaring a name?</div><div>auto=
 [a,,c] =3D foo();</div><div>Or would that be too error prone?<br></div><di=
v><br></div><div>A few other thoughts:</div><div>- Should unnamed variables=
 should also be allowed whenever a structured binding is possible?<br>=C2=
=A0 I&#39;m thinking unnamed statics/globals here.</div><div><br></div><div=
>- It was also mentioned that structured binding creates references... but =
which kind of references are they?</div><div>=C2=A0 const&amp; and &amp;&am=
p; are known to extend the lifetime of the assigned object until the end of=
 the scope.<br></div><div><br></div><div>- Regarding structured binding typ=
e deduction and conversions: there was some discussion around allowing spec=
ifying the types of individual variables.<br>=C2=A0 How that would apply to=
 unnamed variables?<br>=C2=A0 Wrap conversions in other functions or classe=
s (as suggested above for when member function calls are needed)?<br>=C2=A0=
 Or just don&#39;t for now...<br>=C2=A0 If structured binding ever gets thi=
s ability in the future, then types for unnamed variables could be specifie=
d: auto[int a, int, int b] =3D foo();</div><div><div><br></div><div>- Is th=
ere a use case for unnamed class data members?<br>=C2=A0 Maybe for some cra=
zy future use of parameter pack expansion?<br>=C2=A0 Then auto[] would not =
work.</div><div><br></div><div>- I&#39;m trying to find similarities with o=
ther situations where an entity can be unnamed as a case for consistency ..=
..</div><div>=C2=A0 anonymous unions/structs or namespaces, type of a lambda=
....</div><div>=C2=A0 Well, maybe those are different beasts.</div></div></d=
iv><div><div><br></div></div></div></div><div><br><div class=3D"gmail_quote=
">On Sun, Jul 10, 2016 at 9:23 PM, Francisco Lopes <span dir=3D"ltr">&lt;<a=
 rel=3D"nofollow">francisco.m...@oblita.com</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><br><br>Em domingo, 10 de julho d=
e 2016 23:12:32 UTC-3, Francisco Lopes  escreveu:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br><br>Em domingo, 10 de julho de 2016 23:0=
8:39 UTC-3, Francisco Lopes  escreveu:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">Besides _ or __ I&#39;m thinking of other possibilities=
....<br><br>=C2=A0@: I know of its presence solely in mangled names but I su=
spect it won&#39;t be an issue.<br><br>I dunno, maybe the range of special =
characters may be of some use here too.<br></div></blockquote><div><br>If a=
dopting such alternative characters, it would be placeholder only, without =
referentiability.<br></div></div></blockquote><div><br>My preferred choices=
 are _, @ or ? <br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><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"><br>Em =
domingo, 10 de julho de 2016 22:53:11 UTC-3, Francisco Lopes  escreveu:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>Em domingo, 10 de =
julho de 2016 22:11:16 UTC-3, Nicol Bolas  escreveu:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">On Sunday, July 10, 2016 at 7:59:33 PM UT=
C-4, Francisco Lopes wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">That&#39;s interesting Nicol, but what about the other cases? For =
structured binding itself<br>for example, how would I let bindings unnamed?=
</div></blockquote><div><br>Remember the goal: you want an <i>object</i> to=
 be unnamed, because you want to use its construction and destruction only.=
 The variables created by structured binding are not objects; they&#39;re <=
i>references</i>. Their destructors are irrelevant, so making them unnamed =
is equally irrelevant to this particular goal.<br></div></div></blockquote>=
<div>=C2=A0<br>That may look like the <i>original</i> goal in the previous =
thread, but to tell the truth it&#39;s not my goal. The rationale<br>here i=
s for unnamed variables. It&#39;s just about to cover the intention of not =
providing names for things<br>that doesn&#39;t need them, as frequently hap=
pen (and will happen) in the cases presented.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div><br>Don&#39;t try to solve ev=
ery problem at once.</div></div></blockquote><div>=C2=A0<br>Why not? It&#39=
;s a simple solution that covers the relevant problem: having a placeholder=
.. It ends up<br>solving all in an understandable manner, in a uniform way. =
I ask why solve it in a case by case form?<br>or solving one special case w=
hile leaving the others for the future or plain unsolved, when in truth,<br=
>they all refer to the same core subject.<br><br><span><font color=3D"#8888=
88"><br></font></span></div></div></blockquote></div></blockquote></div></b=
lockquote></div><span><font color=3D"#888888"><span><font color=3D"#888888"=
>

<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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</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/69941075-9183-403b-86ac-3e37b7ddfae1%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/69941075-9183-403b-86ac-3e37b7ddfae1%40isocpp.org</a>.<br>
</font></span></font></span></blockquote></div><span><font color=3D"#888888=
"><br></font></span></div><span><font color=3D"#888888">
</font></span></blockquote></div><span><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dd3ec780-537c-4167-8947-4c23238554cf%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dd3ec780-537c-=
4167-8947-4c23238554cf%40isocpp.org</a>.<br>
</font></span></blockquote></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/CA%2BfGSbNt_mxQDr4_S4jiD%3DsrixbsqW%3=
Dyn9Q76Q1KN-zbO4YZAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbNt=
_mxQDr4_S4jiD%3DsrixbsqW%3Dyn9Q76Q1KN-zbO4YZAA%40mail.gmail.com</a>.<br />

--001a114f15a06f6b9505375475e0--

.

On Sun, Jul 10, 2016 at 10:59 PM, Ricardo Fabiano de Andrade
<ricardofabianodeandrade@gmail.com> wrote:
> If I'm following Francisco's line of thought that would not work for:
> auto [a, register, c] = foo();

I want to solve the problem of RAII, not structured
binding.  Feel free to extend structured binding,
but I don't find making them work in the same
way very fascinating.

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

.

We could solve RAII with register, and leave it at that.=C2=A0

But I solution for structured binding would also be nice.=C2=A0
And if/when we get pattern matching, we will really need something short th=
at means 'match any'. auto does that for types, but we need something for v=
alues.=C2=A0

We could solve each of these independently, but if #3 also solves #2 and #1=
 *coherently*, then I'd rather have a single solution.

If a single solution is incoherent, then we shouldn't push it. But we need =
to explore it.=C2=A0

I'm not sure solving any one problem is worth it on its own, but if you can=
 solve all three (and more), then you have bang for the buck.=C2=A0
=C2=A0

Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Zhihao Yuan
Sent: Monday, July 11, 2016 12:20 AM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: Anonymous variables (moved "deferred destr=
uction" topic)

On Sun, Jul 10, 2016 at 10:59 PM, Ricardo Fabiano de Andrade
<ricardofabianodeandrade@gmail.com> wrote:
> If I'm following Francisco's line of thought that would not work for:
> auto [a, register, c] =3D foo();

I want to solve the problem of RAII, not structured
binding. Feel free to extend structured binding,
but I don't find making them work in the same
way very fascinating.

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

--=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/CAGsORuD5GZataPFFfzKTxO7zMgLfkcTFS6uGq6GputasiwF=
10g%40mail.gmail.com.

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

.

On Sun, Jul 10, 2016 at 11:28 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
> We could solve each of these independently, but if #3 also solves #2 and #1 *coherently*, then I'd rather have a single solution.
>
> If a single solution is incoherent, then we shouldn't push it. But we need to explore it.

Let's say we use the keyword `register` as the placeholder
for the solution this thread is looking for, RAII will be written
as

  auto register = lock_guard(lk);

Lengthy.  And structured binding will be

  auto [a, register] = ...;

I want to "ignore", not *not* to ignore.

This way damages both use cases.

>
> I'm not sure solving any one problem is worth it on its own, but if you can solve all three (and more), then you have bang for the buck.

Instead, if we have

  register lock_guard(lk);

and

  auto [a, std::ignore] = expr;

Both intentions seem to be expressed very well.

The point I'm making here is that, for the RAII case,
what you want is to emphasis the existence of the
unnamed variable, while in structured binding/pattern
matching, what you want is to eliminate the presence
of the unnamed variable.  They are not necessarily
to be using the same solution.

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

.

------=_Part_7355_639476418.1468212938258
Content-Type: multipart/alternative;
 boundary="----=_Part_7356_1775219161.1468212938258"

------=_Part_7356_1775219161.1468212938258
Content-Type: text/plain; charset=UTF-8

Hi Zhihao. Of course it doesn't necessarily need to be any way.
I get your point, but the solutions you give to cover that point are
not much pretty.

Em segunda-feira, 11 de julho de 2016 01:40:47 UTC-3, Zhihao Yuan escreveu:
>
> On Sun, Jul 10, 2016 at 11:28 PM, Tony V E <tvan...@gmail.com
> <javascript:>> wrote:
> >
> > We could solve each of these independently, but if #3 also solves #2 and
> #1 *coherently*, then I'd rather have a single solution.
> >
> > If a single solution is incoherent, then we shouldn't push it. But we
> need to explore it.
>
> Let's say we use the keyword `register` as the placeholder
> for the solution this thread is looking for, RAII will be written
> as
>
>   auto register = lock_guard(lk);
>
> Lengthy.


register is not meaningful, it doesn't bring the sense of a placeholder, I
think this is bad.


> And structured binding will be
>
>   auto [a, register] = ...;
>
> I want to "ignore", not *not* to ignore.
>

Indeed, me too! Same for the previous.

This way damages both use cases.
>
> >
> > I'm not sure solving any one problem is worth it on its own, but if you
> can solve all three (and more), then you have bang for the buck.
>
> Instead, if we have
>
>   register lock_guard(lk);
>

OK so, register is still not meaningful about anything as a name, and what
is it doing
at the variable type? I have to bend my mind to understand that's an
anonymous declaration
of a lock_guard.

and
>
>   auto [a, std::ignore] = expr;
>

Have you checked in a previous Nicol email how structure binding should
expand behind
the scenes. Having a placeholder variable name fits well with that, now
std::ignore doesn't,
I can't imagine what the implementation of that should be like. I agree the
intention is
present though, in this case.

Both intentions seem to be expressed very well.
>
> The point I'm making here is that, for the RAII case,
> what you want is to emphasis the existence of the
> unnamed variable, while in structured binding/pattern
> matching, what you want is to eliminate the presence
> of the unnamed variable.  They are not necessarily
> to be using the same solution.
>
--
> 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/08b95db7-54de-4ca0-bbc3-3c453122f79a%40isocpp.org.

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

<div dir=3D"ltr">Hi Zhihao. Of course it doesn&#39;t necessarily need to be=
 any way.<br>I get your point, but the solutions you give to cover that poi=
nt are<br>not much pretty.<br><br>Em segunda-feira, 11 de julho de 2016 01:=
40:47 UTC-3, Zhihao Yuan  escreveu:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">On Sun, Jul 10, 2016 at 11:28 PM, Tony V E &lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"uKJvWwM9CgAJ" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"=
this.href=3D&#39;javascript:&#39;;return true;">tvan...@gmail.com</a>&gt; w=
rote:
<br>&gt;
<br>&gt; We could solve each of these independently, but if #3 also solves =
#2 and #1 *coherently*, then I&#39;d rather have a single solution.
<br>&gt;
<br>&gt; If a single solution is incoherent, then we shouldn&#39;t push it.=
 But we need to explore it.
<br>
<br>Let&#39;s say we use the keyword `register` as the placeholder
<br>for the solution this thread is looking for, RAII will be written
<br>as
<br>
<br>=C2=A0 auto register =3D lock_guard(lk);
<br>
<br>Lengthy.</blockquote><div><br>register is not meaningful, it doesn&#39;=
t bring the sense of a placeholder, I think this is bad.<br>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">And structured binding will be
<br>
<br>=C2=A0 auto [a, register] =3D ...;
<br>
<br>I want to &quot;ignore&quot;, not *not* to ignore.
<br></blockquote><div><br>Indeed, me too! Same for the previous. <br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">This way damages both use =
cases.
<br>
<br>&gt;
<br>&gt; I&#39;m not sure solving any one problem is worth it on its own, b=
ut if you can solve all three (and more), then you have bang for the buck.
<br>
<br>Instead, if we have
<br>
<br>=C2=A0 register lock_guard(lk);
<br></blockquote><div><br>OK so, register is still not meaningful about any=
thing as a name, and what is it doing<br>at the variable type? I have to be=
nd my mind to understand that&#39;s an anonymous declaration<br>of a lock_g=
uard. <br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">and
<br>
<br>=C2=A0 auto [a, std::ignore] =3D expr;
<br></blockquote><div><br>Have you checked in a previous Nicol email how st=
ructure binding should expand behind<br>the scenes. Having a placeholder va=
riable name fits well with that, now std::ignore doesn&#39;t,<br>I can&#39;=
t imagine what the implementation of that should be like. I agree the inten=
tion is<br>present though, in this case.<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">Both intentions seem to be expressed very well.
<br>
<br>The point I&#39;m making here is that, for the RAII case,
<br>what you want is to emphasis the existence of the
<br>unnamed variable, while in structured binding/pattern
<br>matching, what you want is to eliminate the presence
<br>of the unnamed variable. =C2=A0They are not necessarily
<br>to be using the same solution. <br></blockquote><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">--=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/08b95db7-54de-4ca0-bbc3-3c453122f79a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/08b95db7-54de-4ca0-bbc3-3c453122f79a=
%40isocpp.org</a>.<br />

------=_Part_7356_1775219161.1468212938258--

------=_Part_7355_639476418.1468212938258--

.

On Sun, Jul 10, 2016 at 11:55 PM, Francisco Lopes
<francisco.mailing.lists@oblita.com> wrote:
>> Instead, if we have
>>
>>   register lock_guard(lk);
>
>
> OK so, register is still not meaningful about anything as a name, and what
> is it doing
> at the variable type? I have to bend my mind to understand that's an
> anonymous declaration
> of a lock_guard.
>

It's even easier to understand than "unnamed variable".
Given

  lock_guard(lk);

as an expression statement -- a _discarded-value
expression_ alone followed by a semicolon,

  register lock_guard(lk);

statement will be a statement that keep the value to-be-
discarded.  Or you can say, "registered".

--
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/CAGsORuCxnfOqbOt4HaeOus33L2u7XvA46M%3DCc-T9ojSLKqopXQ%40mail.gmail.com.

.

------=_Part_1145_1327840019.1468213983478
Content-Type: multipart/alternative;
 boundary="----=_Part_1146_1729238393.1468213983478"

------=_Part_1146_1729238393.1468213983478
Content-Type: text/plain; charset=UTF-8

Hah, ok, now I get it. In that sense it seems fine.

Em segunda-feira, 11 de julho de 2016 02:08:36 UTC-3, Zhihao Yuan escreveu:
>
> On Sun, Jul 10, 2016 at 11:55 PM, Francisco Lopes
> <francisco.m...@oblita.com <javascript:>> wrote:
> >> Instead, if we have
> >>
> >>   register lock_guard(lk);
> >
> >
> > OK so, register is still not meaningful about anything as a name, and
> what
> > is it doing
> > at the variable type? I have to bend my mind to understand that's an
> > anonymous declaration
> > of a lock_guard.
> >
>
> It's even easier to understand than "unnamed variable".
> Given
>
>   lock_guard(lk);
>
> as an expression statement -- a _discarded-value
> expression_ alone followed by a semicolon,
>
>   register lock_guard(lk);
>
> statement will be a statement that keep the value to-be-
> discarded.  Or you can say, "registered".
>
> --
> 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/299d9f49-7070-4dcf-95ca-1ce0538a582d%40isocpp.org.

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

<div dir=3D"ltr">Hah, ok, now I get it. In that sense it seems fine.<br><br=
>Em segunda-feira, 11 de julho de 2016 02:08:36 UTC-3, Zhihao Yuan  escreve=
u:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Jul 10, 2016 at 11:5=
5 PM, Francisco Lopes
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
nekr24c-CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">francisco.m...@<wbr>oblita.com</a>&gt; wrote:
<br>&gt;&gt; Instead, if we have
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 register lock_guard(lk);
<br>&gt;
<br>&gt;
<br>&gt; OK so, register is still not meaningful about anything as a name, =
and what
<br>&gt; is it doing
<br>&gt; at the variable type? I have to bend my mind to understand that&#3=
9;s an
<br>&gt; anonymous declaration
<br>&gt; of a lock_guard.
<br>&gt;
<br>
<br>It&#39;s even easier to understand than &quot;unnamed variable&quot;.
<br>Given
<br>
<br>=C2=A0 lock_guard(lk);
<br>
<br>as an expression statement -- a _discarded-value
<br>expression_ alone followed by a semicolon,
<br>
<br>=C2=A0 register lock_guard(lk);
<br>
<br>statement will be a statement that keep the value to-be-
<br>discarded. =C2=A0Or you can say, &quot;registered&quot;.
<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/299d9f49-7070-4dcf-95ca-1ce0538a582d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/299d9f49-7070-4dcf-95ca-1ce0538a582d=
%40isocpp.org</a>.<br />

------=_Part_1146_1729238393.1468213983478--

------=_Part_1145_1327840019.1468213983478--

.

------=_Part_7459_1772565320.1468214575531
Content-Type: multipart/alternative;
 boundary="----=_Part_7460_2092923377.1468214575532"

------=_Part_7460_2092923377.1468214575532
Content-Type: text/plain; charset=UTF-8

Now I agree with being an acceptable solution for the RAII problem, it
covers both
scope_exit and guards. Sadly it doesn't touch binding as you already said.

The problem is that the time we get a mechanist to let variables unnamed
(like
with got for types like Tony said), and I hope so this happens. Then we
will end
up with two valid solutions for the RAII problem I guess. It would not
happen only
if placeholders are put at work in specific places solely, which personally
I'd not
like.

Em segunda-feira, 11 de julho de 2016 02:13:03 UTC-3, Francisco Lopes
escreveu:
>
> Hah, ok, now I get it. In that sense it seems fine.
>
> Em segunda-feira, 11 de julho de 2016 02:08:36 UTC-3, Zhihao Yuan escreveu:
>>
>> On Sun, Jul 10, 2016 at 11:55 PM, Francisco Lopes
>> <francisco.m...@oblita.com> wrote:
>> >> Instead, if we have
>> >>
>> >>   register lock_guard(lk);
>> >
>> >
>> > OK so, register is still not meaningful about anything as a name, and
>> what
>> > is it doing
>> > at the variable type? I have to bend my mind to understand that's an
>> > anonymous declaration
>> > of a lock_guard.
>> >
>>
>> It's even easier to understand than "unnamed variable".
>> Given
>>
>>   lock_guard(lk);
>>
>> as an expression statement -- a _discarded-value
>> expression_ alone followed by a semicolon,
>>
>>   register lock_guard(lk);
>>
>> statement will be a statement that keep the value to-be-
>> discarded.  Or you can say, "registered".
>>
>> --
>> 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/08a4079c-802c-484b-8c1e-a0c0866b40b8%40isocpp.org.

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

<div dir=3D"ltr">Now I agree with being an acceptable solution for the RAII=
 problem, it covers both<br>scope_exit and guards. Sadly it doesn&#39;t tou=
ch binding as you already said.<br><br>The problem is that the time we get =
a mechanist to let variables unnamed (like<br>with got for types like Tony =
said), and I hope so this happens. Then we will end<br>up with two valid so=
lutions for the RAII problem I guess. It would not happen only<br>if placeh=
olders are put at work in specific places solely, which personally I&#39;d =
not<br>like.<br><br>Em segunda-feira, 11 de julho de 2016 02:13:03 UTC-3, F=
rancisco Lopes  escreveu:<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">Hah, ok, now I get it. In that sense it seems fine.<br><br>Em s=
egunda-feira, 11 de julho de 2016 02:08:36 UTC-3, Zhihao Yuan  escreveu:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">On Sun, Jul 10, 2016 at 11:55 PM, Fran=
cisco Lopes
<br>&lt;<a rel=3D"nofollow">francisco.m...@oblita.com</a>&gt; wrote:
<br>&gt;&gt; Instead, if we have
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 register lock_guard(lk);
<br>&gt;
<br>&gt;
<br>&gt; OK so, register is still not meaningful about anything as a name, =
and what
<br>&gt; is it doing
<br>&gt; at the variable type? I have to bend my mind to understand that&#3=
9;s an
<br>&gt; anonymous declaration
<br>&gt; of a lock_guard.
<br>&gt;
<br>
<br>It&#39;s even easier to understand than &quot;unnamed variable&quot;.
<br>Given
<br>
<br>=C2=A0 lock_guard(lk);
<br>
<br>as an expression statement -- a _discarded-value
<br>expression_ alone followed by a semicolon,
<br>
<br>=C2=A0 register lock_guard(lk);
<br>
<br>statement will be a statement that keep the value to-be-
<br>discarded. =C2=A0Or you can say, &quot;registered&quot;.
<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/" rel=3D"nofollow" target=3D"=
_blank" 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></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/08a4079c-802c-484b-8c1e-a0c0866b40b8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/08a4079c-802c-484b-8c1e-a0c0866b40b8=
%40isocpp.org</a>.<br />

------=_Part_7460_2092923377.1468214575532--

------=_Part_7459_1772565320.1468214575531--

.

On Mon, Jul 11, 2016 at 12:22 AM, Francisco Lopes
<francisco.mailing.lists@oblita.com> wrote:
> The problem is that the time we get a mechanist to let variables unnamed
> (like
> with got for types like Tony said), and I hope so this happens. Then we will
> end
> up with two valid solutions for the RAII problem I guess. It would not
> happen only
> if placeholders are put at work in specific places solely, which personally
> I'd not
> like.

Structured binding is a prototype for pattern matching,
IMHO it's acceptable for having some features not
usable outside [], as acceptable as having features
usable from outside but not inside, which is the status
quo.

To this specific "ignore" functionality, restricting it
within structured binding gives us a long list of
placeholder candidates:

 ..  // two dots
 <>
 -  // minus, dash
 ~
 :)

, while making it usable in other places is troublesome
in some cases:

  int <placeholder> = get_raii_file_descriptor();

That RAII fd is implicitly convertible to int, so we
destroy the object and return an int?  Or we restrict
the type to be `auto`?  Oh wait, actually I need
`auto&&`!  Welcome home, that is exactly how
structured binding handles the "capturing object",
and by doing this we subset the language in a
much larger scope...

--
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/CAGsORuBtbE1doTfQAXXTtV%3DTLE%2Br%3DCyRVN-t_dLzSbw%3DDL_epQ%40mail.gmail.com.

.

On domingo, 10 de julho de 2016 19:08:38 PDT Francisco Lopes wrote:
>  @: I know of its presence solely in mangled names but I suspect it won't
> be an issue.

It's not part of the basic character set.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/4440553.WvD5SHPUhg%40tjmaciei-mobl1.

.

Hmmm
Maybe we should reserve _ as unusable in structured binding for now?

Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Zhihao Yuan
Sent: Monday, July 11, 2016 2:02 AM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: Anonymous variables (moved "deferred destr=
uction" topic)

On Mon, Jul 11, 2016 at 12:22 AM, Francisco Lopes
<francisco.mailing.lists@oblita.com> wrote:
> The problem is that the time we get a mechanist to let variables unnamed
> (like
> with got for types like Tony said), and I hope so this happens. Then we w=
ill
> end
> up with two valid solutions for the RAII problem I guess. It would not
> happen only
> if placeholders are put at work in specific places solely, which personal=
ly
> I'd not
> like.

Structured binding is a prototype for pattern matching,
IMHO it's acceptable for having some features not
usable outside [], as acceptable as having features
usable from outside but not inside, which is the status
quo.

To this specific "ignore" functionality, restricting it
within structured binding gives us a long list of
placeholder candidates:

... // two dots
<>
- // minus, dash
~
:)

, while making it usable in other places is troublesome
in some cases:

int <placeholder> =3D get_raii_file_descriptor();

That RAII fd is implicitly convertible to int, so we
destroy the object and return an int? Or we restrict
the type to be `auto`? Oh wait, actually I need
`auto&&`! Welcome home, that is exactly how
structured binding handles the "capturing object",
and by doing this we subset the language in a
much larger scope...

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

--=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/CAGsORuBtbE1doTfQAXXTtV%3DTLE%2Br%3DCyRVN-t_dLzS=
bw%3DDL_epQ%40mail.gmail.com.

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

.

------=_Part_373_235130981.1468246114505
Content-Type: multipart/alternative;
 boundary="----=_Part_374_793798715.1468246114506"

------=_Part_374_793798715.1468246114506
Content-Type: text/plain; charset=UTF-8



Em segunda-feira, 11 de julho de 2016 08:20:02 UTC-3, Tony V E escreveu:
>
> Hmmm
> Maybe we should reserve _ as unusable in structured binding for now?
>

I consider it a wise move.

Sent from my BlackBerry portable Babbage Device
>   Original Message
> From: Zhihao Yuan
> Sent: Monday, July 11, 2016 2:02 AM
> To: std-pr...@isocpp.org <javascript:>
> Reply To: std-pr...@isocpp.org <javascript:>
> Subject: Re: [std-proposals] Re: Anonymous variables (moved "deferred
> destruction" topic)
>
> On Mon, Jul 11, 2016 at 12:22 AM, Francisco Lopes
> <francisco.m...@oblita.com <javascript:>> wrote:
> > The problem is that the time we get a mechanist to let variables unnamed
> > (like
> > with got for types like Tony said), and I hope so this happens. Then we
> will
> > end
> > up with two valid solutions for the RAII problem I guess. It would not
> > happen only
> > if placeholders are put at work in specific places solely, which
> personally
> > I'd not
> > like.
>
> Structured binding is a prototype for pattern matching,
> IMHO it's acceptable for having some features not
> usable outside [], as acceptable as having features
> usable from outside but not inside, which is the status
> quo.
>
> To this specific "ignore" functionality, restricting it
> within structured binding gives us a long list of
> placeholder candidates:
>
> .. // two dots
> <>
> - // minus, dash
> ~
> :)
>
> , while making it usable in other places is troublesome
> in some cases:
>
> int <placeholder> = get_raii_file_descriptor();
>
> That RAII fd is implicitly convertible to int, so we
> destroy the object and return an int? Or we restrict
> the type to be `auto`? Oh wait, actually I need
> `auto&&`! Welcome home, that is exactly how
> structured binding handles the "capturing object",
> and by doing this we subset the language in a
> much larger scope...
>
> --
> 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-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/CAGsORuBtbE1doTfQAXXTtV%3DTLE%2Br%3DCyRVN-t_dLzSbw%3DDL_epQ%40mail.gmail.com.
>
>

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

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

<div dir=3D"ltr"><br><br>Em segunda-feira, 11 de julho de 2016 08:20:02 UTC=
-3, Tony V E  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hmmm
<br>Maybe we should reserve _ as unusable in structured binding for now?
<br></blockquote><div><br>I consider it a wise move. <br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=
=C2=A0<wbr>portable=C2=A0Babbage=C2=A0Device
<br>=C2=A0 Original Message =C2=A0
<br>From: Zhihao Yuan
<br>Sent: Monday, July 11, 2016 2:02 AM
<br>To: <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
jdQaxsxSCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-pr...@isocpp.org</a>
<br>Reply To: <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"jdQaxsxSCgAJ" 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;">std-pr...@isocpp.org</a>
<br>Subject: Re: [std-proposals] Re: Anonymous variables (moved &quot;defer=
red destruction&quot; topic)
<br>
<br>On Mon, Jul 11, 2016 at 12:22 AM, Francisco Lopes
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
jdQaxsxSCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">francisco.m...@<wbr>oblita.com</a>&gt; wrote:
<br>&gt; The problem is that the time we get a mechanist to let variables u=
nnamed
<br>&gt; (like
<br>&gt; with got for types like Tony said), and I hope so this happens. Th=
en we will
<br>&gt; end
<br>&gt; up with two valid solutions for the RAII problem I guess. It would=
 not
<br>&gt; happen only
<br>&gt; if placeholders are put at work in specific places solely, which p=
ersonally
<br>&gt; I&#39;d not
<br>&gt; like.
<br>
<br>Structured binding is a prototype for pattern matching,
<br>IMHO it&#39;s acceptable for having some features not
<br>usable outside [], as acceptable as having features
<br>usable from outside but not inside, which is the status
<br>quo.
<br>
<br>To this specific &quot;ignore&quot; functionality, restricting it
<br>within structured binding gives us a long list of
<br>placeholder candidates:
<br>
<br>.. // two dots
<br>&lt;&gt;
<br>- // minus, dash
<br>~
<br>:)
<br>
<br>, while making it usable in other places is troublesome
<br>in some cases:
<br>
<br>int &lt;placeholder&gt; =3D get_raii_file_descriptor();
<br>
<br>That RAII fd is implicitly convertible to int, so we
<br>destroy the object and return an int? Or we restrict
<br>the type to be `auto`? Oh wait, actually I need
<br>`auto&amp;&amp;`! Welcome home, that is exactly how
<br>structured binding handles the &quot;capturing object&quot;,
<br>and by doing this we subset the language in a
<br>much larger scope...
<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>
<br>--=20
<br>You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>To unsubscribe from this group and stop receiving emails from it, send =
an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"jdQaxsxSCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">std-proposal...@<wbr>isocpp.org</a>.
<br>To post to this group, send email to <a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"jdQaxsxSCgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>To view this discussion on the web visit <a href=3D"https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBtbE1doTfQAXXTtV%3DTLE%2Br=
%3DCyRVN-t_dLzSbw%3DDL_epQ%40mail.gmail.com" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/CAGsORuBtbE1doTfQAXXTtV%3DTLE%2Br%3DCyRVN-t_dLzSbw%3=
DDL_epQ%40mail.gmail.com&#39;;return true;" onclick=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBtbE1doTfQ=
AXXTtV%3DTLE%2Br%3DCyRVN-t_dLzSbw%3DDL_epQ%40mail.gmail.com&#39;;return tru=
e;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/=
<wbr>CAGsORuBtbE1doTfQAXXTtV%3DTLE%<wbr>2Br%3DCyRVN-t_dLzSbw%3DDL_epQ%<wbr>=
40mail.gmail.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/b0a7ec43-41b8-47b4-b7c6-b0231a1e2ae3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b0a7ec43-41b8-47b4-b7c6-b0231a1e2ae3=
%40isocpp.org</a>.<br />

------=_Part_374_793798715.1468246114506--

------=_Part_373_235130981.1468246114505--

.

------=_Part_8064_574426399.1468246483117
Content-Type: multipart/alternative;
 boundary="----=_Part_8065_1502286419.1468246483117"

------=_Part_8065_1502286419.1468246483117
Content-Type: text/plain; charset=UTF-8



Em segunda-feira, 11 de julho de 2016 11:08:34 UTC-3, Francisco Lopes
escreveu:
>
>
>
> Em segunda-feira, 11 de julho de 2016 08:20:02 UTC-3, Tony V E escreveu:
>>
>> Hmmm
>> Maybe we should reserve _ as unusable in structured binding for now?
>>
>
> I consider it a wise move.
>

If structured binding alone supported a placeholder already, it could be
done in
a way that would support both auto [x, _, y] = ..., was well as auto [] =
....

Sent from my BlackBerry portable Babbage Device
>>   Original Message
>> From: Zhihao Yuan
>> Sent: Monday, July 11, 2016 2:02 AM
>> To: std-pr...@isocpp.org
>> Reply To: std-pr...@isocpp.org
>> Subject: Re: [std-proposals] Re: Anonymous variables (moved "deferred
>> destruction" topic)
>>
>> On Mon, Jul 11, 2016 at 12:22 AM, Francisco Lopes
>> <francisco.m...@oblita.com> wrote:
>> > The problem is that the time we get a mechanist to let variables
>> unnamed
>> > (like
>> > with got for types like Tony said), and I hope so this happens. Then we
>> will
>> > end
>> > up with two valid solutions for the RAII problem I guess. It would not
>> > happen only
>> > if placeholders are put at work in specific places solely, which
>> personally
>> > I'd not
>> > like.
>>
>> Structured binding is a prototype for pattern matching,
>> IMHO it's acceptable for having some features not
>> usable outside [], as acceptable as having features
>> usable from outside but not inside, which is the status
>> quo.
>>
>> To this specific "ignore" functionality, restricting it
>> within structured binding gives us a long list of
>> placeholder candidates:
>>
>> .. // two dots
>> <>
>> - // minus, dash
>> ~
>> :)
>>
>> , while making it usable in other places is troublesome
>> in some cases:
>>
>> int <placeholder> = get_raii_file_descriptor();
>>
>> That RAII fd is implicitly convertible to int, so we
>> destroy the object and return an int? Or we restrict
>> the type to be `auto`? Oh wait, actually I need
>> `auto&&`! Welcome home, that is exactly how
>> structured binding handles the "capturing object",
>> and by doing this we subset the language in a
>> much larger scope...
>>
>> --
>> 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-proposal...@isocpp.org.
>> To post to this group, send email to std-pr...@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBtbE1doTfQAXXTtV%3DTLE%2Br%3DCyRVN-t_dLzSbw%3DDL_epQ%40mail.gmail.com.
>>
>>
>

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

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

<div dir=3D"ltr"><br><br>Em segunda-feira, 11 de julho de 2016 11:08:34 UTC=
-3, Francisco Lopes  escreveu:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><br><br>Em segunda-feira, 11 de julho de 2016 08:20:02 UTC=
-3, Tony V E  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Hmmm
<br>Maybe we should reserve _ as unusable in structured binding for now?
<br></blockquote><div><br>I consider it a wise move. <br></div></div></bloc=
kquote><div><br>If structured binding alone supported a placeholder already=
, it could be done in<br>a way that would support both auto [x, _, y] =3D .=
..., was well as auto [] =3D ...<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Sen=
t=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0<wbr>portable=C2=A0Babbage=C2=A0De=
vice
<br>=C2=A0 Original Message =C2=A0
<br>From: Zhihao Yuan
<br>Sent: Monday, July 11, 2016 2:02 AM
<br>To: <a rel=3D"nofollow">std-pr...@isocpp.org</a>
<br>Reply To: <a rel=3D"nofollow">std-pr...@isocpp.org</a>
<br>Subject: Re: [std-proposals] Re: Anonymous variables (moved &quot;defer=
red destruction&quot; topic)
<br>
<br>On Mon, Jul 11, 2016 at 12:22 AM, Francisco Lopes
<br>&lt;<a rel=3D"nofollow">francisco.m...@oblita.com</a>&gt; wrote:
<br>&gt; The problem is that the time we get a mechanist to let variables u=
nnamed
<br>&gt; (like
<br>&gt; with got for types like Tony said), and I hope so this happens. Th=
en we will
<br>&gt; end
<br>&gt; up with two valid solutions for the RAII problem I guess. It would=
 not
<br>&gt; happen only
<br>&gt; if placeholders are put at work in specific places solely, which p=
ersonally
<br>&gt; I&#39;d not
<br>&gt; like.
<br>
<br>Structured binding is a prototype for pattern matching,
<br>IMHO it&#39;s acceptable for having some features not
<br>usable outside [], as acceptable as having features
<br>usable from outside but not inside, which is the status
<br>quo.
<br>
<br>To this specific &quot;ignore&quot; functionality, restricting it
<br>within structured binding gives us a long list of
<br>placeholder candidates:
<br>
<br>.. // two dots
<br>&lt;&gt;
<br>- // minus, dash
<br>~
<br>:)
<br>
<br>, while making it usable in other places is troublesome
<br>in some cases:
<br>
<br>int &lt;placeholder&gt; =3D get_raii_file_descriptor();
<br>
<br>That RAII fd is implicitly convertible to int, so we
<br>destroy the object and return an int? Or we restrict
<br>the type to be `auto`? Oh wait, actually I need
<br>`auto&amp;&amp;`! Welcome home, that is exactly how
<br>structured binding handles the &quot;capturing object&quot;,
<br>and by doing this we subset the language in a
<br>much larger scope...
<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/" rel=3D"nofollow" target=3D"=
_blank" 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>
<br>--=20
<br>You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>To unsubscribe from this group and stop receiving emails from it, send =
an email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.
<br>To post to this group, send email to <a rel=3D"nofollow">std-pr...@isoc=
pp.org</a>.
<br>To view this discussion on the web visit <a href=3D"https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBtbE1doTfQAXXTtV%3DTLE%2Br=
%3DCyRVN-t_dLzSbw%3DDL_epQ%40mail.gmail.com" rel=3D"nofollow" target=3D"_bl=
ank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/CAGsORuBtbE1doTfQAXXTtV%3DTLE%2Br%3DCyRVN-t_dLzSbw%3=
DDL_epQ%40mail.gmail.com&#39;;return true;" onclick=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBtbE1doTfQ=
AXXTtV%3DTLE%2Br%3DCyRVN-t_dLzSbw%3DDL_epQ%40mail.gmail.com&#39;;return tru=
e;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/=
<wbr>CAGsORuBtbE1doTfQAXXTtV%3DTLE%<wbr>2Br%3DCyRVN-t_dLzSbw%3DDL_epQ%<wbr>=
40mail.gmail.com</a>.
<br></blockquote></div></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/8945c9e7-bc84-4292-8053-cad42e467954%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8945c9e7-bc84-4292-8053-cad42e467954=
%40isocpp.org</a>.<br />

------=_Part_8065_1502286419.1468246483117--

------=_Part_8064_574426399.1468246483117--

.

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

On Mon, Jul 11, 2016 at 7:01 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2016-07-10 18:25, Zhihao Yuan wrote:
> > My suggestion has always been a simple
> >
> >   with (auto lk = unique_lock(lk)) {
> >   }
> >
> > which is already available as `if (auto ...; true)`,
> > and
> >
> >   with (lock_guard(lk)) {
> >   }
> >
> > whose the wording for introducing a unique name
> > has already presented in the structured binding
> > proposal.
>
> Would this be legal?
>
>   with (lock_guard(a); lock_guard(b))
>   { ... }
>
> I definitely have cases where I want more than one "guard". I'd prefer
> to not need to create a scope for each one.
>
> --
> Matthew
>
>
>
Can someone explain to me what this actually offers over

{ std::lock_guard(whatever);
    // do stuff
}

because I must be missing something, as right now, it just looks like
adding a new keyword for no reason whatsoever, and eschewing a perfectly
valid use of temporary blocks in the process. IOW, completely redundant and
counterproductive.

so i must've missed an undeniable benefit, right?

--
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/CACGiwhF1%2BqeKLcm-szmKNv_BkMx8fX3Hr%2BnxL6Q%2BhHbVsdve8Q%40mail.gmail.com.

--001a114228b83486240537603685
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 M=
on, Jul 11, 2016 at 7:01 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><span class=3D"">On 2016-07-10 18:25, Zhihao Yuan wrote:<br>
&gt; My suggestion has always been a simple<br>
&gt;<br>
&gt;=C2=A0 =C2=A0with (auto lk =3D unique_lock(lk)) {<br>
&gt;=C2=A0 =C2=A0}<br>
&gt;<br>
&gt; which is already available as `if (auto ...; true)`,<br>
&gt; and<br>
&gt;<br>
&gt;=C2=A0 =C2=A0with (lock_guard(lk)) {<br>
&gt;=C2=A0 =C2=A0}<br>
&gt;<br>
&gt; whose the wording for introducing a unique name<br>
&gt; has already presented in the structured binding<br>
&gt; proposal.<br>
<br>
</span>Would this be legal?<br>
<br>
=C2=A0 with (lock_guard(a); lock_guard(b))<br>
=C2=A0 { ... }<br>
<br>
I definitely have cases where I want more than one &quot;guard&quot;. I&#39=
;d prefer<br>
to not need to create a scope for each one.<br>
<br>
--<br>
Matthew<br>
<span class=3D""><br><br></span></blockquote><div><br>Can someone explain t=
o me what this actually offers over<br><br></div><div>{ std::lock_guard(wha=
tever);<br></div><div>=C2=A0 =C2=A0 // do stuff<br>}<br><br></div><div>beca=
use I must be missing something, as right now, it just looks like adding a =
new keyword for no reason whatsoever, and eschewing a perfectly valid use o=
f temporary blocks in the process. IOW, completely redundant and counterpro=
ductive.<br><br></div><div>so i must&#39;ve missed an undeniable benefit, r=
ight?<br>=C2=A0<br></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/CACGiwhF1%2BqeKLcm-szmKNv_BkMx8fX3Hr%=
2BnxL6Q%2BhHbVsdve8Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhF1%2=
BqeKLcm-szmKNv_BkMx8fX3Hr%2BnxL6Q%2BhHbVsdve8Q%40mail.gmail.com</a>.<br />

--001a114228b83486240537603685--

.

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

On Mon, Jul 11, 2016 at 7:20 PM, D. B. <db0451@gmail.com> wrote:

> On Mon, Jul 11, 2016 at 7:01 PM, Matthew Woehlke <mwoehlke.floss@gmail.com
> > wrote:
>
>> On 2016-07-10 18:25, Zhihao Yuan wrote:
>> > My suggestion has always been a simple
>> >
>> >   with (auto lk = unique_lock(lk)) {
>> >   }
>> >
>> > which is already available as `if (auto ...; true)`,
>> > and
>> >
>> >   with (lock_guard(lk)) {
>> >   }
>> >
>> > whose the wording for introducing a unique name
>> > has already presented in the structured binding
>> > proposal.
>>
>> Would this be legal?
>>
>>   with (lock_guard(a); lock_guard(b))
>>   { ... }
>>
>> I definitely have cases where I want more than one "guard". I'd prefer
>> to not need to create a scope for each one.
>>
>> --
>> Matthew
>>
>>
>>
> Can someone explain to me what this actually offers over
>
> { std::lock_guard(whatever);
>     // do stuff
> }
>
> because I must be missing something, as right now, it just looks like
> adding a new keyword for no reason whatsoever, and eschewing a perfectly
> valid use of temporary blocks in the process. IOW, completely redundant and
> counterproductive.
>
> so i must've missed an undeniable benefit, right?
>
>
>
sorry, of course I meant to include a variable name in that declaration,
e.g. *a* or

*b*

--
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/CACGiwhHDDQPwcV6K%3DRBv9wGnYzKZaEGc0kNek5oTnZgoDZ-vvA%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Jul 11, 2016 at 7:20 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D=
"mailto:db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><span class=3D"">On Mon, Jul 11, 2016=
 at 7:01 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehl=
ke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 201=
6-07-10 18:25, Zhihao Yuan wrote:<br>
&gt; My suggestion has always been a simple<br>
&gt;<br>
&gt;=C2=A0 =C2=A0with (auto lk =3D unique_lock(lk)) {<br>
&gt;=C2=A0 =C2=A0}<br>
&gt;<br>
&gt; which is already available as `if (auto ...; true)`,<br>
&gt; and<br>
&gt;<br>
&gt;=C2=A0 =C2=A0with (lock_guard(lk)) {<br>
&gt;=C2=A0 =C2=A0}<br>
&gt;<br>
&gt; whose the wording for introducing a unique name<br>
&gt; has already presented in the structured binding<br>
&gt; proposal.<br>
<br>
</span>Would this be legal?<br>
<br>
=C2=A0 with (lock_guard(a); lock_guard(b))<br>
=C2=A0 { ... }<br>
<br>
I definitely have cases where I want more than one &quot;guard&quot;. I&#39=
;d prefer<br>
to not need to create a scope for each one.<br>
<br>
--<br>
Matthew<br>
<span><br><br></span></blockquote></span><div><br>Can someone explain to me=
 what this actually offers over<br><br></div><div>{ std::lock_guard(whateve=
r);<br></div><div>=C2=A0 =C2=A0 // do stuff<br>}<br><br></div><div>because =
I must be missing something, as right now, it just looks like adding a new =
keyword for no reason whatsoever, and eschewing a perfectly valid use of te=
mporary blocks in the process. IOW, completely redundant and counterproduct=
ive.<br><br></div><div>so i must&#39;ve missed an undeniable benefit, right=
?<br>=C2=A0<br></div></div><br></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">sorry, of course I =
meant to include a variable name in that declaration, e.g. <b>a</b> or <b>b=
<br><br></b><b><br></b></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/CACGiwhHDDQPwcV6K%3DRBv9wGnYzKZaEGc0k=
Nek5oTnZgoDZ-vvA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHDDQPwcV=
6K%3DRBv9wGnYzKZaEGc0kNek5oTnZgoDZ-vvA%40mail.gmail.com</a>.<br />

--94eb2c0d438e0dff3b053760396b--

.

------=_Part_627_1567973889.1468261918426
Content-Type: multipart/alternative;
 boundary="----=_Part_628_1235092622.1468261918426"

------=_Part_628_1235092622.1468261918426
Content-Type: text/plain; charset=UTF-8


>
> Can someone explain to me what this actually offers over
>>
>> { std::lock_guard(whatever);
>>     // do stuff
>> }
>>
>> because I must be missing something, as right now, it just looks like
>> adding a new keyword for no reason whatsoever, and eschewing a perfectly
>> valid use of temporary blocks in the process. IOW, completely redundant and
>> counterproductive.
>>
>> so i must've missed an undeniable benefit, right?
>>
>>
>>
> sorry, of course I meant to include a variable name in that declaration,
> e.g. *a* or *b*
>

Or even writing a function template that does the same thing as "with"
would?

template <class M, class F>
void with_lock(M& mtx, F f ) {
    std::lock_guard _(mtx);
    f();
}

with_lock(mtx, [&]{
    // stuff locked 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/c1e2213b-8d6e-4100-84d3-7a34da3aab03%40isocpp.org.

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"><div>Can someone explain to me what this actually o=
ffers over<br><br></div><div>{ std::lock_guard(whatever);<br></div><div>=C2=
=A0 =C2=A0 // do stuff<br>}<br><br></div><div>because I must be missing som=
ething, as right now, it just looks like adding a new keyword for no reason=
 whatsoever, and eschewing a perfectly valid use of temporary blocks in the=
 process. IOW, completely redundant and counterproductive.<br><br></div><di=
v>so i must&#39;ve missed an undeniable benefit, right?<br>=C2=A0<br></div>=
</div><br></div></div>
</blockquote></div><br></div><div>sorry, of course I meant to include a var=
iable name in that declaration, e.g. <b>a</b> or <b>b</b></div></div></bloc=
kquote><div><br></div><div>Or even writing a function template that does th=
e same thing as &quot;with&quot; would?</div><div><br></div><div><div class=
=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: =
break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">template</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> M</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> F</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> with_lock</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">M</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mtx</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><font co=
lor=3D"#000000"><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
F f </span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">lock_guard _</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">mtx</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 f</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br><br>with_lock</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">mtx</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">[&amp;]{</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// stuff =
locked here...</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">})=
;</span></font></div></code></div><br>=C2=A0<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/c1e2213b-8d6e-4100-84d3-7a34da3aab03%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c1e2213b-8d6e-4100-84d3-7a34da3aab03=
%40isocpp.org</a>.<br />

------=_Part_628_1235092622.1468261918426--

------=_Part_627_1567973889.1468261918426--

.

On Mon, Jul 11, 2016 at 1:01 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
>
> Would this be legal?
>
>   with (lock_guard(a); lock_guard(b))
>   { ... }

Very likely.  But the whole suggestion depends
on whether people can live with one extra
nested scope.

--
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/CAGsORuB1ckoqwQCXBay%2BPdYwmn8axLLh9jou2mz1CeYgR3%2BFrw%40mail.gmail.com.

.

On segunda-feira, 11 de julho de 2016 12:16:56 PDT Francisco Lopes wrote:
> As Nevin noted, `__` is reserved for *implementations*. In theory at
>
> > least, there might be an implementation actually *using* `__` that would
> > be broken if `__` were used for unnamed locals.

In practice, there is.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/2636657.qI9n2J6g8B%40tjmaciei-mobl1.

.

On Mon, Jul 11, 2016 at 2:30 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
>
>>>   with (lock_guard(a); lock_guard(b))
>>>   { ... }
>>
>> Very likely.  But the whole suggestion depends
>> on whether people can live with one extra
>> nested scope.
>
> Are you proposing `with` as a proper language extension, or as a macro
> implemented with `if(expr; true)`? If the latter, is `if(expr; expr;
> ...; condition)` legal? (I guess it would be nice if it is, but I
> haven't read the proposal or followed up on it to know offhand...)

I'm not proposal anything at this point, just looking for...
standpoints?
`if(expression-statement; true)` still discard;
`if(simple-declaration; true)` doesn't, which can be used in
place of `with (auto x = ...)`.

--
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/CAGsORuC0k170G9hjxNFRu0RQOwJTvCBZtqO-k%3DUVFzNj6qZMoA%40mail.gmail.com.

.

------=_Part_6620_108786240.1507587085096
Content-Type: multipart/alternative;
 boundary="----=_Part_6621_2046915466.1507587085096"

------=_Part_6621_2046915466.1507587085096
Content-Type: text/plain; charset="UTF-8"

I was going to propose a similar feature as described in this thread,
fortunately, someone on slack mention this discussion thread, so I'll just
post this here:

https://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md

I'm arguing for an unnamed variable also, but from a 'prevent using macros'
perspective. Also it might have applications in TMP to introduce unnamed
members into a class, by passing a reference from the unnamed variable's
constructor into an outer scope.

I'm going to add a concrete example usecase to the document, but I'd like
to get feedback on it so far...

Greetings,

Jan

--
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/441bbb02-4ba2-4329-a1d8-3b5d5a4c5f2b%40isocpp.org.

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

<div dir=3D"ltr"><div>I was going to propose a similar feature as described=
 in this thread, fortunately, someone on slack mention this discussion thre=
ad, so I&#39;ll just post this here:=C2=A0</div><div><br></div>https://gith=
ub.com/janwilmans/janwilmans.github.io/blob/master/auto.md<div><br></div><d=
iv>I&#39;m arguing for an unnamed variable also, but from a &#39;prevent us=
ing macros&#39; perspective. Also it might have applications in TMP to intr=
oduce unnamed members into a class, by passing a reference from=C2=A0the un=
named variable&#39;s constructor into an outer scope.</div><div><br></div><=
div>I&#39;m going to add a concrete example usecase to the document, but I&=
#39;d like to get feedback on it so far...</div><div><br></div><div>Greetin=
gs,</div><div><br></div><div>Jan</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/441bbb02-4ba2-4329-a1d8-3b5d5a4c5f2b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/441bbb02-4ba2-4329-a1d8-3b5d5a4c5f2b=
%40isocpp.org</a>.<br />

------=_Part_6621_2046915466.1507587085096--

------=_Part_6620_108786240.1507587085096--

.

------=_Part_2308_2027205283.1507675120346
Content-Type: multipart/alternative;
 boundary="----=_Part_2309_97915432.1507675120346"

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

On Monday, October 9, 2017 at 3:11:25 PM UTC-7, janwi...@gmail.com wrote:
>
> I was going to propose a similar feature as described in this thread,=20
> fortunately, someone on slack mention this discussion thread, so I'll jus=
t=20
> post this here:=20
>
> https://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md
> [...]
> I'm going to add a concrete example usecase to the document, but I'd like=
=20
> to get feedback on it so far...
>

Seems plausible to me. Certainly omitting the variable name is more=20
"C++ish" than the perennial proposal to make the variable name `_` magic.
However, I see a very obvious pitfall in your choice of examples. Today we=
=20
have a major pitfall with people accidentally omitting the name of the=20
lock_guard variable. With your proposed syntax, *in codebases that use=20
scope guards with arbitrary lambdas*, we'll see people accidentally=20
omitting the make_guard keyword itself.

auto =3D make_guard([]{ end_of_scope_action(); });

auto =3D []{ end_of_scope_action(); };=20


The former is what you want your codebase to look like.
The latter is what your new hires will write, at least once a month, until=
=20
you train your linter to detect the problem automatically.
This is why it's so nice to use a macro to hide *all* the boilerplate,=20
instead of leaving any boilerplate in the C++ code.
This is why I prefer to write:=20
<http://www.club.cc.cmu.edu/~ajo/disseminate/auto.h>

Auto( end_of_scope_action(); );=20


Of course scope-guards are not the only use for anonymous variables. And=20
many smart C++ programmers will tell you loudly that scope-guards are a=20
Very Bad Pattern and shouldn't be used as justification for anything! But=
=20
if you're proposing that anonymous variables should be involved in the=20
best-practice way to declare scope-guards, I'd have to disagree: I see only=
=20
a source of bugs there.

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Monday, October 9, 2017 at 3:11:25 PM UTC-7, janwi...@g=
mail.com 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=
"><div>I was going to propose a similar feature as described in this thread=
, fortunately, someone on slack mention this discussion thread, so I&#39;ll=
 just post this here:=C2=A0</div><div><br></div><a href=3D"https://github.c=
om/janwilmans/janwilmans.github.io/blob/master/auto.md" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?=
q\x3dhttps%3A%2F%2Fgithub.com%2Fjanwilmans%2Fjanwilmans.github.io%2Fblob%2F=
master%2Fauto.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8u5Vu53M0-hUwE7xa=
Gzq-9sNBUw&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.googl=
e.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjanwilmans%2Fjanwilmans.github.io=
%2Fblob%2Fmaster%2Fauto.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8u5Vu53=
M0-hUwE7xaGzq-9sNBUw&#39;;return true;">https://github.com/janwilmans/<wbr>=
janwilmans.github.io/blob/<wbr>master/auto.md</a><div>[...]</div><div>I&#39=
;m going to add a concrete example usecase to the document, but I&#39;d lik=
e to get feedback on it so far...<br></div></div></blockquote><div><br></di=
v><div>Seems plausible to me. Certainly omitting the variable name is more =
&quot;C++ish&quot; than the perennial proposal to make the variable name `_=
` magic.</div><div>However, I see a very obvious pitfall in your choice of =
examples. Today we have a major pitfall with people accidentally omitting t=
he name of the lock_guard variable. With your proposed syntax, <i><b>in cod=
ebases that use scope guards with arbitrary lambdas</b></i>, we&#39;ll see =
people accidentally omitting the make_guard keyword itself.</div><div><br><=
/div><div><pre style=3D"box-sizing: border-box; font-family: SFMono-Regular=
, Consolas, &#39;Liberation Mono&#39;, Menlo, Courier, monospace; font-size=
: 14px; word-wrap: normal; padding: 16px; overflow: auto; line-height: 1.45=
; background-color: rgb(246, 248, 250); border-top-left-radius: 3px; border=
-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left=
-radius: 3px; word-break: normal; color: rgb(36, 41, 46);"><span class=3D"p=
l-k" style=3D"box-sizing: border-box; color: rgb(215, 58, 73);">auto</span>=
 =3D <span class=3D"pl-c1" style=3D"box-sizing: border-box; color: rgb(0, 9=
2, 197);">make_guard</span>([]{ <span class=3D"pl-c1" style=3D"box-sizing: =
border-box; color: rgb(0, 92, 197);">end_of_scope_action</span>(); });</pre=
><pre style=3D"box-sizing: border-box; font-family: SFMono-Regular, Consola=
s, &#39;Liberation Mono&#39;, Menlo, Courier, monospace; font-size: 14px; w=
ord-wrap: normal; padding: 16px; overflow: auto; line-height: 1.45; backgro=
und-color: rgb(246, 248, 250); border-top-left-radius: 3px; border-top-righ=
t-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: =
3px; word-break: normal; color: rgb(36, 41, 46);"><span class=3D"pl-k" styl=
e=3D"box-sizing: border-box; color: rgb(215, 58, 73);">auto</span> =3D []{ =
<span class=3D"pl-c1" style=3D"box-sizing: border-box; color: rgb(0, 92, 19=
7);">end_of_scope_action</span>(); }; </pre></div><div><br></div><div>The f=
ormer is what you want your codebase to look like.</div><div>The latter is =
what your new hires will write, at least once a month, until you train your=
 linter to detect the problem automatically.</div><div>This is why it&#39;s=
 so nice to use a macro to hide <i><b>all</b></i> the boilerplate, instead =
of leaving any boilerplate in the C++ code.</div><div>This is why=C2=A0<a h=
ref=3D"http://www.club.cc.cmu.edu/~ajo/disseminate/auto.h">I prefer to writ=
e:</a></div><div><br></div><div><pre style=3D"padding: 16px; box-sizing: bo=
rder-box; font-family: SFMono-Regular, Consolas, &#39;Liberation Mono&#39;,=
 Menlo, Courier, monospace; font-size: 14px; word-wrap: normal; overflow: a=
uto; line-height: 1.45; background-color: rgb(246, 248, 250); border-top-le=
ft-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3=
px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(36, 41, =
46);"><span class=3D"pl-k" style=3D"box-sizing: border-box; color: rgb(215,=
 58, 73);">Auto</span>( <span class=3D"pl-c1" style=3D"box-sizing: border-b=
ox; color: rgb(0, 92, 197);">end_of_scope_action</span>(); ); </pre></div><=
div><br></div><div>Of course scope-guards are not the only use for anonymou=
s variables. And many smart C++ programmers will tell you loudly that scope=
-guards are a Very Bad Pattern and shouldn&#39;t be used as justification f=
or anything! But if you&#39;re proposing that anonymous variables should be=
 involved in the best-practice way to declare scope-guards, I&#39;d have to=
 disagree: I see only a source of bugs there.</div><div><br></div><div>=E2=
=80=93Arthur</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/ada9be6d-f9df-49ce-8fe8-641b049c874f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ada9be6d-f9df-49ce-8fe8-641b049c874f=
%40isocpp.org</a>.<br />

------=_Part_2309_97915432.1507675120346--

------=_Part_2308_2027205283.1507675120346--

.

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

The feedback is highly appreciated! I can see the syntax as proposed with
give room for a new class of errors, I had not considered that :)

Well, my main motivation for the introduction of an unnamed variable would
be to prevent the need to rely on non-standard macro extensions to provide
unique names for RAII objects in a local scope
Although the example speaks of a guard, its really just an example...

The logfuction is maybe a better example, although, in that case I would
rely on a __FILE__ macro, so its also not such a convincing example.

Greetings,

Jan

On 11 October 2017 at 00:38, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Monday, October 9, 2017 at 3:11:25 PM UTC-7, janwi...@gmail.com wrote:
>>
>> I was going to propose a similar feature as described in this thread,
>> fortunately, someone on slack mention this discussion thread, so I'll ju=
st
>> post this here:
>>
>> https://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md
>> [...]
>> I'm going to add a concrete example usecase to the document, but I'd lik=
e
>> to get feedback on it so far...
>>
>
> Seems plausible to me. Certainly omitting the variable name is more
> "C++ish" than the perennial proposal to make the variable name `_` magic.
> However, I see a very obvious pitfall in your choice of examples. Today w=
e
> have a major pitfall with people accidentally omitting the name of the
> lock_guard variable. With your proposed syntax, *in codebases that use
> scope guards with arbitrary lambdas*, we'll see people accidentally
> omitting the make_guard keyword itself.
>
> auto =3D make_guard([]{ end_of_scope_action(); });
>
> auto =3D []{ end_of_scope_action(); };
>
>
> The former is what you want your codebase to look like.
> The latter is what your new hires will write, at least once a month, unti=
l
> you train your linter to detect the problem automatically.
> This is why it's so nice to use a macro to hide *all* the boilerplate,
> instead of leaving any boilerplate in the C++ code.
> This is why I prefer to write:
> <http://www.club.cc.cmu.edu/~ajo/disseminate/auto.h>
>
> Auto( end_of_scope_action(); );
>
>
> Of course scope-guards are not the only use for anonymous variables. And
> many smart C++ programmers will tell you loudly that scope-guards are a
> Very Bad Pattern and shouldn't be used as justification for anything! But
> if you're proposing that anonymous variables should be involved in the
> best-practice way to declare scope-guards, I'd have to disagree: I see on=
ly
> a source of bugs there.
>
> =E2=80=93Arthur
>
> --
> 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/ada9be6d-f9df-49ce-
> 8fe8-641b049c874f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ada9be6d-f9=
df-49ce-8fe8-641b049c874f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>



--=20
Met vriendelijke groeten,

Jan Wilmans

--=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/CADtNNhj0zDCXqu65E4rdevp8cCsSAPuPYKQOGNEDjVxigzH=
xnA%40mail.gmail.com.

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

<div dir=3D"ltr"><div>The feedback is highly appreciated! I can see the syn=
tax as proposed with give room for a new class of errors, I had not conside=
red that :)</div><div><br></div>Well, my main motivation for the introducti=
on of an unnamed variable would be to prevent the need to rely on non-stand=
ard macro extensions to provide unique names for RAII objects in a local sc=
ope<div>Although the example speaks of a guard, its really just an example.=
...</div><div><br></div><div>The logfuction is maybe a better example, altho=
ugh, in that case I would rely on a __FILE__ macro, so its also not such a =
convincing example.</div><div><br></div><div>Greetings,<br></div><div><br><=
/div><div>Jan</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On 11 October 2017 at 00:38, Arthur O&#39;Dwyer <span dir=3D"ltr">&=
lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.=
odwyer@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><span class=3D"">On Monday, October 9, 2017 at 3:11:25 PM UT=
C-7, <a href=3D"mailto:janwi...@gmail.com" target=3D"_blank">janwi...@gmail=
..com</a> wrote:</span><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><span class=3D""><div>I was going to propose a similar feature as descr=
ibed in this thread, fortunately, someone on slack mention this discussion =
thread, so I&#39;ll just post this here:=C2=A0</div><div><br></div><a href=
=3D"https://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md"=
 rel=3D"nofollow" target=3D"_blank">https://github.com/janwilmans/<wbr>janw=
ilmans.github.io/blob/mast<wbr>er/auto.md</a></span><div>[...]</div><span c=
lass=3D""><div>I&#39;m going to add a concrete example usecase to the docum=
ent, but I&#39;d like to get feedback on it so far...<br></div></span></div=
></blockquote><div><br></div><div>Seems plausible to me. Certainly omitting=
 the variable name is more &quot;C++ish&quot; than the perennial proposal t=
o make the variable name `_` magic.</div><div>However, I see a very obvious=
 pitfall in your choice of examples. Today we have a major pitfall with peo=
ple accidentally omitting the name of the lock_guard variable. With your pr=
oposed syntax, <i><b>in codebases that use scope guards with arbitrary lamb=
das</b></i>, we&#39;ll see people accidentally omitting the make_guard keyw=
ord itself.</div><div><br></div><div><pre style=3D"box-sizing:border-box;fo=
nt-family:SFMono-Regular,Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,m=
onospace;font-size:14px;word-wrap:normal;padding:16px;overflow:auto;line-he=
ight:1.45;background-color:rgb(246,248,250);border-top-left-radius:3px;bord=
er-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-r=
adius:3px;word-break:normal;color:rgb(36,41,46)"><span class=3D"m_502801165=
2831329779pl-k" style=3D"box-sizing:border-box;color:rgb(215,58,73)">auto</=
span> =3D <span class=3D"m_5028011652831329779pl-c1" style=3D"box-sizing:bo=
rder-box;color:rgb(0,92,197)">make_guard</span>([]{ <span class=3D"m_502801=
1652831329779pl-c1" style=3D"box-sizing:border-box;color:rgb(0,92,197)">end=
_of_scope_action</span>(); });</pre><pre style=3D"box-sizing:border-box;fon=
t-family:SFMono-Regular,Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,mo=
nospace;font-size:14px;word-wrap:normal;padding:16px;overflow:auto;line-hei=
ght:1.45;background-color:rgb(246,248,250);border-top-left-radius:3px;borde=
r-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-ra=
dius:3px;word-break:normal;color:rgb(36,41,46)"><span class=3D"m_5028011652=
831329779pl-k" style=3D"box-sizing:border-box;color:rgb(215,58,73)">auto</s=
pan> =3D []{ <span class=3D"m_5028011652831329779pl-c1" style=3D"box-sizing=
:border-box;color:rgb(0,92,197)">end_of_scope_action</span>(); }; </pre></d=
iv><div><br></div><div>The former is what you want your codebase to look li=
ke.</div><div>The latter is what your new hires will write, at least once a=
 month, until you train your linter to detect the problem automatically.</d=
iv><div>This is why it&#39;s so nice to use a macro to hide <i><b>all</b></=
i> the boilerplate, instead of leaving any boilerplate in the C++ code.</di=
v><div>This is why=C2=A0<a href=3D"http://www.club.cc.cmu.edu/~ajo/dissemin=
ate/auto.h" target=3D"_blank">I prefer to write:</a></div><div><br></div><d=
iv><pre style=3D"padding:16px;box-sizing:border-box;font-family:SFMono-Regu=
lar,Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;font-size:14=
px;word-wrap:normal;overflow:auto;line-height:1.45;background-color:rgb(246=
,248,250);border-top-left-radius:3px;border-top-right-radius:3px;border-bot=
tom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal;color:=
rgb(36,41,46)"><span class=3D"m_5028011652831329779pl-k" style=3D"box-sizin=
g:border-box;color:rgb(215,58,73)">Auto</span>( <span class=3D"m_5028011652=
831329779pl-c1" style=3D"box-sizing:border-box;color:rgb(0,92,197)">end_of_=
scope_action</span>(); ); </pre></div><div><br></div><div>Of course scope-g=
uards are not the only use for anonymous variables. And many smart C++ prog=
rammers will tell you loudly that scope-guards are a Very Bad Pattern and s=
houldn&#39;t be used as justification for anything! But if you&#39;re propo=
sing that anonymous variables should be involved in the best-practice way t=
o declare scope-guards, I&#39;d have to disagree: I see only a source of bu=
gs there.</div><div><br></div><div>=E2=80=93Arthur</div></div><span class=
=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ada9be6d-f9df-49ce-8fe8-641b049c874f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/ada9=
be6d-f9df-49ce-<wbr>8fe8-641b049c874f%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Met vriendelijke gr=
oeten,<br><br>Jan Wilmans<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/CADtNNhj0zDCXqu65E4rdevp8cCsSAPuPYKQO=
GNEDjVxigzHxnA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADtNNhj0zDCXqu65=
E4rdevp8cCsSAPuPYKQOGNEDjVxigzHxnA%40mail.gmail.com</a>.<br />

--f403045d99a0cc2b03055b418a60--

.

------=_Part_11728_850541997.1507838689797
Content-Type: multipart/alternative;
 boundary="----=_Part_11729_895108889.1507838689797"

------=_Part_11729_895108889.1507838689797
Content-Type: text/plain; charset="UTF-8"


>
> Update:
>

I have found multiple earlier discussions, references:
[2012] https://cplusplus.github.io/EWG/ewg-active.html#35

auto [] = make_guard([]{ end_of_scope_action(); });


Seems to be a better, less error-prone alternative syntax (an empty
structured binding).
I've
updated https://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md
with the appropriate attributions and references




--
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/aee7602d-134a-4768-8a62-be47cdb50e98%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div>Upd=
ate:</div></div></blockquote><div><br></div><div>I have found multiple earl=
ier discussions, references:</div><div>[2012]=C2=A0https://cplusplus.github=
..io/EWG/ewg-active.html#35</div><div><br></div><div><pre style=3D"padding: =
16px; font-family: SFMono-Regular, Consolas, &quot;Liberation Mono&quot;, M=
enlo, Courier, monospace; font-size: 14px; word-wrap: normal; overflow: aut=
o; line-height: 1.45; background-color: rgb(246, 248, 250); border-radius: =
3px; word-break: normal; color: rgb(36, 41, 46);"><span style=3D"color: rgb=
(215, 58, 73);">auto</span> [] =3D <span style=3D"color: rgb(0, 92, 197);">=
make_guard</span>([]{ <span style=3D"color: rgb(0, 92, 197);">end_of_scope_=
action</span>(); });</pre></div><div><br></div><div>Seems to be a better, l=
ess error-prone alternative syntax (an empty structured binding).</div><div=
>I&#39;ve updated=C2=A0https://github.com/janwilmans/janwilmans.github.io/b=
lob/master/auto.md with the appropriate attributions and references</div><d=
iv><br></div><div><br></div><div>=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/aee7602d-134a-4768-8a62-be47cdb50e98%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aee7602d-134a-4768-8a62-be47cdb50e98=
%40isocpp.org</a>.<br />

------=_Part_11729_895108889.1507838689797--

------=_Part_11728_850541997.1507838689797--

.

------=_Part_3071_2025968095.1509683519968
Content-Type: multipart/alternative;
 boundary="----=_Part_3072_705171617.1509683519968"

------=_Part_3072_705171617.1509683519968
Content-Type: text/plain; charset="UTF-8"

This might be slightly late but as I see it there are two options here.  I
will try and list both below.

The first option is what is currently accepted
auto [] = make_guard([]{ ... });

This has the advantage of being consistent with what structured bindings
do, they declare a hidden variable that cannot be referenced and used
within user code.  In this case the structured bindings are not even being
decomposed into anything so this approach seems natural.  A hidden variable
is declared behind the scenes and will be destroyed when the scope exists.

The second option that I have in mind is
auto {} = make_guard([]{ ... });

This is not consistent with structured bindings.  However this slightly
matches with the list initialization as it stands currently in C++14, a {}
denotes a default construction for a class type, and can be used to
initialize an object.  vec.push_back({}); is pretty cool.  The {} syntax
seems to naturally scream unnamed object.  Especially given how prevalent
JSON has become these days (although that is completely not directly
relevant to c++)

This however has the advantage of also working in the following context
auto [{}, another] = make_pair(...);

Where the {} denotes an anonymous unnamed reference.  Which can be
consistent with the other case.

The consistent use of {} to denote an unused object seems like an
attractive idea.  It however leaves some ambiguity with respect to what the
semantics of {} are.  The best way to approach this would be to make {} an
unused anonymous identifier.  With the type of {} being whatever preceeds
it, for example
auto&& {} = make_guard(...);

Here {} would be a rvalue reference with its lifetime being extended to
match the object returned by make_guard(...).  Same with the following case
auto [{}, another] = make_pair(...);

Here {} is a reference type, with the referenced type being std::tuple_element<0,
std::decay_t<decltype(make_pair(...))>>

The current alternative however, does not seem to naturally work within
structured bindings themselves
auto [[], another] = make_pair(...);

The semantics of this are not very clear, the [] denotes a structured
binding.  But what is the type of the binding within the binding?  It does
not seem to have am auto type specifier before it, so will it be a
reference or what exactly?  The {} case feels slightly more natural here.

Trying to solve multiple (related but not really) problems at once.  Just
another thought about the matter!


On Thursday, 12 October 2017 13:04:49 UTC-7, janwi...@gmail.com wrote:
>
> Update:
>>
>
> I have found multiple earlier discussions, references:
> [2012] https://cplusplus.github.io/EWG/ewg-active.html#35
>
> auto [] = make_guard([]{ end_of_scope_action(); });
>
>
> Seems to be a better, less error-prone alternative syntax (an empty
> structured binding).
> I've updated
> https://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md
> with the appropriate attributions and references
>
>
>
>

--
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/524d492d-ae6d-4829-8bfa-598fb4e1c082%40isocpp.org.

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

<div dir=3D"ltr">This might be slightly late but as I see it there are two =
options here. =C2=A0I will try and list both below.<div><br></div><div>The =
first option is what is currently accepted</div><div><div class=3D"prettypr=
int" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(1=
87, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">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 styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> make_guard</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">([]{</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">});</span></div></code></div><div><br></div>This has the advanta=
ge of being consistent with what structured bindings do, they declare a hid=
den variable that cannot be referenced and used within user code. =C2=A0In =
this case the structured bindings are not even being decomposed into anythi=
ng so this approach seems natural. =C2=A0A hidden variable is declared behi=
nd the scenes and will be destroyed when the scope exists. =C2=A0</div><div=
><br></div><div>The second option that I have in mind is=C2=A0</div><div><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"s=
tyled-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</sp=
an><font color=3D"#000000"><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> make_guard</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">([]{</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">});</span></font></d=
iv></code></div><div><br></div>This is not consistent with structured bindi=
ngs. =C2=A0However this slightly matches with the list initialization as it=
 stands currently in C++14, a {} denotes a default construction for a class=
 type, and can be used to initialize an object. =C2=A0<font face=3D"courier=
 new, monospace">vec.push_back({});</font>=C2=A0is pretty cool. =C2=A0The <=
font face=3D"courier new, monospace">{}</font> syntax seems to naturally sc=
ream unnamed object. =C2=A0Especially given how prevalent JSON has become t=
hese days (although that is completely not directly relevant to c++)<br><br=
>This however has the advantage of also working in the following context</d=
iv><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span 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"> another</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">]</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> make_pair</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(...);</span>=
<font color=3D"#000000"></font></div></code></div><br>Where the <font face=
=3D"courier new, monospace">{}</font> denotes an anonymous unnamed referenc=
e. =C2=A0Which can be consistent with the other case. =C2=A0</div><div><br>=
</div><div>The consistent use of <font face=3D"courier new, monospace">{}</=
font> to denote an unused object seems like an attractive idea. =C2=A0It ho=
wever leaves some ambiguity with respect to what the semantics of <font fac=
e=3D"courier new, monospace">{}</font> are. =C2=A0The best way to approach =
this would be to make <font face=3D"courier new, monospace">{}</font> an un=
used anonymous identifier. =C2=A0With the type of <font face=3D"courier new=
, monospace">{}</font> being whatever preceeds it, for example</div><div><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-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</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> make_guard</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(...);</span>=
</div></code></div><div><br></div><div>Here <font face=3D"courier new, mono=
space">{}</font> would be a rvalue reference with its lifetime being extend=
ed to match the object returned by <font face=3D"courier new, monospace">ma=
ke_guard(...)</font>. =C2=A0Same with the following case</div><div><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border: 1=
px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">[{},</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a=
nothe</span><font color=3D"#666600"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">r</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</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> make_pair</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(...);</span></=
font></div></code></div><div><br></div>Here <font face=3D"courier new, mono=
space">{}</font> is a reference type, with the referenced type being <font =
face=3D"courier new, monospace">std::tuple_element&lt;0, std::decay_t&lt;de=
cltype(make_pair(...))&gt;&gt;</font>=C2=A0</div></div><div><div><br></div>=
<div>The current alternative however, does not seem to naturally work withi=
n structured bindings themselves</div><div><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 1=
87); word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">[[],</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> another</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><font color=3D"#000000"><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> make_pair</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(...);</span></font></div></=
code></div><br>The semantics of this are not very clear, the <font face=3D"=
courier new, monospace">[]</font> denotes a structured binding. =C2=A0But w=
hat is the type of the binding within the binding? =C2=A0It does not seem t=
o have am auto type specifier before it, so will it be a reference or what =
exactly? =C2=A0The <font face=3D"courier new, monospace">{}</font> case fee=
ls slightly more natural here.=C2=A0</div><div><br></div><div>Trying to sol=
ve multiple (related but not really) problems at once. =C2=A0Just another t=
hought about the matter! =C2=A0</div><div><br></div><div><br></div><div>On =
Thursday, 12 October 2017 13:04:49 UTC-7, janwi...@gmail.com  wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div><div>Update:</div></div></blockquote><div><br></di=
v><div>I have found multiple earlier discussions, references:</div><div>[20=
12]=C2=A0<a href=3D"https://cplusplus.github.io/EWG/ewg-active.html#35" tar=
get=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www=
..google.com/url?q\x3dhttps%3A%2F%2Fcplusplus.github.io%2FEWG%2Fewg-active.h=
tml%2335\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEVcyzwXESmmKmnu7PEiQjK0qkf=
PQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/ur=
l?q\x3dhttps%3A%2F%2Fcplusplus.github.io%2FEWG%2Fewg-active.html%2335\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEVcyzwXESmmKmnu7PEiQjK0qkfPQ&#39;;return=
 true;">https://cplusplus.<wbr>github.io/EWG/ewg-active.html#<wbr>35</a></d=
iv><div><br></div><div><pre style=3D"padding:16px;font-family:SFMono-Regula=
r,Consolas,&quot;Liberation Mono&quot;,Menlo,Courier,monospace;font-size:14=
px;word-wrap:normal;overflow:auto;line-height:1.45;background-color:rgb(246=
,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)"><span st=
yle=3D"color:rgb(215,58,73)">auto</span> [] =3D <span style=3D"color:rgb(0,=
92,197)">make_guard</span>([]{ <span style=3D"color:rgb(0,92,197)">end_of_s=
cope_action</span>(); });</pre></div><div><br></div><div>Seems to be a bett=
er, less error-prone alternative syntax (an empty structured binding).</div=
><div>I&#39;ve updated=C2=A0<a href=3D"https://github.com/janwilmans/janwil=
mans.github.io/blob/master/auto.md" target=3D"_blank" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fg=
ithub.com%2Fjanwilmans%2Fjanwilmans.github.io%2Fblob%2Fmaster%2Fauto.md\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8u5Vu53M0-hUwE7xaGzq-9sNBUw&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps=
%3A%2F%2Fgithub.com%2Fjanwilmans%2Fjanwilmans.github.io%2Fblob%2Fmaster%2Fa=
uto.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8u5Vu53M0-hUwE7xaGzq-9sNBUw=
&#39;;return true;">https://github.com/<wbr>janwilmans/janwilmans.github.<w=
br>io/blob/master/auto.md</a> with the appropriate attributions and referen=
ces</div><div><br></div><div><br></div><div>=C2=A0</div></div></blockquote>=
</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/524d492d-ae6d-4829-8bfa-598fb4e1c082%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/524d492d-ae6d-4829-8bfa-598fb4e1c082=
%40isocpp.org</a>.<br />

------=_Part_3072_705171617.1509683519968--

------=_Part_3071_2025968095.1509683519968--

.

------=_Part_11282_292962994.1519550314422
Content-Type: multipart/alternative;
 boundary="----=_Part_11283_568706033.1519550314422"

------=_Part_11283_568706033.1519550314422
Content-Type: text/plain; charset="UTF-8"

I'm not sure why I missed this reply, I'm just seeing it now. This more
food for thought, thank you.
In the mean time I realized, that while this is a personal annoyance, it
will never be on the top 20 things that C++ needs the most.

It does not enable new expressiveness, at best in cleans up the syntax a
little, but if this introduces new ambiguities, as Arthur pointed out, I
think this will not be worth it.
I will update the page for future reference, but other than that, I'm not
pursuing this any further.

On Friday, November 3, 2017 at 5:32:00 AM UTC+1, Aaryaman Sagar wrote:
>
> This might be slightly late but as I see it there are two options here.  I
> will try and list both below.
>
> The first option is what is currently accepted
> auto [] = make_guard([]{ ... });
>
> This has the advantage of being consistent with what structured bindings
> do, they declare a hidden variable that cannot be referenced and used
> within user code.  In this case the structured bindings are not even being
> decomposed into anything so this approach seems natural.  A hidden variable
> is declared behind the scenes and will be destroyed when the scope exists.
>
> The second option that I have in mind is
> auto {} = make_guard([]{ ... });
>
> This is not consistent with structured bindings.  However this slightly
> matches with the list initialization as it stands currently in C++14, a {}
> denotes a default construction for a class type, and can be used to
> initialize an object.  vec.push_back({}); is pretty cool.  The {} syntax
> seems to naturally scream unnamed object.  Especially given how prevalent
> JSON has become these days (although that is completely not directly
> relevant to c++)
>
> This however has the advantage of also working in the following context
> auto [{}, another] = make_pair(...);
>
> Where the {} denotes an anonymous unnamed reference.  Which can be
> consistent with the other case.
>
> The consistent use of {} to denote an unused object seems like an
> attractive idea.  It however leaves some ambiguity with respect to what the
> semantics of {} are.  The best way to approach this would be to make {}
> an unused anonymous identifier.  With the type of {} being whatever
> preceeds it, for example
> auto&& {} = make_guard(...);
>
> Here {} would be a rvalue reference with its lifetime being extended to
> match the object returned by make_guard(...).  Same with the following
> case
> auto [{}, another] = make_pair(...);
>
> Here {} is a reference type, with the referenced type being std::tuple_element<0,
> std::decay_t<decltype(make_pair(...))>>
>
> The current alternative however, does not seem to naturally work within
> structured bindings themselves
> auto [[], another] = make_pair(...);
>
> The semantics of this are not very clear, the [] denotes a structured
> binding.  But what is the type of the binding within the binding?  It does
> not seem to have am auto type specifier before it, so will it be a
> reference or what exactly?  The {} case feels slightly more natural here.
>
> Trying to solve multiple (related but not really) problems at once.  Just
> another thought about the matter!
>
>
> On Thursday, 12 October 2017 13:04:49 UTC-7, janwi...@gmail.com wrote:
>>
>> Update:
>>>
>>
>> I have found multiple earlier discussions, references:
>> [2012] https://cplusplus.github.io/EWG/ewg-active.html#35
>>
>> auto [] = make_guard([]{ end_of_scope_action(); });
>>
>>
>> Seems to be a better, less error-prone alternative syntax (an empty
>> structured binding).
>> I've updated
>> https://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md
>> with the appropriate attributions and references
>>
>>
>>
>>
>

--
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/6c3686ca-beaa-4892-a2cd-fc880d43a51e%40isocpp.org.

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

<div dir=3D"ltr">I&#39;m not sure why I missed this reply, I&#39;m just see=
ing it now. This more food for thought, thank you.=C2=A0<div>In the mean ti=
me I realized, that while this is a personal annoyance, it will never be on=
 the top 20 things that C++ needs the most.</div><div><br></div><div>It doe=
s not enable new expressiveness, at best in cleans up the syntax a little, =
but if this introduces new ambiguities, as Arthur pointed out, I think this=
 will not be worth it.</div><div>I will update the page for future referenc=
e, but other than that, I&#39;m not pursuing this any further.</div><div><d=
iv><br>On Friday, November 3, 2017 at 5:32:00 AM UTC+1, Aaryaman Sagar wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">This might =
be slightly late but as I see it there are two options here. =C2=A0I will t=
ry and list both below.<div><br></div><div>The first option is what is curr=
ently accepted</div><div><div style=3D"background-color:rgb(250,250,250);bo=
rder:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span styl=
e=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">=3D</span><span style=3D"color:#000"> make_guard</span><span st=
yle=3D"color:#660">([]{</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">...</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">});</span></div></code></div><div><br></div>This has the ad=
vantage of being consistent with what structured bindings do, they declare =
a hidden variable that cannot be referenced and used within user code. =C2=
=A0In this case the structured bindings are not even being decomposed into =
anything so this approach seems natural. =C2=A0A hidden variable is declare=
d behind the scenes and will be destroyed when the scope exists. =C2=A0</di=
v><div><br></div><div>The second option that I have in mind is=C2=A0</div><=
div><div style=3D"background-color:rgb(250,250,250);border:1px solid rgb(18=
7,187,187);word-wrap:break-word"><code><div><span style=3D"color:#008">auto=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{}</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span>=
<font color=3D"#000000"><span style=3D"color:#000"> make_guard</span><span =
style=3D"color:#660">([]{</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">...</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">});</span></font></div></code></div><div><br></div>This is =
not consistent with structured bindings. =C2=A0However this slightly matche=
s with the list initialization as it stands currently in C++14, a {} denote=
s a default construction for a class type, and can be used to initialize an=
 object. =C2=A0<font face=3D"courier new, monospace">vec.push_back({});</fo=
nt>=C2=A0is pretty cool. =C2=A0The <font face=3D"courier new, monospace">{}=
</font> syntax seems to naturally scream unnamed object. =C2=A0Especially g=
iven how prevalent JSON has become these days (although that is completely =
not directly relevant to c++)<br><br>This however has the advantage of also=
 working in the following context</div><div><div style=3D"background-color:=
rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><c=
ode><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"> an=
other</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"> mak=
e_pair</span><span style=3D"color:#660">(...);</span><font color=3D"#000000=
"></font></div></code></div><br>Where the <font face=3D"courier new, monosp=
ace">{}</font> denotes an anonymous unnamed reference. =C2=A0Which can be c=
onsistent with the other case. =C2=A0</div><div><br></div><div>The consiste=
nt use of <font face=3D"courier new, monospace">{}</font> to denote an unus=
ed object seems like an attractive idea. =C2=A0It however leaves some ambig=
uity with respect to what the semantics of <font face=3D"courier new, monos=
pace">{}</font> are. =C2=A0The best way to approach this would be to make <=
font face=3D"courier new, monospace">{}</font> an unused anonymous identifi=
er. =C2=A0With the type of <font face=3D"courier new, monospace">{}</font> =
being whatever preceeds it, for example</div><div><div style=3D"background-=
color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-wo=
rd"><code><div><span style=3D"color:#008">auto</span><span style=3D"color:#=
660">&amp;&amp;</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">{}</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">=3D</span><span style=3D"color:#000"> make_guard</span><span style=3D"=
color:#660">(...);</span></div></code></div><div><br></div><div>Here <font =
face=3D"courier new, monospace">{}</font> would be a rvalue reference with =
its lifetime being extended to match the object returned by <font face=3D"c=
ourier new, monospace">make_guard(...)</font>. =C2=A0Same with the followin=
g case</div><div><div style=3D"background-color:rgb(250,250,250);border:1px=
 solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"col=
or:#008">auto</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">[{},</span><span style=3D"color:#000"> anothe</span><font color=3D"#=
666600"><span style=3D"color:#000">r</span><span style=3D"color:#660">]</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span>=
<span style=3D"color:#000"> make_pair</span><span style=3D"color:#660">(...=
);</span></font></div></code></div><div><br></div>Here <font face=3D"courie=
r new, monospace">{}</font> is a reference type, with the referenced type b=
eing <font face=3D"courier new, monospace">std::tuple_element&lt;0, std::de=
cay_t&lt;decltype(make_<wbr>pair(...))&gt;&gt;</font>=C2=A0</div></div><div=
><div><br></div><div>The current alternative however, does not seem to natu=
rally work within structured bindings themselves</div><div><div style=3D"ba=
ckground-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap=
:break-word"><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"> another</span><span style=3D"color:#660">]</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><font color=
=3D"#000000"><span style=3D"color:#000"> make_pair</span><span style=3D"col=
or:#660">(...);</span></font></div></code></div><br>The semantics of this a=
re not very clear, the <font face=3D"courier new, monospace">[]</font> deno=
tes a structured binding. =C2=A0But what is the type of the binding within =
the binding? =C2=A0It does not seem to have am auto type specifier before i=
t, so will it be a reference or what exactly? =C2=A0The <font face=3D"couri=
er new, monospace">{}</font> case feels slightly more natural here.=C2=A0</=
div><div><br></div><div>Trying to solve multiple (related but not really) p=
roblems at once. =C2=A0Just another thought about the matter! =C2=A0</div><=
div><br></div><div><br></div><div>On Thursday, 12 October 2017 13:04:49 UTC=
-7, <a>janwi...@gmail.com</a>  wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Update=
:</div></div></blockquote><div><br></div><div>I have found multiple earlier=
 discussions, references:</div><div>[2012]=C2=A0<a href=3D"https://cplusplu=
s.github.io/EWG/ewg-active.html#35" rel=3D"nofollow" target=3D"_blank" onmo=
usedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fc=
plusplus.github.io%2FEWG%2Fewg-active.html%2335\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNEVcyzwXESmmKmnu7PEiQjK0qkfPQ&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcplusplus.githu=
b.io%2FEWG%2Fewg-active.html%2335\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE=
VcyzwXESmmKmnu7PEiQjK0qkfPQ&#39;;return true;">https://cplusplus.<wbr>githu=
b.io/EWG/ewg-active.html#<wbr>35</a></div><div><br></div><div><pre style=3D=
"padding:16px;font-family:SFMono-Regular,Consolas,&quot;Liberation Mono&quo=
t;,Menlo,Courier,monospace;font-size:14px;word-wrap:normal;overflow:auto;li=
ne-height:1.45;background-color:rgb(246,248,250);border-radius:3px;word-bre=
ak:normal;color:rgb(36,41,46)"><span style=3D"color:rgb(215,58,73)">auto</s=
pan> [] =3D <span style=3D"color:rgb(0,92,197)">make_guard</span>([]{ <span=
 style=3D"color:rgb(0,92,197)">end_of_scope_action</span>(); });</pre></div=
><div><br></div><div>Seems to be a better, less error-prone alternative syn=
tax (an empty structured binding).</div><div>I&#39;ve updated=C2=A0<a href=
=3D"https://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md"=
 rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https:/=
/www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjanwilmans%2Fjanwilmans=
..github.io%2Fblob%2Fmaster%2Fauto.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNE8u5Vu53M0-hUwE7xaGzq-9sNBUw&#39;;return true;" onclick=3D"this.href=3D&#=
39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjanwilmans%2F=
janwilmans.github.io%2Fblob%2Fmaster%2Fauto.md\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNE8u5Vu53M0-hUwE7xaGzq-9sNBUw&#39;;return true;">https://github.=
com/<wbr>janwilmans/janwilmans.github.<wbr>io/blob/master/auto.md</a> with =
the appropriate attributions and references</div><div><br></div><div><br></=
div><div>=C2=A0</div></div></blockquote></div></div></div></blockquote></di=
v></div></div>

<p></p>

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

------=_Part_11283_568706033.1519550314422--

------=_Part_11282_292962994.1519550314422--

.