220 31833 <57461565-aaec-44d2-becd-9abd76ebeb76@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: This variable should not be named: an identifier (not) to remember Date: Tue, 28 Mar 2017 10:39:12 -0700 (PDT) Lines: 155 Approved: news@gmane.org Message-ID: <57461565-aaec-44d2-becd-9abd76ebeb76@isocpp.org> References: <985b9b2a-c734-45eb-95f4-db4dc0d309a1@isocpp.org> <14211602.1P4LjlnQMh@tjmaciei-mobl1> <8028901.3vRB6vfJZY@tjmaciei-mobl1> <58DA9D90.6020207@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11728_844605381.1490722752778" X-Trace: blaine.gmane.org 1490722756 30620 195.159.176.226 (28 Mar 2017 17:39:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Mar 2017 17:39:16 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBQN75LDAKGQEAMAUNRA@isocpp.org Tue Mar 28 19:39:12 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csv5I-0007BU-7I for gclcip-std-proposals@m.gmane.org; Tue, 28 Mar 2017 19:39:08 +0200 Original-Received: by mail-oi0-f72.google.com with SMTP id n4sf63320661oia.5 for ; Tue, 28 Mar 2017 10:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=cqe7xm6QGZ5wioLhvEjPURtgqMgpbi/e0bLX6XMVJxk=; b=N0O702WX9vE4gmVLuAgV8ezWiMhfxUCDOzwKenhqTQC7hyzrbDMNRneThitE7wZM3w e+aez1ECF8lJuMzmXzlgw+QPNc3tUlBaY3+Ft/XqYqv5ohZUF9BcViZytPIvYcTG/XKi ArBltJIoXBZqfotbqawKJbWUrEJrK7GhBDz7rHYzMnB6e4Ce9oxx+/vFRI82tswNguui O05OV8XEjZVkYfw4ajlM90Cdq9YWJNttcwVuUHbKa3EJTvn+3wbbowZ2qJ0XMEEcc42o Qw2QoP+NjcwAZ8dB5+X60K9pDxf357NCAI7uYLTBkdwhkXGKeWwyOdAswlIT8ZfC6cYg VtJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=cqe7xm6QGZ5wioLhvEjPURtgqMgpbi/e0bLX6XMVJxk=; b=ikBF91eX/mEqtOn2f4u4HJXaxLzecXYfTeaXYiFJnTLXzNvej962BXab7WzkL/ySHP AzRw6a88xphn9DyTjWa2qhjCN7CIkNyvQx6XGD9q2iUgzkypd0zrakK2FnrMzT2Pb61/ IrPTzfz/Fb1SPFYHfcC6HOvz0vaFFRSDScp4567jRlGHxyGaxyUjOMxlk57zkY+1gttd 9b6JpvFGe53UOKpV8VfUKn/DGV16ljD8X1dGu4Qgs/+ZX4eiEpV/CSbMwQyH2wyLW65p BWFy5S2+ABQDtwrVZb7IKAvQ26F6YyddJJ+UphpyPfWARkzYSzS3xv/xr6kUaeRalnEo HIZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=cqe7xm6QGZ5wioLhvEjPURtgqMgpbi/e0bLX6XMVJxk=; b=EWyIAmnzGAH4I/o+f4P3AEllNwc6Mg+wlwFcyH0ZOblSEvzF/JsqE0aNXxwTzYwMQd T7vfDHhpK3Ebv2a5XqTPE/o+Dd3WnH5xtasFWQxWp2fQog68ZIbFi8zdj4xVYWVh0QA1 aaihvOo7c+4Ih8FCV3PoTmHleMsIwZWKTPAu5E6MwS2My0FbuW8T09X1807pjG3B+655 LMwNh0dg9qZhotCjef9KMrqDHBsKqrRN9vLEAxtQ1Ef+89te2kZj94ad0Pm8GDanD0dB 92RB3ebSg8dnOPYNUD9zUoLDxMv+i8MHYkJsxqi2XCVv5MO9+4BkwdNTWSQa0roGuntl LfWg== X-Gm-Message-State: AFeK/H2TDl6yokeTfdB4bUXWOlewqBsMNTKkLD5yLMvCvbf7mXvGddHCEtJamqxSFZ1/lg== X-Received: by 10.157.15.39 with SMTP id 36mr2901857ott.62.1490722753919; Tue, 28 Mar 2017 10:39:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.62.1 with SMTP id a1ls710313otd.37.gmail; Tue, 28 Mar 2017 10:39:13 -0700 (PDT) X-Received: by 10.157.61.131 with SMTP id l3mr2283938otc.1.1490722753191; Tue, 28 Mar 2017 10:39:13 -0700 (PDT) In-Reply-To: <58DA9D90.6020207@gmail.com> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:31833 Archived-At: ------=_Part_11728_844605381.1490722752778 Content-Type: multipart/alternative; boundary="----=_Part_11729_185140298.1490722752778" ------=_Part_11729_185140298.1490722752778 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, March 28, 2017 at 1:29:57 PM UTC-4, Matthew Woehlke wrote: > > 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 exception= .. So it seems to me that if I have a variant, and I do: auto [__, name] =3D expr; I clearly don't want the side effect of calling `get<0>`. I'm declaring=20 very clearly that this variant is in state 1, and if it isn't, then throw. So under what circumstances would a user want the side effect of `get` but= =20 not the name? We shouldn't add such a feature based on whether someone=20 could use it. We should add the feature because someone has a genuine need= =20 to use 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/57461565-aaec-44d2-becd-9abd76ebeb76%40isocpp.or= g. ------=_Part_11729_185140298.1490722752778 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, March 28, 2017 at 1:29:57 PM UTC-4, Matthew Wo= ehlke wrote:
On 2017-03-28 13:0= 3, Thiago Macieira wrote:
> On ter=C3=A7a-feira, 28 de mar=C3=A7o de 2017 09:53:51 PDT Zhihao = Yuan wrote:
>> =C2=A0 auto [__, __] =3D get_tuple(...);
>>
>> should be physically equivalent to
>>
>> =C2=A0 get_tuple(...);
>>
>> thus, the result object is dropped on the floor.
>=20
> This should be equivalent to:
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0auto __ =3D get_tu= ple(...);

I would argue it should be equivalent to:

=C2=A0 auto __magic__ =3D get_tuple(...); // note: same as today
=C2=A0 auto __ =3D get<0>(__magic__);
=C2=A0 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 "ignore= d" to be
implemented separately :'(...

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 decompos= ition `get` function has side effects. Well, with one exception: variant ty= pes. And the side effect there is that you get a thrown exception.

S= o it seems to me that if I have a variant, and I do:

auto [__, name] <= /span>=3D<= span style=3D"color: #000;" class=3D"styled-by-prettify"> expr;
I clearly don't want the side effect of calling `get<0>`. I'= ;m declaring very clearly that this variant is in state 1, and if it isn= 9;t, then throw.

So under what circumstances would a user want the s= ide effect of `get` but not the name? We shouldn't add such a feature b= ased on whether someone could use it. We should add the feature because som= eone has a genuine need to use it.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/57461565-aaec-44d2-becd-9abd76ebeb76= %40isocpp.org.
------=_Part_11729_185140298.1490722752778-- ------=_Part_11728_844605381.1490722752778-- .