Some questions:

• Why do ExprTupField and ExprField have a Vec<P<Ty>>? They never take generic parameters... I think it would be better to remove it.
• Trying to pass type parameters to a tuple index gives a parse error which is unrelated to tuple indices. Does it make sense to have a compile-fail test expecting a specific error? This means that future unrelated changes to the parser would require the error message in this test to be updated.

@aochagavia Thanks for the PR! I think it would be nice if the error message was more targeted. For example see this PR: https://github.com/rust-lang/rust/pull/18879/files, which made an equivalent change to field expressions.

@aochagavia To answer your first question, yes, you're right, feel free to remove them. :)

@jakub- I have some questions regarding the error message. To get a more targeted one, there are two approaches I can think of:

• Try to parse type parameters: a big drawback of this approach is that if you type t.0::; you get strange errors, like expected '<', found ';'
• Try to parse only a '::'. In case of success, show an error like "unexpected token '::'" and a note saying "tuple indices may not have type parameters". I think this is the one to go...

I have implemented the second approach... But it is not a perfect solution and it can be confusing as well:

test.rs:5:23: 5:25 error: unexpected `::` after tuple index
test.rs:5     println!("{}", t.0::<Vec<uint>>)
                                ^~
test.rs:5:23: 5:25 note: tuple indices may not have type parameters
test.rs:5     println!("{}", t.0::<Vec<uint>>)
                                ^~
test.rs:5:34: 5:36 error: unexpected token: `<eof>`
test.rs:5     println!("{}", t.0::<Vec<uint>>)
                                           ^~

Do you have any ideas on how to produce a better error message?

By the way... Who would ever try to pass type parameters to tuple indexing? Do we really want to have a special case for this? It could make the error message even more confusing in most cases.

The only case in which this could make sense is when a generic function is saved in a tuple. However, rust requires the type parameters to be specified when the function is stored in the tuple, not when it is called. For example:

fn something<T>(e: T) { ... }

// This works
let tup = (something::<int>, 42i);
tup.0();

// This doesn't
let tup = (something, 42i);
           ^ unable to infer enough type information about `_`; type annotations required
tup.0()::<int>;
       ^ found `::` expecting `;` or `}`

@aochagavia Yeah, I think you're right! Feel free to push your current changes and I'm happy.

Done!

I have added the error message ;)