Re: [swift-evolution] [Proposal][Discussion] Modular Swift

On Mar 5, 2017, at 4:21 AM, Joanna Carter via swift-evolution wrote: > > I have to say, I really *hate* "Swift style". It wouldn't be so bad if I > could change the indentation rules in Xcode. > > For over 25 years, I have written code with curly braces always on

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

A lot of “Swift Style” is “LLVM Style” enforced in little corners of the language (I, too, like to keep my cases indented a bit further). There are formatting tools available to make your Swift look C#-ish if you want :) > On Mar 5, 2017, at 7:21 AM, Joanna Carter via swift-evolution >

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

~Robert Widmann 2017/03/03 16:10、Matthew Johnson のメッセージ: > >> On Mar 2, 2017, at 10:52 PM, T.J. Usiyan wrote: >> >> Submodules will, I hope, afford us the ability to share meaningfully >> arranged API. In an ideal scenario, I could have a

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> It's part of what has become Swift style and I'm quite happy about it. Indent > on case and on case content is too much indenting :) > >> On 3 Mar 2017, at 11:06, Karl Wagner via swift-evolution >> wrote: >> >> >>> On 3 Mar 2017, at 05:52, T.J. Usiyan via

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Mar 2, 2017, at 10:52 PM, T.J. Usiyan wrote: > > Submodules will, I hope, afford us the ability to share meaningfully arranged > API. In an ideal scenario, I could have a module that has all of the smaller > pieces of 'utilities and conveniences' that one builds up

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Submodules will, I hope, afford us the ability to share meaningfully arranged API. In an ideal scenario, I could have a module that has all of the smaller pieces of 'utilities and conveniences' that one builds up broken into submodules. Importing one of the submodules from its enclosing module

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Sent from my iPad > On Mar 2, 2017, at 9:06 PM, T.J. Usiyan wrote: > > +1 overall. prefer this approach over the "scope based" approach in the other > proposal Can you elaborate? What problems are you hoping submodules will address? > >> On Wed, Feb 22, 2017 at

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

+1 overall. prefer this approach over the "scope based" approach in the other proposal On Wed, Feb 22, 2017 at 10:10 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 21, 2017, at 11:54 PM, Robert Widmann > wrote: > > > On Feb 22,

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 11:54 PM, Robert Widmann wrote: > > >> On Feb 22, 2017, at 12:41 AM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On Feb 21, 2017, at 11:09 PM, Robert Widmann

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 22, 2017, at 12:41 AM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Feb 21, 2017, at 11:09 PM, Robert Widmann > wrote: > >> >>> On Feb 21, 2017, at 11:59 PM, Matthew Johnson

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Sent from my iPad > On Feb 21, 2017, at 11:09 PM, Robert Widmann wrote: > > >>> On Feb 21, 2017, at 11:59 PM, Matthew Johnson >>> wrote: >>> >>> >>> On Feb 21, 2017, at 10:41 PM, Robert Widmann >>> wrote: >>>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 11:59 PM, Matthew Johnson wrote: > > >> On Feb 21, 2017, at 10:41 PM, Robert Widmann > > wrote: >> >> By API boundaries I mean both the one internal to MyModule.Foo and the one >>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:41 PM, Robert Widmann wrote: > > By API boundaries I mean both the one internal to MyModule.Foo and the one > defined by MyModule. Here “the API boundary” is explicitly about the > submodule MyModule.Foo, whose internal state may have been

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Then let’s discuss that. You claim Swift has some emphasis on file-oriented programming constructs, I argue this is the case locally (fileprivate), but not the case in the language as a whole. Looking more broadly, it is possible to restrict yourself to a particular view where one public type

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

By API boundaries I mean both the one internal to MyModule.Foo and the one defined by MyModule. Here “the API boundary” is explicitly about the submodule MyModule.Foo, whose internal state may have been “unsealed” in the top level by the extension, but has not been re-exported. ~Robert

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:29 PM, Robert Widmann wrote: > > This level of access, the “private to this submodule except to the select set > of interfaces I want to see it” level, is the equivalent of friend classes in > C++. I don’t consider leaving this out to be a

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

TJ and I had a proposal that would have closed this loophole by overhauling qualified imports syntax. > On Feb 21, 2017, at 11:36 PM, Matthew Johnson wrote: > > >> On Feb 21, 2017, at 10:25 PM, Robert

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:25 PM, Robert Widmann wrote: > > Good question! This behavior is actually the behavior that exists today. > For example, open a playground and type > > import Foundation.NSDebug > > let s : NSString = “" > > You’ll notice no matter which

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

This level of access, the “private to this submodule except to the select set of interfaces I want to see it” level, is the equivalent of friend classes in C++. I don’t consider leaving this out to be a hole, nor is it an "encapsulation-related problem” because at no point can you break the

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Good question! This behavior is actually the behavior that exists today. For example, open a playground and type import Foundation.NSDebug let s : NSString = “" You’ll notice no matter which submodule you try to visit (Darwin.uuid is another good example), Swift has decided to insert a

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 7:56 PM, Robert Widmann via swift-evolution > 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.

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:11 PM, Matthew Johnson wrote: > > >> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> On Feb 21, 2017, at 7:38 PM, Robert Widmann >>> wrote: >>> >>>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 21, 2017, at 7:38 PM, Robert Widmann wrote: >> >> Correct. Because, in dividing the submodule across an extension, you have >> placed what should

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

FWIW, I like the freedom of choice. A Java-like file-based solution can be limiting for *some* style of programming. It is, as Robert mentioned, geared towards benefit of the implementation. I also suspect ppl who are asking for file-based solution _now_ may find themselves wanting the

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Whoops, move bar() out of the utility and you get the actual answer here, because you want to be able to see this in foo()! > On Feb 21, 2017, at 10:54 PM, Robert Widmann wrote: > > This case is unserved because it is anti-modular and a nightmare to maintain. > The

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

This case is unserved because it is anti-modular and a nightmare to maintain. The actual way to structure this is to factor bar() and baz() into their own utility submodule, or even deeper if necessary, that has as a parent the primary module that wishes to consume them both but not re-export

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:42 PM, Robert Widmann wrote: > > >> On Feb 21, 2017, at 10:36 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution >>>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 7:38 PM, Robert Widmann wrote: > > Correct. Because, in dividing the submodule across an extension, you have > placed what should be a private API into a differently-scoped location. Okay. So is your submodule design not intended to address the

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Well put. As for me, it is not the syntactic delta with which I am concerned. It is just a canary for the organizational delta. There are certain freedoms enabled not by the _lack_ of constraints but rather their judicious application. Swift has in the past--and it is your burden to justify why

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:36 PM, Matthew Johnson wrote: > >> >> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution >> > wrote: >> >>> >>> On Feb 21, 2017, at 10:03 PM, Xiaodi Wu

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

On Tue, Feb 21, 2017 at 9:34 PM, Robert Widmann wrote: > Let’s use some code to illustrate things. > > // FooUtilities.swift > // > // -module-name=Foo > // module Foo { > // Defines Foo.Utilities > module Utilities { > internal func visibleInThisSubmodule() {} > } >

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Correct. Because, in dividing the submodule across an extension, you have placed what should be a private API into a differently-scoped location. > On Feb 21, 2017, at 10:34 PM, Brent Royal-Gordon > wrote: > >> On Feb 21, 2017, at 7:14 PM, Robert Widmann

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution > wrote: > >> >> On Feb 21, 2017, at 10:03 PM, Xiaodi Wu > > wrote: >> >> On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

On Tue, Feb 21, 2017 at 9:28 PM, Robert Widmann wrote: > > On Feb 21, 2017, at 10:03 PM, Xiaodi Wu wrote: > > On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann > wrote: > >> >> On Feb 21, 2017, at 9:37 PM, Xiaodi Wu

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Let’s use some code to illustrate things. // FooUtilities.swift // // -module-name=Foo // module Foo { // Defines Foo.Utilities module Utilities { internal func visibleInThisSubmodule() {} } //} // FooUtilities+MoreUtilities.swift extension Foo.Utilities { private func privateHelper() {

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 7:14 PM, Robert Widmann wrote: > > Fileprivate and private are not changing at all. Their meaning now extends > from “private to this file” and “private to this declaration” respectively to > those meanings plus “unexportable across any module

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

On Tue, Feb 21, 2017 at 9:29 PM, Robert Widmann wrote: > Once again, internal is your keyword. An extension allows you to “open > and expand” the module boundary here, which is exactly what you want here - > to extend this module across file boundaries without showing

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Once again, internal is your keyword. An extension allows you to “open and expand” the module boundary here, which is exactly what you want here - to extend this module across file boundaries without showing your cards to an external consumer of your framework. > On Feb 21, 2017, at 10:26

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:03 PM, Xiaodi Wu wrote: > > On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann >wrote: > >> On Feb 21, 2017, at 9:37 PM, Xiaodi Wu > >

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

On Tue, Feb 21, 2017 at 9:08 PM, Robert Widmann via swift-evolution < swift-evolution@swift.org> wrote: > Sorry, been replying to multiple sub-threads today. > > > For bar(), because you wish to be able to > > 1) Not export it across the outermost module boundary > 2) But still use it internally

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Fileprivate and private are not changing at all. Their meaning now extends from “private to this file” and “private to this declaration” respectively to those meanings plus “unexportable across any module boundary”. One implication of this is it is now possible to create module-scoped private

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

So are private and/or fileprivate changing to mean "visible within current submodule"? Because I specified that baz() is in a type extension, possibly in another file. -- Brent Royal-Gordon Sent from my iPhone > On Feb 21, 2017, at 7:08 PM, Robert Widmann wrote: >

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Sorry, been replying to multiple sub-threads today. For bar(), because you wish to be able to 1) Not export it across the outermost module boundary 2) But still use it internally Internal access is required. Any higher and you would export (violating 1), any lower and you wouldn’t be able

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

On Tue, Feb 21, 2017 at 8:51 PM, Robert Widmann via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 21, 2017, at 9:49 PM, Brent Royal-Gordon > wrote: > > On Feb 21, 2017, at 6:43 PM, Robert Widmann > wrote: > > That is not what

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

I specified two different behaviors for `bar()` and `baz()`. I see now that you describe `internal` as having the behavior I want for `bar()`. Is there a way I can get the behavior I want for `baz()`? -- Brent Royal-Gordon Sent from my iPhone On Feb 21, 2017, at 6:51 PM, Robert Widmann

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann wrote: > > On Feb 21, 2017, at 9:37 PM, Xiaodi Wu wrote: > > On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann > wrote: > >> >> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

What is implied by the definition of `internal` in the proposal (which should, as this thread has shown, be stated explicitly) is that by “export” we mean “export to clients” across the outermost module-boundary. Any API that is not public is, by definition, not able to cross this outermost

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:49 PM, Brent Royal-Gordon > wrote: > >> On Feb 21, 2017, at 6:43 PM, Robert Widmann wrote: >> >> That is not what this proposal requires. A public API is ripe for >> re(export), but if the parent wishes to

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 6:43 PM, Robert Widmann wrote: > > That is not what this proposal requires. A public API is ripe for > re(export), but if the parent wishes to communicate with its children without > exporting across the module boundary, see the definition of

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:44 PM, Xiaodi Wu wrote: > > On Tue, Feb 21, 2017 at 8:32 PM, Robert Widmann > wrote: > There’s an important distinction between the ability to wall off, and this > particular instance of

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

On Tue, Feb 21, 2017 at 8:32 PM, Robert Widmann wrote: > There’s an important distinction between the ability to wall off, and this > particular instance of doing so. By definition, a module allows for the > encapsulation and export of a subset of an API, the same way

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:38 PM, Brent Royal-Gordon > wrote: > >> On Feb 21, 2017, at 6:09 PM, Robert Widmann wrote: >> >>> If I'm reading this correctly, you're proposing that the `internal` APIs in >>> a submodule should *not* be accessible

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:37 PM, Xiaodi Wu wrote: > > On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann >wrote: > >> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu > >

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 6:09 PM, Robert Widmann wrote: > >> If I'm reading this correctly, you're proposing that the `internal` APIs in >> a submodule should *not* be accessible to enclosing modules. I also don't >> see any indication that you can control who is allowed

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann wrote: > > On Feb 21, 2017, at 9:13 PM, Xiaodi Wu wrote: > > On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Feb 21, 2017, at 7:36

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu wrote: > > On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution > > wrote: > >> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

On Tue, Feb 21, 2017 at 8:15 PM, Robert Widmann via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 21, 2017, at 7:46 AM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote: > > On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution < >

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 7:46 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution >> wrote: >> >> It has been my hope that a lightweight module system will remove the need

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution < > swift-evolution@swift.org> wrote: > > To my mind, any submodule system for Swift should be designed to relieve >

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 8:00 AM, Brent Royal-Gordon > wrote: > >> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution >> wrote: >> >> The semantics of some existing access control modifiers shall also be >> extended to support

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution > 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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

I agree with Nevin’s points in large strokes, but I don’t think large files are the end of the world. I think an important takeaway idea from all the access control threads is that we need not provide facilities in the language to support antipatterns; we should more focus on how to encourage

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

This proposal is definitely *not* what I want from a submodule system, because it will exacerbate the problem of developers stuffing large amounts of code into a single file. The “fileprivate” keyword already encourages long files, because there is no way to split up related components into

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

One pattern that lightweight module enables is a lot more free functions in place of methods. Because the functions would be encapsulated by a module and lose the polluting effect. On Feb 21, 2017, at 4:46 AM, Brent Royal-Gordon via swift-evolution wrote: >> On

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 5:00 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution >> wrote: >> >> The semantics of some existing access control modifiers shall also be >>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution > wrote: > > 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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 4:44 AM, Alex Blewitt wrote: > > >> On 21 Feb 2017, at 07:00, Jaden Geller via swift-evolution >> wrote: >> >> We avoid forcing users to organize code in such an opinionated manner just >> to please the compiler. Perhaps

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution > wrote: > > It has been my hope that a lightweight module system will remove the need for > `private` *and* `fileprivate`. I really doubt it will. `private`/`fileprivate` works because you can also

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On 21 Feb 2017, at 07:00, Jaden Geller via swift-evolution > wrote: > > We avoid forcing users to organize code in such an opinionated manner just to > please the compiler. Perhaps some submodules deserve a separate file, but I > think that choice should not be

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

~Robert Widmann 2017/02/21 2:16、Jonathan Hull のメッセージ: > It is how it interacts with our current access control. The scope based > nature of this will conflict with the file based nature of the stuff left > from Swift 2. I am convinced we need to overhaul it in one sweep to

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Sounds distressingly anti-modular! Really, these kinds of hypotheticals can be addressed when the need arises. For now it's a hypothetical fear about a hypothetical issue that isn't expressible and highly discouraged by this system - why produce an inverted dependency when you could simply

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

It’s probably best we explain this motivation under “Alternatives Considered”. I forked and updated the gist—feel free to “pull” in the changes… copy and paste the document https://gist.github.com/JadenGeller/c18b1be8e7b9fa3023e98b84fca423ca#multiple-declarations-instead-of-extensions

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 2:01 AM, Jonathan Hull wrote: > > >> On Feb 20, 2017, at 10:46 PM, Robert Widmann via swift-evolution >> > wrote: >> >> More generally, we need to move access control away as far away from >>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 10:46 PM, Robert Widmann via swift-evolution > wrote: > > More generally, we need to move access control away as far away from > filesystems as possible. One day, the compiler is going to get ported over > to a platform with some bonkers

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

We avoid forcing users to organize code in such an opinionated manner just to please the compiler. Perhaps some submodules deserve a separate file, but I think that choice should not be forced by the language. I don’t have data on the popularity, but I personally very much dislike the similar

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

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 > a écrit : > > Oh, I see. You’re

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Part of it. My concern is that the brackets will push everything in the file to the right. My question is: What do we get in return for that? (as opposed to a system which acted on the whole file) Thanks, Jon > On Feb 20, 2017, at 10:45 PM, Jaden Geller wrote: > >

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 1:46 AM, Jonathan Hull wrote: > > >> On Feb 20, 2017, at 6:44 PM, Robert Widmann > > wrote: >> >>> >>> >>> I would honestly love to see something which just maps modules to >>> folders/groups

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 6:44 PM, Robert Widmann wrote: > >> >> >> 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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 11:39 PM, Matthew Johnson wrote: > > Thanks for bringing up submodules Robert. I agree it's a good time to > discuss them. > > There seem to be two broad approaches to submodules. One is more of a > physical / encapsulation based view and the

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Oh, you’re referring to the fact that a submodule under this proposal must be contained within braces? It would be purely additive to, in the future, annotate that the outer scope of a file is part of some given submodule. Consider the following the following straw-man syntax that might be

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

The same benefits afforded by multiple extensions contained in the same file: sometimes you wish for your concerns not to overlap with one another, but feel that they do not necessarily warrant being split into separate files. There really isn’t a reason we should enforce separation of

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

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 wrote: > > >> On Feb 20, 2017, at 9:36 PM, Jonathan Hull

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Thanks for bringing up submodules Robert. I agree it's a good time to discuss them. There seem to be two broad approaches to submodules. One is more of a physical / encapsulation based view and the other is more of a logical / namespace based view. This proposal falls into the latter

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

To further clarify—I think it would be accurate to say that this proposal introduces 2 things: 1) submodules, without changing the existing module system 2) `public` keyword for re-exporting modules It is both unnecessary and not allowed to name the outermost module in the file. The `module`

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 9:36 PM, Jonathan Hull 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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Jon, I think we might have miscommunicated. It is intended that outermost module is implicit; no `module` declaration is required to wrap every file. We tried to show this in the first code snippet. What do you mean “covering only part of a file”? Cheers, Jaden Geller > On Feb 20, 2017, at

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

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