220 4692 <1432df09-bb46-4552-85fa-68f364ed67fc@isocpp.org> article Path: news.gmane.org!not-for-mail From: potswa@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Changing lambda scope Date: Mon, 27 May 2013 18:46:57 -0700 (PDT) Lines: 345 Approved: news@gmane.org Message-ID: <1432df09-bb46-4552-85fa-68f364ed67fc@isocpp.org> References: <01190eaa-6223-4d3c-a9d3-b0d850aab98e@isocpp.org> <35af8d3d-8ed6-441c-94d0-b898711190b1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3118_21559876.1369705617144" X-Trace: ger.gmane.org 1369784683 7931 80.91.229.3 (28 May 2013 23:44:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 May 2013 23:44:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRB2MCSWGQKGQEOK5M4NI@isocpp.org Wed May 29 01:44:44 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UhTZK-00055Y-KN for gclcip-std-proposals@m.gmane.org; Wed, 29 May 2013 01:44:43 +0200 Original-Received: by mail-ie0-f200.google.com with SMTP id 10sf35600678ied.11 for ; Tue, 28 May 2013 16:44:41 -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=ct9vGuQsRgHozQwybjrm4/9rIYcVd/WubEVQlM7JyXQ=; b=E8by7HIKLVCF/IOyE/Bz8loV/4qqTXIwMMJH+Xm2sIHlNFBdD/s9b8bNGoj7NaJgHH JA8msBi2xNMFYTfGviMdopwYbtKPPjd71HeHAXMP7H0C/Wi/cN8Q6K/gujJOpg8Z1r/z y6RzRg6Xlr4EW+l7FicUQ5p8AuWoCQqyAfN8QOKRLIEAZqhUfbp0EXNPEgjIEOdP7H8E 2fi+CMQ0C8Tm3HE2povhuon0h+xzhTiueJRBUzEvTc8+gwvVQzCWimziNwCsR8wgti40 K9O3UBOSfkvwoJwDhIDrZlFwwd/toGWnQdoY3b2Jk3l58wZVm4cY5AJZI8DFjoMqmZI0 btDA== X-Received: by 10.42.191.145 with SMTP id dm17mr117383icb.11.1369784681719; Tue, 28 May 2013 16:44:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.153.110 with SMTP id vf14ls1594915igb.10.canary; Tue, 28 May 2013 16:44:40 -0700 (PDT) X-Received: by 10.50.56.116 with SMTP id z20mr16864224igp.1.1369784680846; Tue, 28 May 2013 16:44:40 -0700 (PDT) Original-Received: by 10.50.89.196 with SMTP id bq4msigb; Mon, 27 May 2013 18:46:59 -0700 (PDT) X-Received: by 10.50.196.227 with SMTP id ip3mr1101404igc.10.1369705618613; Mon, 27 May 2013 18:46:58 -0700 (PDT) In-Reply-To: X-Original-Sender: potswa@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:4692 Archived-At: ------=_Part_3118_21559876.1369705617144 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > The inner lambda got passed out of the namespace just fine, and that work= s=20 > in C++11. > Oops, good example. Bottom line: the problem is new in C++11, but only with= =20 contrivance, and C++14 gives it the first real exposure. =20 > Interesting. > I think the fundamental approach of the Standard is to define the=20 associated classes (which share their invisible friends) and then define=20 the associated namespaces as a simple function thereof. Despite associating the enclosing namespace through multiple levels of=20 class nesting, both GCC and Clang only expose the invisible friends of the= =20 immediately enclosing class. namespace n { struct s { struct n1 { struct n2 {}; friend int f( s::n1::n2 ) { return 3; } }; friend int g( n1::n2 ) { return 3; } }; friend int h( n1::n2 ) { return 3; } } int i =3D f( n::s::n1::n2() ); // OK: invisible friend of enclosing class.= =20 Implementations agree. int j =3D g( n::s::n1::n2() ); // Error: invisible friend of second enclosi= ng=20 class. Implementations agree. int k =3D h( n::s::n1::n2() ); // Error: member of unassociated namespace.= =20 Implementations disagree with std. On Monday, May 27, 2013 8:34:03 PM UTC+8, DeadMG wrote: > > IYAM, a class should always have as an associated namespace the most=20 > nested namespace which either is, or contains, the scope it is declared i= n. Unfortunately, a function can be declared and defined in different=20 namespaces. namespace a { void x(); } void a::x() { my_template( []{} ); // associated with a or not? } Both Clang and GCC associate a local class according to the namespace=20 enclosing its function, not its declaration. This seems more intuitive to= =20 me and more analogous to the way nested classes already work. My proposed= =20 change would be to adjust 3.4.2/2, =20 -=20 =20 =97 If T is a class type (including unions) *but not a local class type*= ,=20 its associated classes are: the class itself; the class of which it is a= =20 member, if any; and its direct and indirect base classes. Its associated= =20 namespaces are the namespaces of which its associated classes are member= s. - *=97 If T is a local class type, its associated namespaces and classes= =20 determined as if it were a member of the class or namespace of which its= =20 enclosing function is a member.* There are other issues with the paragraph, though: multiple nesting levels= =20 disassociate the namespace, and forward-declared enumerations may be=20 associated improperly. --=20 ---=20 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 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-proposa= ls/?hl=3Den. ------=_Part_3118_21559876.1369705617144 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
The inner lambda = got passed out of the namespace just fine, and that works in C++11.

Oops, good example. Bottom line: the problem is new in C+= +11, but only with contrivance, and C++14 gives it the first real exposure.=
 
Interesting.

I think the fundamental approach of t= he Standard is to define the associated classes (which share their invisibl= e friends) and then define the associated namespaces as a simple function t= hereof.

Despite associating the enclosing namespace through multiple= levels of class nesting, both GCC and Clang only expose the invisible frie= nds of the immediately enclosing class.

namespace n {
struct s {<= span style=3D"color: #000;" class=3D"styled-by-prettify">
    struc= t n1 {
   &n= bsp;    struct n2 {};
        friend int<= /span> f( s::n1::n2 )= {<= span style=3D"color: #000;" class=3D"styled-by-prettify"> return 3; }<= br>    };
    friend<= span style=3D"color: #000;" class=3D"styled-by-prettify"> int g( n1::n2 ) { return 3; }
};
friend int h( n1::n2 )= {<= span style=3D"color: #000;" class=3D"styled-by-prettify"> return 3; }<= br>= }
int i =3D f( n::s:= :n1= ::n2() ); // OK: invisible friend of enclosing class. Implementatio= ns agree.
int j <= /span>=3D<= span style=3D"color: #000;" class=3D"styled-by-prettify"> g( n::s::n1:= :n2= () ); // Error: invisible friend of second encl= osing class. Implementations agree.
int k =3D h= ( n::s::n1::= n2() ); // Error: member of unassociated= namespace. Implementations disagree with std.


On Monday, May 27, 2013 8:34:03 PM UTC+8, DeadMG wrote:IYAM, a class should always have as an associated namespace the most nested=20 namespace which either is, or contains, the scope it is declared in.
Unfortunately, a function can be declared and defined in differen= t namespaces.

namespace a {
&nbs= p;   = void x();
}

void a::x() = {
    m= y_template= ( <= span style=3D"color: #660;" class=3D"styled-by-prettify">[]{} ); // associated with a or not?
}

Both Clang an= d GCC associate a local class according to the namespace enclosing its func= tion, not its declaration. This seems more intuitive to me and more analogo= us to the way nested classes already work. My proposed change would be to a= djust 3.4.2/2,
=09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09

  • = =97 If =97 If T is a loca= l class type, its associated namespaces and classes determined as if it wer= e a member of the class or namespace of which its enclosing function is a m= ember.

There are other issues with the paragraph, th= ough: multiple nesting levels disassociate the namespace, and forward-decla= red enumerations may be associated improperly.

=09 =09

--
 
---
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_3118_21559876.1369705617144-- .