When takeIf returns null, it shouldn’t be allow to get chained directly into any function without the ? check.

Why do you think this? What if you have a function you specifically want to call that takes a nullable receiver?

I think it could be done through Elvis expression. I think anything that could return a null or nonNull, should only follow by

?.

he is complaining about the wrong problem

Maybe

wouldn't solve the problem. The root issue here is that

apply

can take a nullable receiver, and you need to watch out for it.

what if you want to treat the null?

Then you do, thus

.apply

can take a nullable receiver. If you don't want to, you specify

?.apply

. In this case

Maybe

has no benefit over a nullable type.

generic functions should all avoid returning

null

, otherwise it cause problems with nullable tupes

No they shouldn't, that's the point of having nullability be part of the type system.

maybe has the benefit of knowing whether the value was null or it takeIf clause failed

That doesn't make sense. By definition takeIf returns null if it fails. If you want to have more control, you use type safe operators like

?.takeIf

It's

takeIf

definitation that I'm contesting

Ah, I think I see what your trying to say. I still disagree, but I at least see where your coming from.

maybe I'm looking at this wrong, I'm still getting started with Kotlin

It's important to remember that Kotlin isn't a functional language, it just has some functional constructs.

i'm reading more stuff and

?

seems to work like a monad maybe, I need more reading and proof. then for that example in the linked article, shouldn't the

doThis()

method have the type

object?

?

Actually this is not a problem of

?.

operator at all, it’s wrong usage of

takeIf

function in this article. Because looks like

doThis

is just a function or method in context. You never should use takeIf like that. Take if make sense if you want to use someObject itself (pass it somewhere or call method) it’s not a replacement for general if condition

I guess what's interesting to me, and I didn't know before, after reading this is that it's possible to use

apply

on a variable that's

null

, unless you try to access the variable in the passed lambda in a non-

null

fashion.. even though

apply

is defined on

T

instead of

T?

T

means that type can be nullalbe or non-nullable. If you want to define generic that allows only non-nullable types you should define it as

T : Any

good to know, thanks!

so apply that works only with non-nullable types will look like:

public inline fun <T : Any> T.nonNullApply(block: T.() -> Unit): T {
    block()
    return this
}

Thanks for the info guys!

I agree it's a bad use of

takeIf

and

apply

. The author claims the new block is somehow an improvement, but if you ask me it's way less readable than

if (someObject != null && status) doThis()

Using different syntax is only an improvement if it actually improves.