Easy strongified weak `self` in closures

charlieMonroe · 2018-10-07T07:32:34.154Z

I'd personally suggest declaring that you only want the body of the closure to be executed when self is not nil with something like [autoweak self] or [required weak self].

This is both explicitely declarative about only wanting the code to be executed in context of non-nil self and a non-breaking addition.

trenskow · 2018-10-07T07:37:27.089Z

You could make something like what @charlieMonroe suggests (like [autoweak self]) the default behaviour for escaping closures. That would eliminate a lot of unintentional retain cycles.

trenskow · 2018-10-07T07:40:33.274Z

Making it default would be breaking behaviour, though.

Tino · 2018-10-07T10:10:53.495Z

Afair this has been discussed with [guard self] instead of autoweak ([Proposal] Guarded self in closures, Guarded closures).
It doesn't work with closures that return something, though: It might be possible to infer nil if the result is optional... but still, that's no general solution.
I think it's very hard to come up with a really elegant solution, and next to impossible to avoid breaking compatibility (unless it can live alongside with the old behavior) - and even if all those concerns are addressed, the idea still has to survive the evolution process.

QuinceyMorris · 2018-10-07T18:46:57.517Z

The problem here (IMO) is that this:

    guard let `self` = self else { return }

isn't really boilerplate, but is important documentation about what the closure does — since its behavior in the face of self == nil could reasonably be something more complicated, or sometimes could reasonably be handled later in the closure..

Given that, and that [guard self] is problematic if the closure returns a value, it makes more sense to keep the actual guard statement inside the closure, but look for ways to make it a little less wordy.

For example (and these are just suggestions to discuss, not a pitch), we can, and maybe already do — I can't remember if this was just talked about or actually done —, have this as official syntax:

    guard let self = self else { return }

Next, I've always thought that single unconditional control-transferring statements (return, break, continue, etc) should be syntactically equivalent to their singly { }-ified selves, so we could have this:

    guard let self = self else return

Finally, it might not be unreasonable to have a streamlined guard syntax, either for shadowing variables generally, or just for self specifically:

    guard self else return // or maybe 'guard let self else return'

To me, a syntax like that eliminates enough boilerplate to make me happy, but keeps useful explicitness about how the nil value is handled.

GetSwifty · 2018-10-07T22:43:25.171Z

First, for anyone who doesn't know, guard self = self else {} is now (finally) implemented to be valid.
I think this is sufficient for circumstances where you still want the function to run when self == nil, but in my experience that's mostly not the case when I use [weak self].

Been thinking about this some and got some ideas from reading the discussion for Optional iteration. I don't like autoweak and partially like [guard self], but I don't think it's necessary to add/adapt keywords when we already have syntax around optionals.

#1

let myClosure = { [weak self]? in
    //self is already unwrapped
}

This would probably the simplest syntactic change and incredibly easy to add for end users, while also remaining syntactically familiar.

#2
Another option would be to put it on the right side of in:

let myClosure = { in [weak self]? 
    //self is already unwrapped
}
//or since it's on the right side, in could no longer be required
let myClosure = { [weak self]? //self is already unwrapped }

This semantically puts it on the wrong side of the expression, but it would make more sense in cases where we also add a default return value:

let myClosure = { in [weak self]? else *defaultValue* // Or "[weak self] ?? *defaultValue*" ?
    //self is already unwrapped
}

#3
If in? was added as syntax, it could be a good candidate here:

let myClosure = { [weak self] in?
    //self is already unwrapped
}
// with default return value
let myClosure = { [weak self] in? else *defaultValue*
    //self is already unwrapped
}

To make it simple, these could compile to:

let myClosure = { [weak self] in
    guard let self = self else {
        return *defaultValueIfNecessary*
    }
}

QuinceyMorris · 2018-10-07T23:30:31.135Z

I'd also like put in a shout-out to [unowned self], which doesn't cause reference cycles but doesn't make self optional.

In some cases where you think you need [weak self] to avoid a reference cycle, you know that self isn't getting deallocated before the closure is deallocated. [unowned self] avoids the whole guard scenario.

The problem is that you actually have to think carefully whether unowned is going to work, because your app will crash if you're wrong (as opposed to just misbehaving if you get the other kinds of capture wrong).

trenskow · 2018-10-11T10:44:24.622Z

I think there is a lot of interesting proposals here. Thank you for taking my first suggestion ever so serious. I, personally, like @GetSwifty's idea of [weak self] in? else *something*. Would that be able to be implemented without breaking compatibility? It would just be syntactic sugar?

agnosticdev · 2018-10-11T11:10:48.842Z

The optional in? is an interesting idea. To make sure I understand this correctly, is this just unwrapping self for you using a guard and if the unwrap fails the closure is returned? Likewise, the else *defaultValue* values could be added and this would be the value returned from the failure to unwrap the self?

GetSwifty · 2018-10-12T17:02:49.386Z

This is the way I was thinking about it:

let myClosure = { [weak self] in? else *defaultValue* {

}

is equal to

let myClosure = { [weak self] in {
    guard let self = self else {
        return *defaultValue*
    } 
}

Having thought about it a bit more, there are pros and cons to a lot of the options to deal with this and I'm thinking there's probably a more generalized syntax that should be considered and applied for this and similar cases. (.e.g the aforementioned Optional Iteration).

jarod · 2018-10-12T18:22:41.317Z

This is very close to the top of my personal list of quality of life improvements I'd like to see in Swift. I think the recurring nature of the topic is a good indicator that it's a common frustration.

I'd personally get a ton of value from a [guard self] that only works for void-returning closures and removes the self prefix requirement inside the closure. Something that works for non-void closures would be nice if a good solution can be found (the proposed in? seems interesting at first glance), but imo there's still enough value even if returning closures aren't supported.

QuinceyMorris · 2018-10-12T18:52:27.464Z

Throwing a random syntactical "?" at a problem involving optionals seems to be getting more popular lately, and it makes me unhappy because it seems so random.

Also, semantically, this particular problem isn't so much about self being optional, as about self being nil, so I'm not sure a "?" is appropriate.

IAC, there's a larger problem, in that capture lists can capture more than just self, and putting a ? on in prevents discriminating which captured optionals are to be guarded.

Jon_Shier · 2018-10-12T20:04:32.471Z

? is an existing optional pattern matcher, so it's not random at all.

GetSwifty · 2018-10-12T22:32:19.132Z

jarod:

and removes the self prefix requirement inside the closure.

I hadn't even thought about that aspect. I wonder if that could be supported currently. E.g. after guard self = self, self no longer has to be used explicitly.

It would be nice to get rid of one of the few places self is required.

Jon_Hull · 2018-10-12T23:36:10.866Z

Agreed. I basically always use either [unowned self] or the basic strong self, depending on the use-case (i.e. whether I am storing the closure on an ancestor or not).

Another option we may not have considered is some sort of annotation on the storage site that tells it to check for a reference cycle and tells the block to convert to 'unowned self' if there is one.

trenskow · 2019-01-29T15:25:04.112Z

I don't know the process here. If we wanted to turn this into a proposal, how does that work?

Lantua · 2019-01-29T15:50:42.061Z

As of Swift 4.2.1, you can already do this:

class Test {
    func foo() {
        let closure: () -> () = { [weak self] in
            if let self = self {
                // do someting
            }

            guard let self = self else {
                return
            }
        }
    }
}

unless I'm missing something.

trenskow · 2019-01-29T16:18:23.029Z

This is the issue. We were discussing syntactic sugar for dealing with all that boilerplate.

So something like this was suggested.

let closure = () -> () = { [weak self] in?
    // self is unwrapped - or closure has returned.
}

Also if the closure returns a value it could be like this

let closure = () -> (Int) = { [weak self] in? else 0
    // self is unwrapped - or closure has returned with 0
}

Lantua · 2019-01-29T16:49:03.401Z

For a starter, this template should be useful.

xwu · 2019-01-29T21:54:36.610Z

Note that this idea has been written up multiple times already. To proceed to review it will generally need to garner a degree of consensus, absent some pressing need to ship before a deadline, and syntactic sugar has been considered low priority for Swift Evolution. I don’t think writing it up again is likely to be a high-yield activity.