220 10960 <00b0838d-edab-492d-a9ec-3c56b6f1eb7e@isocpp.org> article Path: news.gmane.org!not-for-mail From: Diggory Blake Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Protect Lambda functions against reflection Date: Thu, 29 May 2014 09:12:45 -0700 (PDT) Lines: 115 Approved: news@gmane.org Message-ID: <00b0838d-edab-492d-a9ec-3c56b6f1eb7e@isocpp.org> References: <108c47a2-d952-4f84-a347-923b2ab742ad@isocpp.org> <7ef3d3da-0c1d-443c-88d2-656b91937170@isocpp.org> <68f98b78-8bd4-48e0-9e1d-47cfc0492764@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3089_30387345.1401379965128" X-Trace: ger.gmane.org 1401379976 16498 80.91.229.3 (29 May 2014 16:12:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 May 2014 16:12:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC2MLAWQ6ANBB7VYTWOAKGQE2LNQMDY@isocpp.org Thu May 29 18:12:49 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wq2wi-0003X4-8J for gclcip-std-proposals@m.gmane.org; Thu, 29 May 2014 18:12:48 +0200 Original-Received: by mail-pa0-f70.google.com with SMTP id kp14sf2616788pab.1 for ; Thu, 29 May 2014 09:12:46 -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=lggKh16T70og2oYkVHYoRETjAxRjdCkamlGiKA2Bhvs=; b=ur5IfZLLJPZ/ggkPlYptKVWybUeCAWRfzp3jLk6OKqZvzuPAgQpa3OgJ1qKcOd9sPo Kxq5jbS18LdOFlhW2I/Cg4ppoJPf94eFeK5B8+L7qjX/QrlmapU+zrLdPhNH30vEEI4v /gRRj7MPZRNZotXS9XwI9UmxhFzFFZYQDHUoSyxZUpt/6uMCDMZU7/E19qnfDaASGhuW xE0Hn2U53ZpZSy9/9YkvBqsxnBru0ulc7Tz80R9VTcGQf8TUK9vlwE4yAIPm+UNIPRC6 7kkYpQ1+FOUrZRnuaqYM9ZXTwydPeWJz1nzrxOCJFI7xSMyh0M5DSEcjcTzLvmO0cw+S Hsxg== 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=lggKh16T70og2oYkVHYoRETjAxRjdCkamlGiKA2Bhvs=; b=BT88r4ljHO1oh5kz1s0bEjYeDUG1mcwbEH5sXFKz7DczDWartrWo6dMXS2XxlzDfL0 VugW86unRRkTja0albLxSsNSUl7ICuK7GaExQz4WrUh8YQGWZn/CMWKFaFNAIL8aUiPd DtUtAgksm8a1+kU+eWBrQiUW96yRC7PpXnef+Xy6yKwvTot9z8KR67uAVYf/mU5ZDxQN iESW5NuzzMS3xrJKFyzNQH6q8SXFON4JWiUZp2Zr3Efr/1zG8sSuakycacYR17IGQJwM ge46MtVBa+O19vOdgtfl1OlNhwza5z6aN6Zmq1LojGZoPE/1jJQxggJXseHRH/qO6o+W T/Kg== X-Gm-Message-State: ALoCoQnHJ187TdrlXIgV6Pvclr5JAQ22EKkKVyF2AtNPi8jmM5YQ8f9q6x0EZWyLqfOiAHkAKjQS X-Received: by 10.66.162.165 with SMTP id yb5mr3381505pab.2.1401379966892; Thu, 29 May 2014 09:12:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.27.138 with SMTP id 10ls658732qgx.9.gmail; Thu, 29 May 2014 09:12:46 -0700 (PDT) X-Received: by 10.140.36.6 with SMTP id o6mr31203qgo.26.1401379965905; Thu, 29 May 2014 09:12:45 -0700 (PDT) In-Reply-To: X-Original-Sender: diggsey@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:10960 Archived-At: ------=_Part_3089_30387345.1401379965128 Content-Type: text/plain; charset=UTF-8 It's not hugely different from any other class whose implementation details are not specified. One possibility is to allow reflection of the generated struct directly, but also consider it a special case. Relying on a particular implementation specific layout for the struct would not be portable, but the implementation could provide methods implemented using the lower-level reflection functionality to access the struct in a portable way. This higher level interface would expose the bound variables exactly as they are seen in the capture list, regardless of how the compiler chose to actually implement them. On Thursday, 29 May 2014 14:05:03 UTC+1, Thibaut Lutz wrote: > > To re-center the debate around my original post, I think lambda-generated > classes have to be treated differently compared to user-defined classes. > > While I don't follow SG7 closely, allowing reflection to access private > members seems logical, as long as it doesn't provide an obvious way to > completely disregard visibility qualifiers in basic design. However this > debate is different from the case exposed here originally, and has probably > been discussed extensively in the SG7. > > If possible I would like to come back to lambda functions. The class they > generate is intentionally not well defined in the standard (by-ref entities > could be members or not), and the entire design is really focused around > making the generated class opaque (by obfuscation, which is enough without > reflection), probably to express the local reasoning I talked about in my > original post. > > I realized shortly after posting the first message, and I think this is > what Ville pointed out as well, that adding a visibility keyword is > probably not going to be enough, I think reflection all together should not > be applied to generated Closure types, or should at least be treated as a > very special case of reflection. > > Do you think reflection should be allowed on closure types? Is there any > use-case for it? Serialization comes to mind, but I think it could only > apply to by-copy entities, and it would require adding clauses to the > standard to order by-copy members before by-ref, and reflection should only > be able to access those. As I said earlier, the by-copy entities should > have a restrained visibility, and that should be taken into account by the > reflection mechanism to prevent users to modify by-copy entities unless > they jump through a few hoops to clearly state their intent. > -- --- 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_3089_30387345.1401379965128 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's not hugely different from any other class whose imple= mentation details are not specified. One possibility is to allow reflection= of the generated struct directly, but also consider it a special case. Rel= ying on a particular implementation specific layout for the struct would no= t be portable, but the implementation could provide methods implemented usi= ng the lower-level reflection functionality to access the struct in a porta= ble way. This higher level interface would expose the bound variables exact= ly as they are seen in the capture list, regardless of how the compiler cho= se to actually implement them.

On Thursday, 29 May 2014 14:05:03 UTC= +1, Thibaut Lutz wrote:
To re-center the debate around my original post, I think lambda-= generated classes have to be treated differently compared to user-defined c= lasses.

While I don't follow SG7 closely, allowing refle= ction to access private members seems logical, as long as it doesn't provid= e an obvious way to completely disregard visibility qualifiers in basic des= ign. However this debate is different from the case exposed here originally= , and has probably been discussed extensively in the SG7.

If possible I would like to come back to lambda functions. The clas= s they generate is intentionally not well defined in the standard (by-ref e= ntities could be members or not), and the entire design is really focused a= round making the generated class opaque (by obfuscation, which is enough wi= thout reflection), probably to express the local reasoning I talked about i= n my original post.

I realized shortly after posti= ng the first message, and I think this is what Ville pointed out as well, t= hat adding a visibility keyword is probably not going to be enough, I think= reflection all together should not be applied to generated Closure types, = or should at least be treated as a very special case of reflection.

Do you think reflection should be allowed on closure type= s? Is there any use-case for it? Serialization comes to mind, but I think i= t could only apply to by-copy entities, and it would require adding clauses= to the standard to order by-copy members before by-ref, and reflection sho= uld only be able to access those. As I said earlier, the by-copy entities s= hould have a restrained visibility, and that should be taken into account b= y the reflection mechanism to prevent users to modify by-copy entities unle= ss they jump through a few hoops to clearly state their intent.
=

--

---
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_3089_30387345.1401379965128-- .