220 29870 article Path: news.gmane.org!.POSTED!not-for-mail From: Vittorio Romeo Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Extending the scope of generalized lambda captures to include the lambda's trailing return type Date: Sat, 17 Dec 2016 07:14:30 -0800 (PST) Lines: 576 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_779_216450449.1481987670360" X-Trace: blaine.gmane.org 1481987676 5933 195.159.176.226 (17 Dec 2016 15:14:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Dec 2016 15:14:36 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCO3NDEYZQHRBV5M2XBAKGQE5D2YLWA@isocpp.org Sat Dec 17 16:14:31 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIGgt-0000Jz-JA for gclcip-std-proposals@m.gmane.org; Sat, 17 Dec 2016 16:14:27 +0100 Original-Received: by mail-ua0-f198.google.com with SMTP id 3sf68510191uaz.2 for ; Sat, 17 Dec 2016 07:14:32 -0800 (PST) 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=NRN3BxNWEKxOjtRIvKxYjue/b3j7daSJCWrkXZm3gV0=; b=CZtA8hftnIgmF+mfKOkYRxKcBvsTOY3mwO1Jeip2LGwUuInHGiJtD0V14vCqW8F9cv xgJX/takMOHmRfgnZsQt4ByfS/hFXL7YnjKN/7s++3edX1HPOSvBA8iK0wxtEssVZ3EP LCa7w3o9PiMJNGFBmZjoynESHWm+lNwugIeyMNV0UUzZsNmmWV8+7lnTTOHaCWTnjzaQ ACtIRYjU7TpLqf1UIKgUsXhCGGGd9BDok5B87v00MJI5GHwrQx56QlkHvqeIJ4s+Cq4C VuVjmOO0Pi/X+9iynEzwqEzx2CRtnqU6k7QRnHTdEnuLL/jorLqdeb9mUWwDw+Uo2ge1 GWbg== 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=NRN3BxNWEKxOjtRIvKxYjue/b3j7daSJCWrkXZm3gV0=; b=MawyoSTVEwt5VqqMKZTChcB0uo5i5Xys4cHXD0CbL70YZGq6Yu/ZN93NMaaSMQVwgt iVu2qKoJbcgaB/3jf2gz+5i8RgZ5OZiKxB2yp/wYyUuVCyRbmrv5fr6ig18XpaJTqnfP DFgp7IGILxYI3KilJGdoM9gw6U0YicNgZSDKKiSflACnw0QzxlOv+1kWj0q740iDFw+N j92HItN3Wm7R+AjGNlSeM21r80AQsBib8N7NBxsZAxQPnJLdfNQieYlyO3kMkhzaUskP 8+nCwKUBDM7BHZ39yLabUGwDWoCH7gy9GwLxkJ2yfugFH4U4JQjeMDGgJ/ep4ILV9THc yHcQ== 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=NRN3BxNWEKxOjtRIvKxYjue/b3j7daSJCWrkXZm3gV0=; b=MZwHrYnF1nkN2/ackZIR0UDls3o07nL9NmW2mYrom3kaUlQ+0Hr0zTLdJv7t65uGqu pnp4Pr04c9Pi4CImiCQGUyQDcEj8GvNLjbNhYO3vOiOBZL0sR8B2xm89zVzkAk7aibhK 6Vb8y3hjTGAMgFiHQXXOONB0TIfem4CX7EDhAUSRpHC+2qBg85oNr2EEOx05i11jyyFC op7AKGy8U4BIA+mFPJvmTE1SFCqjKZHRU9iE/DNtPQTI5+yBzTZeEg8lnWAo4NgaLQaV Popcq1kOY5bNhs0NOP/IZ3QlndLagUX1pEP3Nww0uECCS/qFLmQZTlg0hBM9Ykqz9Snp YFPg== X-Gm-Message-State: AIkVDXIRM9ZZKkObhTV10Y6JZMSaK0qx5LUsJF/xzCjH5tVcEZWWw57j8VPzxZPbKFX0nQ== X-Received: by 10.31.207.70 with SMTP id f67mr1369566vkg.41.1481987671802; Sat, 17 Dec 2016 07:14:31 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.27.137 with SMTP id z9ls11875656otd.28.gmail; Sat, 17 Dec 2016 07:14:30 -0800 (PST) X-Received: by 10.157.27.9 with SMTP id l9mr453996otl.6.1481987670923; Sat, 17 Dec 2016 07:14:30 -0800 (PST) In-Reply-To: X-Original-Sender: vittorio.romeo.vee@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:29870 Archived-At: ------=_Part_779_216450449.1481987670360 Content-Type: multipart/alternative; boundary="----=_Part_780_1476758788.1481987670362" ------=_Part_780_1476758788.1481987670362 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you very much for the feedback. Here's a new draft: https://vittorioromeo.info/Misc/lambda_issue_draft_2.html I've looked into most of the issues/inconsistencies you suggested, and I=20 came to the conclusion that also simple-captures need to be "visible" in=20 the lambda-declarator. I'm not sure if the proposed wording is correct (and I'm not sure how I=20 should address captures by reference, as they're not covered by =C2=A75.1.5= /17=20 ). Some questions/feedback requests: * Any idea for a title that clearly conveys the intent of making both=20 simple-captures and init-captures usable in the lambda-declarator in order= =20 to achieve consistency with classes? * Are the proposed changes to the standard reasonable? Would the addition= =20 of a new paragraph make it clearer that all types of captures should be=20 accessible in the lambda-declarator for consistency with classes? * The last example posted by Arthur int i; auto f =3D [i=3D0L](char i) -> decltype(i) { return 0; } // decltype(f(0)) =3D=3D ??? is something that the paper should address, after the change in scope. I am= =20 not sure where to start here though, as I'm confident that multiple rules= =20 from different parts of the standard come into play here.=20 Intuitively I think that the return type should evaluate to `char` (as the= =20 parameter `i` is closer to the trailing return type). What do you think? = =20 On Thursday, 15 December 2016 13:27:06 UTC, Vittorio Romeo wrote: > > int main(){ > auto l =3D [x =3D 10]() -> decltype(x) {};} > > > > > -=20 > =20 > *clang++ 4.0* rejects this code=20 > with the=20 > following error: > -=20 > =20 > error: use of undeclared identifier 'x' > auto l =3D [x =3D 10]() -> decltype(x) {}; > ^ > =20 > -=20 > =20 > *g++ 7* rejects this code=20 > with the=20 > following error: > =20 > In function 'int main()': > error: 'x' was not declared in this scope > auto l =3D [x =3D 10]() -> decltype(x) {}; > ^ > error: 'x' was not declared in this scopeIn lambda function: > warning: no return statement in function returning non-void [-Wreturn-= type] > auto l =3D [x =3D 10]() -> decltype(x) {}; > ^ > =20 > =20 > =20 > I posted this today on StackOverflow thinking it was a compiler bug: > http://stackoverflow.com/questions/41162200/ > > But it's not - the standard says that the scope of `x` is limited to the= =20 > body of the lambda. This answer has the details:=20 > http://stackoverflow.com/a/41162972/598696 > (quoted below) > > --- > > *TL;DR*: Compilers behave as expected. > > The standard defines lambda semantics as follows [expr.prim.lambda,=20 > section 1]: > > lambda-expression: > > lambda-introducer lambda-declarator_opt compound-statement > > Here *compound-statement* is just the body of lambda between {}, because= =20 > everything else is included in *lambda-declarator*: > > lambda-declarator: > > ( parameter-declaration-clause ) decl-specifier-seq_opt > exception-specification_opt attribute-specifier-seq_opt trailing-r= eturn-type_opt > > Also, in section 12 of the same chapter, it's said that > > An init-capture behaves as if it declares and explicitly captures a=20 > variable of the form =E2=80=9Cauto init-capture ;=E2=80=9D whose declarat= ive region is the=20 > lambda-expression=E2=80=99s compound-statement, except that: > > (12.1) =E2=80=94 if the capture is by copy (see below), the non-static da= ta member=20 > declared for the capture and the variable are treated as two different wa= ys=20 > of referring to the same object, which has the lifetime of the non-static= =20 > data member, and no additional copy and destruction is performed, and > > (12.2) =E2=80=94 if the capture is by reference, the variable=E2=80=99s l= ifetime ends when=20 > the closure object=E2=80=99s lifetime ends. > > So, in your first example, variable x scope is the lambda body only, not= =20 > including the decltypeexpression. In the second example, obviously, x sco= pe=20 > is the function main. > > --- > > Do you think that writing a proposal to relax these rules and to=20 > explicitly allow generalized captures to be used inside the trailing retu= rn=20 > type would be worthwhile? > > One possible use case is when the generalized captures are initialized=20 > with complex expressions. I encountered this while experimenting today ( > http://melpon.org/wandbox/permlink/aVasfHaK6boC6NZt). > In general, it would be beneficial to have this feature whenever the=20 > generalized capture is used as part of the return expression in the lambd= a=20 > body. > --=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/cba1a1fa-d3c8-43e0-a1b5-f69fb285a680%40isocpp.or= g. ------=_Part_780_1476758788.1481987670362 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you very much for the feedback.

Here's a = new draft:
https://vittorioromeo.info/Misc/lambda_issue_draft_2.html
=
I've looked into most of the issues/inconsistencies you = suggested, and I came to the conclusion that also simple-captures need to b= e "visible" in the lambda-declarator.
I'm not sure if the = proposed wording is correct (and I'm not sure how I should address capt= ures by reference, as they're not covered by=C2=A0=C2=A75.1.5/17).

Some= questions/feedback requests:
* Any idea for a title that clearly= conveys the intent of making both simple-captures and init-captures usable= in the lambda-declarator in order to achieve consistency with classes?
= * Are the proposed changes to the standard reasonable? Would the addition o= f a new paragraph make it clearer that all types of captures should be acce= ssible in the lambda-declarator for consistency with classes?
* The last= example posted by Arthur
=C2=A0 =C2=A0=C2=A0int=C2=A0i;
=C2=A0 = =C2=A0=C2=A0auto=C2=A0f=C2=A0=3D=C2=A0[i=3D0L](char=C2=A0i)=C2=A0->=C2=A0decltype(i){= =C2=A0return=C2=A00;=C2=A0}
=C2=A0 =C2=A0=C2=A0// decltype(f(0)) =3D=3D ???
is something that the= paper should address, after the change in scope. I am not sure where to st= art here though, as I'm confident that multiple rules from different pa= rts of the standard come into play here.
Intuitively I think that the r= eturn type should evaluate to `char` (as the parameter `i` is closer to the= trailing return type). What do you think? =C2=A0


On Thursday, 1= 5 December 2016 13:27:06 UTC, Vittorio Romeo wrote:
int main=
()
{
    auto l =3D [x =3D <=
span style=3D"color:rgb(125,39,39)">10]() -> decltype(x) {};
}


  • cl= ang++ 4.0=C2=A0rejects this code=C2=A0with the following error:

  • error:= use of undeclared identifier &= #39;x' auto l =3D<= /span> [x =3D 10]() -> = decltype(x) {}; ^

  • g++ 7=C2=A0rejects this code=C2=A0with the foll= owing error:

    In function 'int main()':
error: 'x' was not declared in this scope
  auto l =3D<=
span style=3D"color:rgb(48,51,54)"> [x =3D 10]() -> =
decltype(x) {};
                                  ^
error: 'x' was not declared in this scope
In lambda function:=

warning: no return statement in function returning n=
on-void [-Wreturn-type]
  auto l =3D<=
span style=3D"color:rgb(48,51,54)"> [x =3D 10]() -> =
decltype(x) {};
                                  ^

I posted this today on StackOverflow thinking it was a compil= er bug:

But it's not - the stand= ard says that the scope of `x` is limited to the body of the lambda. This a= nswer has the details:
(quoted below)

---

TL;DR: Compilers behave as expected.

The standard defines lam= bda semantics as follows [expr.prim.lambda, section 1]:

lambda-expression:

=
   lambda-introducer lambda-declarator_opt compound-statement

Here=C2=A0compound-stateme= nt=C2=A0is just the body of lambda between {}, because everything else= is included in=C2=A0lambda-declarator:

lambda-declarator:

   ( parameter-declaration-clause ) de=
cl-specifier-<=
span style=3D"color:rgb(48,51,54)">seq_opt
       exception-specification_opt attribute-specif=
ier-seq_opt trailing-=
return-type_opt

Also, in section 12 of the same chapter, it's said= that

An init-capture behaves = as if it declares and explicitly captures a variable of the form =E2=80=9Ca= uto init-capture ;=E2=80=9D whose declarative region is the lambda-expressi= on=E2=80=99s compound-statement, except that:

(12.1) =E2=80=94 if the capture is by copy (see below), the= non-static data member declared for the capture and the variable are treat= ed as two different ways of referring to the same object, which has the lif= etime of the non-static data member, and no additional copy and destruction= is performed, and

(12.2) =E2=80=94 if the captu= re is by reference, the variable=E2=80=99s lifetime ends when the closure o= bject=E2=80=99s lifetime ends.

So, in your first example, variable= =C2=A0x=C2=A0scope is the lambda body only, not including the=C2= =A0decltypeexpression. In the second example, obviously,=C2=A0x<= /code>=C2=A0scope is the function=C2=A0main.

---

Do you think that writing= a proposal to relax these rules and to explicitly allow generalized captur= es to be used inside the trailing return type would be worthwhile?

One possible= use case is when the generalized captures are initialized with complex exp= ressions. I encountered this while experimenting today (http://melpon.org/w= andbox/permlink/aVasfHaK6boC6NZt).
In general, it would be bene= ficial to have this feature whenever the generalized capture is used as par= t of the return expression in the lambda body.

=

--
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/cba1a1fa-d3c8-43e0-a1b5-f69fb285a680= %40isocpp.org.
------=_Part_780_1476758788.1481987670362-- ------=_Part_779_216450449.1481987670360-- .