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

mixin'd pre-existing symbols only work as expected in calls #20240

Open
TechnoRazor opened this issue Aug 18, 2022 · 1 comment · May be fixed by #24252
Open

mixin'd pre-existing symbols only work as expected in calls #20240

TechnoRazor opened this issue Aug 18, 2022 · 1 comment · May be fixed by #24252
Assignees

Comments

@TechnoRazor
Copy link

What happened?

This example using the mixin keyword works as expected:

type Action[T] = proc (x: T): void {.nimcall.}

proc getDoThing[T]: Action[T] =
  mixin doThing
  assert compiles(doThing(default(T)))
  result = doThing # everything is as expected

proc doThing(x : int) = echo "int: ", x
# overloaded procs don't make any difference:
proc doThing(x : float) = echo "float: ", x

let intDoThing = getDoThing[int]()
intDoThing(100)

While this one does not, with the only change being that a proc named doThing already exists when getDoThing is defined:

type Action[T] = proc (x: T): void {.nimcall.}

proc doThing(x : float) = echo "float: ", x

proc getDoThing[T]: Action[T] =
  mixin doThing
  assert compiles(doThing(default(T))) # still works
  result = doThing # but this doesn't -- type mismatch: got 'None' for 'doThing' but expected 'Action[system.int]'
  
proc doThing(x : int) = echo "int: ", x
let intDoThing = getDoThing[int]()
intDoThing(100)

I also tried using a template I named coerce to encourage it to pick the correct symbol, but then it seems to only consider symbols defined at definition:

type Action[T] = proc (x: T): void {.nimcall.}

proc doThing(x : float) = echo "float: ", x
template coerce[T](x) : T = x

proc getDoThing[T]: Action[T] =
  mixin doThing
  result = coerce[Action[T]](doThing) # type mismatch: got 'proc (x: float){.gcsafe, locks: 0.}' for 'doThing' but expected 'Action[system.int]'
  
proc doThing(x : int) = echo "int: ", x
let intDoThing = getDoThing[int]()
intDoThing(100)

Nim Version

Nim Compiler Version 1.6.6 [Linux: amd64]
Compiled at 2022-05-05
Copyright (c) 2006-2021 by Andreas Rumpf

git hash: 0565a70
active boot switches: -d:release

Current Standard Output Logs

No response

Expected Standard Output Logs

No response

Possible Solution

I'm not very familiar how the compiler works, but I expect mixin to work something like the experimental dynamicBindSym feature?

{.experimental:"dynamicBindSym".}
import std/macros

type Action[T] = proc (x: T): void {.nimcall.}

proc doThing(x : float) = echo "float: ", x

proc getDoThing[T]: Action[T] =
  result = "doThing".bindSym brForceOpen # properly chooses the right symbol

proc doThing(x : int) = echo "int: ", x
let intDoThing = getDoThing[int]()
intDoThing(100)

I briefly tested it across modules as well, and it seems to work as mixin should, except in the case that you want an un-exported symbol to be part of the OpenSymChoice.

Additional Information

Although the example given isn't the most practical, I ran into this issue myself when trying to create a vtable for a given type by grabbing overloaded procs of certain names, similar to https://github.com/andreaferretti/interfaced.
Apologies if this bug report isn't very clear or comprehensive, this is my first time doing this, and I'm incredibly sleepy at the moment.

@metagn
Copy link
Collaborator

metagn commented Sep 25, 2024

nkOpenSymChoice only acts as a mark for overload iteration to include other symbols, but overload iteration isn't done when matching sym choices to types in paramTypesMatch

@metagn metagn self-assigned this Sep 25, 2024
metagn added a commit to metagn/Nim that referenced this issue Oct 7, 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.

2 participants