# Guarded closures

**URL:** <https://forums.swift.org/t/guarded-closures/11029>\
**Category:** Discussion\
**Created:** [March 16, 2018, 4:24am UTC](https://forums.swift.org/t/guarded-closures/11029 "2018-03-16T04:24:42Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [March 16, 2018, 4:24am UTC](https://forums.swift.org/t/guarded-closures/11029/1 "2018-03-16T04:24:42Z")

</div>

The topic of guarded closures came up recently in the thread [The Future Of [weak self] Rebinding - #22 by ashin](https://forums.swift.org/t/the-future-of-weak-self-rebinding/10846/22). I promised to look at the history of the topic and start a new thread for those interested in continuing the discussion. There have been two related proposal drafts in the past.

The first was for a relatively straightforward addition of a `guard` capture specifier that would be available to closures returning `Void` (and possibly `Optional`). The draft can be found here: [A simplified notation for avoiding the weak/strong dance with closure capture lists · GitHub](https://gist.github.com/emaloney/d34ac9b134ece7c60440) and the discussion thread is here: [[Draft Proposal] A simplified notation for avoiding the weak/strong dance with closure capture lists](https://forums.swift.org/t/draft-proposal-a-simplified-notation-for-avoiding-the-weak-strong-dance-with-closure-capture-lists/1332).

The second draft is one I wrote a little over a year ago which explores introducing a new kind of closure which uses guarded captures by default (while still allowing an explicit capture list to override that default). The draft also introduces an `@guarded` function argument attribute which can be used in place of `@escaping` to _require_ the argument to be a guarded closure. The intent behind this is to allow an API to indicate to users that correct use of the API will not usually extend the lifetime of an object and to make frequent usage patterns syntactically concise.

IIRC at the time I was also thinking about how to introduce guarded references to closures which would need to be `Optional` and would be notified when one of the guards was released. This would allow a library to free up resources that are no longer needed when a callback becomes a no-op.

For a number of reasons I am less convinced that the additional complexity in my draft is worthwhile than I was a year ago. Additionally, introducing the basic `guard` capture specifier is a step towards more sophisticated guarded closure features should we wish to introduce them in the future. What do others think? Is there a desire to pursue guarded closures in the Swift 5 timeframe and if so, which direction is preferable? Further, if there is a desire to pursue guarded closures is anyone interested in working on the implementation?

---

<div class="post-metadata">

**Author:** ![ashin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ashin/32/2783_2.png) [@ashin](https://forums.swift.org/u/ashin)\
**Post date:** [March 16, 2018, 5:05pm UTC](https://forums.swift.org/t/guarded-closures/11029/2 "2018-03-16T17:05:07Z")

</div>

+1 to the guarded closures proposal. This would streamline syntax and offer an easy way to bypass a large set of retain cycle issues.

I'd be more hesitant on the `@guarded` attribute. The decision of how to capture values in a closure, including `self`, seems like it should be made at the point of use rather than in the API declaration. What use cases do you have in mind for this?

On a tangential note -- would it be a good time to revisit [this discussion](https://forums.swift.org/t/proposal-allow-strong-self-capture-in-closures-and-remove-the-self-requirement-therein/551) (removing the explicit `self` requirement in closures when `self` is included in the capture list)? It picked up a good bit of support, but looks like it was forgotten. Might be worth revisiting, in the light of this proposal and other discussions on rebinding `self` in closures.

---

<div class="post-metadata">

**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\
**Post date:** [March 16, 2018, 5:46pm UTC](https://forums.swift.org/t/guarded-closures/11029/4 "2018-03-16T17:46:22Z")

</div>

This proposal is nice. It has a lot of acknowledged caveats, and that's honest and good.

Those caveats are serious.

Self rebinding would address the same problem in a much more general way, IMHO.

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [March 16, 2018, 5:58pm UTC](https://forums.swift.org/t/guarded-closures/11029/5 "2018-03-16T17:58:33Z")

</div>

@Maik639 I addressed this use case in the draft I wrote by introducing a `?` prefix sigil for instance methods of classes.

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [March 16, 2018, 6:03pm UTC](https://forums.swift.org/t/guarded-closures/11029/6 "2018-03-16T18:03:27Z")

</div>

@gwendal.roue I agree. If we had to choose one or the other I would also choose rebinding. I don't feel too strongly about guarded closures anymore but there was enough interest in the topic that it deserves a dedicated thread. I see the basic proposal as syntactic sugar that builds on top of `self` rebinding.

The direction I had been exploring goes a bit further and attempts to solve related problems that `self` rebinding does not address. As I mentioned in the opening topic, I am less confident in that being worthwhile than I was a year ago.

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [March 16, 2018, 6:13pm UTC](https://forums.swift.org/t/guarded-closures/11029/7 "2018-03-16T18:13:37Z")

</div>

> [@ashin](#):
>
> I’d be more hesitant on the @guarded attribute. The decision of how to capture values in a closure, including self, seems like it should be made at the point of use rather than in the API declaration. What use cases do you have in mind for this?

I agree that the decision about capturing should happen at the point of use. Nothing discussed here changes that. I don't have a strong opinion on the topic but do want to make it clear that usage sites would remain in full control of every capture.

It is relatively unusual to _want_ to extend the lifetime of an object by capturing a strong reference when using many async APIs. Accidentally doing so is a common source of memory leaks and bugs in Swift code. It may be easier for some programmers to avoid such bugs if such APIs were able to invert the "default" capture mode. The inverted default would be visible at the usage site in order to ensure readers understand what is happening. An example of an API that might choose to use this feature is an API for performing network requests.

---

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [March 16, 2018, 7:26pm UTC](https://forums.swift.org/t/guarded-closures/11029/8 "2018-03-16T19:26:54Z")

</div>

In general I'm not opposed to optimizing for common cases, but if we move forward with `self` rebinding, I have trouble rationalizing guarded closures. My biggest concerns with the concept are:

- A syntax like `[guard self]` or some similar attribute combines two very different concepts—memory ownership and control flow—into a single keyword. That's an oddly specific and heavy weight to add to the language.
- This feature only works for a subset of possible closures—those which return `Void` (or possibly `Optional`, as mentioned above).

That's quite a bit of magic to avoid writing `guard let self = self else { return }`.

---

<div class="post-metadata">

**Author:** ![phlebotinum](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/phlebotinum/32/1515_2.png) [@phlebotinum](https://forums.swift.org/u/phlebotinum)\
**Post date:** [March 17, 2018, 3:00am UTC](https://forums.swift.org/t/guarded-closures/11029/9 "2018-03-17T03:00:07Z")

</div>

I also think that a) self rebinding is a preferable solution to a part of the described problem and b) using the keyword guard in two places in different ways works against the consistency of the language.

---

<div class="post-metadata">

**Author:** ![acecilia](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/acecilia/32/11213_2.png) [@acecilia](https://forums.swift.org/u/acecilia)\
**Post date:** [June 9, 2018, 4:13pm UTC](https://forums.swift.org/t/guarded-closures/11029/10 "2018-06-09T16:13:59Z")

</div>

IMHO here we are mixing two different proposals that solve different issues, and there is no need for opting for one or the other (I would love to have both):

**a) Allowing shadowing and rebinding of self** [[recent discussion](https://forums.swift.org/t/the-future-of-weak-self-rebinding/10846), [old evolution proposal](https://github.com/apple/swift-evolution/blob/master/proposals/0079-upgrade-self-from-weak-to-strong.md), [recently merged implementation](https://github.com/apple/swift/pull/15306)] (please note that this proposal is not being discussed here, I am just considering it in order to explain why I think it is different): it intents to modify the usage of the self keyword. This is an important change for the language, and **_not syntactic sugar_** , because (as I understood) it basically proposes to stop treating self as a reserved keyword and start treating it as any other identifier. This allows to unwrap self by reasigning it, instead of requiring a new identifier:

```
Before:
    let closure: () -> Void = { [weak self] in
        if let strongSelf = self {
            strongSelf.found = true
        } else {
            strongSelf.found = false
        }
    }

After:
    let closure: () -> Void = { [weak self] in
        if let self = self {
            self.found = true
        } else {
            self.found = false
        }
    }

```

**b) Introducing a guard keyword in a capture list** [[recent discussion](https://forums.swift.org/t/guarded-closures/11029), [Unofficial evolution proposal](https://gist.github.com/emaloney/d34ac9b134ece7c60440)]: this introduces a `guard` keyword as part of the capture list of a closure, which is not only intended to be useful when capturing self, but can also be used to capture any other identifiers:

```
Before:
    let closure: () -> Void = { [weak self] in
        guard let strongSelf = self else {
          return
        }
        strongSelf.intProperty += 1
    }

After:
    let closure: () -> Void = { [guard self] in
        self.intProperty += 1
    }

```

This is syntactic sugar for a specific closure usage case, but it is worth considering because this usage case appears a lot. In order to be eligible to use `guard` in a capture list, the closure has to satisfy that:

1. The closure intents to capture one or several properties weakly.
2. The code inside the closure is only intended to be executed if all the weakly captured properties are not nil.
3. The closure returns `Void`.

The [rationale](https://forums.swift.org/t/accepted-se-199-add-toggle-to-bool/10681) I have in mind for this proposal is extremely similar to the rationale given for the recently accepted [toggle() proposal](https://github.com/apple/swift-evolution/blob/master/proposals/0199-bool-toggle.md):

- commonality: the need to unwrap a weakly captured identifier is a common one across multiple different problem domains

- readability: the addition of this command can significantly improve readability for the cases in which it is possible to use it (which are many, despite the requirements that the closure has to comply with)

- consistency: while _capturing weakly and then unwrapping_ is fairly trivial, it is good to have a consistent way of doing this across all swift codebases, rather than having multiple variants (with multiple variants, I mean that the identifier given when unwrapping may be different in every case. For example, when unwrapping self, developers assign the new strong reference to indentifiers such as weakSelf, strongSelf, ss, sSelf, wSelf...)

- correctness: being able to give a different identifier for the unwrapped and weakly (optional) captured object, can lead to this not-so-correct code (which eventually can lead to bugs):

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [June 9, 2018, 6:45pm UTC](https://forums.swift.org/t/guarded-closures/11029/11 "2018-06-09T18:45:05Z")

</div>

> [@acecilia](#):
>
> The [rationale](https://forums.swift.org/t/accepted-se-199-add-toggle-to-bool/10681) I have in mind for this proposal is extremely similar to the rationale given for the recently accepted [toggle() proposal](https://github.com/apple/swift-evolution/blob/master/proposals/0199-bool-toggle.md):
> 
> - commonality: the need to unwrap a weakly captured identifier is a common one across multiple different problem domains
> 
> - readability: the addition of this command can significantly improve readability for the cases in which it is possible to use it (which are many, despite the requirements that the closure has to comply with)
> 
> - consistency: while _capturing weakly and then unwrapping_ is fairly trivial, it is good to have a consistent way of doing this across all swift codebases, rather than having multiple variants (with multiple variants, I mean that the identifier given when unwrapping may be different in every case. For example, when unwrapping self, developers assign the new strong reference to indentifiers such as weakSelf, strongSelf, ss, sSelf, wSelf...)
> 
> - correctness: being able to give a different identifier for the unwrapped and weakly (optional) captured object, can lead to this not-so-correct code (which eventually can lead to bugs):
> 
> ```swift
> let closure: () -> Void = { [weak self] in
> guard let strongSelf = self else {
> return
> }
> strongSelf.intProperty += 1
> self?.anotherIntProperty += 1
> }
> 
> ```

A few issues:

- First, your arguments about inconsistency across code bases now go away because `guard let self = self else { ... }` is now possible; no one needs to decide anymore between `strongSelf`, `ss`, etc.
- As has been said before regarding other shorthand sugar pitched for `guard`, eliding the entire `else` block is not considered a win for correctness. Instead, being explicit about what happens when the condition is not met can be important for reasoning about code. Silently doing nothing is not always correct--it may be that you really want to halt execution with `fatalError()`, for example--and we should not be creating syntax that makes silently doing nothing the default behavior.
- The bar for adding new syntactic sugar is higher than the bar for adding new methods; the same criteria are a good starting point but wouldn't be sufficient.

This topic is now very old. I think that, if you have new concrete use cases that can strongly motivate the addition of new syntax in the face of recent changes that enable `guard let self = self else { ... }`, it would be worth launching a new discussion. However, in the absence of new evidence, if anything the need for new syntax is less rather than greater now, in my view, especially seeing how some of the arguments you're raising in favor are now superseded by the recent change.

---

<div class="post-metadata">

**Author:** ![Nikita\_Leonov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nikita_leonov/32/2833_2.png) [@Nikita\_Leonov](https://forums.swift.org/u/Nikita_Leonov)\
**Post date:** [June 9, 2018, 8:33pm UTC](https://forums.swift.org/t/guarded-closures/11029/12 "2018-06-09T20:33:28Z")

</div>

It makes simple to write a code similar to `if` without `else` and end up with an unpredictable / undesired behavior. An existing `weak self` jump through the hoops always expect you to provide `else` where you should do all the handling, logging etc. `[guard self]` makes it normal to not handle a faulty scenario, this will enforce a bad habits for less experiences engineers.

---

<div class="post-metadata">

**Author:** ![Rod\_Brown](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/rod_brown/32/425_2.png) [@Rod\_Brown](https://forums.swift.org/u/Rod_Brown)\
**Post date:** [June 9, 2018, 9:49pm UTC](https://forums.swift.org/t/guarded-closures/11029/13 "2018-06-09T21:49:29Z")

</div>

> [@xwu](#):
>
> - First, your arguments about inconsistency across code bases now go away because `guard let self = self else { ... }` is now possible; no one needs to decide anymore between `strongSelf` , `ss` , etc.

Has this been confirmed? I thought this was still considered a bug...

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [June 9, 2018, 10:07pm UTC](https://forums.swift.org/t/guarded-closures/11029/14 "2018-06-09T22:07:51Z")

</div>

The fix has been merged into master.

---

<div class="post-metadata">

**Author:** ![acecilia](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/acecilia/32/11213_2.png) [@acecilia](https://forums.swift.org/u/acecilia)\
**Post date:** [June 10, 2018, 3:41am UTC](https://forums.swift.org/t/guarded-closures/11029/15 "2018-06-10T03:41:04Z")

</div>

My first point was to get clear that the two proposal solve different issues. Thus, there is no need to choose one or another. As I see it, discussing if we want `[guard self]` is independent of the `guard let self = self else { ... }` proposal. Can we agree on that?

About the rest:

> [@xwu](#):
>
> - First, your arguments about inconsistency across code bases now go away because `guard let self = self else { ... }` is now possible; no one needs to decide anymore between `strongSelf` , `ss` , etc.

In case `guard let self = self else { ... }` is confirmed, you are right about the consistency argument.

> [@xwu](#):
>
> As has been said before regarding other shorthand sugar pitched for `guard` , eliding the entire `else` block is not considered a win for correctness. Instead, being explicit about what happens when the condition is not met can be important for reasoning about code. Silently doing nothing is not always correct--it may be that you really want to halt execution with `fatalError()` , for example--and we should not be creating syntax that makes silently doing nothing the default behavior.

If you want to halt execution with `fatalError()`, then you do not use `[guard self]`. As explained, `[guard self]` is syntactic sugar for a very concrete scenario, where you dont want to execute the code in the closure if any of the identifiers in the capture list is `nil`. And despite being a very concrete case, in my opinion the `[guard self]` proposal makes sense due to the high amount of times this pattern appears on the code.

> [@xwu](#):
>
> The bar for adding new syntactic sugar is higher than the bar for adding new methods; the same criteria are a good starting point but wouldn't be sufficient.

I understand. As I see it, this `toggle()` proposal that was recently accepted is adding syntactic sugar that is really useful only in a very concrete case: when in larger nested structs. If you are not in an scenario with a large nested struct, then the advantage for using it is not so much.  
If such a proposal was accepted, I wonder why not this syntactic sugar proposal that is being discussed and requested during years would not be accepted, or at least seriously considered as a proposal.  
I think the acceptance and rationale of the `toggle()` proposal is a good starting point for, at least, making an official `[guard self]` proposal, and end up the recurring discussions about it.

> [@xwu](#):
>
> This topic is now very old.

Yes, this topic is very old, but even after discussing it a lot, I have been reading all the information I could find about it and the result is:  
a) This was never oficially proposed in swift evolution.  
b) I could not find a proper rationale of why there has never been an official proposal, or why this syntactic sugar is undesired. Seems to me that when the discussion was happening, it was not the right time for this, or the people supporting the discussion gave up.  
c) Because there has never been an official proposal, there is no official rationale from the core team for or against it.  
d) From the discussion and the comments in [here](https://gist.github.com/emaloney/d34ac9b134ece7c60440), seems to me that there is still interest on this, or alternatively, on a solution for the _capturing weakly and then unwrapping_ commonly repeated scenario.

> [@xwu](#):
>
> eliding the entire `else` block is not considered a win for correctness

I see your point. Maybe `guard` is not the right keyword for this. It seems to me the right one, but of course having a similar implementation with another keyword that fits better is an alternative.

> [@Nikita\_Leonov](#):
>
> `[guard self]` makes it normal to not handle a faulty scenario, this will enforce a bad habits for less experiences engineers.

Well, I think what less experiences engineers do is not use the capture list, thus creating reference cycles. And, at the moment they realise that when using closures almost everything should be _captured weakly and then unwrapped_, is when you start wondering: is there any alternative for this commonly repeated code `[weak self] in guard let strongSelf = self else { return }`?  
Also, if you are using `[guard self]` you should be aware of what you are doing. Using the features of a language without even reading what they are intended for is a bad habit. Using features of a language that allow you to write clearer, more readable code, I think is a good habit.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [June 10, 2018, 3:39pm UTC](https://forums.swift.org/t/guarded-closures/11029/16 "2018-06-10T15:39:55Z")

</div>

> [@acecilia](#):
>
> b) I could not find a proper rationale of why there has never been an official proposal, or why this syntactic sugar is undesired. Seems to me that when the discussion was happening, it was not the right time for this, or the people supporting the discussion gave up.

In the Swift Evolution process, proposals are reviewable when the author creates a document that achieves some amount of consensus during the pitch phase. As you can see from the preceding conversation here, members of the community have doubts that this is the most desired solution.

> [@acecilia](#):
>
> Also, if you are using `[guard self]` you should be aware of what you are doing.

This may fine as a general principle when you're supervising junior developers, but from the perspective of language design you can't wave away the potential of creating sharp edges in the language by saying, "you should know what you're doing." I'm not aware of any place in the language that has hidden control flow like this.

In any case, it can be interesting to visit old topics when something new changes the context. To drive the conversation forward, do you have concrete use cases that haven't been previously considered?

---

<div class="post-metadata">

**Author:** ![Tino](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tino/32/1073_2.png) [@Tino](https://forums.swift.org/u/Tino)\
**Post date:** [June 10, 2018, 3:56pm UTC](https://forums.swift.org/t/guarded-closures/11029/17 "2018-06-10T15:56:39Z")

</div>

btw:  
Has it ever been discussed to make `weak` the default for closures?  
It's probably to late for such a change, but besides compatibility, I think it would be better if you could omit `[weak self]` and had to explicitly state when you want a strong reference.

---

<div class="post-metadata">

**Author:** ![acecilia](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/acecilia/32/11213_2.png) [@acecilia](https://forums.swift.org/u/acecilia)\
**Post date:** [June 10, 2018, 4:07pm UTC](https://forums.swift.org/t/guarded-closures/11029/18 "2018-06-10T16:07:10Z")

</div>

> [@xwu](#):
>
> In any case, it can be interesting to visit old topics when something new changes the context. To drive the conversation forward, do you have concrete use cases that haven't been previously considered?

No. I am bringing back the discussion because:  
a) It is being mentioned lately during the discussion of the "Allowing shadowing and rebinding of self" proposal (with people for and against it), and I see it keeps getting support [here](https://gist.github.com/emaloney/d34ac9b134ece7c60440).  
b) I could not find a rationale with purely technical reasons agains it (most of the reasons agains it that I have red are very subjective to the developer talking).  
c) Considering that I could not find purely technical reasons agains it, I looked for a subjective reason against it coming from the core team. I could not find it either.  
d) I saw the recently approved `toggle()` proposal, and I think the rationale for accepting it has several similarities with the rationale I would give to this `[guard self]` proposal.  
e) Due to point d), and considering that this discussion has happened already several times without a clear acceptance/rejection outcome, I think it would be interesting to push a bit more for it, or even make an official proposal in order to get more visibility, and eventually an acceptance/rejection rationale, making things clear and preventing the discussion from happening in the future.

This discussion being repeated over an over is an indicator to me that several developers are seeking for an alternative for `[weak self] in guard let strongSelf = self else { return }`. Having a clear rationale for or againt it would help.

As an example, the ["Allowing shadowing and rebinding of self"](https://forums.swift.org/t/the-future-of-weak-self-rebinding/10846) proposal has been [accepted](https://github.com/apple/swift-evolution/blob/master/proposals/0079-upgrade-self-from-weak-to-strong.md) in September 2016, but an [implementation](https://github.com/apple/swift/pull/15306) of it did not happen until March 2018, even though the context did not change from 2016 to 2018. And I believe that the reason for this is that in 2016, the focus of the community was on other more important topics, but now in 2018 the focus is shifting thowards this not so important - but still possible to improve - syntactic issues that we are seeing lately.

---

<div class="post-metadata">

**Author:** ![acecilia](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/acecilia/32/11213_2.png) [@acecilia](https://forums.swift.org/u/acecilia)\
**Post date:** [June 10, 2018, 4:09pm UTC](https://forums.swift.org/t/guarded-closures/11029/19 "2018-06-10T16:09:27Z")

</div>

@Tino agree, but that would be another discussion thread, in my opinion. Gather some old threads and discussion about it, and go for it ;P

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [June 10, 2018, 5:22pm UTC](https://forums.swift.org/t/guarded-closures/11029/20 "2018-06-10T17:22:52Z")

</div>

> [@acecilia](#):
>
> No. I am bringing back the discussion because:  
> a) It is being mentioned lately during the discussion of the "Allowing shadowing and rebinding of self" proposal (with people for and against it), and I see it keeps getting support [here](https://gist.github.com/emaloney/d34ac9b134ece7c60440).  
> b) I could not find a rationale with purely technical reasons agains it (most of the reasons agains it that I have red are very subjective to the developer talking).  
> c) Considering that I could not find purely technical reasons agains it, I looked for a subjective reason against it coming from the core team. I could not find it either.  
> d) I saw the recently approved `toggle()` proposal, and I think the rationale for accepting it has several similarities with the rationale I would give to this `[guard self]` proposal.  
> e) Due to point d), and considering that this discussion has happened already several times without a clear acceptance/rejection outcome, I think it would be interesting to push a bit more for it, or even make an official proposal in order to get more visibility, and eventually an acceptance/rejection rationale, making things clear and preventing the discussion from happening in the future.

The Swift Evolution process doesn't really work this way. An idea needs to achieve a certain amount of uptake and consensus before review. When people raise reasons why they are not in favor of the proposal, these need to be addressed or answered in some way and not dismissed as "subjective." Most ideas are brought up and fade out because it never gets to a point where it's ready for review, and pushing an idea forward after extensive discussion requires more than "+1."

---

<div class="post-metadata">

**Author:** ![acecilia](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/acecilia/32/11213_2.png) [@acecilia](https://forums.swift.org/u/acecilia)\
**Post date:** [June 10, 2018, 5:38pm UTC](https://forums.swift.org/t/guarded-closures/11029/21 "2018-06-10T17:38:13Z")

</div>

@xwu I know how the Swift Evolution process work, and that is why we are having this discussion.

I answered your concerns [here](https://forums.swift.org/t/guarded-closures/11029/15). If you think I was not clear enough, ask again.

If you find other arguments against this proposal I would happily read them, because as I said I could not find them in the old threads, where usually the thread was just dying or diverging the discussion topic.

[Next page](https://forums.swift.org/t/guarded-closures/11029.md?page=2)