[swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

L. Mihalkovic laurent.mihalkovic at gmail.com
Mon Jun 27 15:35:48 CDT 2016



Regards
(From mobile)

> On Jun 27, 2016, at 10:18 PM, Dennis Lysenko via swift-evolution <swift-evolution at swift.org> wrote:
> 
> My 2c:
> 
> This proposal is made more appealing to me because it is not simply a 'beginners will get confused' issue. 
> 
> I have written tens of thousands of lines of Swift from Swift 1 to the Swift 3 preview and I still can't shake occasionally accidentally capturing `self` strongly when I, for example, assign a closure as a listener/action to a UI component.

The problem of is that it is easier for an app to survive an accidental extra capture than it is for it the survive a missing one.. So if this is really for beginners, then it is much better to keep the current behavior which will lead them to have leaky apps, than it is to give them apps whre objects will vanish from under their feet... granted neither is good to begin with.


> 
> To spin off of Christopher's last email, my proposal is thus: we could include the original proposal (without numbered addendums) and use tooling, but have it alleviate the burden another way: have the tooling insert `[strong self]` by default when autocompleting a block.
> 
> BTW, @Manuel Krebber: this proposal would not affect your run-of-the-mill map statement. array.map { object in object.property } requires no explicit capture since object is intuitively strongly captured there.
> 
> What do we think? Worth discussing?
> 
> On Mon, Jun 27, 2016 at 12:10 PM Christopher Kornher via swift-evolution <swift-evolution at swift.org> wrote:
>>>> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> All object references used within a closure must unwrap successfully for the closure to execute.
>>> I agree with the logic of this proposal, but this is the confusing part or a part that I slightly disagree with.
>>> 
>>> By this logic, the block won't be invoked if all captured variables can't be unwrapped, which is definitely confusing to the newcomer (to whom this is partially targetted as you've mentioned) if he puts a breakpoint in it and doesn't get executed even when he's explicitely invoking it somewhere.
>>> 
>>> On the other hand, when it crashes, it gives him some idea that something's wrong.
>> 
>> Tooling could alleviate some of this mystery. For example:
>> 
>> 1) In Xcode and other GUIs, closures that will not be executed could be greyed-out, perhaps with the reason overlaid on the closure perhaps this would only happen when a breakpoint was set within the closure. Perhaps the app could break on the on breakpoints within non-executing closures and notify the user that the closure did not execute.
>> 
>> 2) Debugger console commands could be added to describe the execution state of closures in scope and closure variables.
>> 
>> 3) Debug apps could bottleneck all closures through a function that that can be break-pointed. Breakpoints could be edited to filter on specific closures. 
>> 
>> 4) Some runtime switches could be added to enable verbose login modes for closures.
>> 
>> I don’t think that this is an insurmountable problem. There are many features of modern applications that are difficult to debug.
>> 
>>> 
>>> 
>>>> 
>>>> I believe that these are safe, sensible and understandable rules that will eliminate the need for capture lists for many closures. What do you think?
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> 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/20160627/8995e4d9/attachment.html>


More information about the swift-evolution mailing list