Phobos' std.conv.to-conversion from enum to string doesn't scale beyond hundreds of enumerators
schveiguy at yahoo.com
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
> 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 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