I thought that we made it so that enums failed isSomeString

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Sun Oct 2 08:19:22 PDT 2016


On Sunday, October 02, 2016 08:04:58 Jonathan M Davis via Digitalmars-d wrote:
> but I had been quite
> sure that we'd made it so that enums didn't pass isSomeString, so I'm rather
> confused. The documentation for isSomeString doesn't say anything about
> enums one way or the other though.
>
> So, I don't know if we can fix isSomeString, but leaving it as-is puts us at
> serious risk of breaking code any time we templatize code that wasn't
> templatized before or rangify code that only worked on strings before.

Ah, drat. It looks like the problem is partially my fault.

https://github.com/dlang/phobos/pull/739
https://issues.dlang.org/show_bug.cgi?id=8508

I don't know what other discussions there were on that at the time, though
I'm pretty sure that there were discussions on it in the newsgroup.

*sigh* I hate implicit conversions. They wreak havoc with generic code.

So, I don't know what the right decision is here. It seems like a mistake to
me to let enums be treating as their base type by std.traits precisely for
the same reasons that it's a mistake to let std.traits treat structs that
convert to built-in types as if they were those types. But there is code
that will work with enums of a base type just as well as the base type, and
isSomeString and friends have been like this for a while now. It all makes
writing generic code that plays nicely with conversions rather difficult
though.

Generic code really needs to know when it's dealing with implicit
conversions and force the conversions; otherwise, you get all kinds of
subtle bugs - some of which result in compilation errors and some which just
behave badly.

- Jonathan M Davis



More information about the Digitalmars-d mailing list