220 7008 <0d9b268f-cd3a-4048-a0a3-50cff02b28ce@isocpp.org> article Path: news.gmane.org!not-for-mail From: snk_kid Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Unnamed LValues Date: Sat, 5 Oct 2013 07:43:31 -0700 (PDT) Lines: 301 Approved: news@gmane.org Message-ID: <0d9b268f-cd3a-4048-a0a3-50cff02b28ce@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1061_10966967.1380984211255" X-Trace: ger.gmane.org 1380984209 18018 80.91.229.3 (5 Oct 2013 14:43:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Oct 2013 14:43:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCG6DCXN7IPRBE6LYCJAKGQEHGHCAZY@isocpp.org Sat Oct 05 16:43:34 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VST4w-0001rC-0q for gclcip-std-proposals@m.gmane.org; Sat, 05 Oct 2013 16:43:34 +0200 Original-Received: by mail-vc0-f200.google.com with SMTP id ia6sf749946vcb.7 for ; Sat, 05 Oct 2013 07:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=H+C5cbnskcuQC+U/R02QdZO01m/BrnpzZsKHQm8sP+4=; b=H4m2uudGrs0q9eXQwYz8oOuC/AbhUBH6liFk6M+gpQUBrD0a0o0ruCjgUsV4FSAoG1 gDcWuMzxHuEjZzCZB73g9XWckD1CIAVKDlxfRJaEnIsqEiqWsEAM6fa6/m1sq9RSGVTK dZA9OZnOtfDF6RFtf3wDgu1TY5dbntgeIp1UgnV5IufqwFJ2M+pYati7bGGnIRvZ0VC9 d9wrD0+6DAydjHpUliaANQPJpB7p/iarHDnOEYHrlVkpuGxw5p9aWEde6tmIy7yqaQR1 bjBRE7bjdG9KiC937Qv6qbjv4Sq70ceV7OcfFQ/ZKKKrDRyh7edEHTAPwyKjBbg2kNSw jznQ== X-Received: by 10.236.54.68 with SMTP id h44mr19057894yhc.21.1380984212392; Sat, 05 Oct 2013 07:43:32 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.109.226 with SMTP id hv2ls1716819qeb.22.gmail; Sat, 05 Oct 2013 07:43:31 -0700 (PDT) X-Received: by 10.49.133.225 with SMTP id pf1mr741167qeb.6.1380984211681; Sat, 05 Oct 2013 07:43:31 -0700 (PDT) In-Reply-To: X-Original-Sender: korcan.hussein@googlemail.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:7008 Archived-At: ------=_Part_1061_10966967.1380984211255 Content-Type: text/plain; charset=ISO-8859-1 A simpler solution would be to use plain higher-order functions, with-function patterns are very common in functional languages, something like: template < typename Function > auto with_freeze(SomeWxWidgetClass* w, Function&& fn) -> decltype(fn()) { WxScopeFreeze scoped_freeze(w); return fn(); } example usage: with_freeze(this, [&]() -> void { with_freeze(other, [&]() -> void { // do stuff. }); }); If you don't like the nesting you may be able to generalize this in various ways like using variadic templates so it may look more like this: with_freeze(this, other, [&]() -> void { // do stuff. }); On Saturday, October 5, 2013 2:01:29 AM UTC+1, Brent Friedman wrote: > > 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/. ------=_Part_1061_10966967.1380984211255 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A simpler solution would be to use plain higher-order func= tions,=20 with-function patterns are very common in functional languages,=20 something like:

template = < typename= Function >
auto with_freeze(SomeWxWidgetClass* w, <= /span>Function&& fn) -> decltype(fn())=
{
  &nbs= p; WxScope= Freeze sco= ped_freeze= (w<= span style=3D"color: #660;" class=3D"styled-by-prettify">);
    <= span style=3D"color: #008;" class=3D"styled-by-prettify">return fn();
}

example usage:
with_f= reeze(this, [&]() -> void
{
&n= bsp;   with_freeze(other,= [&]() -> void
    {
        // do stuff.
    = });
});

I= f you don't like the nesting you may be able to generalize this in=20 various ways like using variadic templates so it may look more like=20 this:

with_freeze(this, = other, [&]() -> void{=
   = // do stuff.<= span style=3D"color: #000;" class=3D"styled-by-prettify">
});
On Saturday, October 5, 2013 2:01:29 AM UTC+1, Brent Friedman wrote:
When using RAII, t= he need to give the variable an explicit name is cumbersome and often not u= seful. I'll use the example of freezing and thawing in WxWidgets, but the p= roblem is applicable to most any RAII scenario.

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

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 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 scope<= /div>

If your object is generated as the result of a fun= ction 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 obvio= us 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. T= he __COUNTER__ extension supported by some compilers would give you some al= ternative. __COUNTER__ would be quite unsafe to use in the name of a variab= le 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 sti= ll clash if they were defined in a separate file (eg, header). These may no= t 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 macr= o

Instead of macro invention, how about adding som= e 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 syn= tax should be.


We could consider so= me other keyword to identify unnamed variables. Unfortunately, the obvious = syntax of providing no name is taken as I mentioned.

=3D is almost appealing, but wouldn't work well with la= mbdas. Ideally we can bind logic to the lifetime of a lambda with unnamed v= ariable syntax.
WxScopeFreeze =3D(this);
WxScopeFreeze = =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>.
------=_Part_1061_10966967.1380984211255-- .