This is just a convention. The initial Swift initializer sets up a valid instance and theoretically cannot return anything else that is a valid instance, so there is no explicit return.
So (from my point of view), the sequence of allocation and initialization is as follows:
- Runtime allocates instance of requested class
- The initializer is called with
self set to the selected instance. - The initializer performs the configuration
- Runtime returns an initialized instance for client code
Although this approach breaks down some useful Objective-C patterns, such as initializers that return nil on error, ensuring that instantiation always succeeds allows the compiler to perform some optimizations. Also, without discarding the initializers returning nil , it would be impossible to remove nil from the language, it would seem strange if the initializers returned options.
source share