Ternary operator


no matter if it would be added to kotlin or kotlin’s stdlib, i would use ternary operator in simple cases


+1 :wink:


? in Kotlin is about comparing with null. Ternary operator just doesn’t make sense. Most of languages use if as a statement, but with Kotlin if is an expression, so it’s good enough to replace ternary operators. Just few more characters and much more readable and unified code. I’m aware of coding standards which forbid ternary operator at all, because they often lead to confusing code. I would vote against ternary operator, it’s just a duplication of existing operator without any benefit.


I like your interpretation of (success()) ? “foo” : “bar”!!!, maybe open a new thread with it?
On the other hand, this would really create confusion for new programmers :wink:


I think there are too few use cases for this syntax. I cannot think of a situation where I needed it. I was just applying Kotlin think to the syntax.

Another way to achieve the same thing in Kotlin:

success()?.let { "foo" } ?: "bar"

Apparently Kotlin is already confusing, so a bit more confusion won’t hurt anymore :wink:


The ternary operator in Kotlin will soon reach the same state as generics in Go - it will become a forbidden word :wink: (and it should! :slight_smile: )


I think we will get two types of booleans, either the real boolean, or a boolean in the shape of an Any?, so the ternary operator could be used…


I wanted to opt out of this discussion but since you called me (twice) let me reply. I saw your reply to edgeone and it’s … well … it’s not an argument at all. “My way or the highway” usually is not.

We are talking here about improving Kotlin and as such ternary operator is a minor issue so your question “why don’t you switch to different language” is quite overreacting. We all come from different environments and it’s normal that we want to see some nice features from languages we used before. Some people consider that nice features, not to be so nice at all, as we saw here. But that is what’s forum for.

I said all I think about this case. Let me repeat: since Kotlin is new language and since there are things (like ternary operator) that exists in many languages. It would probably be wise to implement it. But I don’t make Kotlin - I just use it. So it’s not my call. I said all I have.
Have a nice day.


I felt the same way about your reply, and that is why I referred you to my earlier reply to edgeone.

I agree about the first part. But from the reactions of the proponents, it certainly does not look like a minor issue. If it was, then the response would have been: Oh okay, too bad, but let’s move on.

The most important reason for why I started asking people to switch to another language is that their expectations of Kotlin differed from what Kotlin is, and that instead of adapting themselves they want Kotlin to be changed.

So please continue with suggestions to make Kotlin a better language. But please also accept that it cannot be the perfect language for everybody, and that some things will always be different from other languages simply because Kotlin was designed with other goals in mind.


it means “you better go to switch to a language that does have this operator”

ternary operator makes kotlin a worst programming language?
ternary operator is more than 30 years old, and it, as short form of if/else, showed it’s usefulness; and this is the fact or not?


Have you read this thread? Yes, it would be redundant, and it would introduce inconsistencies in the meaning of the question mark.

Not in all cases. In languages where if is not an expression, it is not a short form but an entirely different construct. These languages benefit the most from the conditional operator.

True, it is useful for a lot of languages. How is that an argument for inclusion in all languages?

Please tell us where my arguments and those of others are wrong:

  • Is it true that different languages use the same symbol for different constructs, and different symbols for the same construct?
  • Is it true that the introduction of a construct from another language can make a language less consistent/more confusing/compile a lot slower/…? And is it true that any of the consequences can be a reason for not including the construct from the other language?
  • Is it true that all uses of the question mark in Kotlin are currently related to the handling of null?
  • Is it true that you can write the code that you need in Kotlin in a reasonably short notation now?

If I am wrong on any of these points, please explain me why.


show us, code examples, please, how it would introduce inconsistencies?

show, please, code examples of redundancy?

it aint argument, i asked

yes, they can

in what case?


there are other things, that can slower compilation


in kotlin there is so-called elvis operator(http://kotlinlang.org/docs/reference/null-safety.html#elvis-operator)
but, actually, if “elvis operator” in kotlin can be used only for null-checking, then it aint a true elvis operator

one can write code in any way


Again, I ask you if you have read this thread? If you use the Kotlin way of thinking instead of your current way of thinking, the use of the question mark for booleans is consistent: Ternary operator

Again, have you read this thread? You can already do what you need now: if (<some condition>) <some value> else <some other value>. Adding another notation for the exactly the same thing is normally called redundancy.

Well, what would happen if the s-expressions of (among others) Lisp was introduced in Kotlin? What should (x . y) mean in this case?

And your point is? A feature may never be refused because it make compilation times terribly long?

There is no rule that states that the same operator must mean the exact same thing in all languages. Language designers can choose to use the common meaning (for whatever reason), but there is no absolute requirement.

Anyway, it looks like the Wikipedia page needs to be updated, because Kotlin assigns a different meaning to that operator.

Of course, but can you write what you need in a short notation now?

If you have a common use case where it is impossible to write a solution for, or the solution is unreasonably long, there is a an opportunity to improve Kotlin. But the proposed improvements must fit in the current philosophy and semantics, and/or it must improve developer productivity significantly.


it is up to me what way of thinking i use, ok?

again, show us, please, code examples, how it would introduce inconsistencies

i could use ternary operator if it would be in kotlin

the topic is concrete: Ternary operator

my point is, if i have the option of using ternary operator or i aint have.

could you, please, be more specific: you mean ternary operator, or some things from Lisp, etc.?


Fine with me. But in my experience things work out better if I think in Java for Java programming tasks, in Kotlin for Kotlin programming tasks, in Bash for Bash programming tasks, etc.

I did and it looks like you are not willing to see it. What is it that you don’t understand about this inconsistency (if the ternary operator would be introduced with the semantics that you want)?

  • val a: String?: This object reference may contain a null.
  • a as? String: Cast the object reference to a String, but return null if it is not a String.
  • a?.b() : If the object reference is not null, invoke the function.
  • a ?: b: If the object reference is not null, return it. Otherwise return the result of the expression after the operator.
  • a ? b : c: If the boolean is true, return the result of the second expression, otherwise return the result of the third expression.

The first 4 items talk about object references and nulll. The last item talks about booleans. 1 out of 5 does not follow the pattern: inconsistency.

Again: Using the current language constructs you are neither prevented from implementing a conditional expression, nor do you have to write unreasonable amounts of code for it. This also answers your last question.

Unless you come up with new arguments and/or refute my arguments properly, this will be the last thing I have to say about this. I (and others) have put considerable effort in showing you why the ternary operator is not a good fit for Kotlin, but you seem unable or unwilling to understand, or unwilling to accept that Kotlin is missing a tiny feature that you like in other languages.


So, it’s time to summarize this discussion by abstracting over it. You just need to insert some of your favorite arguments instead of ... and enjoy the program running until the stack overflow delivers you :wink:

fun pro() {

fun contra() {


Just to be pedantic here the ? in Kotlin is associated with nullability, but not always comparing with null.

For example:

o as? Foo

replaces class cast exception with null value but isn’t really comparing to null


9 posts were split to a new topic: How to write boolean startDidePc = Math.random() >= 0.5; in Kotlin?


Indeed this is true! I guess I have just always extracted that sort of code into functions/methods. :slight_smile:


Please, just allow to type more shortly and habitually ?: instead of if(...) else.
Let’s see example

ViewCompat.setBackgroundTintList(editText, if (hasFocus) colorLineFocus else colorLine)
ViewCompat.setBackgroundTintList(editText, hasFocus ? colorLineFocus : colorLine)

Subjectevily, 2nd line is more readble for me. In 1st line I need visually to extract (detect) condition, and statements.
When it occurs in big block of code, it reads very uncomfortable.

I do not see any problem to implement this traditional syntax. It has exactly the same logic ?: and if-else.
So, whats problem?