I guess this is a situation where not having the feature would be a ‘fault of imagination’ given the probability that someone in the future will need it for something important. Pretty printing isn’t that critical but comes in handy once in a while:
But then you are assigning the value returned to some var/struct field, aren’t you?
Neither do I about my “interpetation”. Embedding turnLeft() and alike into Direction enum has an advantage that you can then use these methods in any struct with a field of type Direction. In my “approach” I would have to duplicate them in every struct.
This depends on the richness and complexity of the space you are modeling.
The more your enums look like “names for integers,” the less use you will have for bound methods. But consider playing cards: they are frequently used as an example for enums, and there are plenty of questions you might ask about a playing card. Is this a face card, what is the rank, what is the suite, what is the score of this card (depends on the game, obviously)? What nicknames does this card have? What aliases? Does the card have a name or just a descriptor? (Grace’s card, the curse of Scotland, a “suicide king”, “the man with the axe”, “lady Luck”)
Or consider file/directory permissions. On “simple” unix systems, there is still the umask value to be factored in, so an “effective” value might be quite different from the actual value. In an ACL environment, with cascading settings from higher levels, this may be quite challenging. Is this still the domain of an enum? That’s an implementation thing. But there’s likely an enum in there somewhere.
Or, what about HTTP request methods? (GET, POST, DELETE, etc.) There is a big collection of attributes around those values - can they be cached, shared, etc. There’s enough complexity that the answers probably aren’t found in a table. It’s worth writing a function to determine the answers (some of which depend on the individual request). It might not be an enum-level function, but that’s implementor’s choice.
Finally, what about enumerated values? Objects that aren’t integers at all, but that we can still meaningfully talk about in shorthand. Toolchain? Gcc vs. clang. Binaries? Elf vs. Dwarf. Boxers or briefs? Paper or plastic? Fight or flight? Craps or Roulette? BMW or Aston-Martin? There are plenty of “things” we model with potentially infinitely-many values, but practically only a few. Again, that may be an enum or a tagged enum with an “Other” option, or something else. But it certainly could be an enum in version 1 of the project, and have lots of operations and queries to interrogate.