On Oct 18, 2014, at 23:46 , Rick Mann <rm...@latencyzero.com> wrote: > > The rules on initializers don't make sense to me, in all honesty.
Yes, but that tells us more about you than about Swift — specifically, it tells us that you’re more focused on what would ease your coding task in this one case than on embracing more formal relationships between initializers. Understandable, but not really useful to anyone else, if you’ll forgive my saying so. > If you imagine that instantiating the base class by calling any of the > initializers results in a completely instantiated object, the subclass should > also be able to call any of the inherited initializers. Yes, but … (It’s all about the “yes, but”s.) … calling *up* from a subclass convenience initializer bypasses all of the subclass designated initializers (except in the case that the subclass overrides some or all of the superclass's, which introduces its own semantic ambiguities). That means that the subclass can’t be sure it initialized its own properties, since that’s the purview of designated initializers — at least not without supplementary rules. That in turn destroys the integrity of Swift’s 2-pass initialization process. The reason that the Swift rules make you uncomfortable is that the Obj-C rules for initializers are comfortably loose, to say the least. It’s always an option to go on using Obj-C, of course. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
