docs/proposals/Initialization.rst - third_party/swift - Git at Google

 :orphan:

 Initialization
 ==============

 .. contents::

 Superclass Delegation
 ---------------------
 The initializer for a class that has a superclass must ensure that its
 superclass subobject gets initialized. The typical way to do so is
 through the use of superclass delegation::

   class A {
     var x: Int

     init(x: Int) {
       self.x = x
     }
   }

   class B : A {
     var value: String

     init() {
       value = "Hello"
       super.init(5) // superclass delegation
     }
   }

 Swift implements two-phase initialization, which requires that all of
 the instance variables of the subclass be initialized (either within
 the class or within the initializer) before delegating to the
 superclass initializer with ``super.init``.

 If the superclass is a Swift class, superclass delegation is a direct
 call to the named initializer in the superclass. If the superclass is
 an Objective-C class, superclass delegation uses dynamic dispatch via
 ``objc_msgSendSuper`` (and its variants).

 Peer Delegation
 ---------------
 An initializer can delegate to one of its peer initializers, which
 then takes responsibility for initializing this subobject and any
 superclass subobjects::

   extension A {
     init fromString(s: String) {
       self.init(Int(s)) // peer delegation to init(Int)
     }
   }

 One cannot access any of the instance variables of ``self`` nor invoke
 any instance methods on ``self`` before delegating to the peer
 initializer, because the object has not yet been
 constructed. Additionally, one cannot initialize the instance
 variables of ``self``, prior to delegating to the peer, because doing
 so would lead to double initializations.

 Peer delegation is always a direct call to the named initializer, and
 always calls an initializer defined for the same type as the
 delegating initializer. Despite the syntactic similarities, this is
 very different from Objective-C's ``[self init...]``, which can call
 methods in either the superclass or subclass.

 Peer delegation is primarily useful when providing convenience
 initializers without having to duplicate initialization code. However,
 peer delegation is also the only viable way to implement an
 initializer for a type within an extension that resides in a different
 resilience domain than the definition of the type itself. For example,
 consider the following extension of ``A``::

   extension A {
     init(i: Int, j: Int) {
       x = i + j    // initialize x
     }
   }

 If this extension is in a different resilience domain than the
 definition of ``A``, there is no way to ensure that this initializer
 is initializing all of the instance variables of ``A``: new instance
 variables could be added to ``A`` in a future version (these would not
 be properly initialized) and existing instance variables could become
 computed properties (these would be initialized when they shouldn't
 be).

 Initializer Inheritance
 -----------------------
 Initializers are *not* inherited by default. Each subclass takes
 responsibility for its own initialization by declaring the
 initializers one can use to create it. To make a superclass's
 initializer available in a subclass, one can re-declare the
 initializer and then use superclass delegation to call it::

   class C : A {
     var value = "Hello"

     init(x: Int) {
       super.init(x) // superclass delegation
     }
   }

 Although ``C``'s initializer has the same parameters as ``A``'s
 initializer, it does not "override" ``A``'s initializer because there
 is no dynamic dispatch for initializers (but see below).

 We could syntax-optimize initializer inheritance if this becomes
 onerous. DaveA provides a reasonable suggestion::

   class C : A {
     var value = "Hello"

     @inherit init(Int)
   }

 *Note*: one can only inherit an initializer into a class ``C`` if all
 of the instance variables in that class have in-class initializers.

 Virtual Initializers
 --------------------
 The initializer model above only safely permits initialization when we
 statically know the type of the complete object being initialized. For
 example, this permits the construction ``A(5)`` but not the
 following::

   func createAnA(_ aClass: A.metatype) -> A {
     return aClass(5) // error: no complete initializer accepting an ``Int``
   }

 The issue here is that, while ``A`` has an initializer accepting an
 ``Int``, it's not guaranteed that an arbitrary subclass of ``A`` will
 have such an initializer. Even if we had that guarantee, there
 wouldn't necessarily be any way to call the initializer, because (as
 noted above), there is no dynamic dispatch for initializers.

 This is an unacceptable limitation for a few reasons. The most obvious
 reason is that ``NSCoding`` depends on dynamic dispatch to
 ``-initWithCoder:`` to deserialize an object of a class type that is
 dynamically determined, and Swift classes must safely support this
 paradigm. To address this limitation, we can add the ``virtual``
 attribute to turn an initializer into a virtual initializer::

   class A {
     @virtual init(x: Int) { ... }
   }

 Virtual initializers can be invoked when constructing an object using
 an arbitrary value of metatype type (as in the ``createAnA`` example
 above), using dynamic dispatch. Therefore, we need to ensure that a
 virtual initializer is always a complete object initializer, which
 requires that every subclass provide a definition for each virtual
 initializer defined in its superclass. For example, the following
 class definition would be ill-formed::

   class D : A {
     var floating: Double
   }

 because ``D`` does not provide an initializer accepting an ``Int``. To
 address this issue, one would add::

   class D : A {
     var floating: Double

     @virtual init(x: Int) {
       floating = 3.14159
       super.init(x)
     }
   }

 As a convenience, the compiler could synthesize virtual initializer
 definitions when all of the instance variables in the subclass have
 in-class initializers::

   class D2 : A {
     var floating = 3.14159

     /* compiler-synthesized */
     @virtual init(x: Int) {
       super.init(x)
     }
   }

 This looks a lot like inherited initializers, and can eliminate some
 boilerplate for simple subclasses. The primary downside is that the
 synthesized implementation might not be the right one, e.g., it will
 almost surely be wrong for an inherited ``-initWithCoder:``. I don't
 think this is worth doing.

 *Note*: as a somewhat unfortunate side effect of the terminology, the
 initializers for structs and enums are considered to be virtual,
 because they are guaranteed to be complete object initializers. If
 this bothers us, we could use the term (and attribute) "complete"
 instead of "virtual". I'd prefer to stick with "virtual" and accept
 the corner case.

 Initializers in Protocols
 -------------------------
 We currently ban initializers in protocols because we didn't have an
 implementation model for them. Protocols, whether used via generics or
 via existentials, use dynamic dispatch through the witness table. More
 importantly, one of the important aspects of protocols is that, when a
 given class ``A`` conforms to a protocol ``P``, all of the subclasses
 of ``A`` also conform to ``P``. This property interacts directly with
 initializers::

   protocol NSCoding {
     init withCoder(coder: NSCoder)
   }

   class A : NSCoding {
     init withCoder(coder: NSCoder) { /* ... */ }
   }

   class B : A {
     // conforms to NSCoding?
   }

 Here, ``A`` appears to conform to ``NSCoding`` because it provides a
 matching initializer. ``B`` should conform to ``NSCoding``, because it
 should inherit its conformance from ``A``, but the lack of an
 ``initWithCoder:`` initializer causes problems. The fix here is to
 require that the witness be a virtual initializer, which guarantees
 that all of the subclasses will have the same initializer. Thus, the
 definition of ``A`` above will be ill-formed unless ``initWithCoder:``
 is made virtual::

   protocol NSCoding {
     init withCoder(coder: NSCoder)
   }

   class A : NSCoding {
     @virtual init withCoder(coder: NSCoder) { /* ... */ }
   }

   class B : A {
     // either error (due to missing initWithCoder) or synthesized initWithCoder:
   }

 As noted earlier, the initializers of structs and enums are considered
 virtual.

 Objective-C Interoperability
 ----------------------------
 The initialization model described above guarantees that objects are
 properly initialized before they are used, covering all of the major
 use cases for initialization while maintaining soundness. Objective-C
 has a very different initialization model with which Swift must
 interoperate.

 Objective-C Entrypoints
 ~~~~~~~~~~~~~~~~~~~~~~~
 Each Swift initializer definition produces a corresponding Objective-C
 init method. The existence of this init method allows object
 construction from Objective-C (both directly via ``[[A alloc]
 init:5]`` and indirectly via, e.g., ``[obj initWithCoder:coder]``)
 and initialization of the superclass subobject when an Objective-C class
 inherits from a Swift class (e.g., ``[super initWithCoder:coder]``).

 Note that, while Swift's initializers are not inherited and cannot
 override, this is only true *in Swift code*. If a subclass defines an
 initializer with the same Objective-C selector as an initializer in
 its superclass, the Objective-C init method produced for the former
 will override the Objective-C init method produced for the
 latter.

 Objective-C Restrictions
 ~~~~~~~~~~~~~~~~~~~~~~~~
 The emission of Objective-C init methods for Swift initializers open
 up a few soundness problems, illustrated here::

   @interface A
   @end

   @implementation A
   - init {
     return [self initWithInt:5];
   }

   - initWithInt:(int)x {
     // initialize me
   }

   - initWithString:(NSString *)s {
     // initialize me
   }
   @end

   class B1 : A {
     var dict: NSDictionary

     init withInt(x: Int) {
       dict = []
       super.init() // loops forever, initializing dict repeatedly
     }
   }

   class B2 : A {
   }

   @interface C : B2
   @end

   @implementation C
   @end

   void getCFromString(NSString *str) {
     return [C initWithString:str]; // doesn't initialize B's dict ivar
   }

 The first problem, with ``B1``, comes from ``A``'s dispatched
 delegation to ``-initWithInt:``, which is overridden by ``B1``'s
 initializer with the same selector. We can address this problem by
 enforcing that superclass delegation to an Objective-C superclass
 initializer refer to a designated initializer of that superclass when
 that class has at least one initializer marked as a designated
 initializer.

 The second problem, with ``C``, comes from Objective-C's implicit
 inheritance of initializers. We can address this problem by specifying
 that init methods in Objective-C are never visible through Swift
 classes, making the message send ``[C initWithString:str]``
 ill-formed. This is a relatively small Clang-side change.

 Remaining Soundness Holes
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 Neither of the above "fixes" are complete. The first depends entirely
 on the adoption of a not-yet-implemented Clang attribute to mark the
 designated initializers for Objective-C classes, while the second is
 (almost trivially) defeated by passing the ``-initWithString:``
 message to an object of type ``id`` or using some other dynamic
 reflection.

 If we want to close these holes tighter, we could stop emitting
 Objective-C init methods for Swift initializers. Instead, we would
 fake the init method declarations when importing Swift modules into
 Clang, and teach Clang's CodeGen to emit calls directly to the Swift
 initializers. It would still not be perfect (e.g., some variant of the
 problem with ``C`` would persist), but it would be closer. I suspect
 that this is far more work than it is worth, and that the "fixes"
 described above are sufficient.
	:orphan:

	Initialization
	==============

	.. contents::

	Superclass Delegation
	---------------------
	The initializer for a class that has a superclass must ensure that its
	superclass subobject gets initialized. The typical way to do so is
	through the use of superclass delegation::

	class A {
	var x: Int

	init(x: Int) {
	self.x = x
	}
	}

	class B : A {
	var value: String

	init() {
	value = "Hello"
	super.init(5) // superclass delegation
	}
	}

	Swift implements two-phase initialization, which requires that all of
	the instance variables of the subclass be initialized (either within
	the class or within the initializer) before delegating to the
	superclass initializer with ``super.init``.

	If the superclass is a Swift class, superclass delegation is a direct
	call to the named initializer in the superclass. If the superclass is
	an Objective-C class, superclass delegation uses dynamic dispatch via
	``objc_msgSendSuper`` (and its variants).

	Peer Delegation
	---------------
	An initializer can delegate to one of its peer initializers, which
	then takes responsibility for initializing this subobject and any
	superclass subobjects::

	extension A {
	init fromString(s: String) {
	self.init(Int(s)) // peer delegation to init(Int)
	}
	}

	One cannot access any of the instance variables of ``self`` nor invoke
	any instance methods on ``self`` before delegating to the peer
	initializer, because the object has not yet been
	constructed. Additionally, one cannot initialize the instance
	variables of ``self``, prior to delegating to the peer, because doing
	so would lead to double initializations.

	Peer delegation is always a direct call to the named initializer, and
	always calls an initializer defined for the same type as the
	delegating initializer. Despite the syntactic similarities, this is
	very different from Objective-C's ``[self init...]``, which can call
	methods in either the superclass or subclass.

	Peer delegation is primarily useful when providing convenience
	initializers without having to duplicate initialization code. However,
	peer delegation is also the only viable way to implement an
	initializer for a type within an extension that resides in a different
	resilience domain than the definition of the type itself. For example,
	consider the following extension of ``A``::

	extension A {
	init(i: Int, j: Int) {
	x = i + j // initialize x
	}
	}

	If this extension is in a different resilience domain than the
	definition of ``A``, there is no way to ensure that this initializer
	is initializing all of the instance variables of ``A``: new instance
	variables could be added to ``A`` in a future version (these would not
	be properly initialized) and existing instance variables could become
	computed properties (these would be initialized when they shouldn't
	be).

	Initializer Inheritance
	-----------------------
	Initializers are not inherited by default. Each subclass takes
	responsibility for its own initialization by declaring the
	initializers one can use to create it. To make a superclass's
	initializer available in a subclass, one can re-declare the
	initializer and then use superclass delegation to call it::

	class C : A {
	var value = "Hello"

	init(x: Int) {
	super.init(x) // superclass delegation
	}
	}

	Although ``C``'s initializer has the same parameters as ``A``'s
	initializer, it does not "override" ``A``'s initializer because there
	is no dynamic dispatch for initializers (but see below).

	We could syntax-optimize initializer inheritance if this becomes
	onerous. DaveA provides a reasonable suggestion::

	class C : A {
	var value = "Hello"

	@inherit init(Int)
	}

	Note: one can only inherit an initializer into a class ``C`` if all
	of the instance variables in that class have in-class initializers.

	Virtual Initializers
	--------------------
	The initializer model above only safely permits initialization when we
	statically know the type of the complete object being initialized. For
	example, this permits the construction ``A(5)`` but not the
	following::

	func createAnA(_ aClass: A.metatype) -> A {
	return aClass(5) // error: no complete initializer accepting an ``Int``
	}

	The issue here is that, while ``A`` has an initializer accepting an
	``Int``, it's not guaranteed that an arbitrary subclass of ``A`` will
	have such an initializer. Even if we had that guarantee, there
	wouldn't necessarily be any way to call the initializer, because (as
	noted above), there is no dynamic dispatch for initializers.

	This is an unacceptable limitation for a few reasons. The most obvious
	reason is that ``NSCoding`` depends on dynamic dispatch to
	``-initWithCoder:`` to deserialize an object of a class type that is
	dynamically determined, and Swift classes must safely support this
	paradigm. To address this limitation, we can add the ``virtual``
	attribute to turn an initializer into a virtual initializer::

	class A {
	@virtual init(x: Int) { ... }
	}

	Virtual initializers can be invoked when constructing an object using
	an arbitrary value of metatype type (as in the ``createAnA`` example
	above), using dynamic dispatch. Therefore, we need to ensure that a
	virtual initializer is always a complete object initializer, which
	requires that every subclass provide a definition for each virtual
	initializer defined in its superclass. For example, the following
	class definition would be ill-formed::

	class D : A {
	var floating: Double
	}

	because ``D`` does not provide an initializer accepting an ``Int``. To
	address this issue, one would add::

	class D : A {
	var floating: Double

	@virtual init(x: Int) {
	floating = 3.14159
	super.init(x)
	}
	}

	As a convenience, the compiler could synthesize virtual initializer
	definitions when all of the instance variables in the subclass have
	in-class initializers::

	class D2 : A {
	var floating = 3.14159

	/* compiler-synthesized */
	@virtual init(x: Int) {
	super.init(x)
	}
	}

	This looks a lot like inherited initializers, and can eliminate some
	boilerplate for simple subclasses. The primary downside is that the
	synthesized implementation might not be the right one, e.g., it will
	almost surely be wrong for an inherited ``-initWithCoder:``. I don't
	think this is worth doing.

	Note: as a somewhat unfortunate side effect of the terminology, the
	initializers for structs and enums are considered to be virtual,
	because they are guaranteed to be complete object initializers. If
	this bothers us, we could use the term (and attribute) "complete"
	instead of "virtual". I'd prefer to stick with "virtual" and accept
	the corner case.

	Initializers in Protocols
	-------------------------
	We currently ban initializers in protocols because we didn't have an
	implementation model for them. Protocols, whether used via generics or
	via existentials, use dynamic dispatch through the witness table. More
	importantly, one of the important aspects of protocols is that, when a
	given class ``A`` conforms to a protocol ``P``, all of the subclasses
	of ``A`` also conform to ``P``. This property interacts directly with
	initializers::

	protocol NSCoding {
	init withCoder(coder: NSCoder)
	}

	class A : NSCoding {
	init withCoder(coder: NSCoder) { /* ... */ }
	}

	class B : A {
	// conforms to NSCoding?
	}

	Here, ``A`` appears to conform to ``NSCoding`` because it provides a
	matching initializer. ``B`` should conform to ``NSCoding``, because it
	should inherit its conformance from ``A``, but the lack of an
	``initWithCoder:`` initializer causes problems. The fix here is to
	require that the witness be a virtual initializer, which guarantees
	that all of the subclasses will have the same initializer. Thus, the
	definition of ``A`` above will be ill-formed unless ``initWithCoder:``
	is made virtual::

	protocol NSCoding {
	init withCoder(coder: NSCoder)
	}

	class A : NSCoding {
	@virtual init withCoder(coder: NSCoder) { /* ... */ }
	}

	class B : A {
	// either error (due to missing initWithCoder) or synthesized initWithCoder:
	}

	As noted earlier, the initializers of structs and enums are considered
	virtual.

	Objective-C Interoperability
	----------------------------
	The initialization model described above guarantees that objects are
	properly initialized before they are used, covering all of the major
	use cases for initialization while maintaining soundness. Objective-C
	has a very different initialization model with which Swift must
	interoperate.

	Objective-C Entrypoints
	~~~~~~~~~~~~~~~~~~~~~~~
	Each Swift initializer definition produces a corresponding Objective-C
	init method. The existence of this init method allows object
	construction from Objective-C (both directly via ``[[A alloc]
	init:5]`` and indirectly via, e.g., ``[obj initWithCoder:coder]``)
	and initialization of the superclass subobject when an Objective-C class
	inherits from a Swift class (e.g., ``[super initWithCoder:coder]``).

	Note that, while Swift's initializers are not inherited and cannot
	override, this is only true in Swift code. If a subclass defines an
	initializer with the same Objective-C selector as an initializer in
	its superclass, the Objective-C init method produced for the former
	will override the Objective-C init method produced for the
	latter.

	Objective-C Restrictions
	~~~~~~~~~~~~~~~~~~~~~~~~
	The emission of Objective-C init methods for Swift initializers open
	up a few soundness problems, illustrated here::

	@interface A
	@end

	@implementation A
	- init {
	return [self initWithInt:5];
	}

	- initWithInt:(int)x {
	// initialize me
	}

	- initWithString:(NSString *)s {
	// initialize me
	}
	@end

	class B1 : A {
	var dict: NSDictionary

	init withInt(x: Int) {
	dict = []
	super.init() // loops forever, initializing dict repeatedly
	}
	}

	class B2 : A {
	}

	@interface C : B2
	@end

	@implementation C
	@end

	void getCFromString(NSString *str) {
	return [C initWithString:str]; // doesn't initialize B's dict ivar
	}

	The first problem, with ``B1``, comes from ``A``'s dispatched
	delegation to ``-initWithInt:``, which is overridden by ``B1``'s
	initializer with the same selector. We can address this problem by
	enforcing that superclass delegation to an Objective-C superclass
	initializer refer to a designated initializer of that superclass when
	that class has at least one initializer marked as a designated
	initializer.

	The second problem, with ``C``, comes from Objective-C's implicit
	inheritance of initializers. We can address this problem by specifying
	that init methods in Objective-C are never visible through Swift
	classes, making the message send ``[C initWithString:str]``
	ill-formed. This is a relatively small Clang-side change.

	Remaining Soundness Holes
	~~~~~~~~~~~~~~~~~~~~~~~~~
	Neither of the above "fixes" are complete. The first depends entirely
	on the adoption of a not-yet-implemented Clang attribute to mark the
	designated initializers for Objective-C classes, while the second is
	(almost trivially) defeated by passing the ``-initWithString:``
	message to an object of type ``id`` or using some other dynamic
	reflection.

	If we want to close these holes tighter, we could stop emitting
	Objective-C init methods for Swift initializers. Instead, we would
	fake the init method declarations when importing Swift modules into
	Clang, and teach Clang's CodeGen to emit calls directly to the Swift
	initializers. It would still not be perfect (e.g., some variant of the
	problem with ``C`` would persist), but it would be closer. I suspect
	that this is far more work than it is worth, and that the "fixes"
	described above are sufficient.