Ternary operator


#62

But it leads to higher coginitive load, higher learning costs and more bugs.

how something like this

return (response.isSuccessful()) ? response.body().string() : "fail"

leads to higher cognitive load, higher learning costs and more bugs?


#63

Because it’s another way to do things and also it Kotlin, ? means nullable. Glancing at your code leads me to beliebe that response.isSuccessful() somehow returns a nullable value.


#64

i aint see it somehow returns a nullable value.
you mean “(response.isSuccessful()).?response.body().string()” or what?


#65

Higher cognitive load because the ternary operator is hard to read and because you have to recognize different patterns for the same thing (if/else vs. ?:).

Higher learning costs because you have to learn more language features.

More bugs because the ternary operator steals some cognitive capacity, because it will be abused for more complex expressions than a single ?:, and especially in Kotlin because the similarity with the null check operator.


#66

i wrote in C/C++, java, swift and i never felt “Higher cognitive load” when using ternary operator

ternary operator aint take much time to learn.
Looks like one tries to present ternary operator as the thing so hard to learn, or one tries to think of newcomers in Kotlin lang as not smart enough to learn ternary operator?)))

i aint mix up null-access
(variable)?.method()
with ternary operator
(variable) ? "true" : "false"
with elvis operator
(variable) ?: "false"


#67

Yes, it looks like

return (response.isSuccessful()) ?.response.body().string() : "fail"

and that doesn’t make sense. ? in Kotlin means something may be null.


#68

No, it’s not. More than one (obvious) way to do it leads to diversity without real advantages. But it leads to higher coginitive load, higher learning costs and more bugs.

You are right, it is not always a good thing. I didn’t express myself very good.

What I was referring to is conditional operator. It exists alongside if-else in many languages. Kotlin is new language and migration of developers is Kotlins goal. I think that conditional operator (in some form) would add to all efforts to achieve that goal. I don’t really see any downsides. Of course some rules must exist but if we start thinking what some developers can or cannot learn then we will face the wall very soon.


#69

The ternary operator is a workaround in languages that are conceptually too simple to have something that comes close to:

val result = if(success()) “foo” else “bar”

As Kotlin allows for that kind of code as in the sample above there is no need for the ternary operator workaround hack kludge as in languages like C/C++/Java that don’t provide the functionality that Kotlin does.

With the solution in Kotlin you don’t need to know anything about ternary operators. The sample Kotlin code in this reply is crystal clear and is immediately understandable by itself. This is how things are supposed to be.


#70

As has been said numerous times before: This is not a good argument to include it in Kotlin.

I do: Time that could be used to fix my unreliable builds and unusable IDE, would be wasted on a language extension that saves only 6 characters and that starts using the question mark for other purposes than handling null.

Kotlin is (going to be) an amazing ecosystem: great language (readable, flexible, and concise), JVM target, JavaScript target, native targets, multi-platform projects, coroutines, serialization, etc.

Unfortunately I have major usability issues (admittedly with experimental features) right now, and I would rather see them fixed than a superfluous language construct being introduced. Feature-rich and stable IDE and builds, and advanced features to help manage complex problems, are going to do more to help adoption than the addition of a specific expression.


#71

ternary operator is a short form of if/else and short form of ternary operator is elvis operator, isn’t it?

and with the solution in Kotlin i aint need to know anything about elvis operator, even if elvis operator exists in Kotlin?


#72

I disagree.


#73

If all the awesome features of Kotlin do not make up for not having a ternary operator, why don’t you switch to a language that does have this operator? There are alternatives for all Kotlin targets. Note that these lists are far from comprehensive:

  • JVM: Java and JRuby.
  • JavaScript: JavaScript and TypeScript.
  • Native: C, C++ and Swift.

#74

ternary operator is a short form of if/else and short form of ternary operator is elvis operator, isn’t it?

It is actually more than that. In some languages you can’t do:

val result = if(success()) “foo” else “bar”

You have to stick to something like this:

val result: String
if(success) {
result = “foo”
}
else {
result = “bar”
}

This is cumbersome and tedious. In order not to have to write that many lines of code the ternary operator was introduced. But in Kotlin the ternary operator is not needed as the language construct in Kotlin already is a one-liner:

val result = if(success()) “foo” else “bar”

The code above is not a speciality of Kotlin. Other languages have this as well such as Smalltalk and I think also Ruby. In those languages with the given language construct the ternary operator becomes redundant as replaced with a high-level solution.


#75

See my reply to @edgeone.


#76

if(success()) “foo” else “bar”
(success()) ? “foo” : “bar”
(success()) ?: “bar”


#77

Please put some effort in your communication. Most of us write elaborate responses to help the discussion further along, but what you posted above makes no sense at all.


#78

i mean, it would be better to simply compare visually, not semantically these 3 cases:
if(success()) “foo” else “bar”
(success()) ? “foo” : “bar”
(success()) ?: “bar”

in some simple situations, like the above, ternary operator is more appropriate, than if/else; and there are lots of such simple cases one faces when one writes some project;
i side with the point that it would be useful for users of Kotlin lang to add ternary operator, no matter why ternary operator appeared many times ago.


#79

Here is the Kotlin interpretation of the code above if the syntax of the second line would be available:

  • If success() (which returns Boolean) returns true, then use "foo", else use "bar".
  • If success() (which returns a nullable type) does not return null, then use "foo", else use "bar".
  • If success() (which (likely) returns String?) does not return null, then use its result, else use "bar".

And here is what you think the second line should mean:

  • If success() (which returns Boolean) returns true, then use "foo", else use "bar".

Do you see that with your interpretation, very similar syntax: ? <some value> : <some value> and ?: <some value>, has different semantics: control flow and null handling respectively? It is precisely this inconsistency that the language designers (and a lot of developers) do not want in the language.

Kotlin is not a copy of another language because that would be useless. The Kotlin designers have looked at lots of constructs from many languages, experimented with them, and finally chose the ones that resulted in what Kotlin is now. Is it perfect? No. Will it have what all developers are familiar with? No. Is it an awesome language with awesome (future) possibilities? Yes. Does it require you to study and change your mindset? Yes (like all languages do).

I don’t know which language you use the most, but I have been using Java for over 20 years now. Just the facts that I can write the same functionality in about half the code, and that I have to worry about possible NullPointerExceptions a whole lot less, makes Kotlin worthwhile for me. Even if it does not have one particular feature that I like very much.

You have to consider the same thing: Is a missing ternary operator more important than all the things I do get from Kotlin? If you do decide to stick with Kotlin because you value the other things you get from it more, please accept that the ternary operator (in the form that you propose) is very likely not going to be added. There is an issue: Support ternary conditional operator ‘foo ? a : b’ , for it, you can vote there, and hope for the best.


#81

I don’t think we really need a ternary operator in Kotlin, but if you really want one, just implement it.

fun main(args: Array<String>) {
	val boolean = true
	val result = boolean t 1 ?: 0
    println(result)
}

infix fun <T : Any> Boolean.t(value: T): T? = if(this) value else null

#82

Briljant, this must be added to the standard library. I am opening an issue now :wink: