[swift-evolution] [Proposal][Discussion] Modular Swift
Robert Widmann
devteam.codafi at gmail.com
Tue Feb 21 19:59:39 CST 2017
> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
>
> To my mind, any submodule system for Swift should be designed to relieve the pressure for long files, and make it easy to group tightly related files into a single unit with shared visibility. That way developers can easily organize their code into smaller files while utilizing Swift’s pattern of providing protocol conformances in extensions and keeping implementation details hidden from the rest of the module at large.
>
Wonderful, because that’s absolutely supported by this proposal. To group tightly related files into a single unit, simply declare a submodule for them and extend it in each of your related files. Any variables defined with `internal` access will be visible across those files to those extensions and only those extensions (see the section on access control and modules). Any variables declared fileprivate or private will, obviously, not be visible across these files. As an example:
// FooUtilities.swift
//
// -module-name=Foo
// module Foo {
// Defines Foo.Utilities
module Utilities {
public func exportableOutsideThisSubmodule() {}
func visibleInThisSubmodule() {}
private func invisibleToOtherFiles() {}
}
//}
// FooUtilities+MoreUtilities.swift
extension Utilities {
private func privateHelper() {
visibleInThisSubmodule()
}
}
I’m not sure where you got the impression that we were just trying to make another fileprivate happen.
>
> Nevin
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/e76eea81/attachment.html>
More information about the swift-evolution
mailing list