[cfe-commits] [PATCH] C++0x strongly typed enums

Daniel Wallin daniel at boostpro.com
Tue Oct 12 05:45:02 PDT 2010

On Tue, Oct 12, 2010 at 5:56 AM, Sean Hunt <scshunt at csclub.uwaterloo.ca> wrote:
> On 10/11/2010 08:57 AM, Daniel Wallin wrote:
>> On Sat, Oct 9, 2010 at 1:55 AM, Douglas Gregor<dgregor at apple.com>  wrote:
>>> It'd be great if the declaration printer/dumper was updated to print the "class" in "enum class" and the fixed underlying type (when present), so that our -ast-dump and -ast-print output would be helpful.
>>> I've gone ahead and committed a tweaked version of your patch in r116122, with the minor tweaks above. It'd be great if you could address the issues above in a separate patch (disambiguation, diagnostics, declaration printer).
>> Sure! The git mirror I'm using is a bit behind, so I'm not 100% sure
>> these apply cleanly. If not I'll rebase when the mirror catches up.
> I believe that
> enum A { };
> class C {
>   enum A : int();
> };
> is a syntax error for attempting to declare an enumeration with an
> underlying function type, since the default rule in case of ambiguity is
> always to consider it a type-id. I do not believe that the patch
> correctly handles this; I think it should instead attempt to determine
> if it is a type-id before the semicolon/opening brace, and then act
> accordingly.

int() is a integral constant expression and the above code is well
formed in C++98, and I think it's meant to be in C++0x as well. There
isn't really an ambiguity here because base-type must be an integral
type, which of course X() can never satisfy. If we treat everything as
a type-id the case Doug gave above is ill formed.

Daniel Wallin
BoostPro Computing

More information about the cfe-commits mailing list