Oh, I see. You’re questioning the motivation of having scope-granularity submodules at all! My misunderstanding.
I actually hadn’t considered this as added complexity. In my mind, a scoped module declaration seems more Swifty than a file module declaration. It builds on the existing syntax in Swift for defining other sorts of scopes, e.g. types. Cheers, Jaden Geller > On Feb 20, 2017, at 10:41 PM, Jonathan Hull via swift-evolution > <swift-evolution@swift.org> wrote: > > I think my question is: Why do we want to allow submodules that are smaller > than a file? What does that give us to offset the added complexity? > > Thanks, > Jon > >> On Feb 20, 2017, at 6:44 PM, Robert Widmann <devteam.cod...@gmail.com >> <mailto:devteam.cod...@gmail.com>> wrote: >> >> >>> On Feb 20, 2017, at 9:36 PM, Jonathan Hull <jh...@gbis.com >>> <mailto:jh...@gbis.com>> wrote: >>> >>> What is the rational for having modules covering only part of a file? >>> Wouldn’t it be less clutter to have an annotation which worked for the >>> whole file. At the very least it would be nice to have an option to spell >>> it in a way that applies to the whole file. Otherwise, everything will be >>> indented another level. >> >> That is a valid spelling (Rust, IIRC, allows that spelling), but one that is >> easy to miss sitting in a file and makes it confusing to introduce >> submodules. If you include the annotation then define a submodule later >> down in the file, suddenly you have to remember whether you annotated the >> file or whether the submodule you’ve just written is going into the >> top-level module. See: >> >> // -module-name=Foo >> // module Foo { >> module Bar; // Shorthand for “This file defines Foo.Bar” >> >> /* Code */ >> >> // This defines “Foo.Bar.Baz”, but would you know that if it appeared below >> the fold? >> module Baz {} >> //} >> >> If anything, this can be added later if evolution converges on it. >> >>> >>> I would honestly love to see something which just maps modules to >>> folders/groups for simplicity sake. >>> >> >> There is nothing about this scheme that prevents you from organizing your >> code this way. However, modulo that particular method of organization, you >> don’t really gain much as a user of the language by imposing this >> restriction. >> >>> I haven’t thought about it too much yet, so I could easily be missing >>> something obvious... >>> >>> Thanks, >>> Jon >>> >>> >>>> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> Good Evening All, >>>> >>>> Jaden Geller and I have been considering a (sub)module system for Swift >>>> that would complement the existing language but also provide sorely needed >>>> modularity. A draft of the proposal is attached to this email, but it can >>>> also be read as a gist >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a> if you >>>> desire. >>>> >>>> Cheers, >>>> >>>> ~Robert Widmann >>>> >>>> Modular Swift >>>> >>>> Proposal: SE-NNNN <https://gist.github.com/CodaFi/NNNN-filename.md> >>>> Authors: Robert Widmann <https://github.com/codafi>, Jaden Geller >>>> <https://github.com/JadenGeller> >>>> Review Manager: TBD >>>> Status: Awaiting review >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#introduction>Introduction >>>> >>>> Almost every major programming language supports some form of modular >>>> programming through constructs like (sub)modules, packages, or interfaces. >>>> Swift, though it provides top-level modules to organize code under, does >>>> not provide a complete implementation of any of these concepts, which has >>>> led instead to the proliferation of access control levels. This has not >>>> proven an effective way to decompose programs into manageable parts, and >>>> exposes the need for a real system of modules to solve this modularity >>>> problem once and for all. >>>> >>>> Separation of code into distinct islands of functionality should be a >>>> first-class construct in the language, not dependent on external files and >>>> tools or filesystems. To that end, we propose the introduction of a >>>> lightweight module system for Swift. >>>> >>>> Swift-evolution thread >>>> <applewebdata://6211E639-228B-457B-B598-8F026C4DC4FA> >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#motivation>Motivation >>>> >>>> Swift has reached a point in its evolution where rich libraries and large >>>> projects that take on many dependencies have matured significantly. To >>>> accomodate the information-hiding and semantics-signalling needs of these >>>> users at the time, Swift began its access control story with just three >>>> access modifiers: public, private, and internal then grew fileprivate and >>>> open as the need to express locality of implementation and >>>> "subclassability" arose respectively. In doing so, Swift's access control >>>> scheme has become anti-modular. >>>> >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#proposed-solution>Proposed >>>> solution >>>> >>>> We propose the introduction of a lightweight module system for Swift. More >>>> than simply namspaces, a module declaration interacts with Swift's access >>>> control to provide an API boundary that allows better control over an >>>> interface's design. >>>> >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#detailed-design>Detailed >>>> design >>>> >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#syntax>Syntax >>>> >>>> A module is a named region that introduces a lexical scope into which >>>> declarations may be nested. The name of the module can be used to access >>>> these member declarations. A module, like other aggregate structures in >>>> Swift, may be extended with new declarations over one or more translation >>>> units (files). >>>> >>>> We propose a new declaration kind, module-decl be added to the language. A >>>> proposed grammar using the new modulekeyword is given below: >>>> >>>> GRAMMAR OF A MODULE DECLARATION >>>> >>>> module-declaration -> `module` module-identifier module-body >>>> module-name -> identifier >>>> module-body -> { module-members(opt) } >>>> module-members -> module-member module-members(opt) >>>> module-member -> declaration | compiler-control-statement >>>> GRAMMAR OF A DECLARATION >>>> >>>> + declaration -> module-declaration >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#general-semantics>General >>>> Semantics >>>> >>>> Syntax and semantics for imports, as it already supports referencing >>>> submodules imported from C and Objective-C modules, remains unchanged: >>>> >>>> // The outermost module is given explicitly >>>> // by passing `-module-name=Foo` or exists implicitly, as today. >>>> // module Foo { >>>> public class A {} >>>> >>>> module Bar { >>>> module Baz { >>>> public class C {} >>>> } >>>> >>>> public class B {} >>>> } >>>> >>>> let message = "Hello, Wisconsin!" >>>> // } // End declarations added to module Foo. >>>> To consume this interface: >>>> >>>> // imports all of Foo, Foo.Bar, and Foo.Bar.Baz >>>> import Foo.Bar.Baz >>>> >>>> // imports Foo.A as A >>>> import class Foo.A >>>> // imports Foo.Bar.B as B >>>> import class Foo.Bar.B >>>> // imports Foo.Bar.Baz.C as C >>>> import class Foo.Bar.Baz.C >>>> A module declaration may only appear as a top-level entity or as a member >>>> of another module declaration. The following code is therefore invalid: >>>> >>>> module Foo { >>>> class Bar { >>>> module Baz {} // error: module declaration cannot be nested inside >>>> type 'Bar' >>>> } >>>> } >>>> To extend an existing module declaration, simply reference its module name >>>> in an extension declaration. >>>> >>>> // In module 'Foo' >>>> module Bar { >>>> public class A {} >>>> >>>> module Baz {} >>>> } >>>> >>>> extension Bar { >>>> public struct B {} >>>> } >>>> >>>> extension Bar.Baz { >>>> public enum C { case D } >>>> } >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#modules-and-access-control>Modules >>>> and Access Control >>>> >>>> The semantics of some existing access control modifiers shall also be >>>> extended to support module declarations: >>>> >>>> open and public declarations are exported by a module for consumption by >>>> clients of the module. >>>> internal declarations scope over the entire module and any derived >>>> submodules. >>>> By default, to preserve encapsulation of interfaces, modules are "sealed" >>>> and may only be "opened" by explicit named import. However, it is often >>>> desirable to export a module and a set of submodules or even modules from >>>> external dependencies along with a given interface. We propose the public >>>> keyword be used for this purpose: >>>> >>>> // Defines top-level module "Foo" >>>> //module Foo { >>>> public import Foo.Bar.Baz >>>> public import Foundation.Date >>>> //} >>>> Which then causes the following (sub)modules to be imported into scope >>>> along with Foo: >>>> >>>> // imports Foo, Foo.Bar.Baz, and Foundation.Date >>>> import Foo >>>> To support existing Swift packages that cannot have opted into modules, >>>> and to preserve the scriptable nature of Swift, module declarations shall >>>> be optional. Any Swift program that does not declare at least one >>>> top-level module explicitly is considered part of an unnamed special >>>> "Global Module" with the same rules of access control as today. To give >>>> declarations in the Global Module an explicit module without using a >>>> module declaration, use the -module-name flag. >>>> >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#impact-on-existing-code>Impact >>>> on Existing Code >>>> >>>> This proposal is intentionally additive. There is no impact on existing >>>> code. >>>> >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#alternatives-considered>Alternatives >>>> considered >>>> >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#explicit-modules-everywhere>Explicit >>>> Modules Everywhere >>>> >>>> Declarations in the top-level of a program exist today in the top-level of >>>> the corresponding module. If desired, this module declaration could be >>>> required to be explicit like so: >>>> >>>> module Foo { >>>> module Bar { >>>> module Baz {} >>>> } >>>> } >>>> However, we feel that imposing such a requirement not only complicates the >>>> outermost scope, it requires inserting needless extension Foo {} scopes in >>>> every file. It also violates the principle of progressive disclosure by >>>> forcing all new adoptees of Swift to learn what a module is without >>>> actually using the module system. >>>> >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#nested-extensions>Nested >>>> Extensions >>>> >>>> Nested module extensions may be "expanded" as it were to the following: >>>> >>>> module Foo { >>>> module Bar {} >>>> } >>>> >>>> extension Foo { >>>> extension Bar {} >>>> } >>>> However, this syntax is currently not enabled in general in Swift. This >>>> problem should be revisted in a future proposal. >>>> >>>> >>>> <https://gist.github.com/CodaFi/cd66b7d70b5cd8e4e8b433fa2ace378a#deprecations-source-breaking-changes>Deprecations >>>> (Source-Breaking Changes) >>>> >>>> The system described above is intended to be entirely source and binary >>>> compatible. Nonetheless, in its design we feel we have obviated certain >>>> existing features and recommend their deprecation in future proposals: >>>> >>>> fileprivate access can be recreated by creating a private "utility >>>> submodule" containing declarations of at least internal access. >>>> @_exported, the private directive to re-export modules today, should be >>>> deprecated and removed. >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
