On Saturday, 19 July 2014 at 12:31:05 UTC, bearophile wrote:
1. So I want to know if it is expected behaviour?
Yes, this was the chosen behaviour.
2. What are the reasons for it?
It's one of the two main behaviours you may want, even if your
specific case it is not. It can be used to unserialize enums
from a text file. This is the principle behind the text/to pair
of functions, and this was copied by the repr of Python.
Bye,
bearophile
It's not very clear to me what are 2 main behaviours you are
talking about. And I don't agree with current behaviour and I
have following reasons for it:
1. Because enum is based on some underlying type I expect that I
work and make conversions with that exact value but not enum
*identifier* for this value in the code.
2. Using these *identifiers* is for checking if variable has
value from set that declared inside enum statement and creating
readable name for underlying value in source code. If you want to
create binding between some string identifier and value that will
be exposed out of code you could use associative array instead of
enum.
3. Current implementation makes compiler to save enum identifiers
as strings somewhere in programme code (it's how I think it
should do). It's not exactly what enum is indended for (having
double set of values).
4. This implementation looks like mixing base language
functionality with compile-time reflexion and should be moved to
std.traits (for example) not std.conv. And it's not what expected
by module that should simply provide correct conversion between
base types.
5. D is not a Python at all
All of the above is just my own opinion. So I can solve this with
my own wrapper around std.conv. The question is shall all the
users of language design their own wrappers for basic library
function to just get basic behavior that they expect from
standard function?
P.S. All of these should be criticized))
