-
-
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
[TODO] quoted symbols foo
should not be replaced in template substitution
#8899
Comments
This keeps coming up but the template substitution mechanism should remain simple, rename your template parameters when you have a conflict like this. |
How can you rename them if you purposely want to properly support parameter naming at the point of calling? For example:
I want the user to be able to call it like such:
Renaming |
+1 on the quoting idea. I was already trying it anyways, but of course it doesn't work. |
Then you rename your object field. :P |
I would propose the opposite: only substitute quoted symbols. In fact, I'm pretty sure I got @Araq to agree to this over PM at one point... |
nested templates solve all problems var resp: tuple[body: string]
template renderInner(bodyArg: string): untyped =
resp.body = bodyArg
template render*(body: string) :untyped =
renderInner(body)
render(body = "raw content")
echo resp @dom96 I would agree on it as an initial design choice, but right now it would just break too much code. |
Maybe we could use a different symbol for the quoting to have a transition period? |
foo
should not be replaced in template substitutionfoo
should not be replaced in template substitution
Nested templates. Nice thanks. Will work for now. |
Gah, no, quoting is so ugly, but I think you mean, "quote in dot notation to get the replacement"? |
to avoid running into #8882 and allow a common (for me at least) idiom, I'd like to suggest that a quoted symbol
name
should not be replaced in template substitutionThe workaround (renaming the template arguments) is not great, eg:
The text was updated successfully, but these errors were encountered: