220 4611 <0df9d0d8-a752-4841-ba02-54780590f722@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Changing lambda scope Date: Sun, 26 May 2013 16:17:24 -0700 (PDT) Lines: 73 Approved: news@gmane.org Message-ID: <0df9d0d8-a752-4841-ba02-54780590f722@isocpp.org> References: <90375ba5-8005-47da-9e84-eee151d0ba0a@isocpp.org> <2e120ca5-740b-4301-8a32-8ac5035fa108@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1350_24268660.1369610244633" X-Trace: ger.gmane.org 1369610249 20671 80.91.229.3 (26 May 2013 23:17:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 May 2013 23:17:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBBVQRKGQKGQEP3OZ6XQ@isocpp.org Mon May 27 01:17:29 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f197.google.com ([209.85.214.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UgkBt-0001cl-3z for gclcip-std-proposals@m.gmane.org; Mon, 27 May 2013 01:17:29 +0200 Original-Received: by mail-ob0-f197.google.com with SMTP id dn14sf28060250obc.0 for ; Sun, 26 May 2013 16:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=+c+mjWguCgS5M9mIpqOmMtpeFW8Gux8E0MIhbg9bSUQ=; b=HkQBtqSy/feIWDZtqPcmKrVhoLqXHMc8jhYs1s0Uf0eypx0BWHB3RxLBaOy+31+Eg7 FxhSbNSGOrxtjRhnBz4iQkLTMpK4eXHtUigazFv7gvyBcPLQb7KdbtArUJSlIfe/oqWo BoPjWuDnNiQrCtpAbf/wV/rHLvxmZJORNUufQi36DcIhnPO01JzTp2oF9WyoSosX4piH 0on/0wres5qGH6qea8VH5wkW7ew1Yc4teKjIxjJeSnV6J0M+xUNmmWUzpw+73QpxGDrr mGFrJCmUBvhojv/8XicgtQCufOBRAeklbrNZwgMInRz6ln39Fhez6xJ+xDUFl83+FiKV xdfA== X-Received: by 10.43.135.134 with SMTP id ig6mr9974712icc.5.1369610248100; Sun, 26 May 2013 16:17:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.115.102 with SMTP id jn6ls1654472igb.26.gmail; Sun, 26 May 2013 16:17:26 -0700 (PDT) X-Received: by 10.50.73.196 with SMTP id n4mr732517igv.3.1369610246054; Sun, 26 May 2013 16:17:26 -0700 (PDT) In-Reply-To: <2e120ca5-740b-4301-8a32-8ac5035fa108@isocpp.org> X-Original-Sender: jmckesson@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:4611 Archived-At: ------=_Part_1350_24268660.1369610244633 Content-Type: text/plain; charset=ISO-8859-1 On Sunday, May 26, 2013 3:35:28 PM UTC-7, DeadMG wrote: > > Is a question that I just found myself asking. Logically, their utility in > this respect is impaired just like lambdas, although there is much less > push to return a local type vs a non-local one when the local type is not a > lambda type. A lambda is nothing special; it's just shorthand notation for a type declared at that scope. We shouldn't have special-case language in the standard that says "if the local type is a lambda type, blah blah". After all, lambda types declared at namespace scope will have the usual features of classes declared at namespace scope. So there's no reason to restrict any expansion of local type association to just lambdas. If we're going to do this, let's do it right. Also, this should include associated *classes* as well. So if you declare a local class within a member function of a class, it should be associated with that class and any classes that this class is associated with. -- --- 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/?hl=en. ------=_Part_1350_24268660.1369610244633 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sunday, May 26, 2013 3:35:28 PM UTC-7, DeadMG wrote:
Is a question that I just found myself asking. Log= ically, their utility in this respect is impaired just like lambdas, althou= gh there is much less push to return a local type vs a non-local one when t= he local type is not a lambda type.

A lambda is nothin= g special; it's just shorthand notation for a type declared at that scope. = We shouldn't have special-case language in the standard that says "if the l= ocal type is a lambda type, blah blah".

After all, lambda types decl= ared at namespace scope will have the usual features of classes declared at= namespace scope. So there's no reason to restrict any expansion of local t= ype association to just lambdas. If we're going to do this, let's do it rig= ht.

Also, this should include associated classes as well. So = if you declare a local class within a member function of a class, it should= be associated with that class and any classes that this class is associate= d with.

--
 
---
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-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-pro= posals/?hl=3Den.
 
 
------=_Part_1350_24268660.1369610244633-- .