Is there a reason we have binary functions instead...

# announcements

[Dominaezzz]

Is there a reason we have binary functions instead of operators? Like shr, shl, and and or instead of >>, <<, & and |?

[napperley]

Its a Kotlin language experiment gone wrong 😆 (possible theory is that the Kotlin language designers wanted to minimise the number of operators in the language) , just like Java's failed language experiment with checked exceptions.

[gildor]

it’s not a language experiment.
Yes, they tried to reduce amount of operators and do not spend time on implementation and support relatively rare used operators for common JVM code.
Also current implementation do not prevent adding binary operators in the future and allows to have very easy migration

[napperley]

Still ends up being confusing with using infix functions instead of operators for low level stuff like bit fiddling (graphics, embedded/serial etc) which is done on platforms beyond the JVM (native, JS etc).

[gildor]

Sure, bit fiddling is different story and was not part of original use case for Kotlin
And I think at some point Kotlin will have binary operators, especially when unsigned types will be there and native become more popular

[sksk]

it's one of the things i hate about kotlin, this and the lack of real multi dimension flat arrays, i hope it'll be corrected in the future

[gildor]

I just want to say that I can understand this decision, for example in our project (pretty big UI application, ~70% Kotlin) we have 1 shl, about dozen and and dozen of or

[sksk]

depends on the type of project of course, but when you have to use it, it's pretty nice to have regular operators

[Dominaezzz]

Don't you find the infix functions harder to read? I don't see any reason not to have the operators.

[gildor]

Again, as I understand, this decision was made not because infix functions are better, but because it’s just a library function as result require much less work to implement and support than set of new operators.
It’s not an experiment to “replace operators”, just a decision that allows to postpone some work and other decisions to future (like should this operators be overloadable, will not cause this overuse of them)

[Dominaezzz]

Oh I see. It's not that they explicitly left it out, they just have gotten around to it, since the functions already exist.

[napperley]

What makes this situation even more confusing is that the and and or infix functions could be confused with being like logical operators.

[Dominaezzz]

Then precedence becomes weird to think of.

[gildor]

Why is it weird?

[gildor]

Those function were implemented on early stage of Kotlin development at this time it sound like a reasonable decision, Kotlin Team always tries to avoid introducing new operators or other language features if it can be handled by existing language features.
Sometimes it make sense, sometimes they introduce language feature if it’s significantly better

[napperley]

Would have been ok, except some other major languages like python use and and or like logical operators which makes sense and is very distinct from bit operators. Very low chance that there would be confusion between bit and logical operators.

[gildor]

I agree, this is tradeoff. like Python and?

[napperley]

Ruby is one of the other languages.