From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15291 invoked by alias); 26 May 2005 15:57:39 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 15280 invoked by uid 48); 26 May 2005 15:57:35 -0000 Date: Thu, 26 May 2005 16:04:00 -0000 Message-ID: <20050526155735.15279.qmail@sourceware.org> From: "bkoz at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050526065837.21764.bkoz@gcc.gnu.org> References: <20050526065837.21764.bkoz@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/21764] visibility attributes on namespace scope X-Bugzilla-Reason: CC X-SW-Source: 2005-05/txt/msg03478.txt.bz2 List-Id: ------- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-26 15:57 ------- nested namespaces should work the same as nested classes. :) Since that that doesn't seem to be defined anywhere (am I wrong, or should I open a tracker for that in bugzilla), I'd say: case 1: namespace outer __attribute__ ((visibility ("default") )) { namespace inner __attribute__ ((visibility ("hidden") )) { struct A { int i; }; } } case 2: namespace outer __attribute__ ((visibility ("hidden") )) { namespace inner __attribute__ ((visibility ("default") )) { struct B { int i; }; } } Would have the following, easy (?) semantics: hidden makes all enclosed namespaces hidden. Thus, it really doesn't make sense to nest hidden namespaces. I think the only other reasonable alternative is to say that the nearest scope's visibility attribute is the one in effect. However, I've not really looked at the way nested classes are handled. Any insights there? What ever is done, these two things should be treated consistently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764