As a user of cpp!() library, for whatever reason, I may want to write this:
cpp!(unsafe [n as "int"] {
rust!(#[allow(unused)] Rust_myCallback [n : i32 as "int"] {
// do something with or without `n`
})
})
Description
Currently, cpp!() macro generates code with two C++ functions: extern "C" wrapper, and actual native C++ function with your code verbatim. It is done so that user's code control flow would not interfere with wrapping glue, e.g. explicit early return statements.
On contrary, rust! pseudo-macro's is to wrap user's code verbatim in a closure. It is purely an implementation details, but if we change it to a function and make that fact public and engraved in stone, then we'd be able to support new syntax with function attributes.
Why?
I wanted to silence clippy's needless_return warning in #93, but I just couldn't narrow it down to just single invocation, since expression/item attributes are not stable yet (and probably would never be). So, using #![allow(...)] attribute inside the block would give me compile error. Using outer #[allow(...)] block in C++ code is obviously not an option. And adding it to the whole top-level cpp!{{ ... }} macro silently did nothing good.
I just showed my particular example. There might be more use cases for attributes. It just feels like an artificial limitation that gets in the way.
Summary
As a user of
cpp!()library, for whatever reason, I may want to write this:Description
Currently,
cpp!()macro generates code with two C++ functions: extern "C" wrapper, and actual native C++ function with your code verbatim. It is done so that user's code control flow would not interfere with wrapping glue, e.g. explicit early return statements.On contrary,
rust!pseudo-macro's is to wrap user's code verbatim in a closure. It is purely an implementation details, but if we change it to a function and make that fact public and engraved in stone, then we'd be able to support new syntax with function attributes.Why?
I wanted to silence clippy's
needless_returnwarning in #93, but I just couldn't narrow it down to just single invocation, since expression/item attributes are not stable yet (and probably would never be). So, using#![allow(...)]attribute inside the block would give me compile error. Using outer#[allow(...)]block in C++ code is obviously not an option. And adding it to the whole top-levelcpp!{{ ... }}macro silently did nothing good.I just showed my particular example. There might be more use cases for attributes. It just feels like an artificial limitation that gets in the way.