Code below won't compile, because it has name conflict for enum.
type Color3* = enum red, green, blue
type Color7* = enum red, orange, yellow, green, light_blue, blue, violet
proc print_color(color: Color3): void = echo color
print_color(red)
Enum names also conflict with function names, code below would fail too:
type Color3* = enum red, green, blue
proc blue() = "blue color"
proc print_color(color: Color3): void = echo color
print_color(red)
How it could be resolved? Using prefixes as in code below feels very inconvinient and ugly, is there a better way?
type Color3* = enum c3_red, c3_green, c3_blue
type Color7* = enum c7_red, c7_orange, c7_yellow, c7_green, c7_light_blue, c7_blue, c7_violet
proc print_color(color: Color3): void = echo color
print_color(c3_red)
Have you really missed pure enums?
See end of this section
http://ssalewski.de/nimprogramming.html#_enums
or other tutorials. For name conflict with function name -- well never occurred to me?
Thanks, yes I missed it, with pure it looks better :).
Would be even better if the last line print_color(Color3.red) would worked too without the explicit specification as there's enough information for compiler to extend print_color(red) into fully qualified enum name.
type Color3* {.pure.} = enum red, green, blue
type Color7* {.pure.} = enum red, orange, yellow, green, light_blue, blue, violet
proc print_color(color: Color3): void = echo color
print_color(Color3.red)
what you often see in Nim code is to prefix enums so that you just don't have two enums with the same name in the same module. If you have two enums from separate modules but with the same name you can distinguish them by the module name.
See the Nim style guide for official projects: https://nim-lang.org/docs/nep1.html
It's admittedly a bit C-ish, but you get used to it.
It's admittedly a bit C-ish, but you get used to it as it matches the way functions are handled in Nim.
I would say it's against the way functions are used in Nim. One of the biggest advantage of multiple dispatch is to free human memory. So you can say "shape.rotate()" and the machine would figure out by itself if you want rectangle_rotate(rectangle) or circle_rotate(circle).
The way Enum works (at least how it described in naming conventions you mentioned) - break that principle, you need to remember and explicitly specify that it's not only "red" but a red of specific type "c3_red" and not "c7_red".
Yes, there are edge cases with enums when it's impossible to disginguish which one to use. And emitting an error is ok. But in most cases (maybe even in 90%) - it's possible to know what enum to use.
Current way enums are used - looks ugly and inconvenient
let some_re = re(".*\\s:([a-z0-9_-]+)$", flags = {re_study, re_ignore_case})`
That means, among other things, that you can't infer the type of a function argument based on the signature, which is what you're trying to do here.
Sad...