 |
lua-l archive |
|
|
||
|
On 05/10/2021 05:35, Halalaluyafail3 wrote:
Currently the concatenation operator has higher precedence than the binary bitwise operators (<< >> & | ~). This is very unexpected, since the addition and multiplication operators have higher precedence than the concatenation operator. It'd make more sense and be more consistent if the precedence of the concatenation operator was below the bitwise operators. Lua 5.4 removed support for implicit conversions with strings as arguments to bitwise operators, so string concatenation as an operand of a bitwise operator will now error. Code which overloads the concatenation or bitwise operators and uses them such that changing the precedence will alter their behavior is likely very rare. Another useful change to the operator precedence is making relational comparisons (< > <= >=) have higher precedence than equality comparisons (== ~=). This would be less impactful than changing concatenation precedence, but would be beneficial in a few cases. An example would be a<0 == b<0 to see if both are negative or both are nonnegative, which I have done a few times before. This shouldn't be a breaking change, except for the very odd case of doing an equality comparison on the left side of a relational comparison, and overloading relation comparison with a boolean on the left hand side. Even if this is seldom beneficial, I think that this change is still worthwhile. I think that these changes would make the language better, and should have minimal incompatibility issues.
What's the problem you are trying to solve here? All operator-rich languages have their own quirks for operators precedence. Lua is not different in this respect. Any change now will only change those quirks to other quirks.
Having programmed in so many languages (more than 30 for sure, from pro-level to absolute newbie with a week's worth experience) in the past ~40yrs, I have absolutely no strong feelings about that aspect of programming.
As a defensive programming approach, I almost always don't rely on precedence rules except for arithmetic +,-,*, / operators (which are almost universal). I write my expressions as short as reasonably possible without impacting readability, using extra temporary vars for intermediate results. And I use lots of extra parentheses, just in case.
If, like many programmers, you end up using many different languages in your job, it's too risky to try and memorize every precedence for every language, IMHO. Moreover, even if *you* can memorize them (*I* can't, and I don't even try), chances are that the next developer that has to maintain your code will get them wrong once in a while, causing nightmarish debugging sessions.
I vividly remember a case (~4yrs ago) where a colleague was adapting some code found on the Internet for an Arduino board controlling a small robot-car. He spent almost an afternoon trying to understand why some commands sent via an app and bluetooth didn't work the way he intended. He asked me for some help and when I saw his mods I saw some complex conditions in an if-else chain. It felt smelly. I didn't recognize an error rightaway, but I simply told him to add explicit parentheses around any subexpressions in those conditions the way he meant them to be parsed. Problem gone. I didn't even try to analyze where the exact bug was. He simply got some C++ operator precedence wrong. Who cares which.
In my book, operator precedence "misunderstandings" between programmers/programming languages is one of the most common logic error among the "stupid ones" (i.e. those not due to a misunderstanding of a complicated algorithm).
Bottom line: don't change the language, change the way you write your expressions.
Cheers! --Lorenzo