Using std.conv.to with enum that is based on string type

[Uranuz via Digitalmars-d]

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))