Precedence of `box` is possibly wrong

[nikomatsakis]

Now that box is a keyword, and not the ~ operator, I think it's precedence is wrong. It maintains the precedence of a symbolic unary operator but I think keyword unary operators should have lower precedence.

In practical terms, this means that I think:

box 3 + 4

should parse as

box (3+4)

and not

(box 3) + 4

Nominating.

[nikomatsakis]

cc @pnkfelix

[pnkfelix]

(subtask of #11779 ) ((well, sort of; depends on your definition of what "placement box" covers.))

[nikomatsakis]

Assigning this to @pnkfelix too.

[kjpgit]

It would be great if the language would require explicit () in cases like this, for us mortal programmers who have to read code. See this classic: http://lwn.net/Articles/382024/

[pnkfelix]

Possibly related: currently box e_1 as Box<Trait> parses as box (e_1 as Box<Trait>).

Considering the fallout likely to occur with #22181 (shown in prototype #22086), we probably want to instead parse box E as T as (box E) as T

[nikomatsakis]

@pnkfelix yes, this is making me change my mind. Even though my intution is that the precedence of box is too high, it feels like box foo as Box<Trait> really ought to parse...though now that we do implicit coercion I basically never type that anymore.

[pnkfelix]

still, could box parse with lower precedence than + but higher precedence than as ?

[nikomatsakis]

@pnkfelix I think this doesn't work because the precedence of as is higher than +. For example, this program compiles:

fn main() {
    println!("{}", 3_u32 + 4_u64 as u32);
}

(Note also that my intuition is based on some notion that box is a keyword and hence has lower precedence. The current status is also reasonable in that it is the same as other unary operators (pretty tight).)

I think the precedence right now is roughly:

1. suffix operators (x.foo, x[y], x.foo())
2. unary operators (box, &, !)
3. as
4. binary operators like *
5. binary operators like +

[pnkfelix]

box is unstable, so no longer 1.0.

But, I-needs-decision!