-
-
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
document macros.unpackVarargs #18106
Conversation
|
this doesn't answer the question: is there any single use case for it? see previous discussion in #18101 (comment) + tests in this PR, it seems that
|
your example does not fit the situation , the real use case you dont get |
can you show a working example illustrating the point of |
that doesn't use example adapted from import std/macros
template `.`*(fun: typed; x: untyped, args: varargs[untyped]): untyped =
# unpackVarargs(fun, args)
fun(args) # same results
template call(fun: typed; args: varargs[untyped]): untyped =
# unpackVarargs(fun, args)
fun(args) # same results
proc fn1(a, b, c: int) = echo (a, b, c)
proc fn2(a, b: string) = echo (a, b)
call(fn1, 1, 2, 3)
call(fn2, "a", "b")
fn1.zook(2,3,4)
fn2.zook("a", "b") => same results with or without using unpackVarargs noteafter investigating, the only case where it makes a difference is with with an empty varargs, at least that answers the question of in which case it makes a difference. But note that you can use when true:
import std/macros
template call(fun: typed; args: varargs[untyped]): untyped =
# unpackVarargs(fun, args)
# fun(args) # works except for last case with empty `args`
when varargsLen(args) > 0: fun(args)
else: fun()
proc fn1(a = 0, b = 1, c = 2) = echo (a, b, c)
call(fn1, 10, 11, 12)
call(fn1, 10, 11)
call(fn1, 10)
call(fn1) # requires either unpackVarargs or the above impl with `varargsLen`
when varargsLen(args) > 0: fun(args)
else: fun() so the next question is whether we can simply fix the compiler so that |
the use case you need import std/macros
{.experimental: "dotOperators".}
macro `.`*(fun: untyped; x: untyped, args: varargs[untyped]): untyped =
quote do:
unpackVarargs(`fun`, `args`)
#fun(args) # same results
macro call(fun: untyped; args: varargs[untyped]): untyped =
quote do:
unpackVarargs(`fun`, `args`)
#fun(args) # same results
proc fn1(a, b, c: int) = echo (a, b, c)
proc fn2(a, b: string) = echo (a, b)
call(fn1, 1, 2, 3)
call(fn2, "a", "b")
fn1.zook(2,3,4)
fn2.zook("a", "b") |
your example is not convincing for the same reason i explained above: again, as shown in #18106 (comment), it turns out the only case where it makes a difference is when the varargs can be empty (which wasn't illustrated in your example). I'll update this PR later explain those findings and the EDIT: done, I've updated PR |
44842ed
to
2f53355
Compare
Er, how do you write this without import macros
template myecho(x: varargs[typed]) =
unpackVarargs(echo, x)
myecho(1, 2, 3) |
2f53355
to
5598e88
Compare
5598e88
to
0ed1d86
Compare
PTAL
it would work without |
@timotheecour Here's an example usecase of import std/[times, macros]
template timeIt*(theFunc: proc, passedArgs: varargs[typed]): float =
let t = cpuTime()
echo unpackVarargs(theFunc, passedArgs)
cpuTime() - t
proc add2(arg1, arg2: int): int =
result = arg1 + arg2
proc add3(arg1, arg2, arg3: float): float =
result = arg1 + arg2 + arg3
echo timeIt(add2, 15, 5)
echo timeIt(add3, 15.5, 123.12, 10.009) |
that is not very convincing because this works just as well: template timeIt*(theFunc: proc, passedArgs: varargs[untyped]): float =
let t = cpuTime()
echo theFunc(passedArgs)
cpuTime() - t or even simpler/more general: template timeIt2*(call: typed): float =
let t = cpuTime()
echo call
cpuTime() - t
echo timeIt2(add2(15, 5))
echo timeIt2(add3(15.5, 123.12, 10.009)) |
👍 Wow, I didn't know |
* deprecate macros.unpackVarargs * un-deprecate unpackVarargs and add docs+runnableExamples * update examples + tests with varargs[typed]
refs #18101 (comment)
closes #18101
(unless a reviewer can point to a use case, I think this is ready for deprecation)see discussion below, in particular #18106 (comment)