www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Char enum conversion

reply Rekel <paultjeadriaanse gmail.com> writes:
I'm surprised char to enum conversion is currently not possible.
This, as char[] & string conversion to enum is supported.

 enum E{A, B}
 void main()
 char[] a = ['A'];
 a.to!E.writeln;
 "A".to!E.writeln;
 'A'.to!E.writeln; // Crash
 }
The last line crashes with:
 std.conv.ConvException C:\D\dmd2\windows\bin\..\..\src\phob
s\std\conv.d(2058): Value (A) does not match any member value of enum 'Enum'
Jan 01
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/1/21 12:17 PM, Rekel wrote:
 I'm surprised char to enum conversion is currently not possible.
 This, as char[] & string conversion to enum is supported.
 
 enum E{A, B}
 void main()
 char[] a = ['A'];
 a.to!E.writeln;
 "A".to!E.writeln;
 'A'.to!E.writeln; // Crash
 }
The last line crashes with:
 std.conv.ConvException C:\D\dmd2\windows\bin\..\..\src\phob
s\std\conv.d(2058): 
 Value (A) does not match any member value of enum 'Enum'
So what's happening here is that std.conv.to is treating your 'A' as an integer. What you are doing is really: 65.to!E.writeln; // 'A' is really a octet of 65 That char/wchar/dchar are treated as a standard implicit-convertible integer type is one of the failings of D I think. Another gotcha to watch out for, if your enum is string-based, there is NO WAY to use std.conv to convert from the base string to the enum type, it only goes by enum names. -Steve
Jan 01
parent reply Rekel <paultjeadriaanse gmail.com> writes:
On Friday, 1 January 2021 at 17:59:30 UTC, Steven Schveighoffer 
wrote:
 So what's happening here is that std.conv.to is treating your 
 'A' as an integer. What you are doing is really:

 65.to!E.writeln; // 'A' is really a octet of 65

 That char/wchar/dchar are treated as a standard 
 implicit-convertible integer type is one of the failings of D I 
 think.
I see why that makes sense ascii wise, however, does that ruin templating for chars? That would seem very problematic.
 Another gotcha to watch out for, if your enum is string-based, 
 there is NO WAY to use std.conv to convert from the base string 
 to the enum type, it only goes by enum names.
Im unsure about what you mean here. Do you mean that an enum with strings as assigned values cannot be converted to using any of the assigned strings? If so, how come it does work using integers?
Jan 01
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/1/21 1:11 PM, Rekel wrote:
 On Friday, 1 January 2021 at 17:59:30 UTC, Steven Schveighoffer wrote:
 So what's happening here is that std.conv.to is treating your 'A' as 
 an integer. What you are doing is really:

 65.to!E.writeln; // 'A' is really a octet of 65

 That char/wchar/dchar are treated as a standard implicit-convertible 
 integer type is one of the failings of D I think.
I see why that makes sense ascii wise, however, does that ruin templating for chars?
It's not. It's templating based on the base type. when passed a variable that's an enum, `to` looks at 2 possibilities: 1. The type is a string -- match against the names of the enum values 2. The type is implicitly convertible to the enum base type, look up based on the base type. Since char is not a string, but it's implicitly convertible to int (which is the default base type for enums), it uses the second overload.
 That would seem very problematic.
I'd have to see a more compelling example in order to agree. Using 'A' instead of "A" isn't that convincing. Note, that if 'A' is in a variable, you can generate a "string" based on it: auto nameToLookup = (&var)[0 .. 1]; nameToLookup.to!E.writeln;
 
 Another gotcha to watch out for, if your enum is string-based, there 
 is NO WAY to use std.conv to convert from the base string to the enum 
 type, it only goes by enum names.
Im unsure about what you mean here. Do you mean that an enum with strings as assigned values cannot be converted to using any of the assigned strings? If so, how come it does work using integers?
So for example: enum X : string { Foo = "FOO", Bar = "BAR" } // std.conv.ConvException /dlang/dmd/linux/bin64/../../src/phob s/std/conv.d(2819): X does not have a member named 'FOO' auto val = "FOO".to!X; // ok auto val2 = "Foo".to!X; How come it works for integers? Because integers are not strings, so it can distinguish what you want. When both case 1 and case 2 above are the same type, it has to pick one. -Steve
Jan 01
parent reply Rekel <paultjeadriaanse gmail.com> writes:
On Friday, 1 January 2021 at 18:27:05 UTC, Steven Schveighoffer 
wrote:
 That would seem very problematic.
I'd have to see a more compelling example in order to agree. Using 'A' instead of "A" isn't that convincing.
I meant that in case this was an issue with char when templating in general, as I'm quite new to it I wasnt sure if that was what you meant. I guess making your char into a 1 long string is an ok workaround, and the scenario's in which you have a char with names 1 character long are, I guess, limited. Ended up using [0..1]. Thanks for the explanation.
Jan 01
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/1/21 3:27 PM, Rekel wrote:
 On Friday, 1 January 2021 at 18:27:05 UTC, Steven Schveighoffer wrote:
 That would seem very problematic.
I'd have to see a more compelling example in order to agree. Using 'A' instead of "A" isn't that convincing.
I meant that in case this was an issue with char when templating in general, as I'm quite new to it I wasnt sure if that was what you meant.
There may be some misunderstanding here. A string is an *array* and is not implicitly convertible from values like char. However, an int is implicitly convertible from char. If you have an overload set like: void foo(string s) { writeln("string: ", s); } void foo(int i) { writeln("int: ", i); } foo("A"); // prints string: A foo('A'); // prints int: 65 This is all that is happening, the overload set for `to` is either string or the base type of the enum (in this case int). So 'A' matches the int, not the string. It's not an issue with templating at all, you can template on a char no problem. It's just the way `to` is implemented. My comment about not being convincing was basically a solicitation to see if you have a compelling case of why you would want to use a char to represent an enum name instead of a string. The small example you give is not that. -Steve
Jan 01