No we should not support enum types derived from strings

[Andrei Alexandrescu]

On 5/11/21 10:04 PM, deadalnix wrote:
> On Wednesday, 12 May 2021 at 01:06:29 UTC, Walter Bright wrote:
>> On 5/11/2021 5:04 PM, Andrei Alexandrescu wrote:
>>> Another unpleasant issue:
>>>
>>>      enum Y : string { f7 = "%d" }
>>>      writeln(typeof(Y.f7.representation).stringof);
>>>
>>> prints immutable(ubyte)[], not immutable(char)[]. So not even 
>>> Y.f7.representation is usable. Sigh.
>>
>> The representation of a named enum is its base type.
>>
>> The representation of a string type is immutable(ubyte)[].
>>
>> It's consistent.
> 
> Y.f7 is of type Y. It's representation is string, not immutable(ubyte)[]
> 
> typeof(Y.f7.representation) ought to be string.
> typeof(Y.f7.representation.representation) ought to be immutable(ubyte)[]
> 
> Unless I'm missing something, that wold b the consistent behavior. 
> Unless representation is supposed to recurse up to the bottom turtle?

`representation` is a library function, so in a way we get to have a say 
in what it does. I would have expected it doesn't go all the way to 
primitive types, but if it does, that's not necessarily incorrect.