default methods: parser rejects methods with underscore names for parameters

[pnkfelix]

trait Foo {
    fn m(&self, _:int) { }
}

fn main() { }

% rustc /tmp/foo.rs
/tmp/foo.rs:2:16: 2:17 error: expected type, found token UNDERSCORE
/tmp/foo.rs:2     fn m(&self, _:int) { }
                              ^

[pnkfelix]

part of #2794

[msullivan]

There is a related issue where it accepts unnamed arguments in the definition of a default method. (But then ICEs on them.)

The problem is that when parsing function declarations in traits, it uses the code for parsing arguments in function types. That is, allowing a name to be missing, not allowing patterns. This makes sense for required methods, but for provided ones, we would rather not allow a missing name, but allow full patterns. At least, that is my opinion.

How to actually handle this in the parser is problematic, though, since we can't know whether it is a default method definition until after the argument list has been parsed. We could perhaps allow both, and then have a check afterwards...

[nikomatsakis]

Normally we try to avoid having it be ambiguous whether something is a type, pattern, or expression (this is part of guaranteeing that the grammar is LL(1) or whatever our goal is). We may have to make fns in trait declarations require patterns.

[pnkfelix]

Yes, if we take this ticket to its natural limit, then we end up wanting to support arbitrary patterns in trait default methods, and thus hit the problem of arbitrary token look-ahead to find the colon that would allow us to distinguish whether we are looking at an pattern or at a type.

I think I would be weakly in favor of making fns in trait declarations require patterns. (but only weakly so. in the meantime, I'm going to try to fix this particular special case, especially since doing so would make a port towards the aforementioned requirement go more smoothly, since we could add all the _: prefixes mechanically before we flip the switch to require patterns in trait fn declarations.