overloadableEnums are hard to use for library authors

[treeform]

See: https://github.com/nim-lang/RFCs/issues/373

The {.experimental: "overloadableEnums".} should only be required in the file where enums are defined.

I have two files:

enumlib.nim:

{.experimental: "overloadableEnums".}

type
  Enum1* = enum
    A, B, C
  Enum2* = enum
    A, Z

enumuse.nim:

import enumlib

proc f(e: Enum1): int = ord(e)
proc g(e: Enum2): int = ord(e)

proc h(e: Enum1): int = ord(e)
proc h(e: Enum2): int = ord(e)

let fA = f(A) # Type of A is well defined
let gA = g(A) # Same as above

let hA1 = h(Enum1.A) # A requires disambiguation
let hA2 = h(Enum2.A) # Similarly
let x = ord(Enum1.A) # Also
doAssert fA == 0
doAssert gA == 0
doAssert hA1 == 0
doAssert hA2 == 0
doAssert x == 0

I get an error:

Error: ambiguous identifier: 'A' -- use one of the following:
  Enum1.A: Enum1
  Enum2.A: Enum2

But if I put {.experimental: "overloadableEnums".} in both files it works.

I know overloadableEnums is experimental feature, but I can't ship a library that says put {.experimental: "overloadableEnums".} in every file that is used by this library - just in case. I think it should only be required in the definition file only... otherwise it just can't be used. Its just to much for library users to do. The cost is way to high.

Please make it so:

• The {.experimental: "overloadableEnums".} should only be required in the file where enums are defined.
• Or making overloadableEnums be a real feature that just works everywhere.

[beef331]

You dont need to put that pragma in every file that uses it, you just need to say to your users "Create a config.nims and put --experimental:overloadableEnums in it". It's not that elegant but it's not a big deal if you ask me.

[guzba]

You dont need to put that pragma in every file that uses it, you just need to say to your users "Create a config.nims and put --experimental:overloadableEnums in it". It's not that elegant but it's not a big deal if you ask me.

My issue with that response is this: Currently, if we used overloadableEnums in Pixie, the moment you import pixie and start using it anywhere in your project, your project will no longer compile for a mysterious reason. To me, this is unacceptable.

This doesn't matter for personal projects but definitely matters for libraries other people use.

[beef331]

Oh do not get me wrong I agree it sucks, but as it's an experimental feature that will be the default in time. You cannot have the pragma effect(consider strictFuncs/viewTypes/strictNotNil) the entire project, I still think that Nimble project's config.nims should be respected by nimble and nim so then you could just have a config.nims at pixie's root and it'd use that to enable any flags required for the program. This issue effects all experimental pragmas that you'd want to propagate up to user code, caseStmtMacros for instance.

I do have a related issue with --path:"$nim" for nimscripter, there just is no good way of setting flags for a given project. It's not great to have "Create a config.nims with --path:"$nim" for the compiler api to work." but there presently is not anyway around it with nimble or nim.

[guzba]

Ah ok. I see what you're saying. To be more clear as well on my side, for example {.experimental: "dotOperators".} does work outside just the file the flag is in, whereas {.experimental: "overloadableEnums".} does not. Perhaps its just the inconsistency there that is a bit troublesome.

[metagn]

I just wrote https://github.com/nim-lang/RFCs/issues/468, all library authors would have to do is add {.pure.}/whatever annotation to their enums.

[ringabout]

The overloadableEnums feature has been enabled on the devel branch.