220 7019 article Path: news.gmane.org!not-for-mail From: Brent Friedman Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Unnamed LValues Date: Sat, 5 Oct 2013 12:06:08 -0500 Lines: 181 Approved: news@gmane.org Message-ID: References: <0d9b268f-cd3a-4048-a0a3-50cff02b28ce@isocpp.org> <525031B5.80202@wanadoo.fr> <06e15a1f-0f12-408f-b0cd-077669caeb31@isocpp.org> <52503F47.9030308@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdc93ca6c18f304e8016f59 X-Trace: ger.gmane.org 1380992767 7374 80.91.229.3 (5 Oct 2013 17:06:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Oct 2013 17:06:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCHLPXGUXMJBBAMOYGJAKGQE42HLTPI@isocpp.org Sat Oct 05 19:06:11 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f71.google.com ([209.85.219.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VSVIx-0000xp-4i for gclcip-std-proposals@m.gmane.org; Sat, 05 Oct 2013 19:06:11 +0200 Original-Received: by mail-oa0-f71.google.com with SMTP id i3sf7238769oag.10 for ; Sat, 05 Oct 2013 10:06:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=pGdXHJ5plJNzWZVxIuHWx79xTwoWVSVfdhXH6n05WQk=; b=VUx4JCVFHYuTaTyOtGOdKbMcU++v1rlC7XTsY99nGPVlWf3Oht0nk4c/oOa6qNu76a X8y6dc3HQnKpr5WvEwh33JjqxESsLm6okWJmsu9Ks8cdHAE8wrxMZrcjv4REzWIa792z IYDCnh776PcXYMBZ4snZ11sCQ9V2kIIPKbLu9GE4iyJhgKBze39ycvhYvWmdfngsrVDt t7D6LYrc5tU3L8/QORzwftoCHNRJ8IWL8Luh5+3SbhfQ1/vatb0DI50Vb+YItaR9GQ5K JFELDaI5JopXMY+aKW9RufOheFanmvJLtj1Dz1zyaUVQ58bNoAvvOg1p6EFxbqUjHg+h rkug== X-Received: by 10.42.126.72 with SMTP id d8mr10650330ics.4.1380992770127; Sat, 05 Oct 2013 10:06:10 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.47.105 with SMTP id c9ls1976042ign.0.gmail; Sat, 05 Oct 2013 10:06:09 -0700 (PDT) X-Received: by 10.67.2.4 with SMTP id bk4mr22219820pad.78.1380992769343; Sat, 05 Oct 2013 10:06:09 -0700 (PDT) Original-Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [2607:f8b0:400e:c01::22a]) by mx.google.com with ESMTPS id f7si15042476pac.345.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Oct 2013 10:06:09 -0700 (PDT) Received-SPF: pass (google.com: domain of fourthgeek@gmail.com designates 2607:f8b0:400e:c01::22a as permitted sender) client-ip=2607:f8b0:400e:c01::22a; Original-Received: by mail-pb0-f42.google.com with SMTP id un15so5383021pbc.29 for ; Sat, 05 Oct 2013 10:06:08 -0700 (PDT) X-Received: by 10.66.192.132 with SMTP id hg4mr22529120pac.84.1380992768807; Sat, 05 Oct 2013 10:06:08 -0700 (PDT) Original-Received: by 10.70.2.226 with HTTP; Sat, 5 Oct 2013 10:06:08 -0700 (PDT) In-Reply-To: <52503F47.9030308@wanadoo.fr> X-Original-Sender: fourthgeek@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of fourthgeek@gmail.com designates 2607:f8b0:400e:c01::22a as permitted sender) smtp.mail=fourthgeek@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=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:7019 Archived-At: --047d7bdc93ca6c18f304e8016f59 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What functionality do we get by adding new block statements versus the original proposal? Presumably adding new block statements carries much more language risk and implementation time, so what are we getting for that extra effort? Unless there's a way to attach with/using to an object lifetime, it would seem to be even less powerful. I'll use ? as the identifier since auto auto isn't very clear. int reentry_count; class SignalScope { auto ? =3D scope_increment(reentry_count); SignalScope(); ~SignalScope(); }; This wouldn't naturally extend to using/with without adding yet some new language construct. RAII should be inherently composable. Of course, the two ideas aren't completely mutually exclusive. An additional use case for unnamed lvalues would be to standardize the idea of an unused parameter. Many projects have to use some sort of macro or annotation to suppress compiler warnings for unused variables. Often, this is a cast-to-void. void f(int p) { UNUSED(p); } By explicitly stating that the parameter has no name, the compiler can suppress such warnings. Of course you don't use the variable; it's name is unfathomable. void f(int ?) { } On Sat, Oct 5, 2013 at 11:33 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote: > Le 05/10/13 18:12, snk_kid a =E9crit : > > All this is useful, but this doesn't support control flow leaving the >> block. >> > > Well you can still use return statements for early exits (at particular > level) and throw exceptions. > > No return statements will return from the lambda, not from the function > calling with. > > Vicente > > -- > > --- > 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 > http://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 http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --047d7bdc93ca6c18f304e8016f59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What functionality do we get by adding new block stat= ements versus the original proposal? Presumably adding new block statements= carries much more language risk and implementation time, so what are we ge= tting for that extra effort? Unless there's a way to attach with/using = to an object lifetime, it would seem to be even less powerful.

I'll use ? as the identifier since auto auto i= sn't very clear.

int reentry_count;
=
class SignalScope
{
=A0auto ? =3D scope_= increment(reentry_count);
=A0SignalScope();
=A0~SignalScope();
};
=
This wouldn't naturally extend to using/with witho= ut adding yet some new language construct. RAII should be inherently compos= able. Of course, the two ideas aren't completely mutually exclusive.

An additional use case for unnamed lvalues would be to = standardize the idea of an unused parameter. Many projects have to use some= sort of macro or annotation to suppress compiler warnings for unused varia= bles. Often, this is a cast-to-void.
void f(int p)
{
=A0UNUSED(p);
}

By explicitly stating that the parameter has no name, = the compiler can suppress such warnings. Of course you don't use the va= riable; it's name is unfathomable.

void f(int ?)
{
}



On S= at, Oct 5, 2013 at 11:33 AM, Vicente J. Botet Escriba <= ;vicente.bote= t@wanadoo.fr> wrote:
=20 =20 =20
Le 05/10/13 18:12, snk_kid a =E9crit=A0:
All this is useful, but this doesn't support control flow leaving the block.

Well you can still use return statements for early exits (at particular level) and throw exceptions.

No return statements will return from the lambda, not from the function calling with.
Vicente

--
=A0
---
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/gro= up/std-proposals/.

--
 
---
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--047d7bdc93ca6c18f304e8016f59-- .