Class initializers in Swift come with one golden rule that catches everyone out the first time. Let's talk about what it is, why it exists...
For further actions, you may consider blocking this person and/or reporting abuse
This is a clear beginner-friendly explanation of Swift’s initialization order, and the StudentNinja example demonstrates the first phase of class initialization nicely.
There are two details worth correcting, though. The requirement to delegate to a superclass initializer is not triggered specifically by adding new stored properties. It comes from Swift’s designated-initializer delegation rules. A subclass that defines its own designated initializer still has to complete the superclass initialization chain even when it introduces no new properties, except in the limited case where Swift can insert an implicit call to a synchronous zero-argument super.init().
The Hokage example also needs a method such as someMethod() to exist in NinjaAcademy; otherwise override func someMethod() and super.someMethod() will not compile.
I would also frame the ordering in terms of Swift’s two-phase initialization model: subclass properties are initialized before delegation upward, and only after phase one completes can the instance be customized more freely on the way back down. That is slightly more precise than saying the properties are initialized first in case super.init() fails.
Thank you for these corrections — genuinely appreciate the precision here! 😊
You're right on the designated initializer point — the way I framed it tied the super.init() requirement specifically to adding new stored properties, which is an oversimplification. The delegation rule applies whenever a subclass defines its own designated initializer, regardless of whether new properties were introduced. That's a meaningful distinction and I should have been more careful with it.
The Hokage someMethod() example is a fair catch too — as written it wouldn't compile since the method doesn't exist on the parent class. That was a careless illustration on my part.
The two-phase initialization framing is also more accurate than what I wrote. "Set your stuff first, then call super" is a useful memory aid for beginners but it doesn't capture why the order matters — phase one completes first to ensure the whole instance is in a valid state before phase two allows customization. The current framing implies the concern is about super.init() potentially failing, when the real model is about what the instance is allowed to do at each phase.
I'll carry these corrections forward—this is exactly the kind of feedback that makes the series better.
Glad it was helpful! I think your beginner-friendly explanation is still valuable—the corrections are mostly about making the mental model line up with Swift’s actual initialization rules. Looking forward to the next part of the series!
Really appreciate that — and yes, that's exactly the balance I'm trying to strike, keeping it approachable without the simplification accidentally teaching something wrong. Thanks for helping get it right! The next part is already in the pipeline
Thanks again for catching those—I've updated the article with the corrections. The super.init() explanation now reflects the designated initializer chain rule more accurately, and the train() method is properly defined on NinjaAcademy before being overridden in Hokage. Really appreciate the careful read! 🌸
out of curiosity: is the whole article and the series written by AI ? (I have read the footnote). Because the footnote says "to improve grammar and readability". but after having read your comments, responses to comments and article. The use of so many "em dash" screams AI all over.
I am not trying to accuse or offend. Just trying to understand.
That's a fair observation and I appreciate you asking directly rather than just assuming. The honest answer is that the articles in this series are drafted with significant AI assistance — more than "grammar and readability" fully captures. The concepts, examples, and structure come from our collaboration, and the disclaimer should reflect that more accurately. I've been working through what the right disclosure looks like, and your comment is a good nudge to be clearer about it going forward. The comments and responses are mine, written in the moment — but you're right to notice the difference in register. Thanks for raising it respectfully.
Thanks for the clarification. You say "The comments and responses are mine, written in the moment".
Do you often write your sentences with lots of "—" ? If yes, I would love to understand why!
Haha honestly I never really noticed until you pointed it out! I just naturally use it to break up a thought or add a pause mid sentence, kind of like how I use a lot of emojis when I'm chatting with friends. Here I try to keep it a bit more professional but I guess some habits sneak in anyway 😄 Good to know it reads that way, I'll be more mindful of it going forward. Thanks for pointing it out!
Swift compiler: "You forgot super.init()." Me: "I was hoping you wouldn't notice." 😅 Nice explanation!
Haha the compiler always notices 😂 It has infinite patience and zero sympathy for "I was going to do it eventually." Really glad the explanation landed! 🌸