I am replying months lately, but anyway, I just read your proposal, and I think this is cool.
[guard self]
I am in doubt about another stuffs such as `[guard self else …]`. I hope your proposal to be accepted. I am getting a bit tired of writing `guard let S = self else { … }`.
I am still not sure how to use mailing list… but I hope this to be a correct way.
…Sending again because I mistyped Evan’s address.
How about [weak(guard) self]? It would only work with closures returning -> () as if you are weakly capturing something you are likely to be messaging that not returning some, so they can be ignored.
networkRequest.fetchData() { [weak(guard) self] result in
switch result {
case .succeeded(let data):
self.processData(data)
case .failed(let err):
self.handleError(err)
}
}
Patrick
···
On 13 May 2016, at 2:10 AM, Hoon H. via swift-evolution <swift-evolution@swift.org> wrote:
I am replying months lately, but anyway, I just read your proposal, and I think this is cool.
[guard self]
I am in doubt about another stuffs such as `[guard self else …]`. I hope your proposal to be accepted. I am getting a bit tired of writing `guard let S = self else { … }`.
I am still not sure how to use mailing list… but I hope this to be a correct way.
…Sending again because I mistyped Evan’s address.
I think that seems like a good idea until you start looking into the details. There was also the capture list option which I think had more value:
let closure = { [guard self] in
// compiler generates the guard for you
}
The problem comes with what does the guard return if the closure doesn’t return Void? This is actually a big issue if you’re using something like promises or future-chains for functional-style programming, it comes up a lot.
I would be more than happy I we could get this finally implemented for closures that returns Void. For any other closure I don’t think we need any additional syntax as probably it won’t be significantly shorter and more descriptive than typing guard inside the closure as we use to now.
{ [weak(guard) self] in ... }
{ [unowned(guard) self] in ... }
I would only suggest to even use shorter syntax to avoid writing weak and unowned and instead ? and !