What are the actual consequences of not calling "super.init()" in an NSObject subclass's designated initializer?
In trying to figure out a memory leak, I noticed the following code in the superclass of the class of the instance that is being leaked, which is a Swift NSObject subclass with @objcmembers:
override public required init() {
// empty
}
However Apple's documentation says you "must" not do this:
In a custom implementation of this method, you must invoke super’s Initialization then initialize and return the new object.
So ... why does this compile if you must not do it? And what are the consequences of actually not calling "super.init()" here?
In the Obj-C world, it's well known that -[NSObject init] does nothing except return self, and there's no chance that this could change because too much historical code relies on the known behavior.
In Swift, it's conceivable that not following the exact Swift initializer pattern might mess things up in Swift-specific ways, but I believe that for subclasses of NSObject the compiler actually inserts super.init() for you, so you don't need it explicitly.
However, on that last point, I may be misremembering something, so hopefully someone who has the details at their fingertips will jump in and tell you exactly.
So, I don't think this has any chance of causing a memory leak.
If a subclass initializer performs no customization in phase 2 of the initialization process, and the superclass has a zero-argument designated initializer, you can omit a call to super.init() after assigning values to all of the subclass’s stored properties.
The compiler enforces that a designated initializer of a subclass calls super. As quoted above, in certain situations you can omit the explicit call to super; the compiler will insert the call for you.