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!

[pnkfelix]

triage: P-medium

[nixpulvis]

I agree, just bumped into this. box 1 + 2 feels like it really should be box(1 + 2). Another problem here is that things might be hidden issues, for example consider the following. It's because objects dereference for method resolution automatically, x and y could be either the same or different and the programmer might not notice at first.

let v = vec![1,2,3];
let x =  box v[0];
let y = (box v)[0];

[nikomatsakis]

triage: P-low

Decided to keep this open as the place to discuss precedence of box specifically, but not that it must be resolved before box is stabilized.

[nixpulvis]

@kjpgit I'm not sure I completely agree, although I do think Rust is airing in the side of too many levels now. As a programmer that primarily learned using Racket I'd love to throw parenthesis everywhere, but I really don't want to end up with a weird rule like you sometime need parens unless it's a box that is near other operators.

I've always thought that precedence should be a programmer problem solved by education. Personally I've always wanted to see what an editor aware of the grammar of a language could do in terms of alerting programmers to potential issues. A simple fix with an editor would be to show the implicit parens at like 50% opacity.

[steveklabnik]

Triage: IIRC, we're going back the drawing board again with the box syntax stuff. @pnkfelix ?

[nixpulvis]

If you're going back to the drawing board. What's wrong with box!(...)? Kinda like vec![...]. Just a thought.

[pnkfelix]

cc @rust-lang/wg-grammar : this remains an open question and it would be great to try to attack it. (It may well tie in with whatever syntax we adopt for await, for that matter...)