220 10894 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Protect Lambda functions against reflection Date: Tue, 27 May 2014 21:04:50 +0300 Lines: 51 Approved: news@gmane.org Message-ID: References: <108c47a2-d952-4f84-a347-923b2ab742ad@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1401213899 24689 80.91.229.3 (27 May 2014 18:04:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 May 2014 18:04:59 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBQVHSOOAKGQEBLNUGMQ@isocpp.org Tue May 27 20:04:52 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f198.google.com ([209.85.160.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WpLk3-0001FN-Vm for gclcip-std-proposals@m.gmane.org; Tue, 27 May 2014 20:04:52 +0200 Original-Received: by mail-yk0-f198.google.com with SMTP id 9sf23482282ykp.1 for ; Tue, 27 May 2014 11:04:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=ZYDLt9+hR85Ny2u6T0zTBUQEfRCDsGzhfjqGEchRqMk=; b=cGoJnVjgiFlmn/ILmdtIDgouQ03mfGZyvUdixVugJMHPeMv0AQOTrKRPA5tWXb9/j/ /B2Zucb/NVd1us+HucBxpr4AAVqltgKDsmBg9UyBygTiSehTHzSXL4aYqs9k7BkcPL4y SJ8a6hZc7MMBH56r9tCSqvvEhU3h2Sl0g2NT6648hDh3XEfY2nSZXkoN+LLtpvXR8HMd KSmIT1ySeRJFd/5e0/pa8Q9ncUmM6WOacJfJJB6c7W9Qyr2MQe3Mz+aqhTFpKYvp5AYw eJVZ5dykMEtTbmU+sMNYRwdf3OJxblQl4LqIyiDx6oU56iFsSNQXH1R429knTvCDeTjz wnTA== X-Gm-Message-State: ALoCoQm6OaVDf/ki3bYM0Yp7wbgH6HQoJWchUyRzY5pP1xCMM+hzCKAAUA31ev/tlLYse10xAMjB X-Received: by 10.58.236.5 with SMTP id uq5mr13564294vec.35.1401213891169; Tue, 27 May 2014 11:04:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.106.98 with SMTP id d89ls3227922qgf.57.gmail; Tue, 27 May 2014 11:04:50 -0700 (PDT) X-Received: by 10.221.58.144 with SMTP id wk16mr29107162vcb.23.1401213890493; Tue, 27 May 2014 11:04:50 -0700 (PDT) Original-Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [2607:f8b0:400d:c04::22c]) by mx.google.com with ESMTPS id l9si17928053qcn.10.2014.05.27.11.04.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 11:04:50 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c04::22c as permitted sender) client-ip=2607:f8b0:400d:c04::22c; Original-Received: by mail-qg0-f44.google.com with SMTP id i50so14509363qgf.3 for ; Tue, 27 May 2014 11:04:50 -0700 (PDT) X-Received: by 10.140.97.197 with SMTP id m63mr44076301qge.15.1401213890343; Tue, 27 May 2014 11:04:50 -0700 (PDT) Original-Received: by 10.224.181.5 with HTTP; Tue, 27 May 2014 11:04:50 -0700 (PDT) In-Reply-To: X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c04::22c as permitted sender) smtp.mail=ville.voutilainen@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:10894 Archived-At: On 27 May 2014 18:51, Andrew Tomazos wrote: > On Tue, May 27, 2014 at 3:46 PM, Ville Voutilainen > wrote: >> I certainly think we need to carefully consider what sort of things we >> allow reflection >> facilities to be able to see and modify. Reflection shouldn't be a >> means of bypassing >> access control, for instance, and we should also be careful about >> reflection being >> able to treat lambdas as regular classes, since we don't really mean >> that by design. >> However, we don't need such wording changes yet. > So you're saying that you think reflection should only be able to see public > members? If so, the memberwise use cases go out the window for classes with > private data members. I don't think I said that reflection should only be able to see public members. But I do maintain that reflection shouldn't by-magic allow bypassing access control in contexts that normally can't access private members. > In N4027 we propose that you can reflect all members of any access control, > but the access level (public, protected, private) of each member is exposed > too - so if the client library wants to filter public-only, it can - or - if > you want to write a generic memberwise operation (like equality or > comparison for example) that uses private members as well, you can do that > too. This seems like the better of the two alternatives to me. > > When you think about it, the copy constructor and assignment operator > implicitly generated by the compiler bypasses access control as they reads > and writes private members. I would argue that the reflection facility > should have the same privileges. Ultimately, reflection competes with > compiler extensions that have full access to the AST. It shouldn't be > viewed as breaking encapsulation - but in any case - it is certainly > something that would never happen accidentally. If you want to allow a reflection mechanism to access any member regardless of whether it's used in a context that has proper access, I predict you're inviting people to propose a facility that allows defining which members do not participate in reflection. Then again, I expect such a facility to surface regardless of access. :) -- --- 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/. .