Any better workaround for nullable destructuring? ```val (p1,p2) = pair ?: null to null```

# announcements

[spand]

Any better workaround for nullable destructuring?

val (p1,p2) = pair ?: null to null

[Animesh Sahu]

You can make extensions:

operator fun <T, V> Pair<T, V>?.component1(): T? = null
operator fun <T, V> Pair<T, V>?.component2(): V? = null

val (p1,p2) = pair

But that'd only work for pair for example. You've to redefine these things for triple, data classes, etc.

[spand]

I reworked the code and ended up doing this instead:

pair?.let { (p1,p2) -> 
}

[spand]

But thanks

[Irving Rivas]

That last line is a bit unreadable, I think. It is succinct, which is nice — but it’s not straightforward to read. do you need that snippet more than once in the codebase?

[Irving Rivas]

if yes, consider extracting the behavior to a function; otherwise, consider changing how you set the “pair” itself

[Irving Rivas]

(just like we don’t send back a list as null, but an empty list, a similar idiom may work here where you don’t send back a null pair, but a pair of nulls)

[Irving Rivas]

If the situation is recurrent, there’s a case for something like this in the codebase:

inline fun <T>valueOrDefault(value:T?,default:T):T = value?:default

which is easy on the eyes on the calling site

[Nir]

?.let is a totally standard Kotlin idiom so I'm confused why you call it unreadable

[Irving Rivas]

the .let {(p1,p2)-> } is what I find harder to parse.

[Irving Rivas]

or, as I said it earlier — “a bit unreadable”

[Nir]

I dunno, it's really just two pretty standard things combined though, the ?.let and lambda destructuring 🤷

[Irving Rivas]

It’s OK if my point does not make sense to you.