[swift-evolution] Sketch: Teach init a 'defer'-like ability to deinit

[Xiaodi Wu]

On Fri, Jun 10, 2016 at 9:55 PM, Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> I really love this idea.  My mental model of it is that it is exactly like
> ‘defer’, except it works on the lifetime of the object instance instead of
> a function/method.  Same thing, different scope.
>
> I like how the creation and destruction are right next to one another.  It
> also solves a lot of potential issues with partial initialization, I
> believe.
>
> I might spell it ‘deferToDeinit’ or 'deferUntilDeinit'
>
> The only issue I see is accidentally capturing self strongly.  Is there a
> way to mark a closure as implicitly unowned self so the end programmer
> doesn’t have to worry about it?
>

I really like this idea as well. Does it need to be a regular closure? This
is one of those things that can be built into the language itself, surely?
Then the implicitly unowned self part would be taken care of...


>
> Thanks,
> Jon
>
> Twitter tl;dr:
> >* Brent: So each instance must remember which init was used for it and then run the matching deinit code at deinit time?
> *>* Me: In my version, the constructive act and destructive act are always paired, even redundantly, using a stack if needed
> *>* Graham: so all your deferredDeinit blocks would run, no matter which init was invoked?
> *>* Brent: Closure stack in the worst case. Might be able to optimize to something cheaper if no captures.  Degenerate case: `for i in 0..<10 { deinit { print(i) }
> *
> So continuing on from Twitter, assuming the compiler cannot optimize in the case of multiple inits, and init-redirections, how about allowing traditional deinit as well, and introduce compile-time optimization into traditional de-init if the compiler finds only one initialization path per class? We can also warn anyone using my version in a complicated degenerate way that it can be costly through education, manual, etc. It would also help if (especially in Cocoa), you could legally use shared initialization setup closures.
>
> If I create an observer, I want to be able to handle its end-of-life at that point. If I allocate memory, ditto. Etc etc. Surely Swift should be able to support doing this.
>
> -- E
>
> >* On Jun 8, 2016, at 3:43 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote:
> *> >* I really like this idea. Spatially moving cleanup next to unsafe operations is good practice.
> *> >* In normal code, I want my cleanup to follow as closely as possible to my unsafe act:
> *> >* let buffer: UnsafeMutablePointer<CChar> = UnsafeMutablePointer(allocatingCapacity: chunkSize)
> *>*     defer { buffer.deallocateCapacity(chunkSize) }
> *> >* (Sorry for the horrible example, but it's the best I could grep up with on a moment's notice)
> *> >* I like your idea but what I want to see is not the deinit child closure in init you propose but a new keyword that means defer-on-deinit-cleanup
> *> >* self.ptr = UnsafeMutablePointer<T>(allocatingCapacity: count)
> *>*     deferringDeInit { self.ptr.deallocateCapacity(count) }
> *> >* Or something.
> *> >* -- E
> *>* p.s. Normally I put them on the same line with a semicolon but dang these things can be long
> *> >>* On Jun 8, 2016, at 10:54 AM, Graham Perks via swift-evolution <swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution> <mailto:swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution>>> wrote:
> *>> >>* Teach init a 'defer'-like ability to deinit
> *>> >>* 'defer' is a great way to ensure some clean up code is run; it's declaritive locality to the resource acquisition is a boon to clarity.
> *>> >>* Swift offers no support for resources acquired during 'init'.
> *>> >>* For an example, from https://www.mikeash.com/pyblog/friday-qa-2015-04-17-lets-build-swiftarray.html <https://www.mikeash.com/pyblog/friday-qa-2015-04-17-lets-build-swiftarray.html> <https://www.mikeash.com/pyblog/friday-qa-2015-04-17-lets-build-swiftarray.html <https://www.mikeash.com/pyblog/friday-qa-2015-04-17-lets-build-swiftarray.html>>
> *
> >> >>* init(count: Int = 0, ptr: UnsafeMutablePointer<T> = nil) {
> *>>*     self.count = count
> *>>*     self.space = count
> *>> >>*     self.ptr = UnsafeMutablePointer<T>.alloc(count)
> *>>*     self.ptr.initializeFrom(ptr, count: count)
> *>>* }
> *>> >>* deinit {
> *>>*     ptr.destroy(...)
> *>>*     ptr.dealloc(...)
> *>>* }
> *>> >>* Another 'resource' might be adding an NSNotificationCenter observer, and wanting to unobserve in deinit (no need in OS X 10.11, iOS 9, but for earlier releases this is a valid example).
> *>> >>* Changing the above code to use a 'defer' style deinit block might look like:
> *>> >>* init(count: Int = 0, ptr: UnsafeMutablePointer<T> = nil) {
> *>>*     self.count = count
> *>>*     self.space = count
> *>> >>*     self.ptr = UnsafeMutablePointer<T>.alloc(count)
> *>>*     self.ptr.initializeFrom(ptr, count: count)
> *>> >>*     deinit {
> *>>*         ptr.destroy(...)
> *>>*         ptr.dealloc(...)
> *>>*     }
> *>> >>*     // NSNotificationCenter example too
> *>>*     NSNotificationCenter.defaultCenter().addObserver(...)
> *>>*     deinit {
> *>>*         NSNotificationCenter.defaultCenter().removeObserver(...)
> *>>*     }
> *>>* }
> *>> >>* The need to provide a separate implemention of deinit is gone. Reasoning for 'defer' applies here. There is good locality between what was initialized and what needs cleaning up.
> *>> >>* Considerations:
> *>>* 1. Should deinit blocks be invoked before or after code in an explicit deinit method?
> *>>* 2. Should deinit blocks be allowed in other methods; e.g. viewDidLoad()?
> *>>* 3. How should deinit blocks be prevented from strongly capturing self (thus preventing themselves from ever running!)?
> *>
>
>
>
> _______________________________________________
> 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/20160610/59c6f11f/attachment.html>