220 6987 article Path: news.gmane.org!not-for-mail From: Brent Friedman Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Unnamed LValues Date: Fri, 4 Oct 2013 20:01:29 -0500 Lines: 156 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b11191589bf8a04e7f3f572 X-Trace: ger.gmane.org 1380934889 14715 80.91.229.3 (5 Oct 2013 01:01:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Oct 2013 01:01:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCHLPXGUXMJBB2OJXWJAKGQEWPK4NSI@isocpp.org Sat Oct 05 03:01:33 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 1VSGFP-00026b-7f for gclcip-std-proposals@m.gmane.org; Sat, 05 Oct 2013 03:01:31 +0200 Original-Received: by mail-oa0-f71.google.com with SMTP id i3sf5646345oag.2 for ; Fri, 04 Oct 2013 18:01:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version: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=HId+g5rUutWHIKTO94gQ333QhEwFvCTsRsUPhgKL/z0=; b=W0qnRfFbfKR3RBbA5M2tI4pVpyIxD1wAz5+FHQFjc3CxvNvlAKrtiOHBTdRSBv47a8 lPzBl1ige/Q4oAIqenaUQNhClKYOpfXrkXYt1xf2LC+zr3TLVZxOIxpA3kkVo8JJGvvO nlLEa5YuCeGK7fiAIUh7/KjxONT4I6RH7j+YVdKJ9LDxJ+0pBK0+nqZ2VHOzCU7YLrkm Fil6IYYoQrQHLqzgxZPJ4bWlX0nJ0yIsuqhSA8i/BrYPdK8JnfcuRu94IwslUXlFFIRI 45GXTJTpUsTh8qVRDM/nH8Y0KRw0IW+G7R0qbbzoooLuqKfMRLdq9ptO3ma2u9vyqd4O WLkw== X-Received: by 10.42.62.8 with SMTP id w8mr8549329ich.23.1380934890136; Fri, 04 Oct 2013 18:01:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.23.12 with SMTP id i12ls1501182igf.8.canary; Fri, 04 Oct 2013 18:01:29 -0700 (PDT) X-Received: by 10.68.96.130 with SMTP id ds2mr17219810pbb.99.1380934889502; Fri, 04 Oct 2013 18:01:29 -0700 (PDT) Original-Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [2607:f8b0:400e:c03::233]) by mx.google.com with ESMTPS id sl4si12334100pac.39.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Oct 2013 18:01:29 -0700 (PDT) Received-SPF: pass (google.com: domain of fourthgeek@gmail.com designates 2607:f8b0:400e:c03::233 as permitted sender) client-ip=2607:f8b0:400e:c03::233; Original-Received: by mail-pa0-f51.google.com with SMTP id kp14so4888757pab.38 for ; Fri, 04 Oct 2013 18:01:29 -0700 (PDT) X-Received: by 10.66.242.17 with SMTP id wm17mr18700889pac.102.1380934889355; Fri, 04 Oct 2013 18:01:29 -0700 (PDT) Original-Received: by 10.70.2.226 with HTTP; Fri, 4 Oct 2013 18:01:29 -0700 (PDT) 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:c03::233 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:6987 Archived-At: --047d7b11191589bf8a04e7f3f572 Content-Type: text/plain; charset=ISO-8859-1 When using RAII, the need to give the variable an explicit name is cumbersome and often not useful. I'll use the example of freezing and thawing in WxWidgets, but the problem is applicable to most any RAII scenario. class WxScopeFreeze; //Freeze() in constructor, Thaw() in destructor WxScopeFreeze Freeze(this); Later on, I want to freeze an additional widget. I should probably update and maintain these variable names now. WxScopeFreeze FreezeThis(this); WxScopeFreeze FreezeOther(Other); Unfortunately, omitting the name is no good here. Without a name, the object lifetime ends at the end of the full expression and we don't get our scope freezing behavior. WxScopeFreeze(this); //doesn't live for the full scope If your object is generated as the result of a function call (esp. for template argument deduction) then the syntax grows yet still. auto&& FreezeThis = ScopeFreeze(this); auto&& FreezeOther = ScopeFreeze(Other); Let's consider ways to get around this issue. The obvious one would be a macro. #define SCOPE_FREEZE(expr) WxScopeFreeze Freeze##__LINE__##(expr); This hides the noise to some extent; you no longer have to think about what to name this RAII object and there won't be any name clashes as long as you don't declare multiples on the same line of code. The __COUNTER__ extension supported by some compilers would give you some alternative. __COUNTER__ would be quite unsafe to use in the name of a variable which you declare in a header though. There are more downsides to the macro approach. * It requires the existence of the macro for every RAII type helper you want. * For our safer __LINE__ solution, names can still clash if they were defined in a separate file (eg, header). These may not generate compilation errors, but could generate spurious static analysis warnings and confusion when debugging. * In a debugger window, you'll see variable names that you never created and that may be difficult to refer back to. * Its a macro Instead of macro invention, how about adding some syntax for unnamed variables? You could repurpose auto when used as the name of a variable. WxScopeFreeze auto(this); WxScopeFreeze auto(Other); auto auto{WxScopeFreeze(this)}; In that last example we use type deduction on an unnamed variable. It would be nice to standardize that idea a bit more, but I'm not sure what the syntax should be. We could consider some other keyword to identify unnamed variables. Unfortunately, the obvious syntax of providing no name is taken as I mentioned. = is almost appealing, but wouldn't work well with lambdas. Ideally we can bind logic to the lifetime of a lambda with unnamed variable syntax. WxScopeFreeze =(this); WxScopeFreeze ={Other}; [ ==WxScopeFreeze(this) ](){}; //weird? -- --- 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/. --047d7b11191589bf8a04e7f3f572 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
When using RAII, the need to give the variable an explicit= name is cumbersome and often not useful. I'll use the example of freez= ing and thawing in WxWidgets, but the problem is applicable to most any RAI= I scenario.

class WxScopeFreeze; //Freeze() in constructor, Thaw() in de= structor=A0

WxScopeFreeze Freeze(this);
=
Later on, I want to freeze an additional widget. I should pr= obably update and maintain these variable names now.

WxScopeFreeze FreezeThis(this);
WxScopeFreeze= FreezeOther(Other);

Unfortunately, omitting the n= ame is no good here. Without a name, the object lifetime ends at the end of= the full expression and we don't get our scope freezing behavior.

WxScopeFreeze(this); //doesn't live for the full sc= ope

If your object is generated as the result of a= function call (esp. for template argument deduction) then the syntax grows= yet still.

auto&& FreezeThis =3D ScopeFreeze(this);
<= div>auto&& FreezeOther =3D ScopeFreeze(Other);

=

Let's consider ways to get around this issue. The o= bvious one would be a macro.
#define SCOPE_FREEZE(expr) WxScopeFreeze Freeze##__LINE__##(expr);

This hides the noise to some extent; you no longer ha= ve to think about what to name this RAII object and there won't be any = name clashes as long as you don't declare multiples on the same line of= code. The __COUNTER__ extension supported by some compilers would give you= some alternative. __COUNTER__ would be quite unsafe to use in the name of = a variable which you declare in a header though.

There are more downsides to the macro approach.=A0
* It requires the existence of the macro for every RAII type hel= per you want.
* For our safer __LINE__ solution, names can still = clash if they were defined in a separate file (eg, header). These may not g= enerate compilation errors, but could generate spurious static analysis war= nings and confusion when debugging.
* In a debugger window, you'll see variable names that you n= ever created and that may be difficult to refer back to.
* Its a = macro

Instead of macro invention, how about adding= some syntax for unnamed variables?

You could repurpose auto when used as the name of a var= iable.
WxScopeFreeze auto(this);
WxScopeFreeze auto(Oth= er);
auto auto{WxScopeFreeze(this)};

In that last example we use type deduction on an unnamed variable. It would= be nice to standardize that idea a bit more, but I'm not sure what the= syntax should be.


We could conside= r some other keyword to identify unnamed variables. Unfortunately, the obvi= ous syntax of providing no name is taken as I mentioned.

=3D is almost appealing, but wouldn't work well wit= h lambdas. Ideally we can bind logic to the lifetime of a lambda with unnam= ed variable syntax.
WxScopeFreeze =3D(this);
WxScopeFre= eze =3D{Other};
[ =3D=3DWxScopeFreeze(this) ](){}; //weird?

--
 
---
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>.
--047d7b11191589bf8a04e7f3f572-- .