null safety : if I `require(foo != null)` then aft...

# announcements

[TwoClocks]

null safety : if I require(foo != null) then after that the compiles knows foo can't be null. But if I assertTrue( foo != null) I have to use foo?. or foo!!. there after. why is that? Both require and assertTrue throw exceptions... why can't the compiler figure it for one and not the other? Or is it just a hard-coded list of functions someplace?

[Russ Tennant]

https://kotlinlang.org/docs/reference/whatsnew13.html#contracts

[TwoClocks]

interesting. didn't know about those. thanks.

[TwoClocks]

but why wouldn't kotlin test libraries not implement them?

[Russ Tennant]

I don’t know the answer to that.

[nanodeath]

p.s. use requireNotNull (or checkNotNull)

[TwoClocks]

@nanodeath besides the obvious of being more expressive of what is actually happening, is there another reason? I'll use just for that (thank, btw), but curious if there is more to learn.

[ephemient]

custom contracts are still experimental - meaning that libraries using them may not work in future versions of Kotlin

[TwoClocks]

but this feature has been in kotlin a while. before contracts I assume. (or just custom contracts?). How did it work before?

[nanodeath]

contracts were used internally before they were made available externally. I imagine it's compiler magic ("intrinstics"). I mean if you say require(foo != null), all the contract can really say is that require(true/false) should throw or not throw. but if you say requireNotNull(foo), it can actually attach metadata to the foo more directly, such as it not being null

[ephemient]

checkNotNull() and requireNotNull() also return the non-null item, so it can be used in chains. similar to !! but with better messaging