enums and std.traits

Jonathan M Davis jmdavisProg at gmx.com
Sat Aug 4 14:09:29 PDT 2012


At present (though it didn't used to work this way until about 4 months ago - 
the change is in 2.060), a number of std.traits templates - including 
isSomeString - evaluate to false for enums. So,

enum E : string { a = "hello" }
static assert(isSomeString!(E.a));

will fail. This is in spite of the fact that

auto func(string a) {...}

will accept E.a without complaint. So, if you change

auto func(string a) {...}

to

auto func(T)(T a) if(isSomeString!T) {...}

any code passing E.a to func would be broken. Personally, I don't see why 
isSomeString shouldn't consider enums which are strings to be strings (the 
same goes for isUnsigned, isIntegral, etc.), especially when the language 
itself does.

Kenji is argues that they shouldn't because they should treat enums as 
strongly typed:

https://github.com/D-Programming-
Language/phobos/commit/52462bec6ea846f30e8dac309d63ccb4101e8f0c#commitcomment-1671599

But the language itself doesn't and I think that this a real problem given 
that it's very common to use stuff like isSomeString in template constraints, 
and I don't think that much of anyone is considering how that effects enums.

I agree that an enum's base type should not implicitly convert to the enum 
type, since that would mean that you could have an invalid enum value, but I 
see no problem with enums implicitly converted to their base type.

I think that the change to std.traits was a big mistake and will probably file 
it as a regression, but I thought that I should get other people's thoughts on 
this.

- Jonathan M Davis


More information about the Digitalmars-d mailing list