> On Feb 20, 2017, at 9:36 PM, Jonathan Hull <[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://32B8028F-83F6-4547-817C-897FD96FD281>
>>
>> <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
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
