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 ?