> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution > <swift-evolution@swift.org> wrote: > > It has been my hope that a lightweight module system will remove the need for > `private` *and* `fileprivate`.
I really doubt it will. `private`/`fileprivate` works because you can also access `internal` at the same time. What I mean by that is, think about code like this: // Foo.swift public class Foo { public init() { … } func doBar() -> Quux { return helper(in: randomRange()) } private func helper(in range: Range<Int>) -> Quux { … } } // Bar.swift public class Bar { public static let shared = Bar() func baz(with foo: Foo) { let quux = foo.doBar() process(quux) } private func process(_ quux: Quux) { … } } These classes have `public` APIs that are externally visible, `internal` APIs for communicating with each other, and `private` APIs for implementation details. Now try to reproduce the same design with submodules and `public`/`internal` only: public import MyMod.Foo public import MyMod.Bar module Foo { public class Foo { public init() { … } ??? func doBar() -> Quux { return helper(in: randomRange()) } func helper(in range: Range<Int>) -> Quux { … } } } // Bar.swift module Bar { public class Bar { public static let shared = Bar() ??? func baz(with foo: Foo) { let quux = foo.doBar() process(quux) } func process(_ quux: Quux) { … } } } The `doBar()` and `baz()` methods have to be either exposed to third parties or kept away from yourself. That's just not viable. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution