220 11024 <78d46ec5-f7d2-4f84-95ae-cde51869bab9@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: Mon, 2 Jun 2014 09:10:49 -0700 (PDT) Lines: 118 Approved: news@gmane.org Message-ID: <78d46ec5-f7d2-4f84-95ae-cde51869bab9@isocpp.org> 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> <302fe182-6356-49e2-a615-a76c34caf79f@isocpp.org> <05a2f197-c3cf-418b-be18-75970eca5d61@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_136_16210407.1401725449746" X-Trace: ger.gmane.org 1401725460 19819 80.91.229.3 (2 Jun 2014 16:11:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Jun 2014 16:11:00 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC2MLAWQ6ANBBC6EWKOAKGQEY2RJXQQ@isocpp.org Mon Jun 02 18:10:54 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f198.google.com ([209.85.220.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WrUp2-0003hA-EN for gclcip-std-proposals@m.gmane.org; Mon, 02 Jun 2014 18:10:52 +0200 Original-Received: by mail-vc0-f198.google.com with SMTP id ik5sf6868473vcb.1 for ; Mon, 02 Jun 2014 09:10:51 -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=xra0SfopekJdR8dose8zSBOydoHuacBTWfZ+17W/yZ4=; b=k5szEeA1gGuWtRnlS4+zOFXcskl/8f2fj2WQz+rCGYk5KC+Z6k7LeXfyNeY4NnS9LL 9Km6jEcu/2XDPHC4pk7l6Vkk4K6CHZu7JHsk2H535EC0m/zB2SgbzDOz9/pzR0YQTT/X wBS8QfLvxJMqkbtutMLMriZmIooNs5Mky4wBMFLmXeACHAdpr5zitu99Teg1uPK+P6Qa SlI04EsyzFoscpXuK0nqCwdkJChBo/3qdM9DO5w84U83Z6aGs16xobQOcuwKTr/2RAD0 aXgKUrWZqtuL0OGSIN1e0FK6nEEMD6NHZ1XzS9wkdjWyAYbBKEGaeZ8Y2T2K8LkXknW9 oWnA== 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=xra0SfopekJdR8dose8zSBOydoHuacBTWfZ+17W/yZ4=; b=EsStyTaFJVGsjED1h5Il6nktkL12+0ruB0SVexvmmUe9KkMn12DrA66bZMOpQ8PsoT 08DVsokaN5HURyckw5gMTPCr7/vzsYvWdgchcdUwwqSDdqWi8vKs4fk5/Kqau9+r5oZ5 IYkDdBSUD5XYBZJAgJA1Q2jy2LPTLEdk3SmTr9gfrzgfrsllHP2Hf4XzooJwfUzF31cv g8S5ArXcYw3h8ovWoF7FZGqjGKP1UXzv4g0MpIrsIM1OpEF+Hp8+Wa5FT3B72X1HlR+f oTjKlkuJbs5nSMe0b1deySoETqU2RgHld+3kSWliN/+VraRH8RDGH7PmnMfImg4WnIEB 47ew== X-Gm-Message-State: ALoCoQnZ8rCfYJ6yorcFQjtahKYlNYIT0Yaoavei9WlZlKCi7/w5G6zvpdIV3V3CA7vWoj6IxUy4 X-Received: by 10.58.238.7 with SMTP id vg7mr14658617vec.22.1401725451653; Mon, 02 Jun 2014 09:10:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.50.143 with SMTP id s15ls2042825qga.33.gmail; Mon, 02 Jun 2014 09:10:50 -0700 (PDT) X-Received: by 10.140.27.40 with SMTP id 37mr26784qgw.24.1401725450956; Mon, 02 Jun 2014 09:10:50 -0700 (PDT) In-Reply-To: <05a2f197-c3cf-418b-be18-75970eca5d61@isocpp.org> 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:11024 Archived-At: ------=_Part_136_16210407.1401725449746 Content-Type: text/plain; charset=UTF-8 On Monday, 2 June 2014 16:15:14 UTC+1, Thibaut Lutz wrote: > > That's only the case for lambdas with no captures, for lambdas with >> captures the constructor effectively has one argument of some internal type >> (essentially a reference to a stack frame). This internal type need not >> have any constructors or could even be a type without a definition, but >> certainly reflection need not be supported on it, so that would make it >> impossible to call the constructor in a valid way. >> > > This is implementation specific, isn't it? The following could be a valid > compiler transformation too, and exposes a valid constructor: > > Sure, but your original comment about lambdas having constructors is implementation specific - the compiler could just materialise an instance of the lambda from nothing without it even having a constructor, but we're talking about the abstraction that the user can see. Logically, a lambda is constructed from a stack frame, regardless of how it's actually implemented in the compiler, so if the user can see that there's a constructor, that's what it should look like. > I didn't mean based off an existing lambda, I meant creating a completely >> new one: if reflection is going to include ways to create a new class, then >> it could also create a new lambda type. >> > > Right, this is a different use case then. > > >> So that the compiler can just store a single stack pointer in the closure >> for however many by-ref captures there are? >> > > I was thinking more about the by-copy entities. I think the consensus is > that once initialized they are semantically immutable outside the lambda. > In that case, the only case I can think of is so that the compiler can re-order members to reduce space requirements if members have different alignments, but most likely it's left unspecified because there's no need for it to be so. -- --- 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_136_16210407.1401725449746 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, 2 June 2014 16:15:14 UTC+1, Thibaut Lut= z wrote:
That's only the c= ase for lambdas with no captures, for lambdas with captures the constructor= effectively has one argument of some internal type (essentially a referenc= e to a stack frame). This internal type need not have any constructors or c= ould even be a type without a definition, but certainly reflection need not= be supported on it, so that would make it impossible to call the construct= or in a valid way.

This is = implementation specific, isn't it? The following could be a valid compiler = transformation too, and exposes a valid constructor:

 
Sure, but your original comment about lambdas h= aving constructors is implementation specific - the compiler could just mat= erialise an instance of the lambda from nothing without it even having a co= nstructor, but we're talking about the abstraction that the user can see. L= ogically, a lambda is constructed from a stack frame, regardless of how it'= s actually implemented in the compiler, so if the user can see that there's= a constructor, that's what it should look like.
 
I didn't mean based off an existing l= ambda, I meant creating a completely new one: if reflection is going to inc= lude ways to create a new class, then it could also create a new lambda typ= e.

Right, this is a differe= nt use case then.
 
So that the compiler can just store a single sta= ck pointer in the closure for however many by-ref captures there are?

I was thinking more about the by= -copy entities. I think the consensus is that once initialized they are sem= antically immutable outside the lambda. 
=
In that case, the only case I can think of is so that the compiler can = re-order members to reduce space requirements if members have different ali= gnments, but most likely it's left unspecified because there's no need for = it to be so.

--

---
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_136_16210407.1401725449746-- .