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

[Dennis Lysenko]

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160627/60bdb94f/attachment.html>