Assign it to a local val first
# getting-started
r
Assign it to a local val first
s
this was my first thought too, but if you need a function to manage the number of nullables you’re handling at once, all the
val
declarations would probably get unwieldy quickly
but for just two variables, yeah, I’d definitely rather go with this route
p
I'd argue that if you're touching that many nullables at once something's already a bit fishy.
🤷 1
1
r
I'm not sure I follow. It sounds like the function would be more unwieldy. If you're worried the number of `val`s will decrease readability or pollute the scope, you can wrap it in a
run
(which will be inlined).
s
Copy code
class Thing(
    var int: Int?,
    var str: String?,
    var char: Char?
) {
  fun frobnicate() {
    run {
      val i = int
      val s = str
      val c = char
      if (i != null && s != null && c != null) {
        
      }
    }
  }
}
vs
Copy code
class Thing(
    var int: Int?,
    var str: String?,
    var char: Char?
) {
  fun frobnicate() {
    where(int, str, char) { i, s, c ->

    }
}
granted, it only really makes sense if you use this
where
or
multiLet
more than once or twice
don’t get me wrong, I’m not really advocating for this approach, all I’m saying is I think I can kinda get where they’re coming from on this
r
Ah, I was envisioning something else entirely for some reason. I see your point now.
s
Ok, being new, i wanted to make sure i wasn't missing any kotlin feature to this
Thx for chiming in