Or `^` or `|`
# stdlib
s
Or
^
or
|
c
these are quite common in bitwise math in many popular languages, as Karel mentions, not in Kotlin, though 🙂
âž• 1
s
I mean I know they’re common features, but they’re still not terrible intuitive to read or parse imo. I don’t know about you but it’s really rare for me to be, say, setting bitwise flags or xor’ing any bytearrays. I always get a bit tripped up when I see a chain of
|=
operations
k
I like to do write AIs for games, frequently using bitboards: https://en.wikipedia.org/wiki/Bitboard. The absence of the operators in Kotlin is really frustrating!
g
Why do you need operator for this? Really curious, maybe you could share your use case here: https://github.com/Kotlin/KEEP/issues/142
m
Well, in Kotlin they were replaced with infix functions and I support it. They are used rarely and they are confusing. Often people confuse them with logical operations.
âž• 2
g
I agree with Marcin, but probably there are people with good use cases (like work with graphics etc, where you have a lot of work with bits), but every time when I see use cases everyone talks only about bit flags which is imo terrible example that can be solved in a much better way without operators
and probably just shows how limited usage of bitwise operations in high-level programming
c
bitwise operators maybe really welcome in embedded development if kotlin-native catches on.
g
Yes, I agree, I even support idea of bitwise operators, but I don't see people with good use cases (because I don't have them too) and this means or all those people are not interested by kotlin or it's just pretty rare casd
m
BDW one can write a plugin and introduce that operators for a special use-cases 😛
k
@gildor Well my use case is manipulating bits for bitboards (eg in writing chess and sudoku solvers). Operators are not required of course, the code just looks dumb in my opinion with all those
shl
and `inv`s.
Also "left" is just a bit harder to reason about than literally seeing an arrow
<<
. I don't see any downside to adding this feature, infix functions are just as abusable as operators.
g
Yes, sure, this is why suggest to provide some examples of code to this proposal and compare current syntax and operators