# Pre-RFC: allow retreiving foreign items from proc macros

**URL:** <https://internals.rust-lang.org/t/pre-rfc-allow-retreiving-foreign-items-from-proc-macros/8720>\
**Category:** language design\
**Created:** [October 29, 2018, 11:32am UTC](https://internals.rust-lang.org/t/pre-rfc-allow-retreiving-foreign-items-from-proc-macros/8720 "2018-10-29T11:32:30Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kixunil](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kixunil/32/4110_2.png) [@Kixunil](https://internals.rust-lang.org/u/Kixunil)\
**Post date:** [October 29, 2018, 11:32am UTC](https://internals.rust-lang.org/t/pre-rfc-allow-retreiving-foreign-items-from-proc-macros/8720/1 "2018-10-29T11:32:30Z")

</div>

# Summary

Allow to define a proc macro as `fn(TokenStream, TokenStream, &Source) -> TokenStream` where `Source` provides `fn get_item(item: &[String]) -> Option<TokenStream>`, which returns the definition of `item`.

For example `source.get_item(&["std", "option", "Option"])` would return the definition of `Option` type. It’d work with any type or trait in any crate.

Proc macro is invoked as function-like macro: `example!(MyType)`.

# Motivation

There is delegation RFC, [Inherent trait implementation](https://github.com/rust-lang/rfcs/issues/1880) RFC. Both request to add new syntax to the language which could be implemented as a proc macro, if this feature was available today. One could e.g. write `delegate!(MyTrait to MyType::inner)` to delegate the `MyTrait` to `inner` field of `MyType`. Similarly, one could write `inherent!(MyType, MyTrait)` to make trait methods of `MyTriat` inherent to `MyType`.

Further, it’d help when writing (de)serializers. Let’s say I have my own `MySerialize` trait and associated derive macro. The crate implementing derive macro could also provide `foreign_derive!()` one, and reuse the code of classic derive macro. Then the crate defining `MySerialize` could easily implement it for types from other crates.

Similarly, a macro using newtype pattern could implement foreign traits for “foreign” types.

This would allow us experiment with delegation, inherent impls and possibly other ideas the same way we could experiment with `try!()` macro before implementing `?` operator.

What do you think? Is this approach feasible? Do you see some problems? Anyone willing to help me with writing proper RFC?

---

<div class="post-metadata">

**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\
**Post date:** [October 29, 2018, 2:43pm UTC](https://internals.rust-lang.org/t/pre-rfc-allow-retreiving-foreign-items-from-proc-macros/8720/2 "2018-10-29T14:43:05Z")

</div>

This works for derive macros, as those don’t touch the inners of an item definition.

But otherwise, you start running into ordering issues.

If you have a proc macro that emits an item definition, you’d probably expect to be able to access its definition via this API. That means that the macro emitting an item definition has to run before yours.

This isn’t an unsolvable problem (probably). But the question does need to be answered; relying on macro expansion order for correctness is scary.

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [March 25, 2019, 8:31am UTC](https://internals.rust-lang.org/t/pre-rfc-allow-retreiving-foreign-items-from-proc-macros/8720/3 "2019-03-25T08:31:04Z")

</div>

Closed on March 25, 2019, 8:31am UTC

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.