[swift-evolution] [Proposal][Discussion] Modular Swift

[Brent Royal-Gordon]

> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution <swift-evolution at 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