Phobos' std.conv.to-conversion from enum to string doesn't scale beyond hundreds of enumerators

[Steven Schveighoffer]

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 ..to!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);
else
   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.

-Steve