Priority of unary - relative to **

[konovod]

What aspect of the language would you like to see improved?

Change operator precedence, so ** will have higher priority then unary - (and perhaps over other unary operators).

What are the reasons?

In most languages I've checked (Ruby, Python, Julia, Octave, VB6) -2**2 gives -4 (operation ** have higher priority than unary -). This is IMHO consistent with mathematical notation (-2² = 4). Excel (and VBScript\Google Sheets) returns 4 though, so there is no universal consensus.

Include practical examples to illustrate your points.

More complete list of languages (compiled from here and my own checks):

• -2 power 2 gives -4: Ada, AWK, Haskell, J, Julia, langur, Lua, Maple, Mathematica / Wolfram, ExtendedPascal, R, Raku, Ruby, Python, Octave/MATLAB, BASIC(most, but not all dialects), DLang, PHP, VB.NET
• -2 power 2 gives 4: ALGOL 68, F#, Factor, Nim, REXX, Crystal, VBScript/Excel, Smalltalk (but it hasn't unary operators actually)
• explicitly require parenthesis in -2**2: JavaScript

Optionally add one (or more) proposals to improve the current situation.

In Crystal, -2**2 gives 4, this is documented, but i wonder if there is any motivation behind this decision or just coincidence.
JavaScript approach looks appealing to me, but I'm not sure how it fits the rest of language.
Of course, changing it at this stage would be a breaking change for minimal profit, but i haven't found corresponding issue, so I think there should be one. If consensus is to keep current behavior, maybe this worth noting in a Differences from Ruby.

[asterite]

This was already discussed in the past: #9684

We made some changes back then so it's unlikely we'll make them again.

There's more discussion here: https://forum.crystal-lang.org/t/exponentiation-operator-has-unexpected-behaviour/2457

[asterite]

Or maybe it was a separate discussion. I think given that 1.0 is out this is unlikely to change.

[BlobCodes]

Or maybe it was a separate discussion. I think given that 1.0 is out this is unlikely to change.

AFAIK there were concerns about the parser complexity because number literals like -2 can't directly be converted to a token.

---

Until at least Crystal 2.0 (and probably even afterwards), this should stay as-is. Changing the operator precedence post-1.0 will introduce lots of subtle breaking changes, without any useful compiler messages.

[oprypin]

JavaScript's solution sounds great - always require parentheses. It is not subtle. To me it seems perfectly fitting for 2.0. And maybe even the parser can have a retroactive check in a way that doesn't harm the main path.

[straight-shoota]

A much more softer measure we can introduce without any hassel: The formatter could apply parenethesis for this.
That would clearly express associativity in the code.

[oprypin]

Both is best 🙂
They complement each other

[straight-shoota]

I'd like to avoid having the compiler spit out excessive warnings. There's not much point in adding warnings for anything the formatter would reformat.
So whether this should trigger a warning is debatable. The code is technically not ambiguous, the behaviour is clearly specified. So why should the compiler warn about anything?
Having the formatter change the code to a representation that avoids any potential misunderstanding is much better than printing warnings.