# 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:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![SDGGiesbrecht](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sdggiesbrecht/32/4768_2.png) [@SDGGiesbrecht](https://forums.swift.org/u/SDGGiesbrecht)\
**Post date:** [July 28, 2019, 9:16pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/42 "2019-07-28T21:16:43Z")

</div>

Brainstorming a completely different approach to solve the original problem and bulldoze the bike shed so it doesn’t need painting...

It would be nice to be able to extend `Any` (or have a temporary, stand‐in, empty `AnyProtocol` that _everything_ can manually conform to in the meantime). With either, this would be possible:

```swift
let number: Int? = 42

// Isn’t this both as clear and as short as can possibly be?
number?.do { print($0) }

// It can be implemented with the following (in Swift 5.0):
protocol AnyProtocol {}
extension Int: AnyProtocol {}
extension AnyProtocol {
    func `do`(_ closure: (Self) throws -> Void) rethrows {
        try closure()
    }
}

```

Just for kicks (and not very seriously), the `do` method could be tied into the compiler and provided a `yourself` keyword to seem more like `self`, but from an outside context (It is functionally identical to `$0`.):

```swift
number?.do { print(yourself) }

```

---

<div class="post-metadata">

**Author:** ![benrimmington](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/benrimmington/32/695_2.png) [@benrimmington](https://forums.swift.org/u/benrimmington)\
**Post date:** [July 29, 2019, 1:48am UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/43 "2019-07-29T01:48:19Z")

</div>

[SE-0253](https://github.com/apple/swift-evolution/blob/master/proposals/0253-callable.md) (when implemented) might allow for:

```swift
extension Optional {

    @inlinable
    @discardableResult
    public func callAsFunction<U>(
        _ transform: (Wrapped) throws -> U?
    ) rethrows -> U? {
        return try flatMap(transform)
    }
}

```

```swift
let possibleNumber: Int? = Int("42")

let possibleString: String? = possibleNumber { String($0) }

possibleNumber { print($0) } // discardableResult

```

---

<div class="post-metadata">

**Author:** ![AlexanderM](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alexanderm/32/9781_2.png) [@AlexanderM](https://forums.swift.org/u/AlexanderM)\
**Post date:** [July 29, 2019, 2:20am UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/44 "2019-07-29T02:20:59Z")

</div>

This is precisely what `ifSome(_:)`, `ifNone(_:)` did in my pitch here: [API Additions to Optional (filter, ifSome, ifNone, peek) - #16 by salutis](https://forums.swift.org/t/api-additions-to-optional-filter-ifsome-ifnone-peek/22393/16)

However, I haven't had time to learn how to implement it into the standard library, which is a precondition for a formal proposal.

---

<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 29, 2019, 5:21pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/45 "2019-07-29T17:21:20Z")

</div>

> [@cukr](#):
>
> It cannot _know_ that it cannot be nil, at most it can assume that it's the case
> 
> ```swift
> var _number: Int? = 5
> var number: Int? {
> defer { _number = nil }
> return _number
> }
> 
> assert(number != nil)
> print(number) // will print nil in the current swift version
> 
> ```

An interesting example. In general concerns around determinism can be addressed through `@pure` et al, though in this specific case I'm not sure if you could consider that property pure or not… I argue it's not, because it has side effects (mutating itself - _and_ in a way that's non-deterministic from its arguments).

If it were pure, then as per usual for pure functions the compiler could trust that its value would remain the same. In all other cases, the compiler would require the coder to store the value in a local variable for use across validation & subsequent use. This is of course the _only_ safe way to do this irrespective of this particular proposal on possible compiler help with syntax.

An equivalent example that more clearly demonstrates why this sort of thing is _not_ a dissuasion is a queue: once you pop an item, it's no longer in the queue (@cukr's example being a kind of specialised, single-item queue). No one would expect this code to work correctly:

```
while queue.pop() != nil {
    doStuff(queue.pop())
}

```

…unless your very unusual intent is to skip every other item.

`if let ...` handles this elegantly just as saving the value into a local variable does.

---

<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 29, 2019, 5:31pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/46 "2019-07-29T17:31:11Z")

</div>

> [@Jumhyn](#):
>
> It would be much nicer to write something like `(foo, bar, baz).ifAll(doSomething(with:))`.

`try` does this naturally, e.g.:

```
try? doSomething(foo, bar, baz)

```

As long as it's acceptable to the reader that this could mean:

- `doSomething` throws.
- One _or more_ of the arguments are optionals and must be unwrapped in order to match the parameters of `doSomething`.
- Both of the above simultaneously.

I really like the brevity & reuse of existing, clearly related language features for this (more than I like the otherwise interesting `.ifSome { $0 }`-style approach), but I still don't know how I feel about the heavy load on that one little `try?`.

Though, again, it doesn't preclude any coder, whom wishes to make it clearer, from decomposing it:

```
if let bar = bar {
    try? doSomething(foo, bar, baz)
}

```

Though it does rely on a guess, essentially, that `bar` is the one argument that needs unwrapping, and not merely that the author forgot about the others (or that the function signature changed at some point).

So it does hinge on the question of whether you ever really need to distinguish between why the `try` "failed".

It _seems_ to make sense long as you think of `try?` in broad terms: "do this thing if it's possible, and just don't worry about it if it's not for any reason". I'm curious if others read / interpret `try?` differently?

---

<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 29, 2019, 5:49pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/47 "2019-07-29T17:49:28Z")

</div>

> [@SDGGiesbrecht](#):
>
> ```swift
> let number: Int? = 42
> 
> // Isn’t this both as clear and as short as can possibly be?
> number?.do { print($0) }
> 
> ```

I like this [slightly] best amongst the `optional.something { … }` approaches proposed thus far. It's concise and close to the very similar `?.` operator. And could presumably be chained similarly?

```
number?.do { calculate($0) } ?.do { print($0) }

```

Not necessarily elegant, but if you find this ugly then perhaps it's fundamentally because of the use of free functions as opposed to member methods?

A counter-argument to such chaining might be that in the 'inner links' of the chain should logically use `map` instead:

```
number.map { calculate($0) } ?.do { print($0) }

```

Even if so, I don't think Swift needs to be _so_ opinionated about it, however, as to explicitly preclude `?.do` chaining. It can be a style preference.

In any case, it's interesting to me that this does start to look, if you squint a little, like 'then' syntax (e.g. [one](https://github.com/freshOS/then) of many async libraries implementing that pattern).

> [@SDGGiesbrecht](#):
>
> ```swift
> number?.do { print(yourself) }
> 
> ```

…but I worry that `yourself` isn't a suitably generic keyword. Nonetheless an example of where it wouldn't read well doesn't spring immediately to mind.

It is extra language surface area over the established `$0` convention, though, and longer. (though I'm not a particular fan of `$0` to begin with… a tangent making a compelling argument for `yourself` or similar as a general replacement for `$0` would be welcome by me)

---

<div class="post-metadata">

**Author:** ![deanha](https://avatars.discourse-cdn.com/v4/letter/d/eb8c5e/32.png) [@deanha](https://forums.swift.org/u/deanha)\
**Post date:** [July 30, 2019, 6:56am UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/48 "2019-07-30T06:56:13Z")

</div>

> [@SDGGiesbrecht](#):
>
> ```swift
> number?.do { print(yourself) }
> 
> ```

I feel that going this route sends the message that the functionality proposed is **not** really _intimately_ related to the `Optional` type - or any other type, actually - but rather generic, contrary to the current state of affairs in regards to `map(_:)`.

IMHO **Optional Chaining** a generic function as a solution moves the discussion from how to elegantly handling the content of a _Container Type_.

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [July 30, 2019, 1:14pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/49 "2019-07-30T13:14:49Z")

</div>

> [@deanha](#):
>
> However, one could say that using a _control structure_ is quite a verbose pick for such a simple task.

This seems to be the crux of your argument, and I don't really agree with it.

Rather than doing this, I would rather have flow-sensitive optional support. So when the compiler sees:

`if someOptional != nil`

It will secretly transform it in to:

`if let __someOptional = someOptional` (or some other hidden name)

And within the conditional scope, it would accept using `someOptional` directly where the underlying type would be expected, rewriting those uses to instead use `__someOptional` (the unwrapped version). Generic parameter resolution would favour the underlying type over the optional.

So your example would become: `if number != nil { print(number) }`

Similarly,

```swift
if number != nil { 
  let x = Array(number) // favours Array<Int> over Array<Int?>
}

```

---

<div class="post-metadata">

**Author:** ![mattpolzin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mattpolzin/32/6041_2.png) [@mattpolzin](https://forums.swift.org/u/mattpolzin)\
**Post date:** [July 30, 2019, 3:48pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/50 "2019-07-30T15:48:59Z")

</div>

Now that this idea has sat for a few days, I think I agree that using sufficiently concise conditional control flow would be my preference over introducing a `map`-like function intended to be used when side-effects are desirable.

I would go the other direction (as was proposed upthread) and retain the explicit callout that a new constant is being created for the scope that follows rather than retaining the explicit `nil`-check.

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.

---

<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?".

---

<div class="post-metadata">

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

</div>

> can you comment on how Kotlin does this and how well it's worked there?

I'll leave this topic for someone else. I've used Kotlin, but I cannot speak to the community sentiment or how the feature is implemented.

> It's just that in plain English "if let number" is not a sentence

I'd argue that the intent is not in this case to be conversational but rather extremely concise and still very exacting. Use the same natural language trick on the thing we are trying to shorten and it performs no better: `if let number = number`: "If let number equal number" means nothing to me, and certainly does not imply that we are only letting "number equal number" _if_ "number" is not `nil`. The degree to which we are increasing cognitive load is far less than that required to learn the `if let` pattern in the first place.

I want to stress that my second point is specifically that if we introduce

```swift
if let number { ... // number is not optional }

```

as a companion to the existing

```swift
if number != nil { ... // number _is_ still optional }

```

Then we don't break source compatibility, but more importantly the language remains equally expressive -- if I want to `nil`-check without changing the type of the thing named "number" I can still do that in the most obvious way possible.

---

<div class="post-metadata">

**Author:** ![deanha](https://avatars.discourse-cdn.com/v4/letter/d/eb8c5e/32.png) [@deanha](https://forums.swift.org/u/deanha)\
**Post date:** [July 31, 2019, 7:34am UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/53 "2019-07-31T07:34:03Z")

</div>

Verbosity is only _one_ motivation for this suggestion.  
A much stronger one, in my opinion, is providing a **declarative** way of plucking out `Optional`'s honest value. And from your solution it seems we agree that the `if let` dance is **imperative overhead**.

However, you actually touched on what I dislike about your solution:

> [@Karl](#):
>
> It will secretly transform it in to:

This _magical_ transformation unwraps the value **implicitly** , and assumes it's a `let`.  
Why not `var`? What if I only want to check that `number` has an honest value, but without needing to unwrap it?

This secret unwrapping, as you called it, hides _intention_ and holds back on _clarity_. In other words I'd say it's no longer declarative.

That's why the analogy to `Array`'s `forEach(_:)` makes a lot of sense to me - To allow to do something with each value in the container, just with a different type of container. And since `map(_:)` is unclear in callsite, I'm suggesting `forValue(_:)`.

---

<div class="post-metadata">

**Author:** ![lolgear](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lolgear/32/4790_2.png) [@lolgear](https://forums.swift.org/u/lolgear)\
**Post date:** [July 31, 2019, 8:29am UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/54 "2019-07-31T08:29:52Z")

</div>

I don't understand why this topic is still considered.

You have also `Result` ( specialized Either ) monad. I would like to do the same ( print a value or an error ).

Should we consider to add `forEach` or `let` and `forEachError` and `letError` functions with the same functionality to this type?

```swift
extension Result {
  func `let`(_ success: (Success) -> Void) {
    map(success)
  }
  func letError(_ failure: (Failure) -> Void) {
    mapError(failure)
  }
}

```

---

<div class="post-metadata">

**Author:** ![idrougge](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/idrougge/32/3885_2.png) [@idrougge](https://forums.swift.org/u/idrougge)\
**Post date:** [July 31, 2019, 10:31am UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/55 "2019-07-31T10:31:45Z")

</div>

> [@wadetregaskis](#):
>
> 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?".

More bikeshedding: When I write Swift, `nil` is seldom what I'm interested in. What I need to know is if the variable has a value, and if I can bind it. Expressing that in a negated clause about `nil`, which I wasn't interested in to begin with, doesn't express the intent of the program.

---

<div class="post-metadata">

**Author:** ![mattpolzin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mattpolzin/32/6041_2.png) [@mattpolzin](https://forums.swift.org/u/mattpolzin)\
**Post date:** [July 31, 2019, 1:22pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/56 "2019-07-31T13:22:50Z")

</div>

I think your point about verbosity only being one factor is definitely key. I realized only after my latest post in this thread that there’s a totally separate pitch right now that is proposing adding `if let something` as shorthand for `if let something = something` with largely different motivations ([[Syntax] Default name for optional binding self and other properties](https://forums.swift.org/t/syntax-default-name-for-optional-binding-self-and-other-properties/27394)).

I guess where I land in the end is I acknowledge that they address a different set of goals that merely overlap and I happen to be _more_ interested in seeing the `if let` shorthand but (1) I can’t think of an argument against having the method you are looking for, (2) there’s precedent with `forEach`, and (3) I’d probably use it on occasion (as has been the case with `forEach`).

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [July 31, 2019, 1:32pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/57 "2019-07-31T13:32:42Z")

</div>

> [@deanha](#):
>
> This _magical_ transformation unwraps the value **implicitly** , and assumes it's a `let` .  
> Why not `var` ? What if I only want to check that `number` has an honest value, but without needing to unwrap it?

I'm just describing a mental model, for illustrative purposes. Of course, if the value is unused, I wouldn't expect any actual unwrapping.

---

<div class="post-metadata">

**Author:** ![Jean-Daniel](https://avatars.discourse-cdn.com/v4/letter/j/977dab/32.png) [@Jean-Daniel](https://forums.swift.org/u/Jean-Daniel)\
**Post date:** [July 31, 2019, 5:35pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/58 "2019-07-31T17:35:05Z")

</div>

I hate the Kotlin model because it force you to structure your code to workaround limitations of the compiler. There is many places where the compiler is not smart enough or to much conservative and force introduction of intermediary variables or usage of force unwrap to make it accept the code.

The situation improved slightly with Kotlin 1.3 and method annotation, but it remains fragil IMHO.

---

<div class="post-metadata">

**Author:** ![drewster99](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/drewster99/32/4684_2.png) [@drewster99](https://forums.swift.org/u/drewster99)\
**Post date:** [August 2, 2019, 2:50am UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/59 "2019-08-02T02:50:29Z")

</div>

I don’t like forValue, ifLet, or IfSome.

I’m in favor of:

```
if value? { print(value) }

```

and

```
if let value { print(value) }

```

and

```
value.unwrap { ... }

```

and

```
var foo?
var bar?
unwrapping foo, bar { ... }

```

**value.unwrap** has the problem that you can only unwrap a single value for the closure, but I like the clarity.

**unwrapping foo, bar** is clear and can work with multiple values, but requires introducing a new keyword for this single purpose. The other thing is that it wouldn’t lend itself to being combined with other conditions in an if statement, which may lead to be tiny of **if** s inside of _unwrapping_ which leads to ugliness.

**try** is terrible because it overloads the existing meaning of try.

But of everything I’ve seen, I think **if number?** might be best. The ? lets everyone know we’re talking optionals, the syntax is short, we can easily handle multiple unwraps, and you can combine with other conditions in your **if** statement. The one thing I don’t like is that it doesn’t _scream_ that the thing is being unwrapped, but I think I could live with that one.

What reason does anyone have _against_ this one?

---

<div class="post-metadata">

**Author:** ![flowtoolz](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/flowtoolz/32/13358_2.png) [@flowtoolz](https://forums.swift.org/u/flowtoolz)\
**Post date:** [August 2, 2019, 2:22pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/60 "2019-08-02T14:22:21Z")

</div>

+1 for the increased readability and brevity.

I just don't get why this tiny cosmetic addition would be worth standardizing and dragging through the evolution process. Manual implementation can be 5 lines short and allows everybody to name it however they like:

```swift
extension Optional {
    func forSome(_ action: (Wrapped) -> Void) {
        if case .some(let wrapped) = self { action(wrapped) }
    }
}

```

---

<div class="post-metadata">

**Author:** ![cukr](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cukr/32/889_2.png) [@cukr](https://forums.swift.org/u/cukr)\
**Post date:** [August 2, 2019, 3:35pm UTC](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367/61 "2019-08-02T15:35:21Z")

</div>

> [@flowtoolz](#):
>
> I just don't get why this tiny cosmetic addition would be worth standardizing

1. I wouldn't have to wonder if it's implemented in the project I just opened or not
2. I wouldn't have to wonder how is it called if it's implemented
3. I wouldn't have to wonder in what file to put it, and what name the project maintainer would like most if I have to add it
4. I would be able to share code snippets online
5. I wouldn't have to write documentation/answer questions to describe what is it for (the names for this feature aren't great at being self documenting)

[Previous page](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367.md?page=2)

[Next page](https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367.md?page=4)