I constantly have to reference the official Java o...
# announcements
c
I constantly have to reference the official Java operator precedence and use a combination of the official playground and some form of Java playground to make sure I've actually got it right
🧵 2
e
infix precedence is easy: there's only one precedence.
which is different than every other language's bitwise operator precedence, so it's still a pain point... but it shouldn't be hard to figure out
c
yeah I've got it somewhat figured out, it's just frustrating in conversion
and especially since what I'm working on works with bitwise very often
and also, the JVM, JS and native code (mostly C, C++ and languages like that) all have proper bitwise operators, so why shouldn't Kotlin?
e
C-like precedence is bad too - they should have fixed it when they added logical operators but didn't... and so too many languages inherit that absurdity
c
I think the Java precedence makes more sense than the cursed infix precedence does
infix precedence just leads to a bracket abomination
n
I prefer to use parens in all these situations even when writing C++
it's too easy even for experienced people to make mistakes, or even for the reader to get confused. I also think it makes sense for Kotlin to save itself the language real estate of standardizing more operators.
e
the fact that all the infix functions also work as methods means you can get multiple levels of precedence without too many parentheses, e.g.
Copy code
a.and(b shl c) or d.and(e xor f)
but yeah honestly
Copy code
(a and (b shl c)) or (d and (e xor f))
is fine unless you're golfing
n
probably a view that would upset some people, but I'd be fine with a language that didn't fully define its precedence rules and simply made remaining cases an error, i.e. simply force people to use parens
👍🏿 1
e
not controversial in Lisp, no precedence and everything has to be parenthesized :)
🙂 1