0

Swift does make a distinction between designated and convenience initializers. The documentation, however, never states why this distinction is made.

From a programmer's point of view, it seems like an extra burden: I have to think whether some initialization mechanism is "designated" or "convenience" and there are even some practical inconveniences like that I cannot call a convenience constructor of the super class which might sometimes be totally appropriate. There have to be some advantages of this concept in return. Otherwise Apple would not have introduced this feature. So what is the reason for introducing this distinction in Swift? A references to an official statements would nice.

Community
  • 1
  • 1
gexicide
  • 38,535
  • 21
  • 92
  • 152
  • 4
    @close votes: Opinion based? Are you serious? I am asking for a reason for this feature, especially an official statement. I am not asking for an opinion, I am asking for an explanation using hard facts. – gexicide Jul 12 '14 at 15:55
  • 1
    If you're looking for an official statement from Apple, try their [developer forums](http://devforums.apple.com). – rickster Jul 12 '14 at 17:16

2 Answers2

1

The distinction between designated initializers and convenience initializers is not new — it's been part of the Cocoa environment for a long time. The reason for this convention is to ensure that all the internal state managed by a class is configured as intended before a subclass, or code external to the class, starts trying to use it.

Explicit initialization is one of the "safety" features of Swift. Using values before they're initialized can lead to undefined behavior (read: bugs) in C. If you declare a variable in Swift, it has to have a value. (Optionals let you fudge this a bit while still being explicit about it.) Making Cocoa's initializer chaining convention into a requirement is how Swift ensures initialization safety on top of class inheritance.

But don't take my word for it. < /LeVar> There's a great explanation of this in the series of Swift talks from WWDC — check the videos.

rickster
  • 124,678
  • 26
  • 272
  • 326
0

Totally agree on the practical inconvenience, not being able to call a convenience constructor of the super class is a total PITA...

Though I don't have any "official" answer, the conclusion I've reached is that calling a designated constructor is the only future proof way to do so.

Convenience constructors always have the possibility of being changed in future API-releases, so making the initialization of your class depend on one is highly unsafe, while the designated initializer is always going to work, no matter what changes the API is going to go through along the way...

Markus Buhl
  • 1,484
  • 2
  • 9
  • 5
  • But if they change the API and remove a convenience initializer, all my code that creates an object using such initializer will break anyway! There is no way how you can simply remove a part of a published API. Convenience initializers don't change that. – gexicide Jul 12 '14 at 10:37