Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 22, 2017, at 12:04 AM, Brent Royal-Gordon > wrote: > >> On Feb 21, 2017, at 11:11 PM, Jonathan Hull via swift-evolution >> wrote: >> >> There is one major use case which I see all of these proposals failing to >> handle (although

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 22, 2017, at 2:04 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 21, 2017, at 11:11 PM, Jonathan Hull via swift-evolution >> wrote: >> >> There is one major use case which I see all of these proposals failing to

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 22, 2017, at 1:31 AM, Brent Royal-Gordon > wrote: > >> On Feb 21, 2017, at 8:33 PM, Matthew Johnson wrote: >> >>> A submodule may not import any direct parent module (parent, grandparent, >>> etc.), but may import any other submodule

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 21, 2017, at 11:11 PM, Jonathan Hull via swift-evolution > wrote: > > There is one major use case which I see all of these proposals failing to > handle (although that may be intentional for some designs), is where you have > something internal to the type,

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 21, 2017, at 8:33 PM, Matthew Johnson wrote: > >> A submodule may not import any direct parent module (parent, grandparent, >> etc.), but may import any other submodule in the same module. This list >> shows permitted imports for a project with four

Re: [swift-evolution] [Pitch] Let's talk about submodules

I think I could get behind this. It definitely takes care of the 80%. It might even enable adding storage in extensions *within the submodule* There is one major use case which I see all of these proposals failing to handle (although that may be intentional for some designs), is where you

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 20, 2017, at 7:36 PM, Brent Royal-Gordon via swift-evolution > wrote: > > Okay, lots of people want to have some kind of submodule feature, so I'd like > to sketch one out so we can hopefully agree on what submodules might look > like. > > *** > > Any

Re: [swift-evolution] [Pitch] Let's talk about submodules

I think entities declared as “internal” should be visible throughout the entire *module* just as they are today. In particular, if I write “struct Foo {}” inside a submodule, then Foo should have internal visibility (the default when no access level is specified) and thus should be available to

Re: [swift-evolution] [Pitch] Let's talk about submodules

Sent from my iPad On Feb 21, 2017, at 5:18 AM, Dimitri Racordon wrote: >> Maybe we should try to collect what people want from submodules first. > > I’d like a simple method to group my sources files into some kind lexical > scope. Nothing more actually =D I

Re: [swift-evolution] [Pitch] Let's talk about submodules

Sent from my iPad On Feb 21, 2017, at 4:01 AM, Brent Royal-Gordon wrote: >> On Feb 20, 2017, at 7:59 PM, Matthew Johnson wrote: >> >>> Any group of Swift files can be grouped together to form a submodule. >> >> It isn't clear to me how you

Re: [swift-evolution] [Pitch] Let's talk about submodules

> Maybe we should try to collect what people want from submodules first. I’d like a simple method to group my sources files into some kind lexical scope. Nothing more actually =D > The point is, specifying which files belong to which submodules is a build > system responsibility, not a

Re: [swift-evolution] [Pitch] Let's talk about submodules

Maybe we should try to collect what people want from submodules first. I wanted modules for organisational purposes, however with the arrival of SPM that need has been almost completely removed. At least to the point that I do not feel that they are absolutely necessary. Have the people who

Re: [swift-evolution] [Pitch] Let's talk about submodules

Sent from my iPad > On Feb 20, 2017, at 7:36 PM, Brent Royal-Gordon via swift-evolution > wrote: > > Okay, lots of people want to have some kind of submodule feature, so I'd like > to sketch one out so we can hopefully agree on what submodules might look > like.

Re: [swift-evolution] [Pitch] Let's talk about submodules

That’s an interesting proposal. Here are the issues I see: - I don’t like nesting everything within a large “module” block. I would like a top-level “@module Foo” declaration for the entire file. Also, since any sub-modules would be nested within the implicit top-level module, I’d prefer the

Re: [swift-evolution] [Pitch] Let's talk about submodules

You’ll be delighted to know, then, that I’ve been thinking about this for a few weeks now and have a draft proposal that will be submitted for discussion shortly. I believe this can be an additive feature and still preserve all the goodness you would expect of a real module system. ~Robert

Re: [swift-evolution] [Pitch] Let's talk about submodules

Oh, I thought this would be another discussion about namespaces. On Mon, Feb 20, 2017 at 8:39 PM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 20, 2017, at 5:36 PM, Brent Royal-Gordon > wrote: > > > > Okay, lots of people want to

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 20, 2017, at 5:36 PM, Brent Royal-Gordon > wrote: > > Okay, lots of people want to have some kind of submodule feature, so I'd like > to sketch one out so we can hopefully agree on what submodules might look > like. Ten seconds after sending this, I realized

[swift-evolution] [Pitch] Let's talk about submodules

Okay, lots of people want to have some kind of submodule feature, so I'd like to sketch one out so we can hopefully agree on what submodules might look like. *** Any group of Swift files can be grouped together to form a submodule. Submodules belong within a particular module, and have a