No we should not support enum types derived from strings

[Andrei Alexandrescu]

On 5/11/21 7:00 PM, Andrei Alexandrescu wrote:
> On 5/11/21 3:43 PM, Jon Degenhardt wrote:
>>
>>      enum { f4 = "%d" }
>>      writefln!f4(4);
>>
>>      enum : string { f5 = "%d" }
>>      writefln!f5(5);
>>
>>      enum X { f6 = "%d" }
>>      writefln!(X.f6)(6);   // Compilation error
>>
>>      enum Y : string { f7 = "%d" }
>>      writefln!(Y.f7)(7);   // Compilation error
> 
> Thanks. I agree it's confusing. The mystery gets elucidated with some 
> ease if we write the types involved: f4 and f5 have type string, f6 has 
> type X, and f7 have type Y.
> 
> It's unpleasant that `enum : string { f5 = "%d" }` is really the same as 
> `enum f5 = "%d"`. I expected that some anonymous enum type would be 
> generated.

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.