Re: Changing the operator precedence for concatenation and relational comparisons

[Flyer31 Test <flyer31@...>]

Hi,
can you give an example where it would make sense to somehow combine
string concat with bitwise operations?

(just curiosity I must admit... generally I think you will find for
nearly any precedence some problematic cases, but Lua really is quite
nice so far seen from my point as experienced c programmer ... in c
you have this crazy situation that bitwise operators do not even
precede the boolean && and ||, this even me as an (hopefully)
experienced programmer sometimes brings new white hairs... but c
development editors typically have very smart in-situ code checking
installed, which will warn you immediately that brackets would be
needed ... and of course in Lua you do NOT have such advanced
development editors, also somehow not so necessary / senseful of
course in case of an interpreter langunage like Lua...).

On Tue, Oct 5, 2021 at 5:43 AM Halalaluyafail3 <luigighiron@gmail.com> 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.