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
