Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the type system to resolve ambiguity between symbols from different modules #15247

Closed
exelotl opened this issue Aug 30, 2020 · 5 comments · Fixed by #24119
Closed

Use the type system to resolve ambiguity between symbols from different modules #15247

exelotl opened this issue Aug 30, 2020 · 5 comments · Fixed by #24119

Comments

@exelotl
Copy link
Contributor

exelotl commented Aug 30, 2020

Something I've encountered recently while trying to share code between modules:

Across various modules I have some exported symbols which happen to have the same name. When I import these modules and try to pass one of the symbols as an argument, the compiler is unable to disambiguate between them, even when the type system should clearly only allow one of them to be used.

I can of course fix this by explicitly qualifying the symbol, but it feels like this is something that the compiler should be able to figure out.

Example

foo.nim

proc count*(s: string): int = 
  s.len

bar.nim

var count*: int = 10

baz.nim

const count* = 3.142

main.nim

import foo, bar, baz

proc twice(n: int): int =
  n*2

echo twice(count)   # `bar.count` is the only symbol that would allow the program to compile.

Current Output

...
Hint: main [Processing]
Hint: foo [Processing]
Hint: bar [Processing]
Hint: baz [Processing]
/home/exelotl/nim/test/main.nim(6, 12) Error: ambiguous identifier: 'count' -- use one of the following:
  foo.count: proc (s: string): int{.noSideEffect, gcsafe, locks: 0.}
  bar.count: int
  baz.count: float64

Expected Output

Program compiles and prints 20.

Additional Information

Besides explicitly qualifying the symbol, a workaround is to create a local template or const which the compiler will always prefer to use where possible.

import foo, bar, baz

template count: int = bar.count

proc twice(n: int): int =
  n*2

echo twice(count)

$ nim -v
Nim Compiler Version 1.2.6 [Linux: amd64]
@ghost
Copy link

ghost commented Aug 30, 2020

Not really sure, but doesn't this fall into the same category as inferring generics by the assigned value type for example? So it probably needs something like an HM type system.

@RSDuck
Copy link
Contributor

RSDuck commented Aug 30, 2020

that's basically overloading by return type

@Araq
Copy link
Member

Araq commented Aug 31, 2020

This is not overloading by return type, it's "smarter disambiguation rules for sym choices", something which I'm fine with. ;-)

@jibal
Copy link

jibal commented Sep 2, 2020

I think this is begging for trouble. Change a type or add a converter or overload, and the program silently changes what value it uses.

@metagn
Copy link
Collaborator

metagn commented Aug 27, 2024

Implemented in #23123

Araq pushed a commit that referenced this issue Aug 30, 2024
closes #1969, closes #7547, closes #7737, closes #11838, closes #12283,
closes #12714, closes #12720, closes #14053, closes #16118, closes
#19670, closes #22645

I was going to wait on these but regression tests even for recent PRs
are turning out to be important in wide reaching PRs like #24010.

The other issues with the working label felt either finnicky (#7385,
#9156, #12732, #15247), excessive to test (#12405, #12424, #17527), or I
just don't know what fixed them/what the issue was (#16128: the PR link
gives a server error by Github, #12457, #12487).
metagn added a commit to metagn/Nim that referenced this issue Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants