Really silly question, based completely on prefere...

# getting-started

[Alfonso Ristorato]

Really silly question, based completely on preference 🙂
I like to use takeIf a lot, and yes, there are other ways to do the below, but please bear with me 🙂

val printlnFn = println("hey")
printlnFn.takeIf { false }?.let { println("true") } ?: println("false")

The output of this will be hey false , and that is fair, but is there a lazy version of takeIf (no there is not, but any recommendation will be helpful) that will allow to call the fn only if the predicate of takeIf satifies?

[Alfonso Ristorato]

val printlnFn = { println("hey") }
printlnFn.takeIf { false }?.invoke() ?: println("false")

could work, but still I wonder if there's better 🙂

[Rob Elliot]

I think I'd need a more realistic example of what it is you're trying to achieve to be able to suggest anything

[Alfonso Ristorato]

sure, let's say you have a method, that makes a very expensive call, and in production you want to call it, but in test you don't want (because reasons).
You can do a very simple if/else, you can do a when and this is fine, but if you use takeIf on the method, the method will be called and then either discarded or not according to the predicate within takeIf, I was just wondering if people have ever had a need for a lazy takeIf
Clearer example:

val perEnvCondition = false
fun veryExpensiveCall() = println("I spend a long time")
veryExpensiveCall().takeIf { perEnvCondition } ?: println("I do nothing")

[Rob Elliot]

The bit I'm not understanding is why takeIf would ever be preferable to an if statement or a when statement

[Alfonso Ristorato]

it wouldn't 🙂 it's just preference (I tried to highlight in the main thread that this is completely silly and based on me being stubborn with APIs)

[Rob Elliot]

Untitled.cpp

Untitled.cpp

[Rob Elliot]

But it looks like something that's just going to confuse people to me

[hfhbd]

If you only want to run side effects, you can do something like:

debug { myFunc() }

[hfhbd]

But for results or more complex calls, I would really recommend if/when. Don't fight the language

[Alfonso Ristorato]

thanks, that's nice 🙂 yeah, no doubt this is controversial, I just wanted to know if there was a kotlin API to do this

[CLOVIS]

My personal preference: only use .takeIf if you want to reduce the scope of acceptable values from the previous call.

For example,

someString.indexOf('c').takeIf { it >= 0 }

is ok because it exists to remove negative integers from the domain space.

In all other situations, I avoid takeIf & similar.

(notice that all examples in the documentation follow this pattern)

[hfhbd]

BTW the invokeIf from Rob will not work for a function that returns a nullable value, or more specific, the tenary operator ?: should not be used for this kind of code.

[Rob Elliot]

Fair, I've edited it to make it safe

[hfhbd]

Yeah, but the usage of the teary operator won't work if the function needs to return a nullable value.

[Rob Elliot]

Yup, but at least you won't accidentally call both.

But yes, this is obviously safer and easier to understand:

if (perEnvCondition) {
    veryExpensiveCall()
  } else {
    println("I do nothing")
  }

[CLOVIS]

Yeah. These are all situations where a simple

const val perEnvCondition = true

inline fun debug(block: () -> Unit) {
    if (perEnvCondition)
        block()
}

is much simpler.

Usage:

fun main() {
    debug { veryExpensiveCall() }
    // …
}

This kind of utilities is idiomatic and is common in logging libraries.

[Alfonso Ristorato]

I did not want to start a very big debate 🙂 I was just curious to see other people experience and if this was ever something that someone else would have ever wanted

[Alfonso Ristorato]

I will stick with better operators in non side projects 🙂

[Youssef Shoaib [MOD]]

There is a version of this that I've seen people use (if memory serves, even in Kotlin compiler code): letIf, which is a conditional let
For your case, I'd define an onlyIf like so:

inline fun <T: Any> letIf(condition: Boolean, block: () -> T): T? {
  contract {
    condition holdsIn block
    returnsNotNull() implies condition
    returns(null) implies !condition
    // I have a gripe with this new contract, because it shouldn't be necessary due to contrapositives...
    condition implies returnsNotNull()
  }
  return if (condition) block() else null
}
// Usage
onlyIf(perEnvCondition) { veryExpensiveCall() } ?: println("I do nothing")

[Oliver.O]

Late to the party, but what's the point using this?

val printlnFn = println("hey")

Unlike the name suggests, the type of printlnFn is Unit.

[Alfonso Ristorato]

I did not want to write the full fn, in the second example I tried to make it clearer what this hypothetical method should do

[Oliver.O]

But didn't you really mean to write it like so?

val printlnFn = { println("hey") }

[Alfonso Ristorato]

No, I have a method that does something, what the method returns is less important for the use case (assume some heavy op) but the method is not a supplier

[Oliver.O]

So then with proper naming like so?

val printlnResult = println("hey")

[Alfonso Ristorato]

I tried to incline include the word fn in the name to make it clear that my method is actually a function rather than a side effect generator, but yeah