Open overlookmotel opened 4 months ago
I like this idea. The way I could see it working is:
#[expand_derive(Foo)]
is functionally equivalent to #[derive(Foo)]
, with only differences being:
impl Foo for Ty
is not inserted at the call site (the way #[derive]
does) but in a separate file.impl
is generated by codegen, rather than by macro expansion.Perhaps this is what you meant anyway @rzvxa, but just to clarify:
I don't think #[expand_derive]
should act purely as an informational comment. The codegen should use it. If #[expand_derive(Foo)]
is present on a type, codegen will generate impl Foo
, if it's not, it doesn't.
Naming: #[derived]
is a bit ambiguous I think. I prefer #[expand_derive]
. Or maybe #[static_derive]
, #[codegen_derive]
or #[derive_by_codegen]
?
Broken out from https://github.com/oxc-project/oxc/issues/4282#issuecomment-2229046078. @rzvxa said:
I had an idea for generated derives which I've never shared publicly. We might want to add an attribute such as
#[expand_derive(...)]
or#[derived(...)]
to easily mark stuff likeHash
,PartialEq
, and nowCloneIn
derives.It is a marker and wouldn't expand the derived macro base on the builtins(or proc_macro_derive), but it is a good way to telegraph that these are being derived for the said type although they are generated and not happening in the compiler.