This was syntax I initially considered, but Jaden swayed me with the idea that we already have an `extension` keyword so we may as well use it to match the rest of the language. Repeating the `module` declaration also lends itself more to C++-style namespaces, which these are not. I’m not saying it’s out of the question, far from it. It is an alternative we will keep in mind.
~Robert Widmann > On Feb 21, 2017, at 1:53 AM, Psycho Hedgehog via swift-evolution > <swift-evolution@swift.org> wrote: > > The one thing i don't understand is the point of using extensions to extend > modules across multiple files, why not just allow declaring the submodule in > multiple files? > >> Le 20 févr. 2017 à 22:48, Jaden Geller via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> 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 <mailto: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://958D4EFC-6E24-4386-84D4-120E1C2769EC> >>>>>> >>>>>> <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 <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 <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
