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

[Graham Perks]

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

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!)?


Cheers,
Graham Perks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160608/5e63c07c/attachment.html>