Kotlin should have "and" and "or" keywords

I’ve just visited the Wikipedia page of the good, old Pascal programming language. And stumbled upon this piece of code what reminded me of Kotlin:

if i in [5..10] then ...

the similarity is obvious:

if (i in 5..1) {

And then I’ve seen this piece of beauty:

if (i > 4) and (i < 11) then ...

Since Kotlin cares about readability, I think an and keyword would be really nice in Kotlin!

if (i > 4 and i < 11) {

looks much better than

if (i > 4 && i < 11) {

And since Kotlin is somewhat more functional than C, it would be bad style to use a simple & (and side-effects in a condition) so that && is basically the only AND operator that makes sense, what could be and.

If we would have and we should have or, too.

What do you think?

3 Likes

‘and’ and ‘or’ are already used as bitwise operators (corresponding to ‘&’ and ‘|’ in Java) so it would be confusing IMO if they were used for short-circuiting logical operators as well.

I haven’t done any bit operations in Kotlin yet. Sad to hear that this beautiful operator is already in use for the not so common bit operations.

and and or are not operators, they are ordinary functions defined for some classes. Actually they are defined for Boolean type as well, so you can write

if ((1 == 2) and (3 == 4)) {

and it works as expected. What might not be expected is: operator precedence (usually and is of higher precedence, but in this case they are ordinary functions) and lazy evaluations (those functions obviously evaluate both parts).

1 Like

This looks nice. However that a function call is probably slower than &&. The difference shouldn’t be dramatic in most cases, but maybe in some.

You could make it an inline fun, which would effectively negate the small performance overhead of a function call.

1 Like

This by far doesn’t go far enough. If and is nicer than &&, then you should require

`if (i is_less_than 4 and i is_less_than 11) {``

by the same logic. Isn’t it all just about what we’re familiar with?

1 Like

Yes, AND OR and NOT should just be normal keywords. Instead of

if (!a && !(b || c)

You could simple write

if (not a and not (b or c))

which is much easier to read.

That’s not by the same logic, though - is_less_than is much harder to read than < IMO, because it takes more effort, and it looks verbose and unwieldy. This doesn’t happen with and and or.

Also, what do you mean it doesn’t go far enough? and and or keywords/functions are well-defined, the definition being a more readable replacement for && and ||, since it’s not immediately intuitive as and and or (especially for beginners). This is also contrasted with your < example, where people can easily tell that it means “less than”.

and and or are already used widely by DSLs via infix functions (see an example in Spring WebFlux Kotlin DSL), adding this to the language would be a breaking change. That alone is a blocking point to me.

2 Likes