[swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

Callionica (Swift) swift-callionica at callionica.com
Wed Sep 14 12:51:47 CDT 2016

How do you figure unowned pointers help you detect errors? Dangling
pointers give you no guarantees.

On Wednesday, September 14, 2016, Karl Wagner via swift-evolution <
swift-evolution at swift.org> wrote:

> Sorry to hijack the thread, but I was working to fix the fact that we
> can't have optional unowned pointers in swift and Jordan said he didn't
> think anybody ever asked for it before. It made me worry about the kind of
> practices swift is encouraging.
> The overhead of using weak pointers isn't massive, but it involves locking
> and updating global tables (http://stackoverflow.com/
> questions/23689155/lots-of-overhead-for-weak-property). Unowned pointers
> don't have this overhead, and can also help you detect errors because they
> are fail-deadly.
> But yeah, I'd like to be able to reference non-owning instance methods.
> This
> <https://itunes.apple.com/app/apple-store/id922793622?pt=814382&mt=8&ct=how_i_email>
> is how I Email now
> On Sep 14, 2016 at 7:45 am, <Rick Mann
> <javascript:_e(%7B%7D,'cvml','rmann at latencyzero.com');>> wrote:
> > On Sep 13, 2016, at 22:34 , Xiaodi Wu via swift-evolution <swift-evolution at swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
> >
> > It's similar to Linus' argument against using kernel debuggers (https://lwn.net/2000/0914/a/lt-debugger.php3). Understanding your code at a level above the source, and being careful, make you a better developer. There are no features in swift which compensate for a lack of understanding about how your code works.
> Get off my lawn!
> --
> Rick Mann
> rmann at latencyzero.com <javascript:_e(%7B%7D,'cvml','rmann at latencyzero.com');>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160914/4ef86696/attachment.html>

More information about the swift-evolution mailing list