Repository navigation
Allow use of CGP proc macros without explicit import of prelude #40
Description
Activity
You can probably use
::cgpas a default with an attribute/attribute parameter to change the crate path in nested macro invocations@soareschen are you still considering this?
@gkgoat1 Thanks for asking. Yes it is in the plan but I haven't got the time to prioritize on this.
The tentative plan is to add something like a
cgp_macro_preludemodule that will be imported together withcgp::prelude::*. With that, the CGP macros will refer to CGP constructs in the form likecgp_macro_prelude::DelegateComponentinstead of the current bareDelegateComponent.This way, if you don't want to import everything in prelude, you only need to import
cgp::cgp_macro_preludeto make it work with the macros.Using something like
::cgp::DelegateComponentmight be a bit challenging at the moment, because it would make the macros not easily usable by internal CGP crates that don't yet have thecgpcrate available. I might be able to define an internal crate with local renaming to make this work, but it is not clear if it could work at the moment.The biggest blocker was that the macro library has become pretty bloated, with a lot of pending refactoring to be done. I was hoping to fix the prelude together with the macro refactoring. But given the limited time, I will probably try to fix the prelude first, and then refactor the macro code later on.
@gkgoat1 Thanks for asking. Yes it is in the plan but I haven't got the time to prioritize on this.
The tentative plan is to add something like a
cgp_macro_preludemodule that will be imported together withcgp::prelude::*. With that, the CGP macros will refer to CGP constructs in the form likecgp_macro_prelude::DelegateComponentinstead of the current bareDelegateComponent.This way, if you don't want to import everything in prelude, you only need to import
cgp::cgp_macro_preludeto make it work with the macros.That doesn't fully resolve the issue though, you'd still need to import
cgp_macro_prelude(which wrapper crates hiding their usage of CGP shouldn't need to specify)Using something like
::cgp::DelegateComponentmight be a bit challenging at the moment, because it would make the macros not easily usable by internal CGP crates that don't yet have thecgpcrate available. I might be able to define an internal crate with local renaming to make this work, but it is not clear if it could work at the moment.The idea for that could be that, like potential wrapper crates, internal crates specify themselves as the CGP path like ```rust
#[cgp_path(crate)]so the macro would look there and not at `::cgp` > > The biggest blocker was that the macro library has become pretty bloated, with a lot of pending refactoring to be done. I was hoping to fix the prelude together with the macro refactoring. But given the limited time, I will probably try to fix the prelude first, and then refactor the macro code later on.
Currently, the CGP pro macros are unhygenic, and requires import of
cgp::prelude::*for the expanded syntax to work. Unfortunately, there is no equivalent of$cratein the proc macro world to help us bind CGP constructs with proper module path.We would need to figure out how to properly scope CGP constructs inside the macro expansion, so that the macros could work even if users don't import the prelude.