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
