-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
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. |
that's basically overloading by return type |
This is not overloading by return type, it's "smarter disambiguation rules for sym choices", something which I'm fine with. ;-) |
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. |
Implemented in #23123 |
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).
closes nim-lang#4774, closes nim-lang#7385, closes nim-lang#10019, closes nim-lang#12405, closes nim-lang#12732, closes nim-lang#13270, closes nim-lang#13799, closes nim-lang#15247, closes nim-lang#16128, closes nim-lang#16175, closes nim-lang#16774, closes nim-lang#17527, closes nim-lang#20880, closes nim-lang#21346
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
bar.nim
baz.nim
main.nim
Current Output
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.
The text was updated successfully, but these errors were encountered: