It’s probably best we explain this motivation under “Alternatives Considered”. I forked and updated the gist—feel free to “pull” in the changes… <cough>copy and paste the document</cough>
https://gist.github.com/JadenGeller/c18b1be8e7b9fa3023e98b84fca423ca#multiple-declarations-instead-of-extensions <https://gist.github.com/JadenGeller/c18b1be8e7b9fa3023e98b84fca423ca#multiple-declarations-instead-of-extensions> Cheers, Jaden Geller > On Feb 20, 2017, at 10:57 PM, Robert Widmann <[email protected]> wrote: > > 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 >> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>>> On Feb 20, 2017, at 9:36 PM, Jonathan Hull <[email protected] >>>>>> <mailto:[email protected]>> 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 >>>>>>> <[email protected] <mailto:[email protected]>> 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://DA662173-61C2-4A11-9298-89E9CF47D2FE> >>>>>>> >>>>>>> <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 >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
