I prefer pure enums as well. Prefixes are not as descriptive as types, and collisions are much less likely with types than they are with prefixes. This will only become apparent in a sufficiently large code bases, but then it is suddenly a huge pain in the neck. Also, the code generated by the backend should be considered irrelevant as far as Nim's preferred syntax/naming is concerned.
I have no preference whether pure should be default or not, because it is easy to turn it on. Just wanted to add my two cents :)
Also, the code generated by the backend should be considered irrelevant as far as Nim's preferred syntax/naming is concerned.
That was not at all what I was after when I said "you never really looked at the resulting code". I meant the resulting Nim code full of superfluous type prefixes only to prevent rare name conflicts (which can be dealt with the module.foo access already anyway).
Java handles enums specially in switch statements, removing the need for a prefix.
public enum Day {
SUNDAY, MONDAY, TUESDAY, WEDNESDAY,
THURSDAY, FRIDAY, SATURDAY
}
...
switch (day) {
case MONDAY:
System.out.println("Mondays are bad.");
break;
case FRIDAY:
System.out.println("Fridays are better.");
break;
case SATURDAY: case SUNDAY:
System.out.println("Weekends are best.");
break;
default:
System.out.println("Midweek days are so-so.");
break;
}
"Java handles enums specially in switch statements, removing the need for a prefix."
Java doesn't allow type qualification of enum values in switch cases (and requires them everywhere else). It's a hack that was added late to the language and was done that way for binary compatibility.
Swift's enums are pure but it uses .Foo for enum literals, inferring the specific enum type.
Java handles enums specially in switch statements, removing the need for a prefix.
That just shows how right I am. And sorry, but I don't like language design that goes like: "Ah, we enforce the type prefixes everywhere! Brilliant! But oh, not in this context as it's too annoying... And hrm, perhaps in this other context we might want to infer it as well..." The language is complex enough already, we don't need these stunts.
This will help you to know more about Java Enum....
http://net-informations.com/java/basics/enum.htm
Balmer
Also .pure enums beg for further features like SomeEnum.{ValueA, ValueB} as a shortcut for {SomeEnum.ValueA, SomeEnum.ValueB} etc.
This really should be a thing. Like gmpreussner said, non-pure enums are a pain when you make a heavy use of them.
For example, I had a name collision trying to do this:
type XAlign* = enum left, right, center, spread
type YAlign* = enum top, bottom, center, spread