The previous example had no chance of compiling in either form, due to the restrictive follow set for `ty`. This one has the desired behavior: http://is.gd/kYdw4g (well, I don't exactly desire this behavior at all, but it's true at least :p )
breaking existing macros.
The macro system does not deal with parse ambiguity at all. For example, the
breaking existing macros.
The macro system does not deal with parse ambiguity at all. For example, the
-grammar `$($t:ty)* $e:expr` will always fail to parse, because the parser would
-be forced to choose between parsing `$t` and parsing `$e`. Changing the
+grammar `$($i:ident)* $e:expr` will always fail to parse, because the parser would
+be forced to choose between parsing `$i` and parsing `$e`. Changing the
invocation syntax to put a distinctive token in front can solve the problem. In
invocation syntax to put a distinctive token in front can solve the problem. In
-this case, you can write `$(T $t:ty)* E $e:exp`.
+this case, you can write `$(I $i:ident)* E $e:expr`.
[item]: ../reference.html#items
[item]: ../reference.html#items