Closed arcnmx closed 7 years ago
And the strange extra part of these macro changes is the ability to customize the name of the library. The syntax here is:
lambda! {
crate (liblambda, initliblambda, PyInit_liblambda) {
"handler" => f,
}
}
It's awkward due to the lack of a working concat_idents!()
and the python export naming reqiurements... A procedural macro could work around this but might be overkill for this simple macro (and would bring in extra build dependencies for macro parsing).
Also I think we may be able to get away with crate (initliblambda, PyInit_liblambda)
because the first identifier just needs to be something unique, while the latter two must be the same name as the library. Needs checking out.
Needs a decision made on this. As much as I want the ability to customize the library name it could be removed until a better syntax is found...
Needs a decision made on this. As much as I want the ability to customize the library name it could be removed until a better syntax is found...
I'm tempted to wait until concat_idents!()
lands in stable to land something that allows you to change the library name, but the syntax isn't terribly clunky and might make something possible that isn't possible now. (I'm honestly not sure what, though.)
I'm happy to land the crate (liblambda, initliblambda, PyInit_liblambda)
syntax if you are. If anything, we can always deprecate it later when possible.
Besides being unstable, concat_idents!()
doesn't actually work (and has never worked). I'm not sure if there are plans to fix the macro system to make it useful, but it's not likely to be an option for years.
If you're okay with the syntax let's go for it then!
A simple extension to the
lambda!()
macro syntax to allow exporting multiple handler functions:The basic syntax
lambda!(f);
is equivalent tolambda { "handler" => f }