An aside: when I wrote an input scanner inspired by the macro_rules! syntax, and I had a related problem. Instead of escaping, I allowed the separator to be a sub-pattern. Specifically, I represented sub-patterns as paren'ed groups. I don't know enough about the macro_rules! internals to say whether or not full sub-patterns would even be feasible, but if they are, they do solve the problem more generally.

@DanielKeep Added as alternative. The only concern was I thought $($x)(+)+ would expand to A (+) B (+) C 😄

BTW the current macro_rules parser seems to try to expand $($x)(+)+ to A ( B ( C ) + 😒

@kennytm Really? Maybe matchers shouldn't be allowed as separators... :P

cc @kmcallister

This is a fairly minor change and seems like a good thing, however, it is not high enough priority to work on before 1.0. Since macros are likely to be thoroughly revamped in the near future, backwards incompatibility is not a risk. Therefore, this RFC is being postponed (tracked in issue #991).

However, if @kmcallister or anyone else is motivated to implement this before 1.0, then we'd be happy to re-open this RFC for a (hopefully short) discussion and land the implementation.

I agree with @nrc except that I do think backwards compatibility is a concern. In my mind, crate/item hygiene is the top priority for the revamped macro system. That'll require a lot of architectural changes within the compiler, so it's not something I expect to happen very soon.

Even after the new macro system is available, existing projects may choose to stick with macro_rules! until it's removed in Rust 2.0.

In that spirit I'd like to see a version of this RFC which addresses just the changes we need now to add this feature backwards-compatibly in the future. I don't have time to work on this issue but I'd be happy to review the RFC and code.