Negative Literals Improved¶
At the moment, NegativeLiterals
has the following issue, documented
in the User’s Guide:
One pitfall is that with
NegativeLiterals
,x-1
will be parsed asx
applied to the argument-1
, which is usually not what you want.x - 1
or evenx- 1
can be used instead for subtraction.
We propose to fix this.
Additionally, unboxed literals (e.g. -1#
) have the same issue even
without the NegativeLiterals
extension. We propose to fix this, too.
Motivation¶
Having
x-1
parsed asx (-1)
may violate users’ expectations. As evidence, see #18022.Fixing this infelicity would make
NegativeLiterals
a subset ofLexicalNegation
.
Proposed Change Specification¶
When lexing a negative literal, require that it is not preceded by a closing token. See #229 for the definition of a closing token.
Effect and Interactions¶
Code that relies on
x-1
being parsed asx (-1)
will break.Enabling
-XLexicalNegation -XNegativeLiterals
has the same effect as enabling-XLexicalNegation
alone; however, enabling-XNegativeLiterals
alone does not have the same effect, as it does not affect expressions such as-x
. In other words,NegativeLiterals
becomes a subset ofLexicalNegation
.
Costs and Drawbacks¶
Changing the behavior of an existing extension may not be the best practice.
Alternatives¶
Don’t change anything.
Deprecate
NegativeLiterals
in favor ofLexicalNegation
.
Unresolved Questions¶
None at the moment.
Implementation Plan¶
Implemented in Merge Request 3624.