When a base type's initialization code calls a method that a derived type overrides, the language must decide what the object's type already is at that moment. Explain the decision, and how C++, Kotlin, Swift and Rust each resolve it and what each resolution costs.

## The underlying decision During construction an object is in a state the type system normally pretends does not exist: some of its parts are initialized and some are not. If the language also has dynamic dispatch, a call made from the partially built part can reach code belonging to the not-yet-built part. So the language must answer: **while a base's initialization runs, what type is this object?** Every mainstream answer is a different point on the tradeoff between honesty and safety. ## C++: the dynamic type changes as construction proceeds C++ says the object *is* whatever has finished being constructed so far. As each constructor in the chain begins, the object's vptr is set to that class's vtable; the standard specifies that inside a base constructor, virtual dispatch resolves to the base's own override, and `typeid` reports the base class. This is internally consistent -- you can never reach code that depends on members that do not yet exist -- but it means a virtual call behaves differently inside a constructor than everywhere else, which surprises readers. And when the base declares the function pure virtual with no implementation, there is nothing to call: the behaviour is undefined and the common runtime response is an immediate abort with a message about a pure virtual call. Destruction mirrors this exactly, running the sequence in reverse. ## Java, C#, Kotlin: the object is its final class immediately On the JVM and CLR an object's class is fixed at allocation, before any constructor body runs. Dispatch therefore always finds the most-derived override -- including when the call originates in a base constructor, at which point the derived class's field initializers and constructor body have not run. The override then reads fields that hold their default values. In Java that is `0`, `false` or `null`. In **Kotlin** the same mechanism produces something sharper: a property declared `val name: String` -- a type that promises non-null -- reads as `null` inside an overridden method called from the superclass constructor, which is one of the few places Kotlin's null safety can be defeated without a platform type or an explicit assertion. This is exactly why Kotlin warns on calling an `open` member from a constructor. **Scala** had the analogous hole with `val`s defined in traits, which is part of why early definitions and later trait parameters and lazy vals exist. The same family has a second, related hazard: publishing `this` from a constructor. Registering the object with a listener list, submitting it to an executor, or storing it in a static map inside the constructor hands a reference to a half-built object to someone else, and no dispatch rule protects against it. ## Swift: forbid the observation Swift makes the compiler enforce **two-phase initialization**. In phase one, a designated initializer must give every stored property introduced by its own class a value, and only then may it call `super.init`. Until phase one is complete for the whole chain, `self` may not be used at all -- no instance method calls, no property reads. Phase two, after the superclass chain returns, is where customization happens and `self` becomes available. The result is that the entire bug family described above is rejected at compile time rather than discovered at runtime. The cost is real rules to learn: designated versus convenience initializers, delegation direction, `required` initializers, and stricter constraints in the presence of subclassing. ## Rust: nothing to observe Rust has neither constructors nor implementation inheritance. A struct value comes into existence only when a literal supplies every field, and only then can any method be called on it. There is no interval during which a value exists but is incomplete, so the question does not arise. Multi-step setup goes through an explicit builder -- a separate type holding optional fields that yields the real value only when it can produce a complete one. The cost is that no automatic hook runs on construction and that the builder is boilerplate the language does not generate for you. ## Practical guidance regardless of language Do not call an overridable method from initialization code, and where possible remove the temptation: seal the type, make the method non-overridable, pass the value the method would have supplied in as a parameter, or move the work to a creation function that constructs the object fully and then calls the method. In languages where the compiler will not stop you, a linter usually will -- and the warning is worth treating as an error, because the resulting bug appears only in subclasses, sometimes only in ones written later by someone else.