No we should not support enum types derived from strings

Steven Schveighoffer schveiguy at gmail.com
Fri May 7 15:20:21 UTC 2021


On 5/6/21 11:48 PM, Andrei Alexandrescu wrote:
> We should remove all that rot from phobos pronto.
> 
> https://github.com/dlang/phobos/pull/8029

What do you mean "not support"? The language has enums derived from 
strings. Did you mean remove it from the language? That would be a 
severe penalty.

Did you mean that Phobos routines just should error whenever you use 
enum types derived from strings? That's also a severe penalty.

If you mean we shouldn't support it (as an ambiguous case) in 
*conversion* utilities (i.e. to/from string), then this makes some 
sense. But it's also not straightforward. Sometimes you WANT to convert 
from the enum to the base type. Sometimes you want to convert to the 
enum name. Going backwards (string to enum), which one makes more sense? 
It depends on context. It also doesn't help that a string enum 
implicitly converts to a string. The language is going to circumvent any 
policies Phobos has on that front.

For an example, in the serializers I have written, I usually have a 
"treat this enum type as it's base type" UDA, because the data inside 
the serialized format is the base type, but I want it as an enum in 
d-land. But it depends on the situation.

I think it makes possible sense to require either wrappers that clarify 
intent, or always treat enums the same way (as an enum). I think Phobos 
*mostly* does the latter. Erroring for ambiguity might be more 
disruptive than it's worth.

-Steve


More information about the Digitalmars-d mailing list