macro pattern ($($arg:expr)*) should be illegal

[semenzato]

On rustc 1.21.0 it is legal to write a rule like

($($arg:expr)*) => { println!($($arg),*) }

but the manual does not allow space as a separator in an expr list:

https://doc.rust-lang.org/book/first-edition/macros.html#syntactic-requirements

which is reasonable because it leads to ambiguities (e.g. "a b -c" could be three expressions "a", "b", and "-c", or two, "a" and "b-c"). (If you're curious, the implementation picks the second choice in this case).

[ExpHP]

but the manual does not allow space as a separator in an expr list

Can you show more precisely what language in the link makes you say this? I don't see anything on limitations of lists.

The argument I find much more compelling is what you mentioned in the user's thread, that the following

macro_rules! foo {
    ($a:expr $b:expr) => {};
}

is forbidden.

---

because it leads to ambiguities

I fear much worse; that the way such invocations are parsed may even change as the grammar of expressions is extended. This would seem to defeat the whole purpose of the follow-set rules! (but of course! They've been entirely circumvented...)

[durka]

I think this may be the same as #44975.

[semenzato]

In response to ExpHP: It's in the last part of the "Syntactic Requirements" section, copied below.

There are additional rules regarding the next token after a metavariable:
expr and stmt variables may only be followed by one of: => , ;

Clearly allowing ($($arg:expr)*) breaks this rule.

Durka: yes, same problem, thank you for linking this.

Sorry if I am stating the obvious, but there's no good way of allowing space-separated expressions in this context. In addition to the "-" operator, there are function calls (is f (x) one or two expressions?), vectors (a [3]) and I don't know what else (my experience with Rust is about 4 days).

[cuviper]

I think calling this "space-separated" is a misnomer, because the same problem occurs without any spaces in the input at all, just depending on how the tokens are combined.

[semenzato]

Thanks, agree, "space-separated" is not good. It's more like "without a separator" or more precisely "without a separating token" since whitespace can separate tokens. In any case I don't think there's any confusion here.

[steveklabnik]

Triage: this text is no longer in the book; it seems like a warning was added. I'm gonna call this fixed. Please let me know if this is not the case!