-
-
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
Template called when arguments signature doesn't match #21774
Comments
Workaround is template buildHtmlImpl(tname: string, blk): seq[El] =
block:
let it {.inject.} = El(tag: tname)
blk
it.children
template build_html(blk): seq[El] =
buildHtmlImpl("div", blk)
template build_html(tname: untyped, blk): seq[El] =
buildHtmlImpl(tname, blk) |
@metagn It's not looking like RFC, it's looking like a bug that should be fixed. Different bug, but seems to be caused by same problem type El* = ref object
tag*: string
children*: seq[El]
template build_h*(html: string, blk): El =
block:
let it {.inject.} = El(tag: html)
blk
it
template h*(html: string) =
it.children.add El(tag: html)
template h*(html: string, code) =
let parent = it
block:
let it {.inject.} = El(tag: html)
code
parent.children.add it
template section*(content) =
h"section":
content
# Comment out this and result will be different
template section*(title: string, content) =
h"section":
content
proc `$`*[T: typed](x: ref T): string = "->" & $(x[])
echo:
build_h"app":
section:
h"button" Result will be |
I just linked the RFC because it's the closest thing to a collection of these issues, sorry if that wasn't clear. If you want a list of issues with the same problem, here you go #14827 #19556 #20274, Your example there breaks because of the same issue causing the upper template sectionImpl(content: untyped, title: string) =
h"section": content
template sectionImpl(content: untyped) =
h"section": content
template section(title, content: untyped) =
sectionImpl(content, title)
template section(content: untyped) =
sectionImpl(content) |
There is no bug here, it's just that I misread your code on the forum. The compiler check's It's actually quite easy to understand when you don't treat the Nim compiler as an almighty AI overload. |
@Araq but templates can have undeclared variables. The code below with undeclared That's just looks unexpected - you have working code, then add one more template (that don't even match the call signature and shouldn't even be called), and suddenly code that previously worked fail. (I see that possible solution is to use type El* = ref object
tag*: string
children*: seq[El]
template build_html(blk): seq[El] =
block:
let it {.inject.} = El(tag: "div")
blk
it.children
# template build_html(tname: string, blk): seq[El] =
# block:
# let it {.inject.} = El(tag: tname)
# blk
# it.children
template h*(tname: string) =
it.children.add El(tag: tname)
discard build_html: # <= no `tname: string` arg, why `build_html` called?
h"div" |
That's just |
Description
The
build_html
template called. It shouldn't be called, as the call signature doesn't match - there's notname: string
arg supplied.It ends up with the error, but with the wrong error.
Another problem - what I actually wanted to do is to have two versions of
build_html
and it doesn't work. If you uncomment the overloaded version, it won't be called, the wrongbuild_html
will be called.Nim Version
nim -v
Nim Compiler Version 1.6.12 [MacOSX: amd64]
Compiled at 2023-03-10
Copyright (c) 2006-2023 by Andreas Rumpf
active boot switches: -d:release -d:nimUseLinenoise
Current Output
No response
Expected Output
No response
Possible Solution
No response
Additional Information
No response
The text was updated successfully, but these errors were encountered: