I'm trying to create a macro for:
signal my_signal(a:bool = true)
my_signal is being picked up as an object construction syntax, but is there a way get signal recognized as a proc declaration? I'd like to get a nice default arguments syntax working.
@xigoi That's unfortunate. @b3liever I think I'll have to try an alternate syntax. Using proc would be and signal pragma might be ok, or I might do something like
signal my_signal(a:bool): a = true
because I don't want to confuse the signal with procs and methods which are also used. FYI, I'm trying to implement signals for the godot-nim binding.This should work if you leave out the parameter type, it is redundant anyway whith the default value specified:
signal my_signal(a = true)
This is parsed as command syntax and can be transformed to a forward proc declaration, if that's what you want. That said, I would go with the more idiomatic solutions given by @b3liever.
Indeed the most idiomatic solution is:
proc my_signal(a:bool = true) {.signal.}
The {.signal.} is readable to me. Though if you need to pass some data variable to the macro for further usage you could copy nim-json-rpc's approach:
var router: Router = ...
router.rpc("updateData") do(myObj: MyObject, newData: DataBlob) -> DataBlob:
result = myObj.data
myObj.data = newData
This creates a doUpdateData proc and inserts it into the router variable. Though it'd be nice if that could be made into a {.rpc.} annotation.
A lot of good suggestions in this thread but there might be some context missing: https://github.com/pragmagic/godot-nim/issues/74
And even though it might be more idiomatic Nim, I feel like the signal mySignal is cleaner then the pragma and conveys the intent better for the Godot signal use case.
In C, Godot Signal are delegates, which are also just procs in a sense.
And even though it might be more idiomatic Nim, I feel like the signal mySignal is cleaner then the pragma and conveys the intent better for the Godot signal use case.
This doesn't make much sense, sorry. "is cleaner" for somebody, and for Nim programmers it seems unlikely to be "cleaner" because it's less idiomatic. Nim's macro system is not for emulating other languages/syntaxes, it's about avoiding boilerplate and building abstractions.