# A dedicated function for evaluating Void returning closures when Optional instance is not nil

**URL:** <https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367>\
**Category:** Pitches\
**Tags:** foundation, optional\
**Created:** [July 27, 2019, 6:52pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367 "2019-07-27T18:52:03Z")\
**Posts on this page:** 1\
**Showing post:** 51

<div class="post-metadata">

**Author:** ![wadetregaskis](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/wadetregaskis/32/8494_2.png) [@wadetregaskis](https://forums.swift.org/u/wadetregaskis)\
**Post date:** [July 30, 2019, 4:09pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/51 "2019-07-30T16:09:41Z")

</div>

> [@mattpolzin](#):
>
> If we are representing
> 
> ```swift
> if let number = number { ... }
> 
> ```
> 
> with either
> 
> ```swift
> if number != nil { ... // number is not optional in this scope } 
> 
> ```
> 
> or
> 
> ```swift
> if let number { ... // number is not optional in this scope }
> 
> ```
> 
> Then the second option is my preference for a few reasons
> 
> 1. `if let` is established enough to make the leap intuitive.
> 2. We don't accidentally eliminate any code from being possible. If we magically turn an optional into a non-optional within the scope of a conditional then there might be interesting (maybe uncommon) situations where we break code that relies on the variable retaining its optional type within the scope. I could try to come up with an example maybe later.
> 3. It feels less magical to me, which I guess is really just a corollary to point number 1. Rebinding based on a `nil`-check is established in Kotlin but it would be entirely new magic for Swift.

I want to agree unconditionally - especially because, as you note, the safety proof required for the first form is much higher as a result of it being a much broader and more powerful and thus potentially more edge-casey approach. Therefore it'll be more work to pitch. However, you then mention that Kotlin already does this - I know _of_ Kotlin but am not that familiar with it; can you comment on how Kotlin does this and how well it's worked there?

The first approach implies a compiler mechanism with much broader implications, applications, and appeal (e.g. it probably ties in naturally if not as a prerequisite to [constrained types](https://forums.swift.org/t/allow-for-compile-time-checked-intervals-for-parameters-expecting-literal-values) and many other powerful language enhancements). If it does end up being implemented for those reasons, having a redundant `if let optional {` syntax - while not the end of the world - is, well, redundant.

Bikeshedding: I'm not sure I agree that the `let number` reads better than `number != nil` (though I'd get used to either form in practice, I'm sure). It's just that in plain English "if let number" is not a sentence, and it leaves the reader hanging with the natural question "if let number what?".

---

_[View the full topic](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367)._