Feedback on Span::def_site

[mjbshaw]

I’m not sure which of the various Span/hygiene related issues this comment should be in, so instead of posting it on GitHub I’m posting it here.

I’ve been using Span::def_site for awhile now and I have some feedback:

• The documentation on the Span::def_site function is sparse and could be expanded and clarified.
• I wish there were three variants of def_site:
  1. The current Span::def_site, where an identifier resolves at the macro definition site for a single macro invocation.
  2. A variant named* something like Span::unique_site where an identifier resolves at a unique site. Every call to Span::unique_site would return a new unique site. This would allow a single macro invocation to use the same identifier repeatedly (even in the same scope) without any conflicts. Like def_site, macro users would not be able to refer to these identifiers. I personally want this to assist with the composability of my macro implementations, where different macros that rely on shared code can use these shared helpers without the risk of the helper polluting the macro’s namespace.
  3. Another variant named* something like Span::crate_site where an identifier resolves to the macro’s crate’s site. This would allow two different macro invocations to share a namespace (that is inaccessible to the macro user, like def_site), as long as those two macros originate from the same crate. For example, I currently have code like this:

     #[objrs(class)] struct Foo;
     #[objrs(impl)] impl Foo { ... }
     

     The #[objrs(class)] injects some static variables into the namespace that the #[objrs(impl)] macro later consumes. Unfortunately I have to use call_site to do this currently, which pollutes the user’s namespace. It would be nice if my macros could access a shared namespace that doesn’t pollute the user’s namespace.

*The names I’m using here are just placeholders.