220 31857 <81CE0C5F-21B4-46FC-9893-82C65001454C@gmail.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Alberto Barbati 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 22:45:44 +0200 Lines: 108 Approved: news@gmane.org Message-ID: <81CE0C5F-21B4-46FC-9893-82C65001454C@gmail.com> References: <985b9b2a-c734-45eb-95f4-db4dc0d309a1@isocpp.org> <7EF863A1-1454-4116-9164-676FF19BF923@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-C26B9FEB-DB10-4E8C-AD9D-43F1F8FBE10B Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1490733959 10601 195.159.176.226 (28 Mar 2017 20:45:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Mar 2017 20:45:59 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCPY5DV6RIMBB64W5PDAKGQECBU4ZQI@isocpp.org Tue Mar 28 22:45:55 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f72.google.com ([209.85.215.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csxzq-0000xg-2U for gclcip-std-proposals@m.gmane.org; Tue, 28 Mar 2017 22:45:42 +0200 Original-Received: by mail-lf0-f72.google.com with SMTP id b127sf38758724lfe.10 for ; Tue, 28 Mar 2017 13:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=H8MMfNNwd9KZ6yWcMUJ4QnKhIYA/wU2zXbpMcARdZM8=; b=Qz1vaGmuON60avSpKbBkjAaxPizPIDJhsDRM7wsr3PMjDXKbdXsnhM1dPs3XJRwM44 ICgWmt82uffMwi5v0td6rXg+jkeI1Mmg5O27DOuVvMgbLepvcUS4Vb4tzzcryHh/J9GT Gf/xpMGVcEoq1qr9xof0sEPzRtedwKuLc10LQwdN6GmBMKRIz++9zZGOuZyi3N1S6eHo 1uwLx+Zq+9prGZZox/NB4JEmJWnugQpZWbqNIh5K54nN3Vq7lkaV8u53mKgFhYA2Ept4 RIKNtKWO8JQ8b5xjHfPsPvMgNAxf7BFsN90GZthkJjpQm2ZIiFQiZisuQ5ElO2cJ5pZY BddQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=H8MMfNNwd9KZ6yWcMUJ4QnKhIYA/wU2zXbpMcARdZM8=; b=CCJEwOphZxdY6NjjmepaxjQ/0Aot74xbsjCcZYfD0nZB2I2TX6tDOK1zcFChUm/OKr wKNMPb9SLTdP5DrIKy218nRIFDyu0RA7UTJg3kglg2lTf+MeUp/A30+XLCQZiNijAN1+ rAPiiowIAYxKYzHEA+FaCmK6fQOVzv5+DaOiU1XInLRVRags5ownTk0lmzfcGW4O83Rs tTDljISzOqZqed4ixU6X1GxgN6Z6xfC1TJA4gy98nD2X92JENhEmdzfkwaIJ2Ti+3TGM Yrdy5heHgDqBdxU/WOO9qeUYxQk2wzog2N8zib/MWs66hHpkhgd9lughIikZuMwGTcSz tSi X-Gm-Message-State: AFeK/H0vDciMICM6T1i1C20EnVbm3m2U8p1fN5sv10YTYorA6bnNA/rmAymCALHRCdcJIw== X-Received: by 10.46.87.80 with SMTP id r16mr775388ljd.12.1490733948122; Tue, 28 Mar 2017 13:45:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.66.81 with SMTP id p78ls2062956wma.7.canary-gmail; Tue, 28 Mar 2017 13:45:46 -0700 (PDT) X-Received: by 10.28.146.207 with SMTP id u198mr16154281wmd.103.1490733946837; Tue, 28 Mar 2017 13:45:46 -0700 (PDT) Original-Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com. [2a00:1450:400c:c09::22d]) by mx.google.com with ESMTPS id u110si5858287wrc.274.2017.03.28.13.45.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 13:45:46 -0700 (PDT) Received-SPF: pass (google.com: domain of albertobarbati@gmail.com designates 2a00:1450:400c:c09::22d as permitted sender) client-ip=2a00:1450:400c:c09::22d; Original-Received: by mail-wm0-x22d.google.com with SMTP id x124so8918345wmf.0 for ; Tue, 28 Mar 2017 13:45:46 -0700 (PDT) X-Received: by 10.28.29.138 with SMTP id d132mr15602069wmd.40.1490733946284; Tue, 28 Mar 2017 13:45:46 -0700 (PDT) Original-Received: from [192.168.178.44] ([151.20.212.10]) by smtp.gmail.com with ESMTPSA id b13sm5018318wmf.6.2017.03.28.13.45.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 13:45:45 -0700 (PDT) In-Reply-To: X-Mailer: iPad Mail (14D27) X-Original-Sender: AlbertoBarbati@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of albertobarbati@gmail.com designates 2a00:1450:400c:c09::22d as permitted sender) smtp.mailfrom=albertobarbati@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:31857 Archived-At: --Apple-Mail-C26B9FEB-DB10-4E8C-AD9D-43F1F8FBE10B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Il giorno 28 mar 2017, alle ore 18:27, Zhihao Yuan ha scr= itto: >=20 >=20 >> On Tue, Mar 28, 2017 at 4:23 AM, Alberto Barbati wrote: >> However I believe P0577 does not address the issue of decomposition decl= aration >=20 > Because these two "use cases" imply different semantics. > When you write >=20 > auto __ =3D lock_guard(m); >=20 > here you mean to *preserve* the result object, but when > you write >=20 > auto [__, a] =3D get_tuple(...); >=20 > you mean to *ignore* a part of the result object, so > physically, just like std::ignore, I don't expect __ here > to issue a call to get(obj), nor an access to a subobject. > I don't think the *preserving* semantics can fulfill the > *ignoring* demand. I see it differently. For me, those two are instances of the same use case:= "I don't care about the name, since I don't need to refer to this lvalue a= nymore". In the first case we are not actually "preserving" anything, since= we are declaring an object whose lifetime would end at the end of the lexi= cal scope regardless of its name. Similarly in the second case, with the on= ly difference that the name would be bound to a reference to a subobject of= an object whose scope is defined irrespective of the binding. In this case= the compiler can and probably would omit the binding without observable ef= fects. Cheers, 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/81CE0C5F-21B4-46FC-9893-82C65001454C%40gmail.com= .. --Apple-Mail-C26B9FEB-DB10-4E8C-AD9D-43F1F8FBE10B Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Il giorn= o 28 mar 2017, alle ore 18:27, Zhihao Yuan <zy@miator.net> ha scritto:


On Tue, Mar 28, 2017 at 4:23 AM, Alberto Barbati = <albertoba= rbati@gmail.com> wrote:
How= ever I believe P0577 does not address the issue of decomposition declaratio= n

Because these two= "use cases" imply different semantics.
When you write

  auto __ =3D = lock_guard(m);

here you mean to *pr= eserve* the result object, but when
you write

  auto [__, a] =3D get_tuple(...);

you mean to *ignore* a part of the result object, so
= physically, just like std::ignore, I don't expect __ here
to issue a cal= l to get(obj), nor an access to a subobject.
I don't think the *preservi= ng* semantics can fulfill the
*ignoring* demand.

I see it differently. For me, those two are ins= tances of the same use case: "I don't care about the name, since I don't ne= ed to refer to this lvalue anymore". In the first case we are not actually = "preserving" anything, since we are declaring an object whose lifetime woul= d end at the end of the lexical scope regardless of its name. Similarly in = the second case, with the only difference that the name would be bound to a= reference to a subobject of an object whose scope is defined irrespective = of the binding. In this case the compiler can and probably would omit the b= inding without observable effects.

Cheers,

Alberto

--
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.c= om/a/isocpp.org/d/msgid/std-proposals/81CE0C5F-21B4-46FC-9893-82C65001454C%= 40gmail.com.
--Apple-Mail-C26B9FEB-DB10-4E8C-AD9D-43F1F8FBE10B-- .