Parser ambiguity with trait bounds and closure arguments

[alexcrichton]

When specifying a trait with a bound as a closure argument, there is currently a parser ambiguity:

trait Trait {}
fn foo(arg: |&Trait:Send|) {}

Is arg a closure that takes an argument of type Send, or does it take an argument of type &Trait:Send.

Nominating.

[pnkfelix]

Assigning 1.0, P-backcompat-lang.

[ben0x539]

There's no reason to allow patterns for parameters in that position (outside of consistency), is there?

[nikomatsakis]

This cropped up with extern fns. We chose to disallow patterns. Arguably we should do the same, but even then there is an ambiguity in a DST world, since |Trait:Send| would be a type. Perhaps the : syntax for bounded traits is just bad. Maybe we should use +, weird as it looks: |Trait+Send|, or else I personally like []: |Trait[Send]|.

[alexcrichton]

There is also now an ambiguity with procs: |proc:Send()|

[nikomatsakis]

proc is a keyword so I don't believe that is ambiguous, even if our parser treats keywords in a goofy way.

[pcwalton]

RFC #87.