Phobos' from enum to string doesn't scale beyond hundreds of enumerators

Steven Schveighoffer schveiguy at
Sun Jun 24 17:23:54 UTC 2018

On 6/24/18 11:46 AM, Per Nordlöw wrote:
> On Friday, 22 June 2018 at 00:50:05 UTC, Steven Schveighoffer wrote:
>> The sucky thing is, the compiler is *already* doing a sort on the 
>> items in the switch, and *already* doing the duplicate check. It would 
>> be cool to be able to leverage this mechanism to avoid the library 
>> solution, but I don't know how we can do that, as the semantics for 
>> switch are well defined, and there's no other way to hook this builtin 
>> functionality.
> I would like to see a new trait named, say, `primaryMembers` or 
> `nonAliasMembers` that returns exactly what the switch needs. I believe 
> this is motivated by the fact that this is a serious issue; Without the 
> user notices, the use of enums combined with!string or io sucks up 
> more and more RAM in the compiler as new members are added.
> If enough (hundreds) of members are added you can get out of RAM, which 
> is what happened to me. What do you think about that idea?
> We should plot compilation time and memory usage with enumerator count 
> so we can reason about the severity of this issue.

Hm... just had another thought.

Many times, the enum has no repeating members, so your mechanism just 
works. So just use that if it works!

static if(__traits(compiles, fastEnumToString(val)))
   return fastEnumToString(val);
   return slowEnumToString(val); // checks for duplicates

Should eliminate the issues, because it's not going to compile the slow 
version if the fast version can work.


More information about the Digitalmars-d mailing list