Supporting a `return if not null` operator

Language Design
1

A common pattern in functions is to if/return instead of if/else.
More specifically, it’s common to check whether a value is not null and return it:

if (value != null) { return value }

Or in a more Kotlin way:

value?.let {return it}

What about adding a return? operator which means return this value if it's not null, otherwise do nothing:

return? value

Seems shorter and more readable than the if/return or even the let way.

3 Likes
2

if is an expression, so you can do

return if (value != null) value else { 
    // compute a different value, or return a default
}
2 Likes
3

Close. In Kotlin you need to write this :wink:

return if (value != null) value else run { 
    // compute a different value
}
4

No you don’t: Kotlin Playground: Edit, Run, Share Kotlin Code Online

1 Like
5

You’re missing my point, if value is null I want my function to abort the return and continue execution, not return another value

6

Seems like the let way is pretty close to optimal. Doesn’t seem that common of a use case to merit a special language feature to me.

value?.let {return it}

Demo

2 Likes
7

You could use these arguments against a lot of syntax decisions in Kotlin (e.g the safe casting as? vs as).

As far as I understand Kotlin aims to be a concise language which helps you handle nullable types gracefuly, so “close to optimal” should not be the stopping point.

8

I really like this point and I agree the same argument should be applied to other Kotlin features such as the safe-cast operator :slight_smile:
The argument is that the cost of adding the feature is not worth the minor optimization gained (I especially love the minus 100 points rule)

I suspect it would be difficult to demonstrate enough use for a return? value operator as a shortcut for “if not null, return it” for a few reasons:

  • Too few use cases
  • Most use cases could be refactored (IMHO, maybe something cleaner with a return at the end?)
  • The current solutions are not problematic enough to warrant a change

Maybe enough use cases can be presented that are also poorly satisfied with the current methods to change this? Until then I’d suggest this feature isn’t a high priority.

2 Likes
9

FYI. There was a discussion about that here: https://youtrack.jetbrains.com/issue/KT-2046

10

I actually dig this syntax.
Saying something is close to being optimal can be said on java syntax as well from a java developer’s point of view. and still, Kotlin developers decided to change some parts of the java syntax to be more concise and clear.
The change seems pretty simple to understand as a new concept and can make this use case (as specific as it is) more concise and clear.
The let solution is the same as the if statement solution in a different form IMHO, this proposal looks far more in the “Kotlin” way.

11

I actually dislike all these tricks. If there is a branch, I want to see it right away, with a quick glance, without looking into detail. I don’t even like

if (value != null) return value

I’d rather have

if (value != null)
    return value

This way, the branch is clearly visible. As an additional bonus, I can put a breakpoint on the return line. And the code is so clean and readable so I see no reason at all to do anything about it. It reads as plain English: if value is not equal to null, return it.

12

That would be a really handy feature but wouldn’t it be the other way around since ? usually means that thing can be null?

13

its very simple you can use elvis operator
value?.let ?: return?.let ?: {any result that you want}

14

you can use elvis operator as much as you can its like a if else if else as log you want

15

I’m aware that there are other options to achieve this.
The return? one is just the most short and concise IMO.

16

You make like it or not, but implicit branches are already in Kotlin and used everywhere. Every ? character denotes an implicit branch. So it seems only logical to embrace it even more. I like return? suggestion and extending it to break?, continue? would not hurt either.

17

Fair enough. But is it consistent? Is it “return if not null” or “return if null“? How am I to remember that value ?: return means “return if null“ and that return? value means “return value if not null“? Makes no sense to me.

If we really need such a feature (and I’m not sure we do), then I’d rather have value.return as a synonym for return value and value?.return for the proposed feature. It’s more OOP-like and consistent with the ?. usage. Or make it value?.return() instead, but I don’t really like the idea of a flow control operator looking suspiciously like a function call.

And if anyone thinks that value?.return looks weird, think of a popular value ?: return idiom. You can even format it as value ?. return for further consistency. ?. stand for “if not null, then…” and ?: stands for “if it IS null, then…“. Makes perfect sense to me.

18

Maybe return! instead of return??

If I see a return? I’ll immediately assume it means return if null, even though it wouldn’t make much sense to check and return only if the value is null.