Thanks for your reply, @jrose.
I had suspected that the issue had to do with not knowing which designated initializer the superclass's convenience initializer was going to call (given that convenience initializers call a designated initializer on the dynamic type), so it's good to have confirmation of that. Still, it seems a bit odd to me that simply by introducing any stored property that must be given as a parameter to my subclass's designated initializer—and which by definition would not be present in the signatures of any of the superclass's designated initializers—I suddenly lose the ability to use all of a superclass's convenience initializers. Instead, I am presented with the following two choices:
- Make my new stored property an optional value (à la implicitly unwrapped outlets) and use automatic initializer inheritance, or
- Reverse engineer the behavior of the superclass's convenience initializer
It's a shame that there doesn't seem to be any other way around this. Forcing programmers to "reinvent the wheel", as it were, when initializing subclasses just doesn't feel very Swifty to me.