Great! Yes, I suspected we could find a fix by slightly tweaking the example. So let’s look a this example a bit more:
macro_rules! foo(
($x:ident ; $e2:expr) => ...;
($e:expr ; $x:ident @ $e2:expr) => ...
);
For background, the original way I thought to do macro future proofing – which we moved away from – was to make it part of the parser semantics. Basically, to parse nonterminal like expr, we would first pull in all token trees up until we find something in the follow-set. So e.g. if we were applying the macro above to x ; x @ x, when we come to the expression, we would pull in the tokens x @ x. We would then parse those tokens as an expression and error out if any of them remain unconsumed (in this case, that’d be an error, because @ x is unconsumed). One problem with this strategy is that the errors occur on the macro use-sites, but in a way the flaw is with the definition of the macro. (I’m also wondering if it is somehow… “incomplete” in that there may still be inputs that would accepted but would change interpretation?)
Anyway, I was hoping to apply that intution I just described in the previous paragraph to the algorithm, but I admit I’m not 100% sure how to do that. I am doubly convinced we ought to measure the real-world impact of the more conservative strategy. =)