Parser confuses double-borrowed &&type/&&expr with ANDAND token.

[bblum]

These two programs compile only if you put a space between the two ampersands:

fn main() {
    let _x: &&() = fail!();
}

fn main() {
    let _x = &&();
}

[bblum]

here's another good one. this parses:

fn main() {
    let _ = true &&& () as *() as bool;
}

this doesn't:

fn main() {
    let _ = true &&&& () as *&() as bool;
}

[nikomatsakis]

It should be straightforward enough to treat && in the type grammar or in unary operator position as two ampersands, though the use in a unary operator seems more theoretical than actual.

[sfackler]

I've had it come up in a practical context trying to cast a string literal to a trait object:

trait Foo {}

impl<'self> Foo for &'self str {}

...
let _ = & &"foo" as &Foo;

[huonw]

I've also had it come up with hash maps and strings: .find_equiv(& &"foo")

[emberian]

This is really annoying.

[thestinger]

The only mentioned use case is for string literals, and #10105 would get rid of that problem.

[nikomatsakis]

On Mon, Apr 07, 2014 at 11:07:23AM -0700, Corey Richardson wrote:

This is really annoying.

Yes, it is.

[gereeter]

I believe this is fixed by #13576 and should be closed.