220 11020 article Path: news.gmane.org!not-for-mail From: Thibaut Lutz Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Protect Lambda functions against reflection Date: Mon, 2 Jun 2014 07:30:15 -0700 (PDT) Lines: 167 Approved: news@gmane.org Message-ID: References: <108c47a2-d952-4f84-a347-923b2ab742ad@isocpp.org> <7ef3d3da-0c1d-443c-88d2-656b91937170@isocpp.org> <68f98b78-8bd4-48e0-9e1d-47cfc0492764@isocpp.org> <2960c77b-fd52-4052-b50c-c8e2aa829cf7@isocpp.org> <1dd683e4-5728-41f2-9a7d-b8d604dbcf8b@isocpp.org> <1c28d0af-7252-4828-a25a-b34794051883@isocpp.org> <10f413fd-5c55-412e-a791-7ae07b94b8ed@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_196_14608244.1401719415169" X-Trace: ger.gmane.org 1401719425 7713 80.91.229.3 (2 Jun 2014 14:30:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Jun 2014 14:30:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC66PHON7ACRB6EUWKOAKGQEAF57IZY@isocpp.org Mon Jun 02 16:30:19 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f197.google.com ([209.85.192.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WrTFh-00080N-RL for gclcip-std-proposals@m.gmane.org; Mon, 02 Jun 2014 16:30:18 +0200 Original-Received: by mail-pd0-f197.google.com with SMTP id y10sf16002633pdj.8 for ; Mon, 02 Jun 2014 07:30:16 -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=qv7xqJHnHr48UiMUwIPinazVs4UEek2L+Si8WnW4l28=; b=lRmxGpGXXdiuVftUCbRGhhy2c62Bfe1qYkuk8bAORx+fQ5lmvCBovNPwDxEYK3sKln ZZhMMHrqxUgSrjIveKOVPrr5KQK0pSBmwZxK7IjrmAO8IE5fAN2KL4zLNmtdYTL3EnS1 pbRCEbxE4FrhppV+u83TTgVyudEuh5ZI5X9ZpjgINdHvCBIeLD7rPWgd2GzYND64a/YZ nhm5qh1+tSRIQ9ZLEyX/4n/RTIW1+4MdXM0a9XiXEWQm6Zu46Q6dM3sIbcM2eV77MUaV 7HSfSk5OJlWrEYVJPXCtJArBqplLgZ48/99he+IvTWYcaJ+wia7FNrxtsz3/J1QVbR34 +qfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=qv7xqJHnHr48UiMUwIPinazVs4UEek2L+Si8WnW4l28=; b=FDrTELNlJoGui/o4HLSlbpOnST5s9mjKNnF0k2qwWIq1glJqo3/ON1odOdjPRkb1tm e7CI6DQkCDQXn/RIqUhLEKYs57rgYzag3DMaFiBWrwY+0JQFeCNJN97kwUAz+YceCaji yTHVwViCC1nbO/DQU3Ycl2o6sW3iQ2lK1y6z9HKuZNasnfRw04oITHFRjzlvxYXONjb0 /PWUW4MlHXnJOo5SdjBaWt+r8ndGvxeM3LWm9c/ezBgwgW5PrY2ptKl/iFB7+aZgkjW3 MW/EDkPrFWDxtG9oL8HvWhpah3F+wDk613FcnEz+nRV/fK1X/tNSWpVujSCZtZFZSXjR xgeA== X-Gm-Message-State: ALoCoQlLBPNb4w/QYsopiwyN2Rm7VA/LNRgSLHShm9+U+bhj7A2EvX8J1TRdQODQfW+YD6w9lcbo X-Received: by 10.66.222.129 with SMTP id qm1mr14007035pac.6.1401719416782; Mon, 02 Jun 2014 07:30:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.85.138 with SMTP id n10ls2111127qgd.4.gmail; Mon, 02 Jun 2014 07:30:16 -0700 (PDT) X-Received: by 10.140.48.241 with SMTP id o104mr8951qga.38.1401719416067; Mon, 02 Jun 2014 07:30:16 -0700 (PDT) In-Reply-To: <10f413fd-5c55-412e-a791-7ae07b94b8ed@isocpp.org> X-Original-Sender: thibaut.lutz@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:11020 Archived-At: ------=_Part_196_14608244.1401719415169 Content-Type: text/plain; charset=UTF-8 Thanks for the comments. - If construction of lambdas is ever allowed through reflection, then it > should create a new type of lambda, constructing an existing type should > only be possible via copy or move, this avoids the problem you mentioned > with references. > This is a bit tricky. A Lambda declaration is implicitly a constructor call, so the constructor does exist and is accessible. Moreover the type of the newly created object might be explicitly the same as the lambda's: auto test = [](){return 0;}; using Lambda = decltype(test); Lambda closure = std::reflect::construct(); Also, creating new types on the fly introduces transitive oddities: auto test = [](){return 0;}; auto closure = std::reflect::construct(); static_assert::value>(); // this fails test = closure; // this fails > - Maybe it's worth at least having a function which just returns the types > and names of captured variables: this would make it possible for a portable > higher level interface to lambdas to be added to the standard library at a > later time without any additional compiler support (the standard library > can 'know' exactly what the layout of a lambda looks like given a capture > list because it can be aware of the inner workings of the compiler). > This might be one possibility, but it looks to me like it would be more of an extension of the current lambda capabilities rather than a feature of reflection. Another possibility would be to enforce that identifiers are the same in the capture list and the closure type, instead of being unnamed. It would be interesting to know why they decided the members should be unnamed in the first place, my guess it they don't want them to be accessible, which is something reflection would expose. -- --- 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_196_14608244.1401719415169 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the comments.

- If construction of lambdas is ever a= llowed through reflection, then it should create a new type of lambda, cons= tructing an existing type should only be possible via copy or move, this av= oids the problem you mentioned with references.
=
This is a bit tricky. A Lambda declaration is implicitly a c= onstructor call, so the constructor does exist and is accessible. Moreover = the type of the newly created object might be explicitly the same as the la= mbda's:
  auto test =3D [](){<=
/span>return 0;};
  using Lambda =3D decltype(test);
  Lambda closure =3D s=
td::reflect<Lambda>::construct=
();

Also, creating new types on the fly introduces tran= sitive oddities:
  auto <=
span style=3D" color:#000000;">test =
=3D [](){return 0;};=

  auto closure =3D std=
::reflect<decltype(test)>::construct();
  static_assert<is_same<de=
cltype(test),decltype(closure)>::value>(); //=
 thi=
s fails
  test =3D closure;=
 // this fails
&nbs= p;
- May= be it's worth at least having a function which just returns the types and n= ames of captured variables: this would make it possible for a portable high= er level interface to lambdas to be added to the standard library at a late= r time without any additional compiler support (the standard library can 'k= now' exactly what the layout of a lambda looks like given a capture list be= cause it can be aware of the inner workings of the compiler).

This might be one possibility, but it looks to= me like it would be more of an extension of the current lambda capabilitie= s rather than a feature of reflection. Another possibility would be to enfo= rce that identifiers are the same in the capture list and the closure type,= instead of being unnamed. It would be interesting to know why they decided= the members should be unnamed in the first place, my guess it they don't w= ant them to be accessible, which is something reflection would expose.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_196_14608244.1401719415169-- .