`if foo {}.bar()` parses successfully, but `if foo {} + bar` and `foo! {}.bar()` do not

[ftxqxd]

It seems a tiny bit inconsistent that if foo {}.bar() parses successfully, but if foo {} + bar does not, given that . and + are both binary operators. The former isn’t ambiguous (whereas the latter would be if we got a unary + operator), but I still think that it’d be best to either be consistent with + and reject it, or at least adjust macro invocations with curly braces to accept .s afterwards as well.

[steveklabnik]

Runnable:

fn main() {
    // if foo {}.bar()
    // if foo {} + bar
}

uncommenting either gives

hello.rs:2:8: 2:11 error: unresolved name `foo` [E0425]
hello.rs:2     if foo {}.bar()
                  ^~~
hello.rs:2:8: 2:11 help: run `rustc --explain E0425` to see a detailed explanation
error: aborting due to previous error

shell returned 101

Press ENTER or type command to continue
hello.rs:3:15: 3:16 error: unexpected token: `+`
hello.rs:3     if foo {} + bar
                         ^~

[nikomatsakis]

There is a distinction between . and +: + is an operator in that it takes two expressions on either side. . is not an operator, it is in fact part of a couple of kinds of suffix expressions (field accessors, method calls). We chose to allow suffix expressions precisely because the . component isn't used as a unary operator.

Moreover, code like this is both legal now and reasonable:

if foo { bar } else { baz }.debug_print();

so I don't really think we ought to be changing this.

That said, the fact that a macro invocation is treated as an item is somewhat inconsistent but probably for the best. I think we could make foo! { }.bar() work in a backwards compatible way.

[nikomatsakis]

triage: P-medium

[nikomatsakis]

triage: P-low

(patch welcome, don't plan to fix it in near term)

[pnkfelix]

Just to be clear to future readers: a strong reason for why we treat the addition operator + the way we do is by analogy with the minus operator -, where - could be either unary minus or binary minus, and thus one needs to resolve how to parse if foo { 3 } else { 4 } - foo (at least in statement/item context; there's no ambiguity about how to parse the latter if it is forced to be expression context, such as right after (, i.e. an open parenthesis)

[Mark-Simulacrum]

The first example is fixed (i.e., if foo {}.bar() parses and runs fine), but the second isn't. I think the discussion came to the conclusion that we don't want to fix this, though. Can someone confirm that?

[nikomatsakis]

I'm personally happy with the current behavior, I think.

[nikomatsakis]

I think I will close; I don't really see that there is anything to fix here.