Modifier to opt-out of null safety

Language Design
1

Null safety is a nice feature, BUT it is annoying it is obligatory with no easy way to opt-out.

Let’s say I am ready to take the responsibility for variable initializing. Now I have to repeat !! all the time I am dealing with the variable, I would say it is quite annoying :frowning:

Apart from that it seems to be badly compatible with android when your objects are nuked at arbitrary time and you cannot gurantee proper initialization. I may be wrong here, I am not an android expert, but I have just created a hello world project from template in the recent Android studio and I see that code is scattered with fragments like:

     private var _binding: FragmentSlideshowBinding? = null

    // This property is only valid between onCreateView and
    // onDestroyView.
    private val binding get() = _binding!!

I believe, a special type modifier ‘?!’ could be introduced at language level to avoid these inconveniences. Something like:

   private var binding: FragmentSlideshowBinding?! = null

Then one could use varaible at his own risk:

   binding.doSomethng() //<-- Usual npe here as in 'good old times'
1 Like
2

lateinit Properties | Kotlin Documentation is exactly for that.

3

Not quite.

Lateinit modifler is not allowed on nullable types, so you cannot re-assign null to the variable.

image

1 Like
4

I’m quite sure lateinit covers all the Android quirks, which are mostly with class member initialization.

Aside from that I don’t see Kotlin adding a way to throw away null-safety which is one of the great improvements over Java.
Most likely your code can be written in a type-safe way without !! or other tricks.

6 Likes
5

I stronly disagree.

I like that Kotlin authors left a posibility to disable safety checks at programmer discretion. There is ‘!!’ operator and BTW this operator is widely uded in source code of Kotlin itself, which additionaly proves there is a real need for that.

What I am suggesting, is just a more elegant way of expressing this decision.

6

It look like you want to be able to declare platform types. Personally, each time I work with platform types, I encounter problems, or at least I lose a lot of time doing extra checks, so I really do not want any opt-out for null safety.

In practice, I’ve found that many times, !! can be restricted to a few places in my code, and that where it remains, it makes a good indicator of a code section to treat with care (because of complex lifecycles, or interop with another system that does not provide null-safety -SQL, REST API, Java, etc.-).

So, even when null-safety is “annoying”, I find it still better than the alternative : no null-safety check / enforcing that cause unexpected problems.

7 Likes
7

Yes, I think so too. I’ve been using Kotlin for years now and I can tell you that null-safety can be a bit of a pain in the beginning, if you are used to using nullables everywhere. But I really appreciate it now. NPE’s are easier to find and the code just becomes more predictable. I have to say though that I quite dislike the !! operator to afirm non-nullable types in the code and so I usually resort to requireNotNull for that. It just looks better. But at the same time I have only been professionally working on server-side Kotlin and so I can’t determine very well what are the problems using it in mobile development. And on that I can say something else and that is that the source code for the kotlin standard library and even for android isn’t the prettiest code ever, but that is one of the key points of creating a standard library any way. So that we don’t see the ugliest sides of programming, because that is covered up by such a great language like Kotlin.

2 Likes
8

hands off my null-safety :slightly_smiling_face:

2 Likes