220 29934 <78e69be6-4dfd-4949-85d9-145097ea2580@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: "T. C." 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: Mon, 19 Dec 2016 12:21:24 -0800 (PST) Lines: 250 Approved: news@gmane.org Message-ID: <78e69be6-4dfd-4949-85d9-145097ea2580@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1216_1208111683.1482178884753" X-Trace: blaine.gmane.org 1482178894 12825 195.159.176.226 (19 Dec 2016 20:21:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Dec 2016 20:21:34 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCQ43G7NQIIRBRMC4HBAKGQE3S2XZIQ@isocpp.org Mon Dec 19 21:21:25 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f72.google.com ([74.125.83.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJ4R0-0001Rf-1n for gclcip-std-proposals@m.gmane.org; Mon, 19 Dec 2016 21:21:22 +0100 Original-Received: by mail-pg0-f72.google.com with SMTP id z5sf40887pgb.4 for ; Mon, 19 Dec 2016 12:21:26 -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=4/xWhpGIeVTDSHcT24vPEbDXBJvRm1fvzAdQ15WqqkI=; b=AafWMh7qmEeULibZcJpk/1D/6sH8MWspCd5qEhm+CK8JnLLlZmwcUCSu4kbMALonII MU7A/+nlhHgt3c9h1d6+vhnyqZaODG4OCKO65tKynlSGpaN5G9q0qLCcd9OxvOD86ubD jlvNl163pcB90+DkmGy/b6Q4a4WM2otRknEmTianOF8YpAyOHguBNcGakSh/bt7fQkDk RJmAfUJ5EsweFpO5O370dAkXyjgMcZSUHyJ5mDFkCFMNgfBhgh/F42ZHj2KoM3yINOom qy9O79PL/PJPbvCX2g4dDK4JB2SqsCSnqmDPpPuHYRFiRR1RKmDgZaqW0DdniFQV3fwJ Zxxg== 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=4/xWhpGIeVTDSHcT24vPEbDXBJvRm1fvzAdQ15WqqkI=; b=Kx/NDtHc4VeAHJJabb04xkepwQ/tms7/NJrRi6Ek5vv2iLQnGPJimBENRK9/dxZYad 0zP2Iq+L2cBFhYlqqnw7wjzfgaGAhk9nzeBPOuIJnVA18S8Xez2QkOhIsNsbuiElcBOB oKjDLCCrQfBIl5TubA/goXu6oWoVHI5cyKWwRz2idZ/ixzphW0tPoGXOKHS8VKGs0AIG Tlv73WKJaBpgSBJ4rcQu2gad696yMiFAoBQi9nl5Zn1gdpxoucRnAXFXKBgXiYXme3eG WPzZr9wpVXUkN0263aCfW/MvLMZZDzThIthKwb3+ioDaOOcEdG5SFH3HawAgWWvhukit 48LQ== 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=4/xWhpGIeVTDSHcT24vPEbDXBJvRm1fvzAdQ15WqqkI=; b=QQOyeu3kPZioVvfD3HyLB+gUF7afq2SYnAPgRbuN0j0NAMSYyvVC9W0pKyRynB7oew d4tbMI55IY5n4DOWtjurnUCR9yr4BLucep935GxRbxJxZwKMKBWTx9uu54Ft7TyIJGLl OJ/UWquF1RaUK5zZGo/DN0S+JBmNgl9yXq1wT+7fCPNlbQfUHfT0lb50OX71n2888dsR ox79L8scPYxUYtN9Z2CsPu3jfazNd7g5WcMdhPA9fInYIfA7AQWLfxCptIpyC/WT4oMo skNEbU7QifXOZpTG6F69GbFRV0nUNzCy4S87H7gwSH8depyu2Qmzj+nbypJNyWng0KrO 0xSA== X-Gm-Message-State: AKaTC02cLfBK2ZwPw8dlmPsBBe7nvWTMZesF8vEDmo1T3/gP/nkBWBPjDPYjQhbaiI/CJA== X-Received: by 10.99.161.17 with SMTP id b17mr9129813pgf.152.1482178886338; Mon, 19 Dec 2016 12:21:26 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.27.206 with SMTP id v14ls14032272otv.2.gmail; Mon, 19 Dec 2016 12:21:25 -0800 (PST) X-Received: by 10.157.8.134 with SMTP id 6mr832584otf.17.1482178885376; Mon, 19 Dec 2016 12:21:25 -0800 (PST) In-Reply-To: X-Original-Sender: rs2740@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:29934 Archived-At: ------=_Part_1216_1208111683.1482178884753 Content-Type: multipart/alternative; boundary="----=_Part_1217_2041919753.1482178884754" ------=_Part_1217_2041919753.1482178884754 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, December 17, 2016 at 10:14:30 AM UTC-5, Vittorio Romeo wrote: > > 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 orde= r=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= =20 > am not sure where to start here though, as I'm confident that multiple=20 > rules from different parts of the standard come into play here.=20 > Intuitively I think that the return type should evaluate to `char` (as th= e=20 > parameter `i` is closer to the trailing return type). What do you think? = =20 > > > More cases to address - interaction with default captures and with=20 references captured-by-copy: const int& x =3D 1; [x](decltype(x)) {} // this is (const int&) currently. (const int) under=20 your rules? [=3D]{ decltype(x) y =3D 1; } // this is (const int&) currently again, ???= =20 under your rules The p17 change isn't on point: decltype isn't an odr-use (indeed I wonder= =20 if it's even possible to odr-use *anything* in a lambda-declarator). The=20 note in the paragraph also needs changing. In general, I'd suggest laying out the various examples first and saving=20 the wording until the end. The examples convey your intended changes far=20 better than the wording. Also, I'd suggest using https://timsong-cpp.github.io/cppwp/n4618/ rather= =20 than tip-of-trunk, esp. as the project editor seems to be about to do some= =20 editorial restructuring in this subclause. --=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/78e69be6-4dfd-4949-85d9-145097ea2580%40isocpp.or= g. ------=_Part_1217_2041919753.1482178884754 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Saturday, December 17, 2016 at 10:14:30 AM UTC-= 5, Vittorio Romeo wrote:
Thank you very much for the feedback.

Here's a new dr= aft:
https://vittorioromeo.info/Misc/lambda_issue_d= raft_2.html

I've looked into most of the issues/= inconsistencies you suggested, and I came to the conclusion that also simpl= e-captures need to be "visible" in the lambda-declarator.
I= 9;m not sure if the proposed wording is correct (and I'm not sure how I= should address captures by reference, as they're not covered by=C2=A0<= a href=3D"https://timsong-cpp.github.io/cppwp/expr.prim.lambda#17" style=3D= "font-family:"Times New Roman";font-size:medium" target=3D"_blank= " rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.com/u= rl?q\x3dhttps%3A%2F%2Ftimsong-cpp.github.io%2Fcppwp%2Fexpr.prim.lambda%2317= \x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFJUuB_fhKVVtSY5aQc6Fddmz3qXQ';= return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dh= ttps%3A%2F%2Ftimsong-cpp.github.io%2Fcppwp%2Fexpr.prim.lambda%2317\x26sa\x3= dD\x26sntz\x3d1\x26usg\x3dAFQjCNFJUuB_fhKVVtSY5aQc6Fddmz3qXQ';return tr= ue;">=C2=A75.1.5/17).

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



More cases to address - interaction with default captu= res and with references captured-by-copy:

const int& x =3D = 1;
[x](decltype(x)) {} // this is (const int&) currently= .. (const int) under your rules?
[=3D]{ decltype= (x<= span style=3D"color: #660;" class=3D"styled-by-prettify">) y =3D 1; }<= /span> // this is (const in= t&) currently again, ??? under your rules


The p17 change isn't on point: decltype=C2=A0= isn't an odr-use (indeed I wonder if it's even possible to odr-use = *anything* in a lambda-declarator). The note in the paragraph also needs ch= anging.

In general, I'd suggest laying out the vario= us examples first and saving the wording until=C2=A0the end. The examples c= onvey your intended changes far better than the wording.

Also, I'd suggest using https://timsong-cpp.github.io/cppwp/n461= 8/ rather than tip-of-trunk, esp. as the project editor seems to be about t= o do some editorial restructuring in this subclause.

--
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/78e69be6-4dfd-4949-85d9-145097ea2580= %40isocpp.org.
------=_Part_1217_2041919753.1482178884754-- ------=_Part_1216_1208111683.1482178884753-- .