You have to for resilient macro_rules! macros as well, because item names are resolved at the call site. Example:
macro_rules! m {
() => {Vec::<u8>::new()};
}
mod ok {
fn f() {
m!();
}
}
mod nok {
type Vec = u8;
fn f() {
m!(); // ~ Error: no function or associated item named `new` found for type `u8`
}
}
This is not a great argument. Someone still has to write the macro, and that someone has to maintain the code the macro outputs. It's much easier to do so the less namespace noise that is present.
A "perfect"ly implemented macro_rules! macro that wanted to use the std's Vec would use $crate::_reexports::alloc::vec::Vec. A more prepared one night use $crate::_reexports::Vec, if they make their hidden _reexports module directly reƫxport the types they are using.
A less paranoid macro would just use ::alloc::vec::Vec, or maybe ::std::vec::Vec. (If you're using std, there's no reason for your downstream to be #![no_std], and renaming not-std to be used at ::std is just asking for things to not work.)
The "proper" solution for the macro (decl or proc) is full def-site hygeine for all items, not just local bindings ("macros 2.0"). But reƫxporting items at their shortest reasonable path would be an improvement for macros in the short term, where full hygeine is decidedly long-term.
