From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28744 invoked by alias); 15 Oct 2002 20:27:09 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 28737 invoked from network); 15 Oct 2002 20:27:08 -0000 Received: from unknown (HELO Cantor.suse.de) (213.95.15.193) by sources.redhat.com with SMTP; 15 Oct 2002 20:27:08 -0000 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id C48531527E; Tue, 15 Oct 2002 22:27:07 +0200 (MEST) Date: Tue, 15 Oct 2002 14:28:00 -0000 From: Michael Matz To: Jamie Lokier Cc: Kevin Lawton , Subject: Re: Request of new __attribute__ for switch statements (elimination of the bounds check) In-Reply-To: <20021015200247.GA31811@bjl1.asuk.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-10/txt/msg00866.txt.bz2 Hi, On Tue, 15 Oct 2002, Jamie Lokier wrote: > > > (It would be appropriate to add a warning when an enum with this > > > attribute is converted to an integer). > > > > That's not the problematic direction. I can't see why converting such an > > enum to an integer would be dangerous. But converting _to_ such an enum > > should get a warning. > > Good point. (I was thinking of enum arithmetic like `CAT | DOG' being > disallowed for strict enums -- I believe that is defined for standard enums). For the type system I would use the following argumentation (biased to C not C++): First observe that strict enum are not an integer type (in difference to normal ISO C enums), but can be implicitely converted to one. Additionally strict enum shall not be arithmetic types (makes sense, because we want to disallow arithmetics on this thing). Per 6.5.x (the definitions of the different operators) all interesting operators operate on arithmetic types. Ergo the only way to interpret 'BLA | BLUBB' is, that both strict enums are (implicitely) converted to an integer type, which makes the whole expression have integer type. That is you could write: "unsigned int x = BLA | BLUBB;" without a warning, and I think that's Ok. What you _can't_ do then is "enum E_strict e = BLA | BLUBB;" because the RHS arithmetic expression can't be implicitely converted to an E_strict. One would need an explicit cast, and that should get a warning. Does that make sense? Ciao, Michael.