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