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

Uranuz via Digitalmars-d digitalmars-d at puremagic.com
Sat Jul 19 09:29:13 PDT 2014


On Saturday, 19 July 2014 at 15:27:27 UTC, Ali Çehreli wrote:
> On 07/19/2014 04:53 AM, Uranuz wrote:
>
> > When I tried to use std.conv.to to serialize enum values that
> are based
> > on string type I faced with situation that *to* not exactly
> as I
> > expected.
>
> Maybe I misunderstand you but the behavior is consistent for 
> all enum types in both conversion directions. The value 1 does 
> not appear anywhere in the following conversions, so "hello" 
> should not appear either:
>
> import std.conv;
>
> enum I : int    { a = 1 }
> enum S : string { a = "hello" }
>
> void main()
> {
>     assert(I.a.to!string == "a");
>     assert(S.a.to!string == "a");
>
>     assert("a".to!I == I.a);
>     assert("a".to!S == S.a);
> }
>
> Doing anything special for a particular type would be confusing 
> and make at least template programming hard.
>
> Ali

In this case I see than we exactly doing something special when
converting to string type. Using this logic without doing
something special when converting
enum I : int    { a = 1 }

we should try to convert it's *identifier* into int and it should
generate error. But we don't do it, because we convert it's
underlying value into int (not an identifier). But in case with
string we doing specific conversion (that looks unreasonable for
me), because we convert not it's *value* but it's identifier.

I think that we shouldn't touch enum value *identifier* and
ALWAYS convert underlying value. It will be absolutely clear to
explain in documentation.

This is why I disagree with current implementation, because *to*
set of functions is not toString function in objects (that tries
to print pretty string), but it is utilitary function often used
in template code and it should have uniform semantics for all
enum types



More information about the Digitalmars-d mailing list