Re: Changing the operator precedence for concatenation and relational comparisons

[Halalaluyafail3 <luigighiron@...>]

I don't have any examples of using bitwise operators with
concatenation operators as I dislike implicit conversions even in the
case of implicit conversions to strings in concatenation. I think that
it is very surprising that "1"..2+3 works, but not "1"..2&3 or one of
the other bitwise operators. My reason for wanting to change the
precedence of concatenation to be below bitwise operators is to avoid
confusion around asymmetry with addition and multiplication operators.

On Tue, Oct 5, 2021 at 3:11 PM Flyer31 Test <flyer31@googlemail.com> wrote:
>
> 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.