Topic: This variable should not be named: an
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Tue, 28 Mar 2017 16:22:12 +0200
Raw View
--001a11370d7ca53b8a054bcb2faf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Mar 28, 2017 at 3:55 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
> Both solve the simple case, but both also have additional but
non-overlapping usefulness. I'm inclined to think that both are useful.
The usefulness is hard to deny, but I have another consideration. Anonymous
lifetime extension is something that we have wanted for years, or indeed,
for decades. Anonymous decomposition, on the other hand, would be very new,
because the feature it depends on is not even officially standardised yet.
I, for one, do not yet have an intuitive feeling how I would like that to
work.
Also of note is that the authors of the structured bindings proposal did
consider that (P0144R2, 3.8):
We think the answer should be =E2=80=9Cnot yet.=E2=80=9D This is not motiva=
ted by use cases
(silencing compiler warnings is a motivation, but it is not a use case per
se), and is best left until we can revisit this in the context of a more
general pattern matching proposal where this should fall out as a special
case.
(end)
I think that still stands.
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%3D9AFEBuwkpOKBp%3D%2B9H8j0hYA%3DRvWJYKf=
7djJ4DLPNnA%40mail.gmail.com.
--001a11370d7ca53b8a054bcb2faf
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, Mar 28, 2017 at 3:55 PM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>></span> wrote:<br><div><br></div><div>> Both solve the simpl=
e case, but both also have additional but non-overlapping usefulness. I'=
;m inclined to think that both are useful.</div><div><br></div><div>The use=
fulness is hard to deny, but I have another consideration. Anonymous lifeti=
me extension is something that we have wanted for years, or indeed, for dec=
ades. Anonymous decomposition, on the other hand, would be very new, becaus=
e the feature it depends on is not even officially standardised yet. I, for=
one, do not yet have an intuitive feeling how I would like that to work.</=
div><div><br></div><div>Also of note is that the authors of the structured =
bindings proposal did consider that (P0144R2, 3.8):</div><div><br></div><di=
v>We think the answer should be =E2=80=9Cnot yet.=E2=80=9D This is not moti=
vated by use cases (silencing compiler warnings is a
motivation, but it is not a use case per se), and is best left until we can=
revisit this in the context of a more
general pattern matching proposal where this should fall out as a special c=
ase.=C2=A0<br></div><div><br></div><div>(end)</div><div><br></div><div>I th=
ink that still stands.</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" 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%3D9AFEBuwkpOKBp%3D%2B9H8j0hY=
A%3DRvWJYKf7djJ4DLPNnA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2%=
3D9AFEBuwkpOKBp%3D%2B9H8j0hYA%3DRvWJYKf7djJ4DLPNnA%40mail.gmail.com</a>.<br=
/>
--001a11370d7ca53b8a054bcb2faf--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Tue, 28 Mar 2017 23:13:15 +0200
Raw View
> Il giorno 28 mar 2017, alle ore 19:51, Matthew Woehlke <mwoehlke.floss@gm=
ail.com> ha scritto:
>=20
> Consistency?
>=20
> // Same? Uh... no?
> auto __ =3D expr;
> auto [__] =3D expr;
In my proposal, I was not explicit whether the second line is required to c=
all get<0>() or not. As it's currently worded, for consistency I have to as=
sume get<0>() shall be called and the result bound to __. The binding can a=
lways be safely omitted, but the call can be omitted only if has no side ef=
fects. I understand why someone may believe this can be a defect of the pro=
posal. However due to special nature of the name, it would not be unthinkab=
le to explicitly allow the compiler to avoid the call.
> // Same? I hope so?
> auto [__] =3D expr;
> auto x =3D expr; auto __ =3D get<0>(x);
>=20
> // Same? Better be!
> auto [y] =3D expr;
> auto x =3D expr; auto y =3D get<0>(x);
These two are the same. Apart from its "throwaway" meaning, __ is still an =
identifier and works in the same way as any other identifier.
Alberto
--=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/4A64048A-CA16-4DC5-9045-1D9D5074F815%40gmail.com=
..
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Tue, 28 Mar 2017 23:28:26 +0200
Raw View
> Il giorno 28 mar 2017, alle ore 15:55, Matthew Woehlke <mwoehlke.floss@gmail.com> ha scritto:
>
> The
> decomposition case I think would be best solved by allowing empty and
> nested declarations. See
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gg3_eUhCuqo/HcippDFiBgAJ
> and following posts in the thread. This would let you write:
>
> auto [] = get_lock(); // no name
> auto [x, [], y] = get_tuple(); // middle element is unnamed
> auto [x, [a, b], y] = get_tuple(); // nested decomposition
This might actually be a good idea. I'd like to see a proposal in this direction.
Alberto
--
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/7F79A05C-5045-413A-9877-70D6512A927B%40gmail.com.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 29 Mar 2017 07:39:00 +0200
Raw View
This is a multi-part message in MIME format.
--------------BC5A74924EFD605F60C95710
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 28/03/2017 =C3=A0 19:39, Nicol Bolas a =C3=A9crit :
> On Tuesday, March 28, 2017 at 1:29:57 PM UTC-4, Matthew Woehlke wrote:
>
> On 2017-03-28 13:03, Thiago Macieira wrote:
> > On ter=C3=A7a-feira, 28 de mar=C3=A7o de 2017 09:53:51 PDT Zhihao Y=
uan wrote:
> >> auto [__, __] =3D get_tuple(...);
> >>
> >> should be physically equivalent to
> >>
> >> get_tuple(...);
> >>
> >> thus, the result object is dropped on the floor.
> >
> > This should be equivalent to:
> >
> > auto __ =3D get_tuple(...);
>
> I would argue it should be equivalent to:
>
> auto __magic__ =3D get_tuple(...); // note: same as today
> auto __ =3D get<0>(__magic__);
> auto __ =3D get<1>(__magic__);
>
> ...so that in case of side effects, there is no observable behavior
> difference. (The compiler is free to elide bits of the above if there
> are provably no side effects.)
>
> This almost makes me think we need "unnamed" and "ignored" to be
> implemented separately :'(...
>
>
> The question is this: will people actually want side effects of=20
> ignored parameters? Or more to the point, why exactly would you want=20
> those side effects?
>
> I can't think of a case of a type that is decomposable where the=20
> decomposition `get` function has side effects. Well, with one=20
> exception: variant types. And the side effect there is that you get a=20
> thrown exception.
>
variant is not supoorted by structure binding :(
Vicente
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2a803e52-22e8-e18e-ff52-e57c5e797a52%40wanadoo.f=
r.
--------------BC5A74924EFD605F60C95710
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 28/03/2017 =C3=A0 19:39, Nicol Bolas =
a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:57461565-aaec-44d2-becd-9abd76ebeb76@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">On Tuesday, March 28, 2017 at 1:29:57 PM UTC-4,
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
2017-03-28 13:03, Thiago Macieira wrote:
<br>
> On ter=C3=A7a-feira, 28 de mar=C3=A7o de 2017 09:53:51 PDT Z=
hihao
Yuan wrote:
<br>
>> =C2=A0 auto [__, __] =3D get_tuple(...);
<br>
>>
<br>
>> should be physically equivalent to
<br>
>>
<br>
>> =C2=A0 get_tuple(...);
<br>
>>
<br>
>> thus, the result object is dropped on the floor.
<br>
> <br>
> This should be equivalent to:
<br>
> <br>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0auto __ =3D =
get_tuple(...);
<br>
<br>
I would argue it should be equivalent to:
<br>
<br>
=C2=A0 auto __magic__ =3D get_tuple(...); // note: same as today
<br>
=C2=A0 auto __ =3D get<0>(__magic__);
<br>
=C2=A0 auto __ =3D get<1>(__magic__);
<br>
<br>
...so that in case of side effects, there is no observable
behavior
<br>
difference. (The compiler is free to elide bits of the above
if there
<br>
are provably no side effects.)
<br>
<br>
This almost makes me think we need "unnamed" and "ignored" to
be
<br>
implemented separately :'(...<br>
</blockquote>
<div><br>
The question is this: will people actually want side effects
of ignored parameters? Or more to the point, why exactly would
you want those side effects?<br>
<br>
I can't think of a case of a type that is decomposable where
the decomposition `get` function has side effects. Well, with
one exception: variant types. And the side effect there is
that you get a thrown exception.<br>
<br>
</div>
</div>
</blockquote>
variant is not supoorted by structure binding :(<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/2a803e52-22e8-e18e-ff52-e57c5e797a52%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2a803e52-22e8-e18e-ff52-e57c5e797a52=
%40wanadoo.fr</a>.<br />
--------------BC5A74924EFD605F60C95710--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 29 Mar 2017 06:38:32 -0700 (PDT)
Raw View
------=_Part_1103_1563419014.1490794712535
Content-Type: multipart/alternative;
boundary="----=_Part_1104_1124078866.1490794712535"
------=_Part_1104_1124078866.1490794712535
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, March 29, 2017 at 1:39:04 AM UTC-4, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 28/03/2017 =C3=A0 19:39, Nicol Bolas a =C3=A9crit :
>
> On Tuesday, March 28, 2017 at 1:29:57 PM UTC-4, Matthew Woehlke wrote:=20
>>
>> On 2017-03-28 13:03, Thiago Macieira wrote:=20
>> > On ter=C3=A7a-feira, 28 de mar=C3=A7o de 2017 09:53:51 PDT Zhihao Yuan=
wrote:=20
>> >> auto [__, __] =3D get_tuple(...);=20
>> >>=20
>> >> should be physically equivalent to=20
>> >>=20
>> >> get_tuple(...);=20
>> >>=20
>> >> thus, the result object is dropped on the floor.=20
>> >=20
>> > This should be equivalent to:=20
>> >=20
>> > auto __ =3D get_tuple(...);=20
>>
>> I would argue it should be equivalent to:=20
>>
>> auto __magic__ =3D get_tuple(...); // note: same as today=20
>> auto __ =3D get<0>(__magic__);=20
>> auto __ =3D get<1>(__magic__);=20
>>
>> ...so that in case of side effects, there is no observable behavior=20
>> difference. (The compiler is free to elide bits of the above if there=20
>> are provably no side effects.)=20
>>
>> This almost makes me think we need "unnamed" and "ignored" to be=20
>> implemented separately :'(...
>>
>
> The question is this: will people actually want side effects of ignored=
=20
> parameters? Or more to the point, why exactly would you want those side=
=20
> effects?
>
> I can't think of a case of a type that is decomposable where the=20
> decomposition `get` function has side effects. Well, with one exception:=
=20
> variant types. And the side effect there is that you get a thrown excepti=
on.
>
> variant is not supoorted by structure binding :(
>
More accurately, `variant` does not provide the things structured binding=
=20
requires. My point is that, with `__` meaning to not invoke `get` at all,=
=20
you *could* support `variant` and similar 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/91fd8a8e-01c4-4279-a203-e04d3e8c0d6b%40isocpp.or=
g.
------=_Part_1104_1124078866.1490794712535
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, March 29, 2017 at 1:39:04 AM UTC-4, =
Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 28/03/2017 =C3=A0 19:39, Nicol Bolas a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Tuesday, March 28, 2017 at 1:29:57 PM UTC-4,
Matthew Woehlke wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">On
2017-03-28 13:03, Thiago Macieira wrote:
<br>
> On ter=C3=A7a-feira, 28 de mar=C3=A7o de 2017 09:53:51 PDT Z=
hihao
Yuan wrote:
<br>
>> =C2=A0 auto [__, __] =3D get_tuple(...);
<br>
>>
<br>
>> should be physically equivalent to
<br>
>>
<br>
>> =C2=A0 get_tuple(...);
<br>
>>
<br>
>> thus, the result object is dropped on the floor.
<br>
> <br>
> This should be equivalent to:
<br>
> <br>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0auto __ =3D =
get_tuple(...);
<br>
<br>
I would argue it should be equivalent to:
<br>
<br>
=C2=A0 auto __magic__ =3D get_tuple(...); // note: same as today
<br>
=C2=A0 auto __ =3D get<0>(__magic__);
<br>
=C2=A0 auto __ =3D get<1>(__magic__);
<br>
<br>
...so that in case of side effects, there is no observable
behavior
<br>
difference. (The compiler is free to elide bits of the above
if there
<br>
are provably no side effects.)
<br>
<br>
This almost makes me think we need "unnamed" and "=
ignored" to
be
<br>
implemented separately :'(...<br>
</blockquote>
<div><br>
The question is this: will people actually want side effects
of ignored parameters? Or more to the point, why exactly would
you want those side effects?<br>
<br>
I can't think of a case of a type that is decomposable where
the decomposition `get` function has side effects. Well, with
one exception: variant types. And the side effect there is
that you get a thrown exception.<br>
<br>
</div>
</div>
</blockquote>
variant is not supoorted by structure binding :(<br></div></blockquote>=
<div><br>More accurately, `variant` does not provide the things structured =
binding requires. My point is that, with `__` meaning to not invoke `get` a=
t all, you <i>could</i> support `variant` and similar types.<br></div></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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/91fd8a8e-01c4-4279-a203-e04d3e8c0d6b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/91fd8a8e-01c4-4279-a203-e04d3e8c0d6b=
%40isocpp.org</a>.<br />
------=_Part_1104_1124078866.1490794712535--
------=_Part_1103_1563419014.1490794712535--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 29 Mar 2017 18:32:38 +0200
Raw View
This is a multi-part message in MIME format.
--------------6FE9D4D9226A379544F44F9F
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 29/03/2017 =C3=A0 15:38, Nicol Bolas a =C3=A9crit :
>
>
> On Wednesday, March 29, 2017 at 1:39:04 AM UTC-4, Vicente J. Botet=20
> Escriba wrote:
>
> Le 28/03/2017 =C3=A0 19:39, Nicol Bolas a =C3=A9crit :
>>
>>
>> The question is this: will people actually want side effects of
>> ignored parameters? Or more to the point, why exactly would you
>> want those side effects?
>>
>> I can't think of a case of a type that is decomposable where the
>> decomposition `get` function has side effects. Well, with one
>> exception: variant types. And the side effect there is that you
>> get a thrown exception.
>>
> variant is not supoorted by structure binding :(
>
>
> More accurately, `variant` does not provide the things structured=20
> binding requires. My point is that, with `__` meaning to not invoke=20
> `get` at all, you /could/ support `variant` and similar types.
Your point was not clear enough ;-)
Are you serious about providing structured binding support for variant=20
types?
Vicente
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/98c3efe5-25fd-d0d4-0f0b-22fca524b058%40wanadoo.f=
r.
--------------6FE9D4D9226A379544F44F9F
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 29/03/2017 =C3=A0 15:38, Nicol Bolas =
a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:91fd8a8e-01c4-4279-a203-e04d3e8c0d6b@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Wednesday, March 29, 2017 at 1:39:04 AM UTC-4, Vicente J.
Botet Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 28/03/2017 =C3=A0 19:39, Nicol Bolas a =C3=A9crit=C2=A0=
:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex"><br>
</blockquote>
<div> The question is this: will people actually want
side effects of ignored parameters? Or more to the
point, why exactly would you want those side effects?<br>
<br>
I can't think of a case of a type that is decomposable
where the decomposition `get` function has side
effects. Well, with one exception: variant types. And
the side effect there is that you get a thrown
exception.<br>
<br>
</div>
</div>
</blockquote>
variant is not supoorted by structure binding :(<br>
</div>
</blockquote>
<div><br>
More accurately, `variant` does not provide the things
structured binding requires. My point is that, with `__`
meaning to not invoke `get` at all, you <i>could</i> support
`variant` and similar types.<br>
</div>
</div>
</blockquote>
Your point was not clear enough ;-)<br>
Are you serious about providing=C2=A0 structured binding support for
variant types?<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/98c3efe5-25fd-d0d4-0f0b-22fca524b058%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/98c3efe5-25fd-d0d4-0f0b-22fca524b058=
%40wanadoo.fr</a>.<br />
--------------6FE9D4D9226A379544F44F9F--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Thu, 30 Mar 2017 19:09:41 +0200
Raw View
--Apple-Mail-6E323B52-6DB4-4BE9-9208-6E79519400B0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> Il giorno 30 mar 2017, alle ore 10:08, raffaele.rossi@mavensecurities.com=
ha scritto:
>=20
> Wouldn't it be much better to have a concept of Context? I am taking insp=
iration from python (I know they use it for RAII, but that is a different d=
iscussion).
>=20
> The code might look like:
>=20
> void foo() {
> // do stuff
> with (unique_lock{mutex}) {
> // critical code
> }
> // other stuff
> }
>=20
> Then, for prettiness and to avoid unnecessary indentations, when the Cont=
ext extends till the end of the parent scope, it can just be a declaration:
>=20
> void foo() {
> with unique_lock{mutex};
> // critical code
> }
>=20
> You can also nest Contexts:
>=20
> void foo() {
> with unique_lock{mutex1};
> with unique_lock{mutex2};
> // etc
> }
>=20
> Also, by having a proper concept of Context, compilers and static analysi=
s tools would have more information available.
This is essentially achieved by the proposal in P0577.
> I don't know about the decomposition side of things, but perhaps using, s=
ay @ instead? But I have to admit I still haven't understood the differenc=
e with std::ignore (perhaps I have homework to do):
>=20
> auto [x, @, z] =3D expr;
>=20
In my humble opinion, the only sensible choices are an identifier with spec=
ial meaning (like __), the empty brackets [] or nothing at all. All of them=
have pros and cons, but all other suggestions about inventing new punctuat=
ion (be it @, ? or whatever) are too much a waste of lexical space to be co=
nsidered.
A.
--=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/E9C1F839-5B9A-418C-BF3C-89DDCF7360A8%40gmail.com=
..
--Apple-Mail-6E323B52-6DB4-4BE9-9208-6E79519400B0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div><br></div><div>Il giorn=
o 30 mar 2017, alle ore 10:08, <a href=3D"mailto:raffaele.rossi@mavensecuri=
ties.com">raffaele.rossi@mavensecurities.com</a> ha scritto:<br><br></div><=
blockquote type=3D"cite"><div><div>Wouldn't it be much better to have a con=
cept of <b>Context</b>? I am taking inspiration from python (I know they us=
e it for RAII, but that is a different discussion).</div><div><br></div><di=
v>The code might look like:</div><div><br></div><div><font face=3D"courier =
new, monospace"> void foo() {</font></div><div><font face=3D"courier =
new, monospace"> // do stuff</font></div><div><font face=3D"co=
urier new, monospace"> with (unique_lock{mutex}) {</font></div=
><div><font face=3D"courier new, monospace"> // critica=
l code</font></div><div><font face=3D"courier new, monospace"> =
}</font></div><div><font face=3D"courier new, monospace"> // =
other stuff</font></div><div><font face=3D"courier new, monospace"> }=
</font></div><div><br></div><div>Then, for prettiness and to avoid unnecess=
ary indentations, when the <b>Context</b> extends till the end of the paren=
t scope, it can just be a declaration:</div><div><br></div><div><font face=
=3D"courier new, monospace"> void foo() {</font></div><div><font face=
=3D"courier new, monospace"> with unique_lock{mutex};</font></=
div><div><font face=3D"courier new, monospace"> // critical co=
de<br></font></div><div><font face=3D"courier new, monospace"> }</fon=
t></div><div><div><br></div><div>You can also nest <b>Contexts</b>:</div><d=
iv><br></div><div><font face=3D"courier new, monospace"> void foo() {=
</font></div><div><font face=3D"courier new, monospace"> with =
unique_lock{mutex1};</font></div><div><div><font face=3D"courier new, monos=
pace"> with unique_lock{mutex2};</font></div><div><font face=
=3D"courier new, monospace"> // etc</font></div><div><font fac=
e=3D"courier new, monospace"> }</font></div><div><br></div><div>Also,=
by having a proper concept of <b>Context</b>, compilers and static analysi=
s tools would have more information available.</div></div></div></div></blo=
ckquote><div><br></div>This is essentially achieved by the proposal in P057=
7.<div><br><blockquote type=3D"cite"><div>I don't know about the decomposit=
ion side of things, but perhaps using, say <font face=3D"courier new, monos=
pace">@</font> instead? But I have to admit I still haven't understoo=
d the difference with <font face=3D"courier new, monospace">std::ignore</fo=
nt> (perhaps I have homework to do):</div><div><br></div><div><font face=3D=
"courier new, monospace"> auto [x, @, z] =3D expr;<br></font><=
/div><div><br></div></blockquote><br></div><div>In my humble opinion, the o=
nly sensible choices are an identifier with special meaning (like __), the =
empty brackets [] or nothing at all. All of them have pros and cons, but al=
l other suggestions about inventing new punctuation (be it @, ? or whatever=
) are too much a waste of lexical space to be considered.</div><div><br></d=
iv><div>A.</div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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/E9C1F839-5B9A-418C-BF3C-89DDCF7360A8%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/E9C1F839-5B9A-418C-BF3C-89DDCF7360A8%=
40gmail.com</a>.<br />
--Apple-Mail-6E323B52-6DB4-4BE9-9208-6E79519400B0--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Tue, 4 Apr 2017 09:54:58 +0200
Raw View
--Apple-Mail-99013157-A8F0-46C6-83DC-CFEC608B7510
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> Il giorno 03 apr 2017, alle ore 22:28, T. C. <rs2740@gmail.com> ha scritt=
o:
>=20
>> On Monday, April 3, 2017 at 3:55:16 PM UTC-4, Matthew Woehlke wrote:
>> On 2017-04-03 15:37, Barry Revzin wrote:=20
>> > I think the logical extreme of this idea is to not pick any identifier=
at=20
>> > all - simply allow hiding declarations in the same scope. So from the=
=20
>> > original paper's examples, using __ to declare multiple variables in t=
he=20
>> > same scope just works not because of some special magic bestowed upon =
the=20
>> > identifier "__", but instead because you're actually declaring multipl=
e=20
>> > variables in the same scope named "__". You'd have no way of accessing=
the=20
>> > earlier versions of __, but then you don't want to anyway. I don't kno=
w how=20
>> > to get the compiler to not warn against not using the last incarnation=
of=20
>> > __ though. That just may be a "teach the compiler that this is a conve=
ntion=20
>> > that people want to use" kind of thing.=20
>>=20
>> That seems like a recipe for bugs. We have enough problems with -Wshadow=
=20
>> as it is, let alone making the situation *worse*...=20
>>=20
>=20
> Mostra contenuti citati
>> On 2017-04-03 15:37, Barry Revzin wrote:=20
>> > I think the logical extreme of this idea is to not pick any identifier=
at=20
>> > all - simply allow hiding declarations in the same scope. So from the=
=20
>> > original paper's examples, using __ to declare multiple variables in t=
he=20
>> > same scope just works not because of some special magic bestowed upon =
the=20
>> > identifier "__", but instead because you're actually declaring multipl=
e=20
>> > variables in the same scope named "__". You'd have no way of accessing=
the=20
>> > earlier versions of __, but then you don't want to anyway. I don't kno=
w how=20
>> > to get the compiler to not warn against not using the last incarnation=
of=20
>> > __ though. That just may be a "teach the compiler that this is a conve=
ntion=20
>> > that people want to use" kind of thing.=20
>>=20
>> That seems like a recipe for bugs. We have enough problems with -Wshadow=
=20
>> as it is, let alone making the situation *worse*...=20
>>=20
>=20
> I think the original idea Richard posited is that there is no hiding. Ins=
tead, if you declare multiple variables with the same name in the same scop=
e, you can't access *any* of them. Name lookup will simply find all the dec=
larations and declare an ambiguity at that point.
Richard proposal is very interesting indeed, however as someone has already=
pointed out it's a completely different proposal. His proposal avoids spec=
ial treatment of the "placeholder" identifier, which may be good, but my wh=
ole point is that I do want to have a special treatment. Having the maybe_u=
nused automatically applied without an explicit attribute is an essential p=
art of the proposal, as well as the requirement to omit the call to the get=
() function if the placeholder is used in decomposition declarations. Havi=
ng a special identifier seems to me the most concise way to achieve that.
Alberto
--=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/7BCB9188-77D4-4165-857E-CFADBF101DC7%40gmail.com=
..
--Apple-Mail-99013157-A8F0-46C6-83DC-CFEC608B7510
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div><br></div><div>Il giorn=
o 03 apr 2017, alle ore 22:28, T. C. <<a href=3D"mailto:rs2740@gmail.com=
">rs2740@gmail.com</a>> ha scritto:<br><br></div><blockquote type=3D"cit=
e"><div>On Monday, April 3, 2017 at 3:55:16 PM UTC-4, Matthew Woehlke wrote=
:<a href=3D"#" class=3D"_AppleShowQuotedContentButton"><div style=3D"overfl=
ow: hidden !important; height: 54px !important;"><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;" preoffsettop=3D"91" preoffsetheight=3D"390">On 2017-04-0=
3 15:37, Barry Revzin wrote:
<br>> I think the logical extreme of this idea is to not pick any identi=
fier at=20
<br>> all - simply allow hiding declarations in the same scope. So from =
the=20
<br>> original paper's examples, using __ to declare multiple variables =
in the=20
<br>> same scope just works not because of some special magic bestowed u=
pon the=20
<br>> identifier "__", but instead because you're actually declaring mul=
tiple=20
<br>> variables in the same scope named "__". You'd have no way of acces=
sing the=20
<br>> earlier versions of __, but then you don't want to anyway. I don't=
know how=20
<br>> to get the compiler to not warn against not using the last incarna=
tion of=20
<br>> __ though. That just may be a "teach the compiler that this is a c=
onvention=20
<br>> that people want to use" kind of thing.=20
<br>
<br>That seems like a recipe for bugs. We have enough problems with -Wshado=
w
<br>as it is, let alone making the situation *worse*...
<br>
<br></blockquote></div><div class=3D"button">Mostra contenuti citati</div><=
div style=3D"overflow: hidden !important; height: 54px !important;"><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;" preoffsettop=3D"91" preoffsetheight=
=3D"390">On 2017-04-03 15:37, Barry Revzin wrote:
<br>> I think the logical extreme of this idea is to not pick any identi=
fier at=20
<br>> all - simply allow hiding declarations in the same scope. So from =
the=20
<br>> original paper's examples, using __ to declare multiple variables =
in the=20
<br>> same scope just works not because of some special magic bestowed u=
pon the=20
<br>> identifier "__", but instead because you're actually declaring mul=
tiple=20
<br>> variables in the same scope named "__". You'd have no way of acces=
sing the=20
<br>> earlier versions of __, but then you don't want to anyway. I don't=
know how=20
<br>> to get the compiler to not warn against not using the last incarna=
tion of=20
<br>> __ though. That just may be a "teach the compiler that this is a c=
onvention=20
<br>> that people want to use" kind of thing.=20
<br>
<br>That seems like a recipe for bugs. We have enough problems with -Wshado=
w
<br>as it is, let alone making the situation *worse*...
<br>
<br></blockquote></div></a><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 2=
04, 204); border-left-style: solid; padding-left: 1ex; display: none;" preo=
ffsettop=3D"91" preoffsetheight=3D"390">On 2017-04-03 15:37, Barry Revzin w=
rote:
<br>> I think the logical extreme of this idea is to not pick any identi=
fier at=20
<br>> all - simply allow hiding declarations in the same scope. So from =
the=20
<br>> original paper's examples, using __ to declare multiple variables =
in the=20
<br>> same scope just works not because of some special magic bestowed u=
pon the=20
<br>> identifier "__", but instead because you're actually declaring mul=
tiple=20
<br>> variables in the same scope named "__". You'd have no way of acces=
sing the=20
<br>> earlier versions of __, but then you don't want to anyway. I don't=
know how=20
<br>> to get the compiler to not warn against not using the last incarna=
tion of=20
<br>> __ though. That just may be a "teach the compiler that this is a c=
onvention=20
<br>> that people want to use" kind of thing.=20
<br>
<br>That seems like a recipe for bugs. We have enough problems with -Wshado=
w
<br>as it is, let alone making the situation *worse*...
<br>
<br></blockquote><div><br></div><div>I think the original idea Richard posi=
ted is that there is no hiding. Instead, if you declare multiple variables =
with the same name in the same scope, you can't access *any* of them. Name =
lookup will simply find all the declarations and declare an ambiguity at th=
at point.</div></div></blockquote><br><div>Richard proposal is very interes=
ting indeed, however as someone has already pointed out it's a completely d=
ifferent proposal. His proposal avoids special treatment of the "placeholde=
r" identifier, which may be good, but my whole point is that I do want to h=
ave a special treatment. Having the maybe_unused automatically applied with=
out an explicit attribute is an essential part of the proposal, as well as =
the requirement to omit the call to the get() function if the placeholder &=
nbsp;is used in decomposition declarations. Having a special identifier see=
ms to me the most concise way to achieve that.</div><div><br></div><div>Alb=
erto</div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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/7BCB9188-77D4-4165-857E-CFADBF101DC7%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7BCB9188-77D4-4165-857E-CFADBF101DC7%=
40gmail.com</a>.<br />
--Apple-Mail-99013157-A8F0-46C6-83DC-CFEC608B7510--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 4 Apr 2017 13:46:36 -0700 (PDT)
Raw View
------=_Part_2043_1052015268.1491338796977
Content-Type: multipart/alternative;
boundary="----=_Part_2044_1414693579.1491338796977"
------=_Part_2044_1414693579.1491338796977
Content-Type: text/plain; charset=UTF-8
I would like Richards idea of allowing redeclaration of _ and disallowing
access to any of those multiple instances if it wasn't for the unfortunate
_("Text to translate") use that is really widespread. On the other hand a
macro definition with parameters (such as _) does not get expanded if no
parameters are provided, so at least for some cases this could still work.
I have previously suggested using the ? token for this same purpose. As ?
is currently used only for an infix operator I don't think this would cause
any ambiguities, but I'm not entirely convinced... can anyone find a case
where a ternary ? and a declarator named ? would clash?
--
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/92f6ef19-1045-449a-9cef-e7a633269b3f%40isocpp.org.
------=_Part_2044_1414693579.1491338796977
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I would like Richards idea of allowing redeclaration of _ =
and disallowing access to any of those multiple instances if it wasn't =
for the unfortunate _("Text to translate") use that is really wid=
espread. On the other hand a macro definition with parameters (such as _) d=
oes not get expanded if no parameters are provided, so at least for some ca=
ses this could still work.<div><br></div><div>I have previously suggested u=
sing the ? token for this same purpose. As ? is currently used only for an =
infix operator I don't think this would cause any ambiguities, but I=
9;m not entirely convinced... can anyone find a case where a ternary ? and =
a declarator named ? would clash?</div><div><br></div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/92f6ef19-1045-449a-9cef-e7a633269b3f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/92f6ef19-1045-449a-9cef-e7a633269b3f=
%40isocpp.org</a>.<br />
------=_Part_2044_1414693579.1491338796977--
------=_Part_2043_1052015268.1491338796977--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 04 Apr 2017 21:51:59 -0700
Raw View
Em ter=C3=A7a-feira, 4 de abril de 2017, =C3=A0s 13:46:36 PDT, Bengt Gustaf=
sson=20
escreveu:
> On the other hand a
> macro definition with parameters (such as _) does not get expanded if no
> parameters are provided, so at least for some cases this could still work=
..
Yet there's one very important use that wouldn't be included: variable=20
declaration.
std::lock_guard _(mutex);
--=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/1655572.Mm6e78YzX3%40tjmaciei-mobl1.
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Wed, 5 Apr 2017 08:16:49 +0200
Raw View
> Il giorno 04 apr 2017, alle ore 22:46, Bengt Gustafsson <bengt.gustafsson=
@beamways.com> ha scritto:
>=20
> I have previously suggested using the ? token for this same purpose. As ?=
is currently used only for an infix operator I don't think this would caus=
e any ambiguities, but I'm not entirely convinced... can anyone find a case=
where a ternary ? and a declarator named ? would clash?
Using a punctuation would require significant changes in the grammar, since=
we would have to allow it in places where only identifiers are allowed tod=
ay. Non mentioning that we might lose the possibility to use the symbol for=
other uses. For what is perceived as a little feature, the cost seems too =
high. Just my opinion.=20
Alberto
--=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/38CC2C58-C201-463B-B6F1-1CC4EA20B2B2%40gmail.com=
..
.