[swift-evolution] [Draft] Guarded closures and `@guarded` arguments

[David Hart]

Hi Matthew,

Finally found time to read the proposal. Much better than the previous iterration. I’m not a huge fan of the proposed syntax either but don’t have the energy for bike shedding :)

As a side note, I’d like to say that I would not use this very often. I much more often use unowned capture variables when its clear that the closure can’t outlive the captured variable. For example, my code often looks like this:

class MyViewController : UIViewController {
    var button: ActionButton!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        button.addAction { [unowned self] in
            print("self: \(self)")
        }
    }
}

> On 20 Feb 2017, at 18:01, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 20, 2017, at 8:33 AM, Florent Bruneau <florent.bruneau at intersec.com> wrote:
>> 
>> 
>> 
>>> Le 20 févr. 2017 à 06:35, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> a écrit :
>>> 
>>>> On Feb 19, 2017, at 2:57 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> A guarded closure may be created by prefixing a bound instance method reference with the `?` sigil:
>>>> 
>>>> ```swift
>>>> let guarded = ?myObject.myMethod
>>>> 
>>>> // desugars to:
>>>> let guarded = { [weak myObject] in
>>>> guard let myObejct = myObject else {
>>>> return
>>>> }
>>>> myObject.myMethod()
>>>> }
>>>> ```
>>> 
>>> I like this in principle, but I don't like the syntax. The `?` is cryptic and looks pretty strange in prefix position. I think what I'd like to see is:
>>> 
>>> 	let guarded = weak myObject.myMethod
>> 
>> I like the idea of weak closures even if this may conflict with the fact closures are already internally refcounted object. While we cannot have weak references to closure in the language, using `weak` might be misleading in some ways.
>> 
>> In term of syntax, the `weak` keyword looks nice (much better than the '?' and @guarded once). The weak could be used on both sides.
>> 
>> ```swift
>> addAction(action: weak Action)
>> addAction(action: weak myAction)
>> ```
>> 
>> However, I think this might still look weird with inlined closures, in particular in case you use the suffix syntax for closures:
>> 
>> ```swift
>> addAction() weak {
>>   /* */
>> }
>> ```
> 
> 
> We wouldn’t want to use `weak` if this has the guarded behavior I proposed.  We could use `guarded` though.
> 
> There are a couple of important things enabled by having the language implement the guarded behavior.  
> 
> First, the implementation could release the entire closure context as soon as one of the guarded captures is released.  This is not possible if users write the code out manually.  Second, in the future directions I discuss allowing libraries to detect that the guard has been triggered and the closure has become a no-op.  This is also not possible when users write the guard out manually and would be quite desirable for libraries that want to discard their reference to the closure after it becomes a no-op.
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170222/0478f005/attachment.html>