-
Notifications
You must be signed in to change notification settings - Fork 23
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
overloadExists(foo(args))
to tell whether an overload exists without compiling/running body via compiles
#164
Comments
Does it need to be magic? Or can we lift something already implemented in sigmatch? If it helps I wrote my own overload resolution macro for my needs though it requires a typed input |
I don't see how that could work without relying on a
yes, it would leverage sigmatch, the basic functionality to implement this is already there ; unless I'm missing something, a PR implementing proposal1 shouldn't be hard
well typed input would be "too late", since we don't know whether overload exists
yes, that's the other sensible module. it would logically group well with |
|
Funny hack proc plusExists[T]: bool =
type Foo = concept
proc `+`(x, y: T): T
result = void is Foo
echo plusExists[int]()
echo plusExists[string]() |
(originally discussed here: nim-lang/Nim#11722 (comment) /cc @krux02 )
proposal1
overloadExists(foo(args))
compiler magic that checks whetherfoo(args)
has a proper overload; it doesn't try to compilefoo(args)
; in particular, the check succeeds even iffoo(args)
has a fwd declaration and no definition.examples:
proposal2
independent / orthogonal to proposal1. This selects a particular overload via
overloadResolve
. Works with any routine (template/macro/iterator/generics, regardless of all optional params/varargs)this 2nd proposal requires nim-lang/Nim#11992
rationale
depending on
compiles(foo(args))
can be problematic for a number of reasons:The side effect can even be executed when the
compiles()
eventually fails after the side effectcompiles(foo(args))
can fail for a reason the user did not expect, eg a bug in proc body; that bug may end up not getting caught; eg:here user expects
fun(args)
to compile for everyT
inOrdinal | Foo1 | Foo2
but in fact some cases may trigger the other branch to be taken due to a bug insidefun
The text was updated successfully, but these errors were encountered: