# Guarded closures **URL:** \ **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:** 1\ **Showing post:** 15
**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")
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. --- _[View the full topic](https://forums.swift.org/t/guarded-closures/11029)._