------=_Part_1549_1072152368.1455912304546
Content-Type: multipart/alternative;
 boundary="----=_Part_1550_1070216524.1455912304547"

------=_Part_1550_1070216524.1455912304547
Content-Type: text/plain; charset=UTF-8

Hi!

Does anyone see helpfulness of such solution:

for(auto _ : {1, 2, 3})
{
}

Variable with name "_" has an implicit unused attribute set.


--

Dmitry Banschikov

--

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

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

<div dir=3D"ltr"><div><span style=3D"font-family: arial, sans-serif; font-s=
ize: small;">Hi!</span><br style=3D"font-family: arial, sans-serif; font-si=
ze: small;"><br style=3D"font-family: arial, sans-serif; font-size: small;"=
><span style=3D"font-family: arial, sans-serif; font-size: small;">Does any=
one see helpfulness of such solution:</span><br style=3D"font-family: arial=
, sans-serif; font-size: small;"><br style=3D"font-family: arial, sans-seri=
f; font-size: small;"><span style=3D"font-family: arial, sans-serif; font-s=
ize: small;">for(auto _ : {1, 2, 3})</span><br style=3D"font-family: arial,=
 sans-serif; font-size: small;"><span style=3D"font-family: arial, sans-ser=
if; font-size: small;">{</span><br style=3D"font-family: arial, sans-serif;=
 font-size: small;"><span style=3D"font-family: arial, sans-serif; font-siz=
e: small;">}</span><br style=3D"font-family: arial, sans-serif; font-size: =
small;"><br style=3D"font-family: arial, sans-serif; font-size: small;"><sp=
an style=3D"font-family: arial, sans-serif; font-size: small;">Variable wit=
h name &quot;_&quot; has an implicit unused attribute set.</span><br></div>=
<div><br></div><div><br></div><div>--=C2=A0</div><div><br></div><div>Dmitry=
 Banschikov</div></div>

<p></p>

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

------=_Part_1550_1070216524.1455912304547--
------=_Part_1549_1072152368.1455912304546--

.

On 19 February 2016 at 22:05, Dmitry Banshchikov <me@ubique.spb.ru> wrote:
> Hi!
>
> Does anyone see helpfulness of such solution:
>
> for(auto _ : {1, 2, 3})
> {
> }
>
> Variable with name "_" has an implicit unused attribute set.


Certainly, it has been discussed before, but hasn't progressed in a while:
http://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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

I often use _ as =C2=ABuninteresting but needed=C2=BB variables such as loc=
k_guards.
Please don't break my code :)

2016-02-19 15:05 GMT-05:00 Dmitry Banshchikov <me@ubique.spb.ru>:

> Hi!
>
> Does anyone see helpfulness of such solution:
>
> for(auto _ : {1, 2, 3})
> {
> }
>
> Variable with name "_" has an implicit unused attribute set.
>
>
> --
>
> Dmitry Banschikov
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">I often use _ as =C2=ABuninteresting but needed=C2=BB vari=
ables such as lock_guards. Please don&#39;t break my code :)<br></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-02-19 15:05 GMT-0=
5:00 Dmitry Banshchikov <span dir=3D"ltr">&lt;<a href=3D"mailto:me@ubique.s=
pb.ru" target=3D"_blank">me@ubique.spb.ru</a>&gt;</span>:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-family:arial,san=
s-serif;font-size:small">Hi!</span><br style=3D"font-family:arial,sans-seri=
f;font-size:small"><br style=3D"font-family:arial,sans-serif;font-size:smal=
l"><span style=3D"font-family:arial,sans-serif;font-size:small">Does anyone=
 see helpfulness of such solution:</span><br style=3D"font-family:arial,san=
s-serif;font-size:small"><br style=3D"font-family:arial,sans-serif;font-siz=
e:small"><span style=3D"font-family:arial,sans-serif;font-size:small">for(a=
uto _ : {1, 2, 3})</span><br style=3D"font-family:arial,sans-serif;font-siz=
e:small"><span style=3D"font-family:arial,sans-serif;font-size:small">{</sp=
an><br style=3D"font-family:arial,sans-serif;font-size:small"><span style=
=3D"font-family:arial,sans-serif;font-size:small">}</span><br style=3D"font=
-family:arial,sans-serif;font-size:small"><br style=3D"font-family:arial,sa=
ns-serif;font-size:small"><span style=3D"font-family:arial,sans-serif;font-=
size:small">Variable with name &quot;_&quot; has an implicit unused attribu=
te set.</span><span class=3D"HOEnZb"><font color=3D"#888888"><br></font></s=
pan></div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><di=
v><br></div><div>--=C2=A0</div><div><br></div><div>Dmitry Banschikov</div><=
/font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--001a1143dd18cdbf14052c2504c2--

.

On 2016-02-19 15:06, Patrice Roy wrote:
> I often use _ as =C2=ABuninteresting but needed=C2=BB variables such as l=
ock_guards.
> Please don't break my code :)

I don't think this would break your code (except that using '_' is
probably a no-go due to its use for GNU translations). The idea is that
the variable exists, but cannot be named, and isn't used except for side
effects. A lock_guard is certainly a side effect. (Critically, the
lifetime of such a variable is not different from a regular variable.)

Hmm... I wonder if `.` could be used...

--=20
Matthew

--=20

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

.

On 19 February 2016 at 22:16, Matthew Woehlke <mwoehlke.floss@gmail.com> wr=
ote:
> On 2016-02-19 15:06, Patrice Roy wrote:
>> I often use _ as =C2=ABuninteresting but needed=C2=BB variables such as =
lock_guards.
>> Please don't break my code :)
>
> I don't think this would break your code (except that using '_' is
> probably a no-go due to its use for GNU translations). The idea is that
> the variable exists, but cannot be named, and isn't used except for side
> effects. A lock_guard is certainly a side effect. (Critically, the
> lifetime of such a variable is not different from a regular variable.)
>
> Hmm... I wonder if `.` could be used...


If anyone wants to work on a proposal/implementation for it, I recommend ta=
lking
to Jeffrey Yasskin.

--=20

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

.

------=_Part_3868_1617014993.1456001184425
Content-Type: multipart/alternative;
 boundary="----=_Part_3869_1647956295.1456001184425"

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

On Friday, February 19, 2016 at 12:16:28 PM UTC-8, Matthew Woehlke wrote:
>
> On 2016-02-19 15:06, Patrice Roy wrote:=20
> > I often use _ as =C2=ABuninteresting but needed=C2=BB variables such as=
=20
> lock_guards.=20
> > Please don't break my code :)=20
>
> I don't think this would break your code (except that using '_' is=20
> probably a no-go due to its use for GNU translations). The idea is that=
=20
> the variable exists, but cannot be named, and isn't used except for side=
=20
>

While that may be for Roy's example, I think the potential for breakage=20
remains. _ today is a legal identifier with no special semantics. You=20
propose to change that. I think we'd need a new identifier that is not=20
currently legal (or far less likely to be in use).
=20

> effects. A lock_guard is certainly a side effect. (Critically, the=20
> lifetime of such a variable is not different from a regular variable.)=20
>

> Hmm... I wonder if `.` could be used...=20
>

Actually, __ (double underscore) might work, since all identifiers with=20
leading double underscores are technically reserved (although iirc they're=
=20
reserved for the implementation, not the standard).
=20

>
> --=20
> Matthew=20
>
>

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

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

<div dir=3D"ltr">On Friday, February 19, 2016 at 12:16:28 PM UTC-8, Matthew=
 Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-02-19 1=
5:06, Patrice Roy wrote:
<br>&gt; I often use _ as =C2=ABuninteresting but needed=C2=BB variables su=
ch as lock_guards.
<br>&gt; Please don&#39;t break my code :)
<br>
<br>I don&#39;t think this would break your code (except that using &#39;_&=
#39; is
<br>probably a no-go due to its use for GNU translations). The idea is that
<br>the variable exists, but cannot be named, and isn&#39;t used except for=
 side
<br></blockquote><div><br></div><div>While that may be for Roy&#39;s exampl=
e, I think the potential for breakage remains. _ today is a legal identifie=
r with no special semantics. You propose to change that. I think we&#39;d n=
eed a new identifier that is not currently legal (or far less likely to be =
in use).</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">effects. A lock_guard is certainly a side effect. (Critically, the
<br>lifetime of such a variable is not different from a regular variable.)
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Hmm... I =
wonder if `.` could be used...
<br></blockquote><div><br></div><div>Actually, __ (double underscore) might=
 work, since all identifiers with leading double underscores are technicall=
y reserved (although iirc they&#39;re reserved for the implementation, not =
the standard).</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;">
<br>--=20
<br>Matthew
<br>
<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/90451a1c-3531-46bd-819d-88b8d8181ddb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/90451a1c-3531-46bd-819d-88b8d8181ddb=
%40isocpp.org</a>.<br />

------=_Part_3869_1647956295.1456001184425--
------=_Part_3868_1617014993.1456001184425--

.

On Fri, Feb 19, 2016 at 12:20 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 19 February 2016 at 22:16, Matthew Woehlke <mwoehlke.floss@gmail.com> =
wrote:
>> On 2016-02-19 15:06, Patrice Roy wrote:
>>> I often use _ as =C2=ABuninteresting but needed=C2=BB variables such as=
 lock_guards.
>>> Please don't break my code :)
>>
>> I don't think this would break your code (except that using '_' is
>> probably a no-go due to its use for GNU translations). The idea is that
>> the variable exists, but cannot be named, and isn't used except for side
>> effects. A lock_guard is certainly a side effect. (Critically, the
>> lifetime of such a variable is not different from a regular variable.)
>>
>> Hmm... I wonder if `.` could be used...
>
>
> If anyone wants to work on a proposal/implementation for it, I recommend =
talking
> to Jeffrey Yasskin.

I'm not actively working on this, and nobody will be stepping on my
toes by taking it over. I do still think that __ is the most likely
name for the concept.

--=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/CANh-dXkgyHteF7Kq-6vK%3D9TxpVyj5tTcSZRM_xBuT4A%3=
Dh_9Gig%40mail.gmail.com.

.

On 21 February 2016 at 00:11, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>> If anyone wants to work on a proposal/implementation for it, I recommend talking
>> to Jeffrey Yasskin.
> I'm not actively working on this, and nobody will be stepping on my
> toes by taking it over. I do still think that __ is the most likely
> name for the concept.


My recommendation isn't about stepping on anyone's toes, but rather
getting familiar with the existing design issues of the idea. ;)

--
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/CAFk2RUaGGvss1-gavbe9wuGkFijgEqbiuGF0WvJ0uw-LwTZuEw%40mail.gmail.com.

.

On Sat, Feb 20, 2016 at 4:11 PM, 'Jeffrey Yasskin' via ISO C++
Standard - Future Proposals <std-proposals@isocpp.org> wrote:
> I do still think that __ is the most likely
> name for the concept.

I'd rather see a syntax like `if` but not branching:

  with (locking()) {
    // ...
  }

  with (auto f = open_file(...))
    // ...

For this use case,

  for(auto _ : {1, 2, 3})
  {
  }

I think, maybe, we can just allow range-for to have no declarator:

  for ({1, 2, 3})
  {
  }

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

--
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/CAGsORuBYcweY31s-U_gOaSapBzNjxgOCmCuUp4r%3D6ZrA0oOQnA%40mail.gmail.com.

.

On Sat, Feb 20, 2016 at 2:21 PM, Zhihao Yuan <zy@miator.net> wrote:
> On Sat, Feb 20, 2016 at 4:11 PM, 'Jeffrey Yasskin' via ISO C++
> Standard - Future Proposals <std-proposals@isocpp.org> wrote:
>> I do still think that __ is the most likely
>> name for the concept.
>
> I'd rather see a syntax like `if` but not branching:

Did you read http://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/CANh-dXmbR%2BLYSkS%2BJjMCjEdHBEMDaWc38Y%2BK6sHK2qKNDvtYvg%40mail.gmail.com.

.

On Sat, Feb 20, 2016 at 6:13 PM, 'Jeffrey Yasskin' via ISO C++
Standard - Future Proposals <std-proposals@isocpp.org> wrote:
> On Sat, Feb 20, 2016 at 2:21 PM, Zhihao Yuan <zy@miator.net> wrote:
>> On Sat, Feb 20, 2016 at 4:11 PM, 'Jeffrey Yasskin' via ISO C++
>> Standard - Future Proposals <std-proposals@isocpp.org> wrote:
>>> I do still think that __ is the most likely
>>> name for the concept.
>>
>> I'd rather see a syntax like `if` but not branching:
>
> Did you read http://cplusplus.github.io/EWG/ewg-active.html#35?

I didn't.

__ is a simple (maybe) solution, may have more uses, but I hope,
in many cases, we can just let the C++ syntax itself not introducing
a name from the beginning, and I think that's nicer.

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

--
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/CAGsORuA3vu5Ap1FFOp%2BzgXDRgpsZvZtc2fg6wJ%3DSGKFuVS94kA%40mail.gmail.com.

.

On s=C3=A1bado, 20 de fevereiro de 2016 12:46:24 PST Sean Middleditch wrote=
:
> Actually, __ (double underscore) might work, since all identifiers with=
=20
> leading double underscores are technically reserved (although iirc they'r=
e=20
> reserved for the implementation, not the standard).

And yet they're abused.

https://github.com/v8/v8/search?q=3Ddefine+__&type=3DCode

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

--=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/3554272.CN1BCuHPGl%40tjmaciei-mobl4.

.

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

On Fri, Feb 19, 2016 at 9:06 PM, Patrice Roy <patricer@gmail.com> wrote:

> I often use _ as =C2=ABuninteresting but needed=C2=BB variables such as
lock_guards. Please don't break my code :)

I would even say that this case, "uninteresting but needed" is more
interesting. It would be nice to have a language construct that creates an
"anonymous" variable in the current scope. Alternatively, this could be
conceptualized as a temporary whose lifetime is extended till the end of
the current scope.

Cheers,
V.

--=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/CAA7YVg1T2WQM5fzckDE5oczmAycJt-cibZ_iYvWp4SzgkGL=
pQQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 19, 2016 at 9:06 PM, Patrice Roy <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:patricer@gmail.com" target=3D"_blank">patricer@gmail.com</a>&gt;</spa=
n> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quo=
te">&gt; I often use _ as =C2=ABuninteresting but needed=C2=BB variables su=
ch as lock_guards. Please don&#39;t break my code :)<div><br></div><div>I w=
ould even say that this case, &quot;uninteresting but needed&quot; is more =
interesting. It would be nice to have a language construct that creates an =
&quot;anonymous&quot; variable in the current scope. Alternatively, this co=
uld be conceptualized as a temporary whose lifetime is extended till the en=
d of the current scope.</div><div><br></div><div>Cheers,</div><div>V.</div>=
</div></div></div>

<p></p>

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

--089e01177a6dd9c2e7052c48102a--

.

------=_Part_5278_1412481907.1456122649077
Content-Type: multipart/alternative;
 boundary="----=_Part_5279_2029677197.1456122649077"

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

On Saturday, February 20, 2016 at 2:22:02 PM UTC-8, Zhihao Yuan wrote:
>
> On Sat, Feb 20, 2016 at 4:11 PM, 'Jeffrey Yasskin' via ISO C++=20
> Standard - Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:=
=20
> > I do still think that __ is the most likely=20
> > name for the concept.=20
>
> I'd rather see a syntax like `if` but not branching:=20
>
>   with (locking()) {=20
>     // ...=20
>   }=20
>
>   with (auto f =3D open_file(...))=20
>     // ...=20
>
> For this use case,=20
>
>   for(auto _ : {1, 2, 3})=20
>   {=20
>   }=20
>
> I think, maybe, we can just allow range-for to have no declarator:=20
>
>   for ({1, 2, 3})=20
>   {=20
>   }=20
>

I suspect that that would produce ambiguities in the grammar (allowing=20
either a declaration or an expression there).
I suggest

    for (int : {1, 2, 3}) { ... }

or

    for (auto : {1, 2, 3}) { ... }

as being less likely to produce ambiguity, but just as good from the POV of=
=20
avoiding unused variables.

Thanks for the observation that

    {
        lock_guard<mutex> lk(m);
        ...
    }

could also be written

    template<class T> class with;  // convert RAII class T into an iterable=
=20
with one "element"

    for (auto lk : with<lock_guard<mutex>>(m)) {
        ...
    }

or, post-P0135,

    template<class T> auto with(T);

    for (auto lk : with(lock_guard<mutex>(m))) {
        ...
    }

or,=20
post-a-proposal-in-which-the-name-of-an-otherwise-unused-loop-control-varia=
ble-may-be-omitted,

    template<class T> auto with(T);
    template<class M> auto with_lock(M);

    for (auto : with_lock(m)) {
        ...
    }

which is getting to be practically readable!

However, I admit that this might be a case of the good being the enemy of=
=20
the perfect. I would hate to standardize this weird "for" hack, if there's=
=20
a chance of one day standardizing the "with" keyword itself.

http://cplusplus.github.io/EWG/ewg-active.html#35 is IMHO talking about=20
standardizing __COUNTER__ and/or __GUID__, which is a very good idea in its=
=20
own right (much better than standardizing some weird interaction between=20
short variable names and compiler diagnostics), but probably not useful for=
=20
the lock_guard use-case.

=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/6994ff0c-b5b5-450c-9fc0-4c22f70b7a3c%40isocpp.or=
g.

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

<div dir=3D"ltr">On Saturday, February 20, 2016 at 2:22:02 PM UTC-8, Zhihao=
 Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sat, Feb 20, 20=
16 at 4:11 PM, &#39;Jeffrey Yasskin&#39; via ISO C++
<br>Standard - Future Proposals &lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"ChPv4cArAQAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;=
javascript:&#39;;return true;">std-pr...@isocpp.org</a>&gt; wrote:
<br>&gt; I do still think that __ is the most likely
<br>&gt; name for the concept.
<br>
<br>I&#39;d rather see a syntax like `if` but not branching:
<br>
<br>=C2=A0 with (locking()) {
<br>=C2=A0 =C2=A0 // ...
<br>=C2=A0 }
<br>
<br>=C2=A0 with (auto f =3D open_file(...))
<br>=C2=A0 =C2=A0 // ...
<br>
<br>For this use case,
<br>
<br>=C2=A0 for(auto _ : {1, 2, 3})
<br>=C2=A0 {
<br>=C2=A0 }
<br>
<br>I think, maybe, we can just allow range-for to have no declarator:
<br>
<br>=C2=A0 for ({1, 2, 3})
<br>=C2=A0 {
<br>=C2=A0 }
<br></blockquote><div><br></div><div>I suspect that that would produce ambi=
guities in the grammar (allowing either a declaration or an expression ther=
e).</div><div>I suggest</div><div><br></div><div>=C2=A0 =C2=A0 for (int : {=
1, 2, 3}) { ... }</div><div><br></div><div>or</div><div><br></div><div><div=
>=C2=A0 =C2=A0 for (auto : {1, 2, 3}) { ... }</div></div><div><br></div><di=
v>as being less likely to produce ambiguity, but just as good from the POV =
of avoiding unused variables.</div><div><br></div><div>Thanks for the obser=
vation that</div><div><br></div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 lock_guard&lt;mutex&gt; lk(m);</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 ...</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>could =
also be written</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;class T&=
gt; class with; =C2=A0// convert RAII class T into an iterable with one &qu=
ot;element&quot;</div><div><br></div><div>=C2=A0 =C2=A0 for (auto lk : with=
&lt;lock_guard&lt;mutex&gt;&gt;(m)) {<br></div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 ...</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>or, post-P013=
5,</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;class T&gt; auto with=
(T);</div><div><br></div><div>=C2=A0 =C2=A0 for (auto lk : with(lock_guard&=
lt;mutex&gt;(m))) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=
=A0 =C2=A0 }</div><div><br></div><div>or, post-a-proposal-in-which-the-name=
-of-an-otherwise-unused-loop-control-variable-may-be-omitted,</div><div><br=
></div><div><div>=C2=A0 =C2=A0 template&lt;class T&gt; auto with(T);</div><=
/div><div>=C2=A0 =C2=A0 template&lt;class M&gt; auto with_lock(M);</div><di=
v><br></div><div><div>=C2=A0 =C2=A0 for (auto : with_lock(m)) {</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 =C2=A0 }</div></div><div><=
br></div><div>which is getting to be practically readable!</div><div><br></=
div><div>However, I admit that this might be a case of the good being the e=
nemy of the perfect. I would hate to standardize this weird &quot;for&quot;=
 hack, if there&#39;s a chance of one day standardizing the &quot;with&quot=
; keyword itself.</div><div><br></div><div><a href=3D"http://cplusplus.gith=
ub.io/EWG/ewg-active.html#35" target=3D"_blank" rel=3D"nofollow" style=3D"c=
ursor: pointer;">http://cplusplus.github.io/<wbr>EWG/ewg-active.html#35</a>=
=C2=A0is IMHO talking about standardizing __COUNTER__ and/or __GUID__, whic=
h is a very good idea in its own right (much better than standardizing some=
 weird interaction between short variable names and compiler diagnostics), =
but probably not useful for the lock_guard use-case.<br></div><div><br></di=
v><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/6994ff0c-b5b5-450c-9fc0-4c22f70b7a3c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6994ff0c-b5b5-450c-9fc0-4c22f70b7a3c=
%40isocpp.org</a>.<br />

------=_Part_5279_2029677197.1456122649077--
------=_Part_5278_1412481907.1456122649077--

.

On 2016-02-20 20:12, Zhihao Yuan wrote:
> __ is a simple (maybe) solution, may have more uses, but I hope,
> in many cases, we can just let the C++ syntax itself not introducing
> a name from the beginning, and I think that's nicer.

That's what `__` *is*... it's a placeholder for 'not named'.

--
Matthew

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

.

On 2016-02-21 08:55, Viacheslav Usov wrote:
> On Fri, Feb 19, 2016 at 9:06 PM, Patrice Roy wrote:
>> I often use _ as =C2=ABuninteresting but needed=C2=BB variables such as
>> lock_guards. Please don't break my code :)
>=20
> I would even say that this case, "uninteresting but needed" is more
> interesting. It would be nice to have a language construct that creates a=
n
> "anonymous" variable in the current scope. Alternatively, this could be
> conceptualized as a temporary whose lifetime is extended till the end of
> the current scope.

Is that not what we're proposing?

--=20
Matthew

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

.

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

On Mon, Feb 22, 2016 at 4:35 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2016-02-21 08:55, Viacheslav Usov wrote:
> > On Fri, Feb 19, 2016 at 9:06 PM, Patrice Roy wrote:
> >> I often use _ as =C2=ABuninteresting but needed=C2=BB variables such a=
s
> >> lock_guards. Please don't break my code :)
> >
> > I would even say that this case, "uninteresting but needed" is more
> > interesting. It would be nice to have a language construct that creates
> an
> > "anonymous" variable in the current scope. Alternatively, this could be
> > conceptualized as a temporary whose lifetime is extended till the end o=
f
> > the current scope.
>
> Is that not what we're proposing?
>

I am not sure. The discussion definitely started with a very different
idea, and I do not think I saw a clear statement similar to what I wrote
above.

For the record, I dislike the special names that have been proposed. I
believe the lifetime-extended temporary approach is more appropriate, so
this should probably be phrased in a language involving temporaries; say if
<expression> produces a temporary, then &<expression> makes it an anonymous
variable (and an l-value) in the current scope. The use of & is just an
example and not essential.

Cheers,
V.

--=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/CAA7YVg2QppYXRg-zGEnD4%2Bm5yET4fisd0BhXLyGwMaRZg=
Ne6tQ%40mail.gmail.com.

--001a113e24b47423a7052c5ec59c
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, Feb 22, 2016 at 4:35 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-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">On 2016-02-21 08:55, Viaches=
lav Usov wrote:<br>
&gt; On Fri, Feb 19, 2016 at 9:06 PM, Patrice Roy wrote:<br>
&gt;&gt; I often use _ as =C2=ABuninteresting but needed=C2=BB variables su=
ch as<br>
&gt;&gt; lock_guards. Please don&#39;t break my code :)<br>
&gt;<br>
&gt; I would even say that this case, &quot;uninteresting but needed&quot; =
is more<br>
&gt; interesting. It would be nice to have a language construct that create=
s an<br>
&gt; &quot;anonymous&quot; variable in the current scope. Alternatively, th=
is could be<br>
&gt; conceptualized as a temporary whose lifetime is extended till the end =
of<br>
&gt; the current scope.<br>
<br>
Is that not what we&#39;re proposing?<br></blockquote><div><br></div><div>I=
 am not sure. The discussion definitely started with a very different idea,=
 and I do not think I saw a clear statement similar to what I wrote above.<=
/div><div><br></div><div>For the record, I dislike the special names that h=
ave been proposed. I believe the lifetime-extended temporary approach is mo=
re appropriate, so this should probably be phrased in a language involving =
temporaries; say if &lt;expression&gt; produces a temporary, then &amp;&lt;=
expression&gt; makes it an anonymous variable (and an l-value) in the curre=
nt scope. The use of &amp; is just an example and not essential.</div><div>=
<br></div><div>Cheers,</div><div>V.</div></div></div></div>

<p></p>

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

--001a113e24b47423a7052c5ec59c--

.

On 2016-02-22 12:00, Viacheslav Usov wrote:
> On Mon, Feb 22, 2016 at 4:35 PM, Matthew Woehlke wrote:
>> On 2016-02-21 08:55, Viacheslav Usov wrote:
>>> On Fri, Feb 19, 2016 at 9:06 PM, Patrice Roy wrote:
>>>> I often use _ as =C2=ABuninteresting but needed=C2=BB variables such a=
s
>>>> lock_guards. Please don't break my code :)
>>>
>>> I would even say that this case, "uninteresting but needed" is=20
>>> more interesting. It would be nice to have a language construct=20
>>> that creates an "anonymous" variable in the current scope.=20
>>> Alternatively, this could be conceptualized as a temporary whose
>>> lifetime is extended till the end of the current scope.
>>=20
>> Is that not what we're proposing?
>=20
> I am not sure. The discussion definitely started with a very different
> idea, and I do not think I saw a clear statement similar to what I wrote
> above.

I'm not sure I'd call it "different" or not. The OP (who curiously seems
to have dropped out of the conversation) originally only mentioned being
implicitly `[[maybe_unused]]`. Ville immediately brought up
http://cplusplus.github.io/EWG/ewg-active.html#35, which dealt with
"nameless" variables, which seems consistent with the OP's intent as
well as much more useful (though Dmitry brings up the interesting point
that these should be `[[maybe_unused]]`, now that that seems likely to
be in C++17). I've generally read the rest of the thread as referring to
such 'anonymous variables'.

> For the record, I dislike the special names that have been proposed. I
> believe the lifetime-extended temporary approach is more appropriate, so
> this should probably be phrased in a language involving temporaries; say =
if
> <expression> produces a temporary, then &<expression> makes it an anonymo=
us
> variable (and an l-value) in the current scope. The use of & is just an
> example and not essential.

I see at least one issue with that, namely that it doesn't solve the
OP's problem (anonymous variables as loop iterators). Otherwise, I fail
to see a semantic difference between:

  &lock_guard{...}; // life extended until end of scope
  auto&& . =3D lock_guard{...}; // anonymous variable

In both cases, a temporary that would otherwise be immediately destroyed
is lifetime-extended to the end of the scope in which the statement
appears. Said temporary is anonymous and cannot be named (i.e. used
again). The only difference I see=C2=B9 is syntactic.

Do I miss something?

(=C2=B9 Again, ignoring that reuse of declaration syntax means I can do
things with 'auto .' that I can't do with pure lifetime extension.)

Note also I'm not a big fan of changing the meaning of an existing
identifier, even `__`, to be something other than an identifier. That's
why I suggested using `.` instead; the proposed syntax is not (AFAIK)
currently legal, and `.` is definitely not an identifier.



Just for fun... here's how a potential 'do something X times' loop might
look in the future:

  for (.: [0..X))
    do_something();

(And no, this isn't completely theoretical code; it might well appear in
timing tests.)

--=20
Matthew

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

.

On segunda-feira, 22 de fevereiro de 2016 12:56:16 PST Matthew Woehlke wrote:
>   for (.: [0..X))
>     do_something();
>
> (And no, this isn't completely theoretical code; it might well appear in
> timing tests.)

With the potential of being O(n) in memory instead of O(1) if the compiler
doesn't optimise the intialiser list away.

Don't be lazy, just write:

 for (int i = 0; i < X; ++i)

--
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/4389011.vXu2aERc61%40tjmaciei-mobl4.

.

On Mon, Feb 22, 2016 at 8:56 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
> On 2016-02-22 12:00, Viacheslav Usov wrote:
>> On Mon, Feb 22, 2016 at 4:35 PM, Matthew Woehlke wrote:
>>> On 2016-02-21 08:55, Viacheslav Usov wrote:
>>>> On Fri, Feb 19, 2016 at 9:06 PM, Patrice Roy wrote:
>>>>> I often use _ as =C2=ABuninteresting but needed=C2=BB variables such =
as
>>>>> lock_guards. Please don't break my code :)
>>>>
>>>> I would even say that this case, "uninteresting but needed" is
>>>> more interesting. It would be nice to have a language construct
>>>> that creates an "anonymous" variable in the current scope.
>>>> Alternatively, this could be conceptualized as a temporary whose
>>>> lifetime is extended till the end of the current scope.
>>>
>>> Is that not what we're proposing?
>>
>> I am not sure. The discussion definitely started with a very different
>> idea, and I do not think I saw a clear statement similar to what I wrote
>> above.
>
> I'm not sure I'd call it "different" or not. The OP (who curiously seems
> to have dropped out of the conversation) originally only mentioned being
> implicitly `[[maybe_unused]]`. Ville immediately brought up
> http://cplusplus.github.io/EWG/ewg-active.html#35, which dealt with
> "nameless" variables, which seems consistent with the OP's intent as
> well as much more useful (though Dmitry brings up the interesting point
> that these should be `[[maybe_unused]]`, now that that seems likely to
> be in C++17). I've generally read the rest of the thread as referring to
> such 'anonymous variables'.

I haven't dropped conversation, just listening for opinions.
My initial desire was to have something like blank identifier in Go or _
variable in Python. Actually, I have got construct that works but looks ugl=
y:
for(auto attempt [[gnu::unused]] : {1,2,3})
{
.. . .
}

Possibly standard [[unused]] attribute specifier will make a sense.

The idea to have a "__" seems to me as orthogonal one(and for sure useful) =
and
having implicit unused attribute may be not appropriate for it.

--=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/CABuNDZSXRcaZPoYGSbcCLK1x3p70jzxLCeuVO07Mpu%3DD4=
1M5tw%40mail.gmail.com.

.

On 2016-02-22 13:38, Thiago Macieira wrote:
> On segunda-feira, 22 de fevereiro de 2016 12:56:16 PST Matthew Woehlke wr=
ote:
>>   for (.: [0..X))
>>     do_something();
>>
>> (And no, this isn't completely theoretical code; it might well appear in
>> timing tests.)
>=20
> With the potential of being O(n) in memory instead of O(1) if the compile=
r=20
> doesn't optimise the intialiser list away.

Uh... no? There is no initializer list in the above. That's a P0268
up-to expression; P0268 is quite clear=C2=B9 that the memory use is O(1).
(Likewise for my indexrange library version... and the underlying
implementation is likely very similar between the two.)

(=C2=B9 "The memory usage of `[a..b)` is proportional to `make_pair(a,b)`,
not an array of length b=E2=80=93a." "Note that this example [...] does not
store 1,000,000 `int`s at any time.")

--=20
Matthew

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

.

On 2016-02-22 13:47, Dmitry Banschikov wrote:
> I haven't dropped conversation, just listening for opinions.
> My initial desire was to have something like blank identifier in Go or _
> variable in Python.

That sure *sounds* like what we're discussing :-). (But then, I'm not
familiar with either of those...)

> Actually, I have got construct that works but looks ugly:
> for(auto attempt [[gnu::unused]] : {1,2,3})
> {
> . . .
> }
>=20
> Possibly standard [[unused]] attribute specifier will make a sense.

That's P0068/P0212 (http://wg21.link/p0212).

The problem - as most of us are viewing it - with the above is you still
have to name the variable :-).

> The idea to have a "__" seems to me as orthogonal one (and for sure usefu=
l) and
> having implicit unused attribute may be not appropriate for it.

Well... yes and no. We're likely to get `[[maybe_unused]]` in C++17. I
don't see where you'd want an anonymous variable to *not* have that
attribute, though. After all, it is *necessarily* unused, since you
can't name it...

So... not *quite* orthogonal, but the dependency is only at the QoI
level and only in one direction.

To be clear: I think we mostly=C2=B9 agree that we'd like both features;
we're just arguing about the implementation details :-).

One thing I think we *don't* want is to merely apply `[[maybe_unused]]`
to one or more specific identifiers (e.g. `_`). That seems silly. But we
want (and seem likely to get) the attribute, and we (most of us anyway)
also want the ability to declare anonymous variables.

(=C2=B9 See Viacheslav Usov's most recent post re: lifetime extension for a
contrary opinion - so far, the only one expressed in this thread.)

I would encourage you or someone to write a paper. I'll even offer to
help. (I'd write it myself, I just don't want to do it right now. If no
one else does, I may write it in a few months.) It's definitely not a
crazy idea and seems like it has decent hope for being accepted.

--=20
Matthew

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

.

On Mon, Feb 22, 2016 at 10:35 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
> On 2016-02-22 13:47, Dmitry Banschikov wrote:
>> I haven't dropped conversation, just listening for opinions.
>> My initial desire was to have something like blank identifier in Go or _
>> variable in Python.
>
> That sure *sounds* like what we're discussing :-). (But then, I'm not
> familiar with either of those...)
>
>> Actually, I have got construct that works but looks ugly:
>> for(auto attempt [[gnu::unused]] : {1,2,3})
>> {
>> . . .
>> }
>>
>> Possibly standard [[unused]] attribute specifier will make a sense.
>
> That's P0068/P0212 (http://wg21.link/p0212).
>
> The problem - as most of us are viewing it - with the above is you still
> have to name the variable :-).
>
>> The idea to have a "__" seems to me as orthogonal one (and for sure usef=
ul) and
>> having implicit unused attribute may be not appropriate for it.
>
> Well... yes and no. We're likely to get `[[maybe_unused]]` in C++17. I
> don't see where you'd want an anonymous variable to *not* have that
> attribute, though. After all, it is *necessarily* unused, since you
> can't name it...
>
> So... not *quite* orthogonal, but the dependency is only at the QoI
> level and only in one direction.
>
> To be clear: I think we mostly=C2=B9 agree that we'd like both features;
> we're just arguing about the implementation details :-).
>
> One thing I think we *don't* want is to merely apply `[[maybe_unused]]`
> to one or more specific identifiers (e.g. `_`). That seems silly. But we
> want (and seem likely to get) the attribute, and we (most of us anyway)
> also want the ability to declare anonymous variables.
>
> (=C2=B9 See Viacheslav Usov's most recent post re: lifetime extension for=
 a
> contrary opinion - so far, the only one expressed in this thread.)
>
> I would encourage you or someone to write a paper. I'll even offer to
> help. (I'd write it myself, I just don't want to do it right now. If no
> one else does, I may write it in a few months.) It's definitely not a
> crazy idea and seems like it has decent hope for being accepted.
>

OK, I will try it. I will contact you off the list for details.
Thank you!



--=20

Dmitry Banschikov

--=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/CABuNDZTfdNSL8AC-g8cAv8a3JUBiBX-ReDksxD1U_8g3j9Q=
-EQ%40mail.gmail.com.

.

On segunda-feira, 22 de fevereiro de 2016 14:21:12 PST Matthew Woehlke wrot=
e:
> Uh... no? There is no initializer list in the above. That's a P0268
> up-to expression; P0268 is quite clear=C2=B9 that the memory use is O(1).
> (Likewise for my indexrange library version... and the underlying
> implementation is likely very similar between the two.)

Ah, I see. I haven't read P0268 yet.

I don't think I like the language change. If it can be done in a library, i=
t=20
should be done in the library. indexrange is better.

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

--=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/9337425.Of3J9qAeCA%40tjmaciei-mobl4.

.

On 2016-02-22 16:09, Thiago Macieira wrote:
> On segunda-feira, 22 de fevereiro de 2016 14:21:12 PST Matthew Woehlke wr=
ote:
>> Uh... no? There is no initializer list in the above. That's a P0268
>> up-to expression; P0268 is quite clear=C2=B9 that the memory use is O(1)=
..
>> (Likewise for my indexrange library version... and the underlying
>> implementation is likely very similar between the two.)
>=20
> Ah, I see. I haven't read P0268 yet.
>=20
> I don't think I like the language change. If it can be done in a library,=
 it=20
> should be done in the library. indexrange is better.

Hehe... :-) I'd love to see P0268, but I'm inclined to agree. That's one
of a couple points I have regarding the paper that I intend to bring up
when it's presented.

--=20
Matthew

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

.

For the issues of backwards compatibility, I think we could use _ (single) =
with just the additional rule that _ can be used to name more than one vari=
able per scope. So

void f()
{
auto _ =3D lock_guard(...); // OK today
auto _ =3D foo(); // OK, becomes anonymous=C2=A0
....
for (int _ : {0,1,2,3}) =C2=A0// OK today
=C2=A0cout << _; // uses inner scope _

cout << _; // Error - ambiguous use of _


=E2=80=8ESo if anyone is currently using _ as a variable name - even beyond=
 just construction, it still works.=C2=A0



Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Matthew Woehlke
Sent: Monday, February 22, 2016 4:39 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: [std-proposals] Re: throwaway variable

On 2016-02-22 16:09, Thiago Macieira wrote:
> On segunda-feira, 22 de fevereiro de 2016 14:21:12 PST Matthew Woehlke wr=
ote:
>> Uh... no? There is no initializer list in the above. That's a P0268
>> up-to expression; P0268 is quite clear=C2=B9 that the memory use is O(1)=
..
>> (Likewise for my indexrange library version... and the underlying
>> implementation is likely very similar between the two.)
>=20
> Ah, I see. I haven't read P0268 yet.
>=20
> I don't think I like the language change. If it can be done in a library,=
 it=20
> should be done in the library. indexrange is better.

Hehe... :-) I'd love to see P0268, but I'm inclined to agree. That's one
of a couple points I have regarding the paper that I intend to bring up
when it's presented.

--=20
Matthew

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

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

.

I'm excited that this is getting attention because I was thinking about
proposing a feature for this, too.

I don't think that macro magic like `__COUNTER__` that was mentioned by
somebody is a solution.  It is too cumbersome in header files due to
potential ODR violations.

My preferred syntax for such a variable would be to simple not give it a
name.

    auto /* anonymous */ =3D std::unique_lock<std::mutex> { ... };

We could have any number of them in a scope.

    auto =3D finally {[](){ std::cout << "I'm done!\n"; }};
    auto =3D 42;  // pointless but valid, it's a different variable

This would be consistent with (default) parameters in templates and
functions.

    template <typename, typename =3D int>
    void foo(double, std::string =3D "anonymous");

I'm not sure whether extending this to concrete types (rather than
`auto`) would be desirable.

    finally =3D [](){ std::cout << "I'm really done!\n"; };  // looks cute
    int =3D 42;  // still valid, still pointless

For a start, I'd recommend against it.  It can always be added later.

The only problem with this syntax is that it doesn't work with
non-move types.  Unfortunately, those are notoriously frequent
candidates for anonymous scoped variables, think `std::lock_guard`.

The analogue syntax using direct initialization

    std::lock_guard<std::mutex> /* anonymous */ { ... };

is already taken and creates a temporary object...

Fortunately, there is a proposal (I don't know the number off the top of
my head) to make copy elision mandatory in some cases so "always almost
auto" could become "always auto".  If this were accepted, I think that
the described syntax would be a powerful yet easy to understand
solution.

Otherwise, we might absuse the `auto` keyword.

    auto auto =3D 42;
    int auto =3D 42;
    std::lock_guard<std::mutex> auto { ... };

Not that pretty but possibly doable.

If somebody is about to write a proposal, I'd be happy to contribute.


Tony V E <tvaneerd@gmail.com> writes:

> For the issues of backwards compatibility, I think we could use _
> (single) with just the additional rule that _ can be used to name more
> than one variable per scope. So
>
> void f()
> {
> auto _ =3D lock_guard(...); // OK today
> auto _ =3D foo(); // OK, becomes anonymous
> ...
> for (int _ : {0,1,2,3}) // OK today
>   cout << _; // uses inner scope _
>
> cout << _; // Error - ambiguous use of _
>
>
> =E2=80=8ESo if anyone is currently using _ as a variable name - even beyo=
nd
> just construction, it still works.
--=20
OpenPGP:

Public Key:   http://openpgp.klammler.eu
Fingerprint:  2732 DA32 C8D0 EEEC A081  BE9D CF6C 5166 F393 A9C0

--=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/87io1gtj7g.fsf%40gmail.com.

.

Note that use of _ would also work well with s=E2=80=8Etructured bindings:

auto { x, _, _, w} =3D getthing();

(although you may or may not want/expect lifetime extension here)

Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Moritz Klammler
Sent: Monday, February 22, 2016 6:32 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: throwaway variable

I'm excited that this is getting attention because I was thinking about
proposing a feature for this, too.

I don't think that macro magic like `__COUNTER__` that was mentioned by
somebody is a solution. It is too cumbersome in header files due to
potential ODR violations.

My preferred syntax for such a variable would be to simple not give it a
name.

auto /* anonymous */ =3D std::unique_lock<std::mutex> { ... };

We could have any number of them in a scope.

auto =3D finally {[](){ std::cout << "I'm done!\n"; }};
auto =3D 42; // pointless but valid, it's a different variable

This would be consistent with (default) parameters in templates and
functions.

template <typename, typename =3D int>
void foo(double, std::string =3D "anonymous");

I'm not sure whether extending this to concrete types (rather than
`auto`) would be desirable.

finally =3D [](){ std::cout << "I'm really done!\n"; }; // looks cute
int =3D 42; // still valid, still pointless

For a start, I'd recommend against it. It can always be added later.

The only problem with this syntax is that it doesn't work with
non-move types. Unfortunately, those are notoriously frequent
candidates for anonymous scoped variables, think `std::lock_guard`.

The analogue syntax using direct initialization

std::lock_guard<std::mutex> /* anonymous */ { ... };

is already taken and creates a temporary object...

Fortunately, there is a proposal (I don't know the number off the top of
my head) to make copy elision mandatory in some cases so "always almost
auto" could become "always auto". If this were accepted, I think that
the described syntax would be a powerful yet easy to understand
solution.

Otherwise, we might absuse the `auto` keyword.

auto auto =3D 42;
int auto =3D 42;
std::lock_guard<std::mutex> auto { ... };

Not that pretty but possibly doable.

If somebody is about to write a proposal, I'd be happy to contribute.


Tony V E <tvaneerd@gmail.com> writes:

> For the issues of backwards compatibility, I think we could use _
> (single) with just the additional rule that _ can be used to name more
> than one variable per scope. So
>
> void f()
> {
> auto _ =3D lock_guard(...); // OK today
> auto _ =3D foo(); // OK, becomes anonymous
> ...
> for (int _ : {0,1,2,3}) // OK today
> cout << _; // uses inner scope _
>
> cout << _; // Error - ambiguous use of _
>
>
> =E2=80=8ESo if anyone is currently using _ as a variable name - even beyo=
nd
> just construction, it still works.
--=20
OpenPGP:

Public Key: http://openpgp.klammler.eu
Fingerprint: 2732 DA32 C8D0 EEEC A081 BE9D CF6C 5166 F393 A9C0

--=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/87io1gtj7g.fsf%40gmail.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/20160222234646.4898897.70283.5544%40gmail.com.

.

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

The =C2=ABcan use more than once in a scope=C2=BB is an interesting twist. =
If that
doesn't cause too many problems with existing code (such as people
accessing members of _ afterwards), it could be an interesting
language-supported idiom. Does anyone have any idea whether people actually
write such things as =C2=ABauto _ =3D string{"Hi"}; auto n =3D _.size(); /*=
 evil
distilled */=C2=BB? If it's not common practice (which I sincerely hope, bu=
t can
in no way guarantee), we might have something...

2016-02-22 18:46 GMT-05:00 Tony V E <tvaneerd@gmail.com>:

> Note that use of _ would also work well with s=E2=80=8Etructured bindings=
:
>
> auto { x, _, _, w} =3D getthing();
>
> (although you may or may not want/expect lifetime extension here)
>
> Sent from my BlackBerry portable Babbage Device
>   Original Message
> From: Moritz Klammler
> Sent: Monday, February 22, 2016 6:32 PM
> To: std-proposals@isocpp.org
> Reply To: std-proposals@isocpp.org
> Subject: Re: [std-proposals] Re: throwaway variable
>
> I'm excited that this is getting attention because I was thinking about
> proposing a feature for this, too.
>
> I don't think that macro magic like `__COUNTER__` that was mentioned by
> somebody is a solution. It is too cumbersome in header files due to
> potential ODR violations.
>
> My preferred syntax for such a variable would be to simple not give it a
> name.
>
> auto /* anonymous */ =3D std::unique_lock<std::mutex> { ... };
>
> We could have any number of them in a scope.
>
> auto =3D finally {[](){ std::cout << "I'm done!\n"; }};
> auto =3D 42; // pointless but valid, it's a different variable
>
> This would be consistent with (default) parameters in templates and
> functions.
>
> template <typename, typename =3D int>
> void foo(double, std::string =3D "anonymous");
>
> I'm not sure whether extending this to concrete types (rather than
> `auto`) would be desirable.
>
> finally =3D [](){ std::cout << "I'm really done!\n"; }; // looks cute
> int =3D 42; // still valid, still pointless
>
> For a start, I'd recommend against it. It can always be added later.
>
> The only problem with this syntax is that it doesn't work with
> non-move types. Unfortunately, those are notoriously frequent
> candidates for anonymous scoped variables, think `std::lock_guard`.
>
> The analogue syntax using direct initialization
>
> std::lock_guard<std::mutex> /* anonymous */ { ... };
>
> is already taken and creates a temporary object...
>
> Fortunately, there is a proposal (I don't know the number off the top of
> my head) to make copy elision mandatory in some cases so "always almost
> auto" could become "always auto". If this were accepted, I think that
> the described syntax would be a powerful yet easy to understand
> solution.
>
> Otherwise, we might absuse the `auto` keyword.
>
> auto auto =3D 42;
> int auto =3D 42;
> std::lock_guard<std::mutex> auto { ... };
>
> Not that pretty but possibly doable.
>
> If somebody is about to write a proposal, I'd be happy to contribute.
>
>
> Tony V E <tvaneerd@gmail.com> writes:
>
> > For the issues of backwards compatibility, I think we could use _
> > (single) with just the additional rule that _ can be used to name more
> > than one variable per scope. So
> >
> > void f()
> > {
> > auto _ =3D lock_guard(...); // OK today
> > auto _ =3D foo(); // OK, becomes anonymous
> > ...
> > for (int _ : {0,1,2,3}) // OK today
> > cout << _; // uses inner scope _
> >
> > cout << _; // Error - ambiguous use of _
> >
> >
> > =E2=80=8ESo if anyone is currently using _ as a variable name - even be=
yond
> > just construction, it still works.
> --
> OpenPGP:
>
> Public Key: http://openpgp.klammler.eu
> Fingerprint: 2732 DA32 C8D0 EEEC A081 BE9D CF6C 5166 F393 A9C0
>
> --
> 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/87io1gtj7g.f=
sf%40gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/201602222346=
46.4898897.70283.5544%40gmail.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/CAKiZDp0wTc7BwmA6KtgAfcxFG-OkyETuF%3DhBXneW6rSO1=
gAHig%40mail.gmail.com.

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

<div dir=3D"ltr">The =C2=ABcan use more than once in a scope=C2=BB is an in=
teresting twist. If that doesn&#39;t cause too many problems with existing =
code (such as people accessing members of _ afterwards), it could be an int=
eresting language-supported idiom. Does anyone have any idea whether people=
 actually write such things as =C2=ABauto _ =3D string{&quot;Hi&quot;}; aut=
o n =3D _.size(); /* evil distilled */=C2=BB? If it&#39;s not common practi=
ce (which I sincerely hope, but can in no way guarantee), we might have som=
ething...<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">2016-02-22 18:46 GMT-05:00 Tony V E <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span>:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">Note that use of _ would also work well =
with s=E2=80=8Etructured bindings:<br>
<br>
auto { x, _, _, w} =3D getthing();<br>
<br>
(although you may or may not want/expect lifetime extension here)<br>
<span class=3D""><br>
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce<br>
=C2=A0 Original Message =C2=A0<br>
</span>From: Moritz Klammler<br>
Sent: Monday, February 22, 2016 6:32 PM<br>
<span class=3D"">To: <a href=3D"mailto:std-proposals@isocpp.org">std-propos=
als@isocpp.org</a><br>
Reply To: <a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.=
org</a><br>
</span>Subject: Re: [std-proposals] Re: throwaway variable<br>
<div><div class=3D"h5"><br>
I&#39;m excited that this is getting attention because I was thinking about=
<br>
proposing a feature for this, too.<br>
<br>
I don&#39;t think that macro magic like `__COUNTER__` that was mentioned by=
<br>
somebody is a solution. It is too cumbersome in header files due to<br>
potential ODR violations.<br>
<br>
My preferred syntax for such a variable would be to simple not give it a<br=
>
name.<br>
<br>
auto /* anonymous */ =3D std::unique_lock&lt;std::mutex&gt; { ... };<br>
<br>
We could have any number of them in a scope.<br>
<br>
auto =3D finally {[](){ std::cout &lt;&lt; &quot;I&#39;m done!\n&quot;; }};=
<br>
auto =3D 42; // pointless but valid, it&#39;s a different variable<br>
<br>
This would be consistent with (default) parameters in templates and<br>
functions.<br>
<br>
template &lt;typename, typename =3D int&gt;<br>
void foo(double, std::string =3D &quot;anonymous&quot;);<br>
<br>
I&#39;m not sure whether extending this to concrete types (rather than<br>
`auto`) would be desirable.<br>
<br>
finally =3D [](){ std::cout &lt;&lt; &quot;I&#39;m really done!\n&quot;; };=
 // looks cute<br>
int =3D 42; // still valid, still pointless<br>
<br>
For a start, I&#39;d recommend against it. It can always be added later.<br=
>
<br>
The only problem with this syntax is that it doesn&#39;t work with<br>
non-move types. Unfortunately, those are notoriously frequent<br>
candidates for anonymous scoped variables, think `std::lock_guard`.<br>
<br>
The analogue syntax using direct initialization<br>
<br>
std::lock_guard&lt;std::mutex&gt; /* anonymous */ { ... };<br>
<br>
is already taken and creates a temporary object...<br>
<br>
Fortunately, there is a proposal (I don&#39;t know the number off the top o=
f<br>
my head) to make copy elision mandatory in some cases so &quot;always almos=
t<br>
auto&quot; could become &quot;always auto&quot;. If this were accepted, I t=
hink that<br>
the described syntax would be a powerful yet easy to understand<br>
solution.<br>
<br>
Otherwise, we might absuse the `auto` keyword.<br>
<br>
auto auto =3D 42;<br>
int auto =3D 42;<br>
std::lock_guard&lt;std::mutex&gt; auto { ... };<br>
<br>
Not that pretty but possibly doable.<br>
<br>
If somebody is about to write a proposal, I&#39;d be happy to contribute.<b=
r>
<br>
<br>
Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>&g=
t; writes:<br>
<br>
&gt; For the issues of backwards compatibility, I think we could use _<br>
&gt; (single) with just the additional rule that _ can be used to name more=
<br>
&gt; than one variable per scope. So<br>
&gt;<br>
&gt; void f()<br>
&gt; {<br>
&gt; auto _ =3D lock_guard(...); // OK today<br>
&gt; auto _ =3D foo(); // OK, becomes anonymous<br>
&gt; ...<br>
&gt; for (int _ : {0,1,2,3}) // OK today<br>
&gt; cout &lt;&lt; _; // uses inner scope _<br>
&gt;<br>
&gt; cout &lt;&lt; _; // Error - ambiguous use of _<br>
&gt;<br>
&gt;<br>
&gt; =E2=80=8ESo if anyone is currently using _ as a variable name - even b=
eyond<br>
&gt; just construction, it still works.<br>
--<br>
OpenPGP:<br>
<br>
Public Key: <a href=3D"http://openpgp.klammler.eu" rel=3D"noreferrer" targe=
t=3D"_blank">http://openpgp.klammler.eu</a><br>
Fingerprint: 2732 DA32 C8D0 EEEC A081 BE9D CF6C 5166 F393 A9C0<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/87io1gtj7g.fsf%40gmail.com" rel=3D"no=
referrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/87io1gtj7g.fsf%40gmail.com</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>
</div></div>To view this discussion on the web visit <a href=3D"https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/20160222234646.4898897.70=
283.5544%40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/20160222234646.4898897.70283.5=
544%40gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

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

--001a114577883f88ae052c6504ca--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Even if code currently does that, we are still fine. </div>    =
                                                                           =
                                                      <div style=3D"width: =
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sa=
ns-serif; color: rgb(31, 73, 125); text-align: initial; background-color: r=
gb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initial=
; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31,=
 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">It i=
s only once you add the second _ in the same scope as the first *then* _.si=
ze() will start to fail.&nbsp;</div><div style=3D"width: 100%; font-size: i=
nitial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: r=
gb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);=
"><br></div><div style=3D"width: 100%; font-size: initial; font-family: Cal=
ibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-al=
ign: initial; background-color: rgb(255, 255, 255);">Which is fine. Don't d=
o that.</div><div style=3D"width: 100%; font-size: initial; font-family: Ca=
libri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-a=
lign: initial; background-color: rgb(255, 255, 255);"><br></div><div style=
=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);"><br></div>                                  =
                                                                           =
                                                                           =
           <div style=3D"font-size: initial; font-family: Calibri, 'Slate P=
ro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; =
background-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackBer=
ry&nbsp;portable&nbsp;Babbage&nbsp;Device</div>                            =
                                                                           =
                                                                           =
<table width=3D"100%" style=3D"background-color:white;border-spacing:0px;">=
 <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: init=
ial; background-color: rgb(255, 255, 255);">                           <div=
 style=3D"border-style: solid none none; border-top-color: rgb(181, 196, 22=
3); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB A=
lpha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>Patrice Roy<=
/div><div><b>Sent: </b>Monday, February 22, 2016 7:27 PM</div><div><b>To: <=
/b>std-proposals@isocpp.org</div><div><b>Reply To: </b>std-proposals@isocpp=
..org</div><div><b>Subject: </b>Re: [std-proposals] Re: throwaway variable</=
div></div></td></tr></tbody></table><div style=3D"border-style: solid none =
none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-siz=
e: initial; text-align: initial; background-color: rgb(255, 255, 255);"></d=
iv><br><div id=3D"_originalContent" style=3D""><div dir=3D"ltr">The =C2=ABc=
an use more than once in a scope=C2=BB is an interesting twist. If that doe=
sn't cause too many problems with existing code (such as people accessing m=
embers of _ afterwards), it could be an interesting language-supported idio=
m. Does anyone have any idea whether people actually write such things as =
=C2=ABauto _ =3D string{"Hi"}; auto n =3D _.size(); /* evil distilled */=C2=
=BB? If it's not common practice (which I sincerely hope, but can in no way=
 guarantee), we might have something...<br></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">2016-02-22 18:46 GMT-05:00 Tony V E <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvan=
eerd@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Note tha=
t use of _ would also work well with s=E2=80=8Etructured bindings:<br>
<br>
auto { x, _, _, w} =3D getthing();<br>
<br>
(although you may or may not want/expect lifetime extension here)<br>
<span class=3D""><br>
Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Devi=
ce<br>
&nbsp; Original Message &nbsp;<br>
</span>From: Moritz Klammler<br>
Sent: Monday, February 22, 2016 6:32 PM<br>
<span class=3D"">To: <a href=3D"mailto:std-proposals@isocpp.org">std-propos=
als@isocpp.org</a><br>
Reply To: <a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.=
org</a><br>
</span>Subject: Re: [std-proposals] Re: throwaway variable<br>
<div><div class=3D"h5"><br>
I'm excited that this is getting attention because I was thinking about<br>
proposing a feature for this, too.<br>
<br>
I don't think that macro magic like `__COUNTER__` that was mentioned by<br>
somebody is a solution. It is too cumbersome in header files due to<br>
potential ODR violations.<br>
<br>
My preferred syntax for such a variable would be to simple not give it a<br=
>
name.<br>
<br>
auto /* anonymous */ =3D std::unique_lock&lt;std::mutex&gt; { ... };<br>
<br>
We could have any number of them in a scope.<br>
<br>
auto =3D finally {[](){ std::cout &lt;&lt; "I'm done!\n"; }};<br>
auto =3D 42; // pointless but valid, it's a different variable<br>
<br>
This would be consistent with (default) parameters in templates and<br>
functions.<br>
<br>
template &lt;typename, typename =3D int&gt;<br>
void foo(double, std::string =3D "anonymous");<br>
<br>
I'm not sure whether extending this to concrete types (rather than<br>
`auto`) would be desirable.<br>
<br>
finally =3D [](){ std::cout &lt;&lt; "I'm really done!\n"; }; // looks cute=
<br>
int =3D 42; // still valid, still pointless<br>
<br>
For a start, I'd recommend against it. It can always be added later.<br>
<br>
The only problem with this syntax is that it doesn't work with<br>
non-move types. Unfortunately, those are notoriously frequent<br>
candidates for anonymous scoped variables, think `std::lock_guard`.<br>
<br>
The analogue syntax using direct initialization<br>
<br>
std::lock_guard&lt;std::mutex&gt; /* anonymous */ { ... };<br>
<br>
is already taken and creates a temporary object...<br>
<br>
Fortunately, there is a proposal (I don't know the number off the top of<br=
>
my head) to make copy elision mandatory in some cases so "always almost<br>
auto" could become "always auto". If this were accepted, I think that<br>
the described syntax would be a powerful yet easy to understand<br>
solution.<br>
<br>
Otherwise, we might absuse the `auto` keyword.<br>
<br>
auto auto =3D 42;<br>
int auto =3D 42;<br>
std::lock_guard&lt;std::mutex&gt; auto { ... };<br>
<br>
Not that pretty but possibly doable.<br>
<br>
If somebody is about to write a proposal, I'd be happy to contribute.<br>
<br>
<br>
Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>&g=
t; writes:<br>
<br>
&gt; For the issues of backwards compatibility, I think we could use _<br>
&gt; (single) with just the additional rule that _ can be used to name more=
<br>
&gt; than one variable per scope. So<br>
&gt;<br>
&gt; void f()<br>
&gt; {<br>
&gt; auto _ =3D lock_guard(...); // OK today<br>
&gt; auto _ =3D foo(); // OK, becomes anonymous<br>
&gt; ...<br>
&gt; for (int _ : {0,1,2,3}) // OK today<br>
&gt; cout &lt;&lt; _; // uses inner scope _<br>
&gt;<br>
&gt; cout &lt;&lt; _; // Error - ambiguous use of _<br>
&gt;<br>
&gt;<br>
&gt; =E2=80=8ESo if anyone is currently using _ as a variable name - even b=
eyond<br>
&gt; just construction, it still works.<br>
--<br>
OpenPGP:<br>
<br>
Public Key: <a href=3D"http://openpgp.klammler.eu" rel=3D"noreferrer" targe=
t=3D"_blank">http://openpgp.klammler.eu</a><br>
Fingerprint: 2732 DA32 C8D0 EEEC A081 BE9D CF6C 5166 F393 A9C0<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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/87io1gtj7g.fsf%40gmail.com" rel=3D"no=
referrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/87io1gtj7g.fsf%40gmail.com</a>.<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%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>
</div></div>To view this discussion on the web visit <a href=3D"https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/20160222234646.4898897.70=
283.5544%40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/20160222234646.4898897.70283.5=
544%40gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0wTc7BwmA6KtgAfcxFG-OkyETuF%3D=
hBXneW6rSO1gAHig%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0wTc=
7BwmA6KtgAfcxFG-OkyETuF%3DhBXneW6rSO1gAHig%40mail.gmail.com</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

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

.

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

On Mon, Feb 22, 2016 at 8:35 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:


> (=C2=B9 See Viacheslav Usov's most recent post re: lifetime extension for=
 a
> contrary opinion - so far, the only one expressed in this thread.)
>

I do not think I said anything really contrarian. I definitely do see a
need for anonymous variables; the interpretation as a lifetime extension of
temporaries is secondary.

I am leaning toward lifetime extension because that could be made
syntactically an expression, which has a value (l-value), which can be used
in a greater expression, thus making it possible to refer to the otherwise
inaccessible variable.

With respect to anonymous looping variables, frankly, I do not think I have
ever missed them, but that may be just me.

Cheers,
V.

--=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/CAA7YVg2%3DjXgrMK-ud6VzMim0R2eHAr_MWXUmfY9_a2Lbq=
-RKLA%40mail.gmail.com.

--001a1134ab3ab332ba052c6eb282
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, Feb 22, 2016 at 8:35 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><div>=C2=A0<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">(=C2=B9 See Viacheslav Usov&#39;s most recent post re: lifetime exte=
nsion for a<br>
contrary opinion - so far, the only one expressed in this thread.)<br></blo=
ckquote><div><br></div><div>I do not think I said anything really contraria=
n. I definitely do see a need for anonymous variables; the interpretation a=
s a lifetime extension of temporaries is secondary.</div><div><br></div><di=
v>I am leaning toward lifetime extension because that could be made syntact=
ically an expression, which has a value (l-value), which can be used in a g=
reater expression, thus making it possible to refer to the otherwise inacce=
ssible variable.</div><div><br></div><div>With respect to anonymous looping=
 variables, frankly, I do not think I have ever missed them, but that may b=
e just me.<br></div><div><br></div><div>Cheers,</div><div>V.</div></div></d=
iv></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/CAA7YVg2%3DjXgrMK-ud6VzMim0R2eHAr_MWX=
UmfY9_a2Lbq-RKLA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2%3DjXgr=
MK-ud6VzMim0R2eHAr_MWXUmfY9_a2Lbq-RKLA%40mail.gmail.com</a>.<br />

--001a1134ab3ab332ba052c6eb282--

.

On 2016-02-23 07:00, Viacheslav Usov wrote:
> On Mon, Feb 22, 2016 at 8:35 PM, Matthew Woehlke wrote:
>=20
>> (=C2=B9 See Viacheslav Usov's most recent post re: lifetime extension fo=
r a
>> contrary opinion - so far, the only one expressed in this thread.)
>=20
> I do not think I said anything really contrarian. I definitely do see a
> need for anonymous variables; the interpretation as a lifetime extension =
of
> temporaries is secondary.
>
> I am leaning toward lifetime extension because that could be made
> syntactically an expression, which has a value (l-value), which can be us=
ed
> in a greater expression, thus making it possible to refer to the otherwis=
e
> inaccessible variable.

Oh, okay, now I understand. Thanks for clarifying.

Maybe we do need both. Do you have an example of such an expression
"used in a greater expression"?

> With respect to anonymous looping variables, frankly, I do not think I ha=
ve
> ever missed them, but that may be just me.

Sure... I feel somewhat confident that I could have used them at least a
few times, but they're definitely less common=C2=B9. It's more that they do
have potential, and fall out as a natural consequence ("for free", if
you will) of using a variable-declaration syntax.

(=C2=B9 I am confident I could find at least a half dozen instances where I
could use an anonymous variable / lifetime extended temporary in less
than five minutes, whereas I know I'd have to look hard for where I
might use an anonymous loop variable. Of course, everyone "knows" that
just about any "scoped guard" - of which I could name several offhand -
would typically benefit...)

--=20
Matthew

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

.

On 2016-02-22 17:21, Tony V E wrote:
> For the issues of backwards compatibility, I think we could use _=20
> (single) with just the additional rule that _ can be used to name
> more than one variable per scope. [...]
>=20
> =E2=80=8ESo if anyone is currently using _ as a variable name - even beyo=
nd
> just construction, it still works.

Besides that I dislike that that's now a "magic identifier", what about
*functions* named `_`?

I'd really prefer `.`... what's wrong with `.`? No one has discussed
that except a vague impression that it's not liked, but no one has said
why...

--=20
Matthew

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

.

On 2016-02-22 18:32, Moritz Klammler wrote:
> I'm excited that this is getting attention because I was thinking about
> proposing a feature for this, too.
>
> I don't think that macro magic like `__COUNTER__` that was mentioned by
> somebody is a solution.  It is too cumbersome in header files due to
> potential ODR violations.
>
> My preferred syntax for such a variable would be to simple not give it a
> name.
>
>     auto /* anonymous */ = std::unique_lock<std::mutex> { ... };

That's the idea behind using `.`... `.` is not a name, but it's a
syntactic placeholder. My concern with omitting *any* name (or
placeholder) is that there may be syntactic ambiguities that arise as a
result.

> This would be consistent with (default) parameters in templates and
> functions.
>
>     template <typename, typename = int>
>     void foo(double, std::string = "anonymous");

Why is that valuable? I don't see how the two are related.

> The only problem with this syntax is that it doesn't work with
> non-move types.

Um... `auto&& . = not_movable{};`? Works AFAIK. (Does need the `&&`, but
that doesn't strike me as a deal-breaker.)

--
Matthew

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

.

------=_Part_185_876295107.1456241089000
Content-Type: multipart/alternative;
 boundary="----=_Part_186_969257559.1456241089000"

------=_Part_186_969257559.1456241089000
Content-Type: text/plain; charset=UTF-8

If you guys are proposing to add special case syntax rule to the language
for "_" variable names. Why not try and make the rule and feature a bit
more general? So it not only support unique variable name
generation/substitution, but also supports user configurable (compile time)
name substitution. That way we might get rid of another use case for unsafe
preprocessor macros.

Example for unique name generation and substitution might look something
like this:

int __SubstituteName("")__ = 2; //if param is an empty str then compiler
generate a unique one.

for(auto __SubstituteName("")__ : {1, 2, 3}) {}

std::lock_guard<std::mutex> __SubstituteName("")__(m);

Example for user configured name substitution might look something like
this:

int mycounter = 0;
static_string name = "mycounter";
__SubstituteName(name)__ = 1;
__SubstituteName(name)__++;
assert(__SubstituteName(name)__==2);

Such a feature might with a bit of imagination (and magic) help in
de-serialization of a compile time string into a generated struct.

stuct __GetName(meta.name)__{
typename meta.vars[1].type __SubstituteName(meta.vars[1].name)__;
typename meta.vars[2].type __SubstituteName(meta.vars[2].name)__;
typename meta.vars[3].type __SubstituteName(meta.vars[3].name)__;
//...
};

It should probably play nice with the static reflection proposal. I'm not
familiar with it, but surely it uses somekind of static_string type one
could use.

Just my 2 cents. I haven't thought this through much though.

Regards /Petke

--
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/b6cf3631-8c98-4cb1-8d2a-cb0b77b96ed3%40isocpp.org.

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

<div dir=3D"ltr"><div>If you guys are proposing to add special case syntax =
rule to the language for &quot;_&quot; variable names. Why not try and make=
 the rule and feature a bit more general? So it not only support unique var=
iable name generation/substitution, but also supports user configurable (co=
mpile time) name substitution. That way we might get rid of another use cas=
e for unsafe preprocessor macros.</div><div><br></div><div>Example for uniq=
ue name generation and substitution might look something like this:</div><d=
iv><br></div><div>int __SubstituteName(&quot;&quot;)__ =3D 2; //if param is=
 an empty str then compiler generate a unique one.</div><div><br></div><div=
>for(auto __SubstituteName(&quot;&quot;)__ : {1, 2, 3}) {}</div><div><br></=
div><div>std::lock_guard&lt;std::mutex&gt; __SubstituteName(&quot;&quot;)__=
(m);</div><div><br></div><div>Example for user configured name substitution=
 might look something like this:</div><div><br></div><div>int mycounter =3D=
 0;</div><div>static_string name =3D &quot;mycounter&quot;;</div><div>__Sub=
stituteName(name)__ =3D 1;<br></div><div>__SubstituteName(name)__++;<br></d=
iv><div>assert(__SubstituteName(name)__=3D=3D2);<br></div><div><br></div><d=
iv>Such a feature might with a bit of imagination (and magic) help in de-se=
rialization of a compile time string into a generated struct.</div><div><br=
></div><div>stuct __GetName(meta.name)__{</div><div><span class=3D"Apple-ta=
b-span" style=3D"white-space:pre"> </span>typename meta.vars[1].type __Subs=
tituteName(meta.vars[1].name)__;</div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre"> </span>typename meta.vars[2].type __SubstituteNam=
e(meta.vars[2].name)__;</div><div><span class=3D"Apple-tab-span" style=3D"w=
hite-space:pre"> </span>typename meta.vars[3].type __SubstituteName(meta.va=
rs[3].name)__;</div><div><span class=3D"Apple-tab-span" style=3D"white-spac=
e:pre"> </span>//...</div><div>};<br></div><div><br></div><div>It should pr=
obably play nice with the static reflection proposal. I&#39;m not familiar =
with it, but surely it uses somekind of static_string type one could use.<b=
r></div><div><br></div><div>Just my 2 cents. I haven&#39;t thought this thr=
ough much though.</div><div><br></div><div>Regards /Petke</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/b6cf3631-8c98-4cb1-8d2a-cb0b77b96ed3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b6cf3631-8c98-4cb1-8d2a-cb0b77b96ed3=
%40isocpp.org</a>.<br />

------=_Part_186_969257559.1456241089000--
------=_Part_185_876295107.1456241089000--

.

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

On Tue, Feb 23, 2016 at 3:56 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> Do you have an example of such an expression "used in a greater
expression"?

Assuming that the lifetime-extending syntax is @ in front of a temporary:

{
    auto ptr = (@std::string("hello")).c_str(); // ptr is valid till the
end of the scope
}

Cheers,
V.

--
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/CAA7YVg1oopar_hXR2B9AxWYeYpKitf7gm%2B3mwyyi-mOWDB%2BPZw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 23, 2016 at 3:56 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><div><br></div><div>&gt; Do you have an examp=
le of such an expression &quot;used in a greater expression&quot;?</div><di=
v><br></div><div>Assuming that the lifetime-extending syntax is @ in front =
of a temporary:</div><div><br></div><div>{</div><div>=C2=A0 =C2=A0 auto ptr=
 =3D (@std::string(&quot;hello&quot;)).c_str(); // ptr is valid till the en=
d of the scope<br></div><div>}</div><div><br></div><div>Cheers,</div><div>V=
..</div></div></div></div>

<p></p>

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

--001a1134bbfcad6e35052c71985a--

.

On 2016-02-23 10:28, Viacheslav Usov wrote:
> On Tue, Feb 23, 2016 at 3:56 PM, Matthew Woehlke wrote:
>> Do you have an example of such an expression "used in a greater
>> expression"?
>
> Assuming that the lifetime-extending syntax is @ in front of a temporary:
>
> {
>     auto ptr = (@std::string("hello")).c_str(); // ptr is valid till the
> end of the scope
> }

Aah...

....wasn't there a proposal floating around to do that automatically,
though? (Maybe annotating it is easier?)

--
Matthew

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

.

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

On Tue, Feb 23, 2016 at 4:41 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> ...wasn't there a proposal floating around to do that automatically,
though?

I am not aware of a such a proposal; any pointers?

If that proposal pins a temporary to the scope when it is used in some
particular way, then perhaps it would be equivalent. But then one of those
"particular ways" should include something that the equivalent of

{
    @std::lock_guard(mutex);
    // do things
}

were easily expressible.

Cheers,
V.

--
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/CAA7YVg2-dEDh-pK%3DET0DL41yM%2BbfTjGr5h%3DigkeRh2ZxK%2BdOuA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 23, 2016 at 4:41 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:</div><div class=3D"gmail_quote"><div><br></div><=
div>&gt; ...wasn&#39;t there a proposal floating around to do that automati=
cally, though?</div><div><br></div><div>I am not aware of a such a proposal=
; any pointers?</div><div><br></div><div>If that proposal pins a temporary =
to the scope when it is used in some particular way, then perhaps it would =
be equivalent. But then one of those &quot;particular ways&quot; should inc=
lude something that the equivalent of</div><div><br></div><div>{</div><div>=
=C2=A0 =C2=A0 @std::lock_guard(mutex);</div><div>=C2=A0 =C2=A0 // do things=
</div><div>}</div><div><br></div><div>were easily expressible.</div><div><b=
r></div><div>Cheers,</div><div>V.</div><div><br></div></div></div></div>

<p></p>

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

--001a113d2f8a7bc8f8052c71e436--

.

On 2016-02-23 10:49, Viacheslav Usov wrote:
> On Tue, Feb 23, 2016 at 4:41 PM, Matthew Woehlke wrote:
>> ...wasn't there a proposal floating around to do that automatically,
>> though?
>
> I am not aware of a such a proposal; any pointers?

http://wg21.link/n4221 ...and you may want to ping David Krauss (CC'd)
as to what ever happened with it, as I don't recall offhand.

> If that proposal pins a temporary to the scope when it is used in some
> particular way, then perhaps it would be equivalent. But then one of those
> "particular ways" should include something that the equivalent of
>
> {
>     @std::lock_guard(mutex);
>     // do things
> }
>
> were easily expressible.

I don't think it tried to cover this; only where the entity was still
accessible, albeit indirectly or only partially.

--
Matthew

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

.

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

On Tue, Feb 23, 2016 at 5:03 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> I don't think it tried to cover this; only where the entity was still
accessible, albeit indirectly or only partially.

It would be nice to know where that proposal stands, certainly.

Even if it gets adopted, though, I'd say an explicit lifetime extension
syntax is not useless. As far as I can tell, the proposal essentially
depends on propagating lifetime extension via export-decorated functions.
That takes an effort, and there is legacy/library code, too, so pinning a
temporary explicitly can just be easier. And it solves the anonymous
variable problem, too.

Cheers,
V.

--
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/CAA7YVg3vmdqDpFUO0uTPgepMHxPkxG%3D0cz%2BA%3D72WL2S3QKoH6w%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 23, 2016 at 5:03 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><div><br></div><div>&gt; I don&#39;t think it=
 tried to cover this; only where the entity was still accessible, albeit in=
directly or only partially.</div><div><br></div><div>It would be nice to kn=
ow where that proposal stands, certainly.</div><div><br></div><div>Even if =
it gets adopted, though, I&#39;d say an explicit lifetime extension syntax =
is not useless. As far as I can tell, the proposal essentially depends on p=
ropagating lifetime extension via export-decorated functions. That takes an=
 effort, and there is legacy/library code, too, so pinning a temporary expl=
icitly can just be easier. And it solves the anonymous variable problem, to=
o.</div><div><br></div><div>Cheers,</div><div>V.</div><div><br></div></div>=
</div></div>

<p></p>

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

--001a113e24b4d5ba46052c72a52a--

.

Matthew Woehlke <mwoehlke.floss@gmail.com> writes:

> On 2016-02-22 18:32, Moritz Klammler wrote:
>> I'm excited that this is getting attention because I was thinking about
>> proposing a feature for this, too.
>>
>> I don't think that macro magic like `__COUNTER__` that was mentioned by
>> somebody is a solution.  It is too cumbersome in header files due to
>> potential ODR violations.
>>
>> My preferred syntax for such a variable would be to simple not give it a
>> name.
>>
>>     auto /* anonymous */ = std::unique_lock<std::mutex> { ... };
>
> That's the idea behind using `.`... `.` is not a name, but it's a
> syntactic placeholder. My concern with omitting *any* name (or
> placeholder) is that there may be syntactic ambiguities that arise as a
> result.

I understand that but I'd prefer if we culd do without adding yet
another magic token.  `...` is already heavily used (and yet quite
consistently).  `.` might be a smart trick, although a little too smart
for my taste.  `_` and `__` have already been discussed at length
before.  In particular, I wouldn't like special-casing along the lines
of "if the identifier is defined more than once, magic happens".  But I
think we have agreement here.

>> This would be consistent with (default) parameters in templates and
>> functions.
>>
>>     template <typename, typename = int>
>>     void foo(double, std::string = "anonymous");
>
> Why is that valuable? I don't see how the two are related.

Well, I don't have a mathematical proof for my stylistic preferences but
isn't it the case that in

    static std::mutex mtx {};  // global variable

    void
    synchronized(const std::string& msg,
                 std::unique_lock<std::mutex> = std::unique_lock<std::mutex> {mtx})
    {
      std::cout << msg << std::endl;
    }

we basically have the same thing as we would have in

    void
    synchronized(const std::string& msg)
    {
      static std::mutex mtx {};
      auto = std::unique_lock<std::mutex> {mtx};
      std::cout << msg << std::endl;
    }

would the syntax be allowed?

It's not exactly the same because the parameter is constructed before
the function body is entered and the anonymous scoped variable in the
body is only created after that but from the user's point of view, I see
many parallels.

Most fundamentally, in both cases we want to have a variable with a
certain value and well-defined life-time but don't bother giving it a
name because we never access it again.

And because the syntax

    <type> [ <identifier> ] [ '=' <expression> ]

is already used elsewhere, it would seem natural and easy-to-explain to
me if we would re-use it 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/87povnjj50.fsf%40gmail.com.

.

On ter=C3=A7a-feira, 23 de fevereiro de 2016 07:24:48 PST Patrik wrote:
> It should probably play nice with the static reflection proposal. I'm not=
=20
> familiar with it, but surely it uses somekind of static_string type one=
=20
> could use.

Not in the way you're talking about.

Reflection is about obtaining information about types that exist, not about=
=20
modifying them or generating code.

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

--=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/6226346.ZkjeafXDGD%40tjmaciei-mobl4.

.

------=_Part_935_1490889143.1456331513888
Content-Type: multipart/alternative;
 boundary="----=_Part_936_173150117.1456331513888"

------=_Part_936_173150117.1456331513888
Content-Type: text/plain; charset=UTF-8

I think we will need something like this for sure if C++ continues
expanding on (more) pattern matching functionality, in particular
"structural bindings" and case/match expressions, especially with
nested-patterns. In other languages with pattern matching support _ is
usually called a wildcard (binding) pattern and means to "match anything".
In those languages _ isn't a variable and I don't think it's a good idea to
be standardized as a variable, I think it should be part of the syntax
sub-grammars for pattern-expressions. If that's not possible due to
conflicts with existing code that has _ variables then use another symbol?

On Friday, February 19, 2016 at 8:05:04 PM UTC, Dmitry Banshchikov wrote:
>
> Hi!
>
> Does anyone see helpfulness of such solution:
>
> for(auto _ : {1, 2, 3})
> {
> }
>
> Variable with name "_" has an implicit unused attribute set.
>
>
> --
>
> Dmitry Banschikov
>

--
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/c6b7a2ed-3af0-4f36-9b9b-7de60ada33b0%40isocpp.org.

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

<div dir=3D"ltr">I think we will need something like this for sure if C++ c=
ontinues expanding on (more) pattern matching functionality, in particular =
&quot;structural bindings&quot; and case/match expressions, especially with=
 nested-patterns. In other languages with pattern matching support _ is usu=
ally called a wildcard (binding) pattern and means to &quot;match anything&=
quot;. In those languages _ isn&#39;t a variable and I don&#39;t think it&#=
39;s a good idea to be standardized as a variable, I think it should be par=
t of the syntax sub-grammars for pattern-expressions. If that&#39;s not pos=
sible due to conflicts with existing code that has _ variables then use ano=
ther symbol?<div><br><div><div><div><div><div>On Friday, February 19, 2016 =
at 8:05:04 PM UTC, Dmitry Banshchikov wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><span style=3D"font-family:arial,sans-s=
erif;font-size:small">Hi!</span><br style=3D"font-family:arial,sans-serif;f=
ont-size:small"><br style=3D"font-family:arial,sans-serif;font-size:small">=
<span style=3D"font-family:arial,sans-serif;font-size:small">Does anyone se=
e helpfulness of such solution:</span><br style=3D"font-family:arial,sans-s=
erif;font-size:small"><br style=3D"font-family:arial,sans-serif;font-size:s=
mall"><span style=3D"font-family:arial,sans-serif;font-size:small">for(auto=
 _ : {1, 2, 3})</span><br style=3D"font-family:arial,sans-serif;font-size:s=
mall"><span style=3D"font-family:arial,sans-serif;font-size:small">{</span>=
<br style=3D"font-family:arial,sans-serif;font-size:small"><span style=3D"f=
ont-family:arial,sans-serif;font-size:small">}</span><br style=3D"font-fami=
ly:arial,sans-serif;font-size:small"><br style=3D"font-family:arial,sans-se=
rif;font-size:small"><span style=3D"font-family:arial,sans-serif;font-size:=
small">Variable with name &quot;_&quot; has an implicit unused attribute se=
t.</span><br></div><div><br></div><div><br></div><div>--=C2=A0</div><div><b=
r></div><div>Dmitry Banschikov</div></div></blockquote></div></div></div></=
div></div></div></div>

<p></p>

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

------=_Part_936_173150117.1456331513888--
------=_Part_935_1490889143.1456331513888--

.

On quarta-feira, 24 de fevereiro de 2016 08:31:53 PST 'snk_kid' via ISO C++=
=20
Standard - Future Proposals wrote:
> If that's not possible due to=20
> conflicts with existing code that has _ variables then use another symbol=
?

It's about 40 years too late to change the meaning of _. Using other symbol=
s=20
has the problem that we're out of characters from the basic character set.

The symbol characters allowed are:

_ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ~ ! =3D , \ " =E2=80=99

All of those are already in use.

We'd need a compound identifier (more than one character), like digraphs do=
..

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

--=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/1669265.e0sitpsIiN%40tjmaciei-mobl4.

.

On 2/24/2016 3:01 PM, Thiago Macieira wrote:
> On quarta-feira, 24 de fevereiro de 2016 08:31:53 PST 'snk_kid' via ISO C=
++
> Standard - Future Proposals wrote:
>> If that's not possible due to
>> conflicts with existing code that has _ variables then use another symbo=
l?
> It's about 40 years too late to change the meaning of _. Using other symb=
ols
> has the problem that we're out of characters from the basic character set=
..
>
> The symbol characters allowed are:
>
> _ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ~ ! =3D , \ " =E2=80=99
>
> All of those are already in use.
>
> We'd need a compound identifier (more than one character), like digraphs =
do.
>
Or we add @ or $ or ` or ... to the basic source character set :)

Tom.

--=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/56CE1C23.3050109%40honermann.net.

.

--Apple-Mail=_BC265C96-821F-487D-92A3-F797D866753D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2016=E2=80=9302=E2=80=9324, at 12:03 AM, Matthew Woehlke <mwoehlke.flo=
ss@gmail.com> wrote:
>=20
> On 2016-02-23 10:49, Viacheslav Usov wrote:
>> On Tue, Feb 23, 2016 at 4:41 PM, Matthew Woehlke wrote:
>>> ...wasn't there a proposal floating around to do that automatically,
>>> though?
>>=20
>> I am not aware of a such a proposal; any pointers?
>=20
> http://wg21.link/n4221 ...and you may want to ping David Krauss (CC'd)
> as to what ever happened with it, as I don't recall offhand.

The EWG consensus on N4221 was that it didn=E2=80=99t support generic progr=
amming well enough. I revised it as P0066R0, but that was found to be too c=
omplicated, and also too open-ended for the included analysis.

I hope to revise it eventually, but it has some distance to go. In particul=
ar, there are too many manual annotations required. It would be better to a=
nnotate classes that are iterators, containers, views, etc., and then funct=
ions would adjust automatically.

A prototype is available at https://github.com/potswa/clang/tree/lifetime_e=
xtension <https://github.com/potswa/clang/tree/lifetime_extension>. It work=
s up to conversions (casts) between the new function types, and automatic a=
nnotation of implicitly-declared members. (I should add some documentation!=
) Since the feature is intended to be open-ended, and the analysis in P0066=
R0 is already voluminous, significant field testing and user testimonials w=
ould need to happen before it could go back to ISO.

>> If that proposal pins a temporary to the scope when it is used in some
>> particular way, then perhaps it would be equivalent. But then one of tho=
se
>> "particular ways" should include something that the equivalent of
>>=20
>> {
>>    @std::lock_guard(mutex);
>>    // do things
>> }
>>=20
>> were easily expressible.
>=20
> I don't think it tried to cover this; only where the entity was still
> accessible, albeit indirectly or only partially.

Right. Actually, immediately before N4221, I presented another proposal abo=
ut scope guards, N4149 <http://wg21.link/N4149>. It annotated such classes =
with &, where && was given some =E2=80=9Copposite=E2=80=9D meaning. EWG was=
 open to annotating guard classes and suggested to split and specialize tha=
t aspect.

A guard class always instantiates a guard variable, and that=E2=80=99s why =
anonymity works for them. So, I think decorating the class should work well=
, and we might not need anonymous variables of other arbitrary types.

--=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/C34478BB-6220-4DAD-8216-DBA2F7AD64E3%40gmail.com=
..

--Apple-Mail=_BC265C96-821F-487D-92A3-F797D866753D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9302=
=E2=80=9324, at 12:03 AM, Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.fl=
oss@gmail.com" class=3D"">mwoehlke.floss@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">On 2016=
-02-23 10:49, Viacheslav Usov wrote:<br class=3D""><blockquote type=3D"cite=
" class=3D"">On Tue, Feb 23, 2016 at 4:41 PM, Matthew Woehlke wrote:<br cla=
ss=3D""><blockquote type=3D"cite" class=3D"">...wasn't there a proposal flo=
ating around to do that automatically,<br class=3D"">though?<br class=3D"">=
</blockquote><br class=3D"">I am not aware of a such a proposal; any pointe=
rs?<br class=3D""></blockquote><br class=3D""><a href=3D"http://wg21.link/n=
4221" class=3D"">http://wg21.link/n4221</a> ...and you may want to ping Dav=
id Krauss (CC'd)<br class=3D"">as to what ever happened with it, as I don't=
 recall offhand.<br class=3D""></div></div></blockquote><div><br class=3D""=
></div><div>The EWG consensus on N4221 was that it didn=E2=80=99t support g=
eneric programming well enough. I revised it as P0066R0, but that was found=
 to be too complicated, and also too open-ended for the included analysis.<=
/div><div><br class=3D""></div><div>I hope to revise it eventually, but it =
has some distance to go. In particular, there are too many manual annotatio=
ns required. It would be better to annotate classes that are iterators, con=
tainers, views, etc., and then functions would adjust automatically.</div><=
div><br class=3D""></div><div>A prototype is available at&nbsp;<a href=3D"h=
ttps://github.com/potswa/clang/tree/lifetime_extension" class=3D"">https://=
github.com/potswa/clang/tree/lifetime_extension</a>. It works up to convers=
ions (casts) between the new function types, and automatic annotation of im=
plicitly-declared members. (I should add some documentation!) Since the fea=
ture is&nbsp;intended to be open-ended, and the analysis in P0066R0 is alre=
ady voluminous, significant field testing and user testimonials would need =
to happen before it could go back to ISO.</div><br class=3D""><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><div class=3D""><blockquote type=3D=
"cite" class=3D"">If that proposal pins a temporary to the scope when it is=
 used in some<br class=3D"">particular way, then perhaps it would be equiva=
lent. But then one of those<br class=3D"">"particular ways" should include =
something that the equivalent of<br class=3D""><br class=3D"">{<br class=3D=
""> &nbsp;&nbsp;&nbsp;@std::lock_guard(mutex);<br class=3D""> &nbsp;&nbsp;&=
nbsp;// do things<br class=3D"">}<br class=3D""><br class=3D"">were easily =
expressible.<br class=3D""></blockquote><br class=3D"">I don't think it tri=
ed to cover this; only where the entity was still<br class=3D"">accessible,=
 albeit indirectly or only partially.<br class=3D""></div></div></blockquot=
e></div><br class=3D""><div class=3D"">Right. Actually, immediately before =
N4221, I presented another proposal about scope guards,&nbsp;<a href=3D"htt=
p://wg21.link/N4149" class=3D"">N4149</a>. It annotated such classes with <=
font face=3D"Courier" class=3D"">&amp;</font>, where <font face=3D"Courier"=
 class=3D"">&amp;&amp;</font> was given some =E2=80=9Copposite=E2=80=9D mea=
ning. EWG was open to annotating guard classes and suggested to split and s=
pecialize that aspect.</div><div class=3D""><br class=3D""></div><div class=
=3D"">A guard class always instantiates a guard variable, and that=E2=80=99=
s why anonymity works for them. So, I think decorating the class should wor=
k well, and we might not need anonymous variables of other arbitrary types.=
</div><div class=3D""><br class=3D""></div></body></html>

<p></p>

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

--Apple-Mail=_BC265C96-821F-487D-92A3-F797D866753D--

.

------=_Part_6_50316643.1456453497706
Content-Type: multipart/alternative;
 boundary="----=_Part_7_524642676.1456453497706"

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



On Wednesday, February 24, 2016 at 3:01:40 PM UTC-5, Thiago Macieira wrote:
>
> On quarta-feira, 24 de fevereiro de 2016 08:31:53 PST 'snk_kid' via ISO=
=20
> C++=20
> Standard - Future Proposals wrote:=20
> > If that's not possible due to=20
> > conflicts with existing code that has _ variables then use another=20
> symbol?=20
>
> It's about 40 years too late to change the meaning of _. Using other=20
> symbols=20
> has the problem that we're out of characters from the basic character set=
..=20
>
> The symbol characters allowed are:=20
>
> _ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ~ ! =3D , \ " =E2=80=99=20
>
> All of those are already in use.=20
>
> We'd need a compound identifier (more than one character), like digraphs=
=20
> do.=20
>

Do we? What are the syntactic issues around making this work:

auto =3D <insert expression here>;

Note that I'm being as conservative as possible here. It would *only* be=20
allowed for `auto` (or `decltype(auto)` perhaps?), and you could only=20
declare one such variable at a time.

It's not an ideal syntax, but I think it's workable given the problem=20
domain.

--=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/f0a2eeb8-8f66-47c4-8c9b-47c2d100b1cc%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Wednesday, February 24, 2016 at 3:01:40 PM UTC-=
5, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On qu=
arta-feira, 24 de fevereiro de 2016 08:31:53 PST &#39;snk_kid&#39; via ISO =
C++=20
<br>Standard - Future Proposals wrote:
<br>&gt; If that&#39;s not possible due to=20
<br>&gt; conflicts with existing code that has _ variables then use another=
 symbol?
<br>
<br>It&#39;s about 40 years too late to change the meaning of _. Using othe=
r symbols=20
<br>has the problem that we&#39;re out of characters from the basic charact=
er set.
<br>
<br>The symbol characters allowed are:
<br>
<br>_ { } [ ] # ( ) &lt; &gt; % : ; . ? * + - / ^ &amp; | ~ ! =3D , \ &quot=
; =E2=80=99
<br>
<br>All of those are already in use.
<br>
<br>We&#39;d need a compound identifier (more than one character), like dig=
raphs do.
<br></blockquote><div><br>Do we? What are the syntactic issues around makin=
g this work:<br><br><div class=3D"prettyprint" style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">auto</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"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">insert expression here</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;;</span></di=
v></code></div><br>Note that I&#39;m being as conservative as possible here=
.. It would <i>only</i> be allowed for `auto` (or `decltype(auto)` perhaps?)=
, and you could only declare one such variable at a time.<br><br>It&#39;s n=
ot an ideal syntax, but I think it&#39;s workable given the problem domain.=
<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/f0a2eeb8-8f66-47c4-8c9b-47c2d100b1cc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f0a2eeb8-8f66-47c4-8c9b-47c2d100b1cc=
%40isocpp.org</a>.<br />

------=_Part_7_524642676.1456453497706--
------=_Part_6_50316643.1456453497706--

.

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

On Thu, Feb 25, 2016 at 5:25 PM, David Krauss <potswa@gmail.com> wrote:

> Right. Actually, immediately before N4221, I presented another proposal
about scope guards, N4149 <http://wg21.link/N4149>. It annotated such
classes with &, where && was given some =E2=80=9Copposite=E2=80=9D meaning.=
 EWG was open to
annotating guard classes and suggested to split and specialize that aspect.

A problem with that approach is that the semantics of, e.g.,
std::lock_guard(mutex), will be very different (correct or seriously
flawed) depending on what implementation is being used. With the pretty
much unavoidably uneven state of the field, that is dangerous. But that's
always the case with semantics changing silently and profoundly, so it is
surprising EWG was so relaxed about that.

Cheers,
V.

--=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/CAA7YVg3ZXXtgXTw_YNiNtqZzesusd5e8gN-7Q_ULdv-Mgj6=
nVA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Feb 25, 2016 at 5:25 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> =
wrote:<br><div><br></div><div>&gt; Right. Actually, immediately before N422=
1, I presented another proposal about scope guards,=C2=A0<a href=3D"http://=
wg21.link/N4149" target=3D"_blank">N4149</a>. It annotated such classes wit=
h <font face=3D"Courier">&amp;</font>, where <font face=3D"Courier">&amp;&a=
mp;</font> was given some =E2=80=9Copposite=E2=80=9D meaning. EWG was open =
to annotating guard classes and suggested to split and specialize that aspe=
ct.</div><div><br></div><div>A problem with that approach is that the seman=
tics of, e.g., std::lock_guard(mutex), will be very different (correct or s=
eriously flawed) depending on what implementation is being used. With the p=
retty much unavoidably uneven state of the field, that is dangerous. But th=
at&#39;s always the case with semantics changing silently and profoundly, s=
o it is surprising EWG was so relaxed about that.<br></div><div><br></div><=
div>Cheers,</div><div>V.</div></div></div></div>

<p></p>

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

--089e01177a6d6bd216052cab9491--

.

Nicol Bolas <jmckesson@gmail.com> writes:

> [...]
>
> Do we? What are the syntactic issues around making this work:
>
> auto = <insert expression here>;
>
> Note that I'm being as conservative as possible here. It would *only*
> be allowed for `auto` (or `decltype(auto)` perhaps?), and you could
> only declare one such variable at a time.
>
> It's not an ideal syntax, but I think it's workable given the problem
> domain.

As mentioned earlier, this would be my preferred syntax, too.  I
actually believe it *would* be "ideal".  If you don't want to name a
thing -- just don't give it a name.  Same as with parameter
declarations.

--
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/87vb5bd1w2.fsf%40gmail.com.

.

--Apple-Mail=_3195D9C9-F3E1-4B55-AFEF-8267DD48254A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2016=E2=80=9302=E2=80=9326, at 8:38 PM, Viacheslav Usov <via.usov@gmai=
l.com> wrote:
>=20
> On Thu, Feb 25, 2016 at 5:25 PM, David Krauss <potswa@gmail.com <mailto:p=
otswa@gmail.com>> wrote:
>=20
> > Right. Actually, immediately before N4221, I presented another proposal=
 about scope guards, N4149 <http://wg21.link/N4149>. It annotated such clas=
ses with &, where && was given some =E2=80=9Copposite=E2=80=9D meaning. EWG=
 was open to annotating guard classes and suggested to split and specialize=
 that aspect.
>=20
> A problem with that approach is that the semantics of, e.g., std::lock_gu=
ard(mutex), will be very different (correct or seriously flawed) depending =
on what implementation is being used. With the pretty much unavoidably unev=
en state of the field, that is dangerous. But that's always the case with s=
emantics changing silently and profoundly, so it is surprising EWG was so r=
elaxed about that.

I don=E2=80=99t quite follow. In this case, std::lock_guard would be annota=
ted, for example,

template <class... MutexTypes>
class lock_guard guard { // contextual keyword
    =E2=80=A6
};

Then the user would be free to simply omit the declarator:

std::mutex m;
void foo() {
    std::lock_guard( m ); // expression-statement comprising a conversion e=
xpression
    do_something();
    do_next_thing();
    // release lock.
}

The benefit is that the common mistake is restored to correct working order=
..

Do you mean that this would be dangerous with user-defined guards?

std::mutex m;
template< typename locker >
void foo() {
    locker( m ); // idiomatic
    do_something();
    do_next_thing();
    // release lock.
}

void bar() {
    foo< old_library::custom_lock >(); // Danger!
}

Indeed, the flip side of blessing any common lazy error is that everyone wi=
ll start doing it.

If this is what you mean, it implies that an opt-in is necessary. I don=E2=
=80=99t think any opt-in solution is worth the effort, because if I can rem=
ember to use the anonymizing feature,  then I can remember to name the vari=
able. 99% of guards do not share their scope with another guard, and so the=
y can all be named guard.

It happens that guards are often generated by macros, but then you can alwa=
ys get a unique name like MY_LIB_GUARD##__LINE__. Ugly perhaps, but it=E2=
=80=99s uniform with what macros ordinarily do. The corner cases left behin=
d are minuscule. (And just to be clear, you don=E2=80=99t need this unless =
you=E2=80=99re already inside a macro definition.)

Checking EWG 35, its motivation is also generating multiple guard variables=
 on a single line from a macro. Just my 2=C2=A2, I guess, but while macro h=
acks are bad, macro catenation isn=E2=80=99t really a hack if you=E2=80=99r=
e already inside a macro. The naming convention used by a macro is at least=
 somewhat meaningful, and pulling names out of thin air could make it total=
ly impossible to figure out the provenance of an anonymous variable.

A preprocessor-like feature baked into the core language is still as bad as=
 (even worse than) using the preprocessor.

--=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/3DA36452-20AF-4E7A-B99A-D0A099ACCDD4%40gmail.com=
..

--Apple-Mail=_3195D9C9-F3E1-4B55-AFEF-8267DD48254A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9302=
=E2=80=9326, at 8:38 PM, Viacheslav Usov &lt;<a href=3D"mailto:via.usov@gma=
il.com" class=3D"">via.usov@gmail.com</a>&gt; wrote:</div><br class=3D"Appl=
e-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote">On Thu, Feb 25, 2016 at 5:25 =
PM, David Krauss <span dir=3D"ltr" class=3D"">&lt;<a href=3D"mailto:potswa@=
gmail.com" target=3D"_blank" class=3D"">potswa@gmail.com</a>&gt;</span> wro=
te:<br class=3D""><div class=3D""><br class=3D""></div><div class=3D"">&gt;=
 Right. Actually, immediately before N4221, I presented another proposal ab=
out scope guards,&nbsp;<a href=3D"http://wg21.link/N4149" target=3D"_blank"=
 class=3D"">N4149</a>. It annotated such classes with <font face=3D"Courier=
" class=3D"">&amp;</font>, where <font face=3D"Courier" class=3D"">&amp;&am=
p;</font> was given some =E2=80=9Copposite=E2=80=9D meaning. EWG was open t=
o annotating guard classes and suggested to split and specialize that aspec=
t.</div><div class=3D""><br class=3D""></div><div class=3D"">A problem with=
 that approach is that the semantics of, e.g., std::lock_guard(mutex), will=
 be very different (correct or seriously flawed) depending on what implemen=
tation is being used. With the pretty much unavoidably uneven state of the =
field, that is dangerous. But that's always the case with semantics changin=
g silently and profoundly, so it is surprising EWG was so relaxed about tha=
t.<br class=3D""></div></div></div></div></div></blockquote><div><br class=
=3D""></div><div>I don=E2=80=99t quite follow. In this case, <font face=3D"=
Courier" class=3D"">std::lock_guard</font> would be annotated, for example,=
</div><div><br class=3D""></div><div class=3D""><font face=3D"Courier" clas=
s=3D"">template &lt;class... MutexTypes&gt;</font></div><div><font face=3D"=
Courier" class=3D"">class lock_guard guard { // contextual keyword</font></=
div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; =E2=80=A6</font></=
div><div><font face=3D"Courier" class=3D"">};</font></div><div><br class=3D=
""></div><div>Then the user would be free to simply omit the declarator:</d=
iv><div><br class=3D""></div><div><font face=3D"Courier" class=3D"">std::mu=
tex m;</font></div><div><font face=3D"Courier" class=3D"">void foo() {</fon=
t></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; std::lock_guar=
d( m ); // expression-statement comprising a conversion expression</font></=
div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; do_something();</f=
ont></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; do_next_thin=
g();</font></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; // re=
lease lock.</font></div><div><font face=3D"Courier" class=3D"">}</font></di=
v><div><br class=3D""></div><div>The benefit is that the common mistake is =
restored to correct working order.</div><div><br class=3D""></div><div>Do y=
ou mean that this would be dangerous with user-defined guards?</div><div><b=
r class=3D""></div><div><div><font face=3D"Courier" class=3D"">std::mutex m=
;</font></div><div><font face=3D"Courier" class=3D"">template&lt; typename =
locker &gt;</font></div><div><font face=3D"Courier" class=3D"">void foo() {=
</font></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; locker( m=
 ); // idiomatic</font></div><div><font face=3D"Courier" class=3D"">&nbsp; =
&nbsp; do_something();</font></div><div><font face=3D"Courier" class=3D"">&=
nbsp; &nbsp; do_next_thing();</font></div><div><font face=3D"Courier" class=
=3D"">&nbsp; &nbsp; // release lock.</font></div><div><font face=3D"Courier=
" class=3D"">}</font></div><div class=3D""><br class=3D""></div><div class=
=3D""><font face=3D"Courier" class=3D"">void bar() {</font></div><div class=
=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; foo&lt; old_library::=
custom_lock &gt;(); // Danger!</font></div><div class=3D""><font face=3D"Co=
urier" class=3D"">}</font></div></div><div><br class=3D""></div><div>Indeed=
, the flip side of blessing any common lazy error is that everyone will sta=
rt doing it.</div><div><br class=3D""></div><div>If this is what you mean, =
it implies that an opt-in is necessary. I don=E2=80=99t think any opt-in so=
lution is worth the effort, because if I can remember to use the anonymizin=
g feature, &nbsp;then I can remember to name the variable. 99% of guards do=
 not share their scope with another guard, and so they can all be named <fo=
nt face=3D"Courier" class=3D"">guard</font>.</div><div><br class=3D""></div=
><div>It happens that guards are often generated by macros, but then you ca=
n always get a unique name like&nbsp;<font face=3D"Courier" class=3D"">MY_L=
IB_GUARD##__LINE__</font>. Ugly perhaps, but it=E2=80=99s uniform with what=
 macros ordinarily do. The corner cases left behind are minuscule. (And jus=
t to be clear, you don=E2=80=99t need this unless you=E2=80=99re <i class=
=3D"">already</i>&nbsp;inside a macro definition.)</div><div><br class=3D""=
></div><div>Checking EWG 35, its motivation is also generating multiple gua=
rd variables on a single line from a macro. Just my 2=C2=A2, I guess, but w=
hile macro hacks are bad, macro catenation isn=E2=80=99t really a hack if y=
ou=E2=80=99re already inside a macro. The naming convention used by a macro=
 is at least somewhat meaningful, and pulling names out of thin air could m=
ake it totally impossible to figure out the provenance of an anonymous vari=
able.</div><div><br class=3D""></div><div>A preprocessor-like feature baked=
 into the core language is still as bad as (even worse than) using the prep=
rocessor.</div><div><br class=3D""></div></div></body></html>

<p></p>

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

--Apple-Mail=_3195D9C9-F3E1-4B55-AFEF-8267DD48254A--

.

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

On Fri, Feb 26, 2016 at 3:31 PM, David Krauss <potswa@gmail.com> wrote:

> Do you mean that this would be dangerous with user-defined guards?

That too, but I am more concerned about things like std::lock_guard that in
today's implementations would normally need to be used as

{
    lock_guard lg(mutex);
    // ...
}

When it becomes possible to use them as

{
    lock_guard(mutex);
    // ...
}

They will get used as such, but then if the code using them migrates to the
old (today's) implementations, it will become silently broken. In the
particular case of locking, breakage can easily make it into production,
when everything works most of the time, but misbehaves sometimes, and it is
about impossible to repro and debug that.

An opt-in seems definitely in order, and, as you say, it's worthwhile only
if it is more trivial in use than the current practice. Something like a
new postfix expression extending the lifetime of a temporary could do it.

Cheers,
V.

--
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/CAA7YVg1JsRv6aBVUiRPmr0qmav%2B%2Bfo1JCbUmxLmFKSmWpg-mKw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 26, 2016 at 3:31 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> =
wrote:</div><div class=3D"gmail_quote"><div><br></div><div>&gt; Do you mean=
 that this would be dangerous with user-defined guards?</div><div><br></div=
><div>That too, but I am more concerned about things like std::lock_guard t=
hat in today&#39;s implementations would normally need to be used as</div><=
div><br></div><div>{</div><div>=C2=A0 =C2=A0 lock_guard lg(mutex);</div><di=
v>=C2=A0 =C2=A0 // ...</div><div>}</div><div><br></div><div>When it becomes=
 possible to use them as</div><div><br></div><div><div>{</div><div>=C2=A0 =
=C2=A0 lock_guard(mutex);</div><div>=C2=A0 =C2=A0 // ...</div><div>}</div><=
/div><div><br></div><div>They will get used as such, but then if the code u=
sing them migrates to the old (today&#39;s) implementations, it will become=
 silently broken. In the particular case of locking, breakage can easily ma=
ke it into production, when everything works most of the time, but misbehav=
es sometimes, and it is about impossible to repro and debug that.</div><div=
><br></div><div>An opt-in seems definitely in order, and, as you say, it&#3=
9;s worthwhile only if it is more trivial in use than the current practice.=
 Something like a new postfix expression extending the lifetime of a tempor=
ary could do it.</div><div><br></div><div>Cheers,</div><div>V.</div></div><=
/div></div>

<p></p>

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

--001a11c3029e5dc1ab052cad75b2--

.

------=_Part_876_680658607.1456506466437
Content-Type: multipart/alternative;
 boundary="----=_Part_877_753707367.1456506466438"

------=_Part_877_753707367.1456506466438
Content-Type: text/plain; charset=UTF-8



On Friday, February 26, 2016 at 10:53:14 PM UTC+8, Viacheslav Usov wrote:
>
> On Fri, Feb 26, 2016 at 3:31 PM, David Krauss <pot...@gmail.com
> <javascript:>> wrote:
>
> > Do you mean that this would be dangerous with user-defined guards?
>
> That too, but I am more concerned about things like std::lock_guard that
> in today's implementations would normally need to be used as
>
> {
>     lock_guard lg(mutex);
>     // ...
> }
>
> When it becomes possible to use them as
>
> {
>     lock_guard(mutex);
>     // ...
> }
>
> They will get used as such, but then if the code using them migrates to
> the old (today's) implementations, it will become silently broken. In the
> particular case of locking, breakage can easily make it into production,
> when everything works most of the time, but misbehaves sometimes, and it is
> about impossible to repro and debug that.
>
> An opt-in seems definitely in order, and, as you say, it's worthwhile only
> if it is more trivial in use than the current practice. Something like a
> new postfix expression extending the lifetime of a temporary could do it.
>
> Cheers,
> V.
>


Assuming that lock_guard is a type, `lock_guard(mutex);` is a declaration
of a lock_guard called 'mutex' (which is error because you can't
default-construct a lock_guard).

If you want this to work, you'll have to change the disambiguation rule too.

--
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/4616836c-6060-42cf-887b-b365a7fd30bc%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, February 26, 2016 at 10:53:14 PM UTC+8,=
 Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Feb 26, 2016 at 3:31 PM, =
David Krauss <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"fG7Im77qAgAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;j=
avascript:&#39;;return true;">pot...@gmail.com</a>&gt;</span> wrote:</div><=
div class=3D"gmail_quote"><div><br></div><div>&gt; Do you mean that this wo=
uld be dangerous with user-defined guards?</div><div><br></div><div>That to=
o, but I am more concerned about things like std::lock_guard that in today&=
#39;s implementations would normally need to be used as</div><div><br></div=
><div>{</div><div>=C2=A0 =C2=A0 lock_guard lg(mutex);</div><div>=C2=A0 =C2=
=A0 // ...</div><div>}</div><div><br></div><div>When it becomes possible to=
 use them as</div><div><br></div><div><div>{</div><div>=C2=A0 =C2=A0 lock_g=
uard(mutex);</div><div>=C2=A0 =C2=A0 // ...</div><div>}</div></div><div><br=
></div><div>They will get used as such, but then if the code using them mig=
rates to the old (today&#39;s) implementations, it will become silently bro=
ken. In the particular case of locking, breakage can easily make it into pr=
oduction, when everything works most of the time, but misbehaves sometimes,=
 and it is about impossible to repro and debug that.</div><div><br></div><d=
iv>An opt-in seems definitely in order, and, as you say, it&#39;s worthwhil=
e only if it is more trivial in use than the current practice. Something li=
ke a new postfix expression extending the lifetime of a temporary could do =
it.</div><div><br></div><div>Cheers,</div><div>V.</div></div></div></div></=
blockquote><div><br></div><div><br></div><div>Assuming that lock_guard is a=
 type, `lock_guard(mutex);` is a declaration of a lock_guard called &#39;mu=
tex&#39; (which is error because you can&#39;t default-construct a lock_gua=
rd).=C2=A0</div><div><br></div><div>If you want this to work, you&#39;ll ha=
ve to change the disambiguation rule too.</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/4616836c-6060-42cf-887b-b365a7fd30bc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4616836c-6060-42cf-887b-b365a7fd30bc=
%40isocpp.org</a>.<br />

------=_Part_877_753707367.1456506466438--
------=_Part_876_680658607.1456506466437--

.

--Apple-Mail=_8C487201-50E9-481E-8A4C-C7F7D5D7E30E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2016=E2=80=9302=E2=80=9327, at 1:07 AM, T. C. <rs2740@gmail.com> wrote=
:
>=20
> Assuming that lock_guard is a type, `lock_guard(mutex);` is a declaration=
 of a lock_guard called 'mutex' (which is error because you can't default-c=
onstruct a lock_guard).=20
>=20
> If you want this to work, you'll have to change the disambiguation rule t=
oo.

Yeah. Tricky, but doable. At least the parser has the benefit of having see=
n the decl-specifier-seq, so it can look up std::lock_guard. If that names =
a complete guard class type, then don=E2=80=99t parse parentheses in the de=
clarator. (And of course that=E2=80=99s a breaking change for existing decl=
arations like std::lock_guard (guard)( m );. A proposer might try to convin=
ce EWG that such things don=E2=80=99t exist in practice.)

--=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/9F5C1B1E-626A-4F0F-B4E5-9399FC669184%40gmail.com=
..

--Apple-Mail=_8C487201-50E9-481E-8A4C-C7F7D5D7E30E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9302=
=E2=80=9327, at 1:07 AM, T. C. &lt;<a href=3D"mailto:rs2740@gmail.com" clas=
s=3D"">rs2740@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-=
newline"><div class=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: nor=
mal; letter-spacing: normal; orphans: auto; text-align: start; text-indent:=
 0px; text-transform: none; white-space: normal; widows: auto; word-spacing=
: 0px; -webkit-text-stroke-width: 0px;" class=3D""><div class=3D"">Assuming=
 that lock_guard is a type, `lock_guard(mutex);` is a declaration of a lock=
_guard called 'mutex' (which is error because you can't default-construct a=
 lock_guard).&nbsp;</div><div class=3D""><br class=3D""></div><div class=3D=
"">If you want this to work, you'll have to change the disambiguation rule =
too.</div></div></div></blockquote><div><br class=3D""></div><div>Yeah. Tri=
cky, but doable. At least the parser has the benefit of having seen the <i =
class=3D"">decl-specifier-seq</i>, so it can look up <font face=3D"Courier"=
 class=3D"">std::lock_guard</font>. If that names a complete&nbsp;<span sty=
le=3D"font-family: Courier;" class=3D"">guard</span>&nbsp;class type,&nbsp;=
then don=E2=80=99t parse parentheses in the declarator. (And of course that=
=E2=80=99s a breaking change for existing declarations like <font face=3D"C=
ourier" class=3D"">std::lock_guard (guard)( m );</font>. A proposer might t=
ry to convince EWG that such things don=E2=80=99t exist in practice.)</div>=
<div><br class=3D""></div></div></body></html>

<p></p>

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

--Apple-Mail=_8C487201-50E9-481E-8A4C-C7F7D5D7E30E--

.

------=_Part_226_20889153.1456746908334
Content-Type: multipart/alternative;
 boundary="----=_Part_227_885645772.1456746908334"

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

Le samedi 27 f=C3=A9vrier 2016 02:11:59 UTC+1, David Krauss a =C3=A9crit :
>
>
> On 2016=E2=80=9302=E2=80=9327, at 1:07 AM, T. C. <rs2...@gmail.com <javas=
cript:>> wrote:
>
> Assuming that lock_guard is a type, `lock_guard(mutex);` is a declaration=
=20
> of a lock_guard called 'mutex' (which is error because you can't=20
> default-construct a lock_guard).=20
>
> If you want this to work, you'll have to change the disambiguation rule=
=20
> too.
>
>
> Yeah. Tricky, but doable. At least the parser has the benefit of having=
=20
> seen the *decl-specifier-seq*, so it can look up std::lock_guard. If that=
=20
> names a complete guard class type, then don=E2=80=99t parse parentheses i=
n the=20
> declarator. (And of course that=E2=80=99s a breaking change for existing=
=20
> declarations like std::lock_guard (guard)( m );. A proposer might try to=
=20
> convince EWG that such things don=E2=80=99t exist in practice.)
>
>
I'm pretty sure I've seen that used in C for simple functions for which a=
=20
macro equivalent is also provided for performance purpose.  Obviously in=20
C++ inline is a far better solution, but I'd be surprised if there no such=
=20
code existed in the wild, for instance having survived a conversion from C=
=20
with nobody taking the pain to rewrite something which worked.

Yours,

--=20
Jean-Marc

--=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/c97c30a2-93d1-46d7-8808-084d1210039e%40isocpp.or=
g.

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

<div dir=3D"ltr">Le samedi 27 f=C3=A9vrier 2016 02:11:59 UTC+1, David Kraus=
s a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div styl=
e=3D"word-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 2016=
=E2=80=9302=E2=80=9327, at 1:07 AM, T. C. &lt;<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"giQdX4IMAwAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">rs2...@gmail.com</a>&gt; wrote:</d=
iv><br><div><div dir=3D"ltr" style=3D"font-family:Helvetica;font-size:12px;=
font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:nor=
mal;text-align:start;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px"><div>Assuming that lock_guard is a type, `lock_guard(mut=
ex);` is a declaration of a lock_guard called &#39;mutex&#39; (which is err=
or because you can&#39;t default-construct a lock_guard).=C2=A0</div><div><=
br></div><div>If you want this to work, you&#39;ll have to change the disam=
biguation rule too.</div></div></div></blockquote><div><br></div><div>Yeah.=
 Tricky, but doable. At least the parser has the benefit of having seen the=
 <i>decl-specifier-seq</i>, so it can look up <font face=3D"Courier">std::l=
ock_guard</font>. If that names a complete=C2=A0<span style=3D"font-family:=
Courier">guard</span>=C2=A0class type,=C2=A0then don=E2=80=99t parse parent=
heses in the declarator. (And of course that=E2=80=99s a breaking change fo=
r existing declarations like <font face=3D"Courier">std::lock_guard (guard)=
( m );</font>. A proposer might try to convince EWG that such things don=E2=
=80=99t exist in practice.)</div><div><br></div></div></div></blockquote><d=
iv><br></div><div>I&#39;m pretty sure I&#39;ve seen that used in C for simp=
le functions for which a macro equivalent is also provided for performance =
purpose. =C2=A0Obviously in C++ inline is a far better solution, but I&#39;=
d be surprised if there no such code existed in the wild, for instance havi=
ng survived a conversion from C with nobody taking the pain to rewrite some=
thing which worked.</div><div><br></div><div>Yours,</div><div><br></div><di=
v>--=C2=A0</div><div>Jean-Marc</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/c97c30a2-93d1-46d7-8808-084d1210039e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c97c30a2-93d1-46d7-8808-084d1210039e=
%40isocpp.org</a>.<br />

------=_Part_227_885645772.1456746908334--
------=_Part_226_20889153.1456746908334--

.

--Apple-Mail=_06C4742D-7B08-4184-99F4-028A0C4C6114
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2016=E2=80=9302=E2=80=9329, at 7:55 PM, Jean-Marc Bourguet <jm.bourgue=
t@gmail.com> wrote:
>=20
> Le samedi 27 f=C3=A9vrier 2016 02:11:59 UTC+1, David Krauss a =C3=A9crit =
:
>=20
> Yeah. Tricky, but doable. At least the parser has the benefit of having s=
een the decl-specifier-seq, so it can look up std::lock_guard. If that name=
s a complete guard class type, then don=E2=80=99t parse parentheses in the =
declarator. (And of course that=E2=80=99s a breaking change for existing de=
clarations like std::lock_guard (guard)( m );. A proposer might try to conv=
ince EWG that such things don=E2=80=99t exist in practice.)
>=20
>=20
> I'm pretty sure I've seen that used in C for simple functions for which a=
 macro equivalent is also provided for performance purpose.  Obviously in C=
++ inline is a far better solution, but I'd be surprised if there no such c=
ode existed in the wild, for instance having survived a conversion from C w=
ith nobody taking the pain to rewrite something which worked.

Certainly parenthesized declarator-ids have a time and place. It just doesn=
=E2=80=99t intersect with scope guard usage.


--=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/351F7791-8238-4C38-927D-7AAB1538E697%40gmail.com=
..

--Apple-Mail=_06C4742D-7B08-4184-99F4-028A0C4C6114
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9302=
=E2=80=9329, at 7:55 PM, Jean-Marc Bourguet &lt;<a href=3D"mailto:jm.bourgu=
et@gmail.com" class=3D"">jm.bourguet@gmail.com</a>&gt; wrote:</div><br clas=
s=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""=
>Le samedi 27 f=C3=A9vrier 2016 02:11:59 UTC+1, David Krauss a =C3=A9crit&n=
bsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:b=
reak-word" class=3D""><div class=3D""><div class=3D""><br class=3D""></div>=
<div class=3D"">Yeah. Tricky, but doable. At least the parser has the benef=
it of having seen the <i class=3D"">decl-specifier-seq</i>, so it can look =
up <font face=3D"Courier" class=3D"">std::lock_guard</font>. If that names =
a complete&nbsp;<span style=3D"font-family:Courier" class=3D"">guard</span>=
&nbsp;class type,&nbsp;then don=E2=80=99t parse parentheses in the declarat=
or. (And of course that=E2=80=99s a breaking change for existing declaratio=
ns like <font face=3D"Courier" class=3D"">std::lock_guard (guard)( m );</fo=
nt>. A proposer might try to convince EWG that such things don=E2=80=99t ex=
ist in practice.)</div><div class=3D""><br class=3D""></div></div></div></b=
lockquote><div class=3D""><br class=3D""></div><div class=3D"">I'm pretty s=
ure I've seen that used in C for simple functions for which a macro equival=
ent is also provided for performance purpose. &nbsp;Obviously in C++ inline=
 is a far better solution, but I'd be surprised if there no such code exist=
ed in the wild, for instance having survived a conversion from C with nobod=
y taking the pain to rewrite something which worked.</div></div></div></blo=
ckquote><br class=3D""></div><div>Certainly parenthesized declarator-ids ha=
ve a time and place. It just doesn=E2=80=99t intersect with scope guard usa=
ge.</div><div><br class=3D""></div><br class=3D""></body></html>

<p></p>

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

--Apple-Mail=_06C4742D-7B08-4184-99F4-028A0C4C6114--

.