-
-
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
resolveSymbol(foo(args))
and overloadExists(foo(args))
to return symbol after overload resolution
#12076
resolveSymbol(foo(args))
and overloadExists(foo(args))
to return symbol after overload resolution
#12076
Conversation
good feature: i do this manually in a hacky and probably wrong way |
Btw, a little offtopic but what use cases are left for |
definitely still useful, at least for testing: proc testFoo() =
# bar1() slow at **runtime**
doAssert compiles bar1()
# bar2() would bring things in scope
# bar3() would bring things in scope that clash with bar2
doAssert compiles bar2()
doAssert compiles bar3() There are other use cases I have in mind for however, probably almost always when overloadExists(foo(arg)): foo(arg)
else: fooAlt(arg) |
I am not the biggest fan of this pattern. when overloadExists(foo(arg)): foo(arg)
else: fooAlt(arg) Usually it is much better to replace it with just template foo(arg: MyType): untyped =
fooAlt(arg)
foo(arg) I prefer it for two reasons. |
Overloads have their use obviously but there are many use cases where
proc foo(a: SomeOrdinal): auto = (a,"ordinal")
proc fooAlt[T](a: T): auto = (a,"alt")
template foo(a: uint8): untyped = fooAlt(a) # hijacks `foo(a: SomeOrdinal)`
echo foo(1) # (1, "ordinal")
echo foo(1'u8) # (1, "alt")
proc fun[T](a: T, b: static string) =
when overloadExists(foo(a)): foo(arg)
else: doAssert false, $("additional context:", $T, b) That's not possible with the pattern you're suggesting, you'd just get CT error without the user defined custom context
proc fun[T1, T2](a1: T1, a2: T2) =
when overloadExists(foo(a1)): foo(a1)
elif overloadExists(foo2(a2)): foo2(a2)
elif condition(a1,a2): .... again, I don't see how the template overload pattern would help there |
I would rather call it "providing explicit overloads".
If things become too complex, I usually cut complexity by providing explicit overloads only. Then I know exactly what is going on.
Not really necessary. A missung overload is usually enough information for me to remind myself to introduce that overload.
For me this looks like code smell. I can't think of a situation where I would want to use this pattern.
Well when it is possible I always prefer static overloads over the when pattern. There are just some cases where a when pattern is necessary. |
5a67758
to
ab53f55
Compare
ab53f55
to
3586daf
Compare
6a9f238
to
2e69fdc
Compare
@Araq PTAL
There's been talks recently of getting rid of
Note that this is also more flexible than alternatives based on Furthermore, |
I think currently more in the direction of a tryExpression. tryExpr(something.len):
body:
# in this body the argument ``something.len`` exists and can be used with just ``expr``. This way the duplication of the argument doesn't need to happen.
for x in 0 ..< expr: # `expr` here will be substituted with ``something.len``
echo x
fallback:
# in this body neuther ``expr`` nor ``something.len`` can be used.
echo "<nothing>" This |
feel free to write a separate PR with
when overloadExists(sideEffect1()) and overloadExists(sideEffect2(foo)):
code involving calls to sideEffect1() and sideEffect2(...)
when overloadExists(callNeedingNetwork(url)):
setupNetwork()
callNeedingNetwork(url)
# or this example:
when overloadExists(expansiveCall(urls[0])):
if runtimeCondition(): expansiveCall(urls[0]) else: expansiveCall(urls[1])
proc fun2[T](a: T): int = 100
echo tryCompile(fun2("foo"), 18) # this gives: Error: ambiguous call with code in http://ix.io/2eL3
all of which work with my PR btw, see the tests in this PR. |
@timotheecour regarding reganding
True that is a real limitation that I din't think about. Could destroy the entire idea. But I don't want to give it up so soon.
I just looked at your
True could be worked on. But for the concept I currently don't really care that much. |
no argument doesn't mean it can't indicate an overload:
I don't see how that could be implemented, I suggest to follow-up here: timotheecour#71 to keep this discussion focused on this PR. |
Regarding nim-lang/RFCs#164 I really like |
This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions. |
This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions. |
overloadExists(foo(args))
to tell whether an overload exists without compiling/running body viacompiles
RFCs#164 (both proposal1 and proposal2)resolveSymbol
that performs symbol resolution (in particular overload resolution for call-like expressions) and returns either nil if not such overload was found, or the symbol after overload resolution is done, or the symchoice if a symbol is ambiguous.overloadExists(foo(args))
is a library proc built on top ofresolveSymbol
to tell whether a proper overload existstests/magics/tresolve_overloads.nim
As an example use case, see library defined
inspect
macro that inspects the sym/symchoice returned byresolveSymbol
:inspect
is a bit similar to whatnimsuggest
binary provides but it's a pure library solution, ie easier to integrate with custom user needs. It can resolve things that aren't possible with nimsuggest, eg:note
compiles
, this does not do any analysis of routine body, hence is more efficient and solves issues related tocompiles
(eg when proc body has an error for input args but signature matches, compiles returns false, unlikeresolveSymbol
andoverloadExists
)See also [superseded] new
macros.genAst
: sidesteps issues withquote do
#11722 (comment) where this came up /cc @krux02note2
will allow doings something more targeted than this:
which results in re-exporting all the
system.$
overloads instead of just$(typedesc)
(currently, it shows in https://nim-lang.github.io/Nim/typetraits.html#elementType.t%2Cuntyped: