"-NUM.method()" is parsed in surprising ways

[RalfJung]

This came up here but I am pretty sure I ran into this before: Rust parses -5.5f32.method() as -(5.5f32.method()). I don't know if that is the parsing result that anyone expects, I certainly would never expect it -5.5f32 is a float literals, and that is what I want to apply the method to, I never even considered that the compiler might interpret this as a unary minus applied to the method result.

Assuming that we cannot change the parser, I think we should spend some effort defending against the possible confusion here. For instance:

• lint against -5.5f32.method() (suggesting to write -(5.5f32.method()) if that's really what one meant)
• have rustfmt add the parentheses that make precedence explicit

[jhorstmann]

This also made me question my sanity some time ago, a lint would have been very helpful. The code in question was

assert_eq!(1_i32, -1_i32.rem_euclid(12)) // should be (-i_i32)

[clarfonthey]

I would personally be very surprised if -x.method() and -1.method() parsed differently, and it feels proper to me that -(x.method()) would be the way it's parsed.

This matches similar precedence rules in maths, like how -2^x is -(2^x).

Another good test is if adding 0 to the beginning would change the result: 0-x.method() shouldn't parse as (0-x).method(), so why should -x.method() be different?

[RalfJung]

In math I would insist on parentheses since -2^x looks ambiguous.

Another good test is if adding 0 to the beginning would change the result:

That's not at all how think about negative integer literals. -2 is just the mathematical integer negative-two, and having -2.method() split up the literal is totally unexpected.

It's great that your intuition aligns with the current parser, but that doesn't mean that everybody's intuition aligns with the parser. I literally thought the gamma_ln function had a bug (see the comment linked in the OP); it didn't even occur to me that the Rust parser could dis-associate the - from my integer literal -- that possibility was so outlandish it didn't enter my mind. So clearly this is ambiguous, and the right thing to do is add parentheses.

[chfogelman]

I too would be very surprised if it was not parsed the way it currently is. If -5.method() were parsed as (-5).method(), then how would we expect - 5.method() to be parsed? You either end up having very unintuitive behavior, where - 5.method() is parsed as (-5).method(), or you end up in a situation where whitespace affects the way an expression is parsed.

To my knowledge, every language with both unary minus and a . operator does exactly what Rust currently does here.

I also don't think it's fair to say that the compiler is disassociating the - from the literal. The lexer has always treated - as a separate token from whatever follows it.

[RalfJung]

It doesn't matter what the lexer does internally. For many humans reading and writing code, "-5" is an atom that cannot be split meaningfully. If the lexer doesn't work like that then it is up to us to minimize the fallout and confusion stemming from that decision. This is true even if the alternative parsing would be just as surprising in other contexts. Thay just means we should steer the user towards code that is unambiguous.

[chfogelman]

Even ignoring what the lexer does, my point is that for many other humans, especially those who work in mathematics or computing, -5 is a sequence of two atoms that obey standard operator precedence and just happen not to have a space between them. For those of us in that group, anything other than the current behavior would be confusing. I don't necessarily disagree that it can create confusion, though I do think that changing the parser would have been a step too far.

As a side note, rustfmt currently reformats let _ = - 5.method() to let _ = -5.method(). Should this be another angle by which we can reduce confusion?

[Ghabriel]

The way it's currently being parsed feels very natural and correct to me as well. It not only matches similar rules in math as pointed out earlier but is also how it works in every language that allows an equivalent syntax. Adding extra parentheses in situations like this would just feel like visual noise to me, personally.

[clarfonthey]

Note that there are cases where a negative literal is treated as a fused literal, in particular in cases with the literal macro matcher. In these cases, it was weird that 1.0 would be accepted but not -1.0, which makes sense from a syntax perspective but not from a user perspective.

I don't really think that any of the proposed suggestions for negation really work well, though. Adding an extra space looks like a typo, and adding extra parentheses also makes rewriting code more obnoxious since it's a non-local change (adding a negative sign requires adding a closing parenthesis at the end of the expression).

Even though the precedence rules are well-motivated, parentheses exist regardless and Rust even has lints that encourage using them even in unambiguous situations, like converting x && y || z to (x && y) || z.

So, I do think that at minimum there could be an allow-by-default lint suggesting one or more of these methods, and/or style rules for rustfmt.