I love this, what do you think? :slightly_smiling_...

# stdlib

[Marc Knaup]

I love this, what do you think? 🙂

inline fun <R> Boolean.thenTake(action: () -> R) =
    if (this) action() else null

val result = if (input) something() else null
->
val result = input.thenTake { something() }

[gildor]

I don’t like it because it completely non obvious that then returns null

[gildor]

also if tomorrow someone decide to add default value you will get:

val result = input.then { something() } ?: someDefault

Which is ridiculous replacement for if/else

[Marc Knaup]

What about a better name then?
mapTrueElseNull?

[Marc Knaup]

I use it for making this more readable:

override fun visitExtensions(type: KmExtensionType) =
		(type == JvmConstructorExtensionVisitor.TYPE).then {
			object : JvmConstructorExtensionVisitor() {

				override fun visit(desc: JvmMethodSignature?) {
					jvmSignature = desc
				}
			}
		}


	override fun visitExtensions(type: KmExtensionType) =
		if (type == JvmConstructorExtensionVisitor.TYPE) {
			object : JvmConstructorExtensionVisitor() {

				override fun visit(desc: JvmMethodSignature?) {
					jvmSignature = desc
				}
			}
		}
		else
			null

[gildor]

if you add to else {} second version is more readable for me

[gildor]

also I would rewreite it like this:

override fun visitExtensions(type: KmExtensionType): JvmConstructorExtensionVisitor {
        if (type != JvmConstructorExtensionVisitor.TYPE) ?: return null
        return object : JvmConstructorExtensionVisitor() {
                override fun visit(desc: JvmMethodSignature?) {
                    jvmSignature = desc
                }
            }
}

[elect]

something().takeIf{ input }

[Marc Knaup]

That's doing something different @elect

[Marc Knaup]

It always executes something()

[elect]

uh, right

[Marc Knaup]

@gildor I don't like that version because it gives up bodyless approach, requires me to invert the condition, add two returns and you have to state the return type.

[gildor]

anyway, IMO in this case else is the best

[Marc Knaup]

@elect but I can borrow the name here!

boolValue.thenTake { … }
which is basically the reverse of
{ … }.takeIf(boolValue)
except it's not evaluated unless boolValue is true

[miha-x64]

R should be non-nullable:
inline fun <R : Any> Boolean.thenTake
Otherwise ?: may lead to puzzlers.

[Marc Knaup]

hmm, isn't the same true then for the existing .takeIf()?
Also allows null.

[miha-x64]

I think takeIf shouldn't allow nullable receiver. This makes ?: ambiguous.

[Marc Knaup]

I think that's not a big problem and a rare case where you actually want to distinguish between the two cases.
This would also affect a lot other functions like let for example.

[Marc Knaup]

Swift is a little different here as it would return a double optional in such cases, unless you flatMap the double-optional into one.

[Marc Knaup]

But that quickly adds overhead

[miha-x64]

functions like let

let has nothing to do with nullability.

[Marc Knaup]

mayBeNull.let { mayReturnNull() } <- no distinguishing between which one is null
mayBeNull.takeIf { false } <- same

Where is the difference when it comes to the nullable receiver problem you mention?

[miha-x64]

let is not about nullability. takeIf is.

[Marc Knaup]

I'd say in both cases it depends on context and intention

[aarjav]

I don't think the following should be in stdlib but what about compute {something()} forCondition isReady where compute is a function that takes in a lambda that returns an object with a forCondition infix method

[miha-x64]

Unreadable. And cannot be inline.

[Marc Knaup]

It pushes the important info to the end and causes an unnatural flow.

Do all this.
And that.
Some more.
Maybe a dozen more lines.
And some database queries.
.
.
.
.
Oh and BTW, do all of that above only if the following condition is met:...

But +1 for creativity 👍

[aarjav]

I prefer a simple if else. When is also an option