Consider the follow class (equally applicable to a struct, as well) in a module:
public class Foo {
public func bar() {
// method body
}
}
>
Marking a class public does not necessarily imply that the developer wants the class to be initialized publicly. For example, I often write base classes that exist solely for me to be able to subclass them. I give these superclasses internal
initializers so that their subclasses can access them, but those in the outside world shouldn't be using them directly. For example, Operation
in Foundation
has no accessible initializers, yet the class is public. It is simply meant to be subclassed. This is considered an abstract class in Objective-C.
Since Swift doesn't contain explicit support for abstract classes, the act of making a class public but without public initializers basically serves as an abstract class (except each function must still have a default definition, either in the class itself or some protocol extension).
With this in mind, here are some Swift rules:
private
, all variables, inits, and functions will default to private
.internal
(which is default), public
, or open
, all variables, inits, and functions will default to internal
.public
in Objective-C are imported into Swift as open
, due to there being no such distinction in Objective-C.That second one is the one you are running into. The default init is picking up the default internal
because the last thing Swift wants to do is expose your init as public API unless it is explicitly instructed to do so.
Note: In my tests (at least in the playground), it seems that with the introduction of fileprivate
:
private
or fileprivate
, it seems that class members default to fileprivate
unless explicitly annotated private
.