I’d suggest you to consider using if expression in Kotlin. This is pretty idiomatic:
return if (!response.isSuccessful()) "fail" else response.body().string()
It becomes slightly better if you flip it:
return if (response.isSuccessful()) response.body().string() else "fail"
And you if are actually designing your own Kotlin API for response object, then you can make body() return null when response is not successful, and the usage is going to be even better with Kotlin’s elvis operator:
If you happen to find yourself writing this kind of code often, then you can consider defining an extension function like this one for the corresponding Response class (whatever it is the actual class you are using):
fun Response.bodyOrNull(): Body? = if (isSuccessful()) body() else null
I think your idea (bodyOrNull) is only useful in some special cases. The purpose of ternary operator is for more general cases. The main advantage of using ternary operator is making code concise when the logic is short. This kind of logic happens very often in real life. Let’s compare these 2 versions:
val v = if (b) x else y // 23 chars
val v = b ? x : y // 17 chars (saved 6 chars = 26%)
result = if (response.isSuccessful()) response.body().string() else "fail" //74 chars
result = response.isSuccessful() ? response.body().string() : "fail" //68 chars (saved 6 chars = 8%)
IMO, saving 26% of time for typing in first case is really a good deal, plus the code in 2nd line is very clean and easier to read. For the later, we can only save 8% of time. If the expression is longer, it would be better to use if/else and separate into multiple lines to improve code readability.
I am really wonder why Kotlin doesn’t support this feature. The goal of Kotlin is to be better than Java, but in this case, it is not.
Of course, we must always check for other perspectives. Therefore I asked: “why Kotlin doesn’t support this feature?”
If the feature is only a good thing, does not prevent other features and used commonly, then it should be supported (or at least plan to do it if it is not yet so important).
In the case of “optional semicolons”, Kotlin has the right decision because it saves developers’ time and make them happy. Ternary operator will also do the same job.
I believe Kotlin lacks ternary conditional operator because it was impossible to get it into the grammar at the point the language was designed. For example, colon : was used to do static type assertion: val c = someList: Collection // now c is Collection<T>
That syntax was removed before 1.0, but I’m not sure is there any syntactical obstacles left for ternary conditional operator.
i think, the bigger any project will be, the more one will need to write if/else, and because of that, in a strategic point of view it looks like it would be better to add a ternary operator in the compiler
It’s highly debatable that the omission will actually cost you, if any, it may actually save you some costs. Multiple constructs of the same type can make code more difficult to read. The less characters argument is easily debunked: we would be writing the shortest class and function names possible if that would actually saves use money, which it doesn’t.
So all this cutting cost is just speculating, we need actual numbers and studies if this is going to be the argument for a conditional operator.
After a year of writing Kotlin code, I still start writing ? and catch myself when completions don’t work because the code makes no sense in Kotlin.
I have plenty of Kotlin if else expressions used but still prefer the elegance and aesthetics of the ternary operator, for short and shallow conditional expressions. I know and understand that the if in Kotlin and ? : are equivalent but that is not the point.
If else may be equivalent and only 4 characters longer but not as elegant for simple conditions and expressions.
It is definitely not an argument against Kotlin, which I find in general very elegant and highly productive, especially when compared to Java, but it is a minor nuisance.
For anything but short conditions and maybe one nesting level, I prefer the full if/else syntax which lends itself to better formatting to convey the logical structure.
It is not lack of Kotlin coding either, in my Markdown Navigator plugin Java and Kotlin code is about 50/50 with 60k lines of each. Kotlin being more terse, I would argue that I have more functionality implemented in Kotlin than Java.
I was hoping with time to get over ternary operator use but so far have not managed to kick the habit.