Suggestion: Better Nullability in functions

[joffrey.bion]

@dmstocking

My main concern is from a readability standpoint. The problem I have with it is that it changes when something could or couldn’t be called. So I have to read all the arguments to see if a function is called.

Couldn’t agree more about this. I believe it could enable people to write really messy code.

@Wasabi375

That being said I try to structure my program in a way that I don’t use nullable types wherever possible, most nullable types deal with 3rd party libraries and are handled early.

Same here, that’s why I don’t think this feature has much value to me, even ignoring the syntax for now.

@H4xX0r1337

But luckily there is the ?: return operator. So the following code works fine, BUT if i change any of those 4 values to null, main would return and not continue at all.

In fact, most of the time, functions/methods should be short enough to benefit from ?: return without a need for this feature. This feature is like returning from a local block, but without explicitly defining that block. Writing functions is an easy way to work around your problem by explicitly defining the block from which you return, and it has the positive side effect of forcing you to name it.

Coming back to your code, this does what you want, and I personally find it better than anything else proposed so far (at least in a real use case, applying this would be better IMO):

var v1 = 5 as Int?
var v2 = 4 as Int?
var v3 = 6 as Int?
var v4 = 1 as Int?

fun main() {
    maybePrintMax()
    maybePrintMin()
}

fun maybePrintMax() {
    println(maxOf(v1 ?: return, v2 ?: return))
}

fun maybePrintMin() {
    println(minOf(v3 ?: return, v4 ?: return))
}

@H4xX0r1337

I usually do not need this for the same function twice. If I would need it multiple times, then this would properly be the best workaround.

Writing functions is not only intended to share code between 2 or more places.
You can actually extract functions simply to conveniently define self-documented blocks by using nice names. And this is a perfect use case for it.

I like the fact that Kotlin allows to write most common patterns very simply. Usually, when something is hard to write, the code could be rewritten at a larger scale to avoid a specific local problem.

The only exception I have found to this so far (among my own common use cases) is a collection property that should be exposed as read-only but is internally mutable.
More generally, we can’t express a property with a different private and public type. We have to go through 2 properties (it’s not that much work, but it’s not what the programmer means).

[gidds]

@joffrey.bion

I like the fact that Kotlin allows to write most common patterns very simply.

Me too. But skipping a function call when one of its parameters would be null is not a pattern I can ever recall needing. (In fact, I might even consider it a code smell…)

For sheer readability, I think the fact that a call might not happen is better off up front where it’s more obvious. (Admittedly, the … ?: return construction suffers from the same problem, but is much more obvious and explicit.)

As you say, such a feature could easily lead to messy code and very subtle bugs.

[H4xX0r1337]

@joffrey.bion

My main concern is from a readability standpoint. The problem I have with it is that it changes when something could or couldn’t be called. So I have to read all the arguments to see if a function is called.

Couldn’t agree more about this. I believe it could enable people to write really messy code.

People will always find a way to write bad code. But it would also reduce boilerplate kotlin code (especially for android development). I really like kotlin and how it can reduce code, but this is one just of it’s few flaws (other flaws for me: No multi exception catch, no multi use)

@joffrey.bion

That being said I try to structure my program in a way that I don’t use nullable types wherever possible, most nullable types deal with 3rd party libraries and are handled early.

Same here, that’s why I don’t think this feature has much value to me, even ignoring the syntax for now.

It might depend, for which things you are using kotlin. I often stumble over those cases and I am quite annoyed, because there is no way to handle this right. Nulls are quite useful in some some cases.

@joffrey.bion

In fact, most of the time, functions/methods should be short enough to benefit from ?: return without a need for this feature. This feature is like returning from a local block, but without explicitly defining that block. Writing functions is an easy way to work around your problem by explicitly defining the block from which you return, and it has the positive side effect of forcing you to name it.

Coming back to your code, this does what you want, and I personally find it better than anything else proposed so far (at least in a real use case, applying this would be better IMO):

Wut? I’ve been that verbose with java. I would only use that code once, and the next time I need something like that, it is for another purpose. That is just too much code and too much effort. That would defeat the entire reason to use kotlin for me. It’s just not right.

@joffrey.bion

Writing functions is not only intended to share code between 2 or more places.
You can actually extract functions simply to conveniently define safe-documented blocks by using nice names. And this is a perfect use case for it.

That’s right, but the function already exists, and the extra method would just be an if with the method. Plus all of the documentation hassle.

Don’t get me wrong, if I seem a little bit rude, but I am just frustrated.

[H4xX0r1337]

Code smell. Really?

class X {
    var number = 0
    var string = "Test"
        
    fun main() {
        // Imitate fetching
        onResult(1337, null)
        onResult(null, "0123")
    }
    
    // Processes a result of a method fetching a number and a string. It might fail to get one.
    fun onResult(number: Int?, string: String?) {
        // Then how about this boilerplate code? Add some extra parameters and you are in a copy paste mess.
        if(number != null) {
            this.number = number
        }
        if(string != null) {
            this.string = string
        }
        
        // This seems a lot nicer, doesn't it? (maybe still not perfect, but still)
        this.number = number ?: abort
        this.string = string ?: abort
    }
}

[arocnies]

If I understand correctly, the problem is that the following method for checking multiple nullable values are not null is not very readable when there’s a large number of variables to check:

if (v1 != null && v2 != null && v3 != null && v4 != null && v5 != null && v6 != null) {
    // All values aren't null and smart cast to non-nullable.
}

IMHO I am not in favor of a keyword (or some other syntax) for aborting a call since I think the feature falls for the xy problem.

I see the use case as checking a large number of variables (and maybe capturing vars) and enabling smart casting, which is valid. I suspect the use case is also rare in most code.

---

There may be other solutions that could be proposed? Maybe a request for some advanced Kotlin contracts feature?

As mentioned, there’s already a few options that help a bit. For example, you could do something like the following using the standard library (or some cleaner looking function that performed basically the same logic)

if (listOf(v1, v2, v3, v4, v5, v6).none { it == null }) {
    // do something
}

Or

if (listOf(v1, v2, v3, v4, v5, v6).any { it == null }) return

These may not solve the problem to the degree you were hoping (e.g. variables won’t be smart cast to non-nullable) but I’m not yet convinced a method of aborting a call would be the best solution.

[dmstocking]

I will admit I originally came from an Android background and the Android team really produces some of the most insane APIs littered with horrible interfaces for the caller. I get why this is desired. I just don’t know if it really fits Kotlin as a whole. Granted, Kotlin runs on Android, but that doesn’t make Kotlin Android’s language. Realm, the language I referenced earlier that has this feature, is basically trying to make a smoother version of OCaml, so javascript interop is better. It basically married itself to javascript. But Java as a whole doesn’t have all of Android API problems. I solved this the way a lot of functional languages do with zip. I don’t know if the new syntax is really is that much better. Maybe with contracts and stuff you could try to make a better zip so that you wouldn’t need the extra parameters. If you could pull that off then I wouldn’t think any of this is necessary.