Allowing `guard let self = self else { … }` for weakly captured self in a closure.

Evolution Discussion
1

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.

— Hoon H.

2

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.

— Hoon H.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

How about if the compiler was smart enough to apply the pattern behind the scenes since it is smart enough to know it's an issue.

1 Like
4

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.

1 Like
5

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 !

{ [guard self?] in ... }
{ [guard self!] in ... }
1 Like
6

You return T else guard returns the default of T

1 Like
7

Oh it's great to see this feature is getting interests.
I didn't expect someone would be interested in this feature again.

Yes, I agree to @Rod_Brown 's point. And I think @Sean.Batson's solution (designating default return value on closure) is great.