[swift-evolution] Yet Another Take on Swift Sub-modules

[Karim Nassar]

> On Mar 3, 2017, at 1:13 PM, Karim Nassar <karim at karimnassar.com> wrote:
> 
>> 
>> On Mar 3, 2017, at 12:35 PM, David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
>> 
>>> 
>>> ### Making a Sub-module
>>> 
>>> To create a sub-module within a Module (or sub-module) is simple: The author creates a directory, and places a "sub-module declaration file" within the directory:
>>> 
>>> ```
>>> //  __submodule.swift
>>> //  MyModule
>>> 
>>> submodule SubA
>>> 
>>> ```
>> 
>> Like the previous response, I think this potentially the weakest part of he proposal. I like the idea of a file-system based submodule system but I'm not sure I like this version of it. People are going to be very vocal about this too. Perhaps you could rewrite the proposal with several solutions for this part? Let people discuss the different solutions.
> 
> Thanks, this is exactly why I posted this original concept—to spur conversation.
> 
> An alternate approach might be to eliminate the “magic file” and directory dependency and replace them with explicit sub-module adoption per file. Something like this:
> 
> **all spellings are straw-men!**
> 
> ```
> // declared in any file
> 
> // this is the same sub-module declaration previously declared in the magic file, 
> // and serves the same purpose of declaring the sub-module, 
> // and acting as a home for future configuration:
> 
> submodule SubA 
> 
> 
> // announced once in any file you wish to include in the sub-module:
> 
> in_submodule SubA
> 
> ```
> 
> Some issues I see with this:
> increases the surface area— need to introduce a new declaration for announcing sub-module inclusion
> Either: 
> introduces a new *kind* of declaration… `in_submodule` which can only appear once in a file (which would need to be compiler-enforced), OR:
> increases complexity by allowing multiple sub-module declarations in a file
> 

Yet another possible approach is to treat the sub-module as a symbolically-named scope (in plain-English, I’d call it a meta-type, but that already means something). This is similar mechanically to one of the earlier proposals:

```
submodule SubA { }

extension SubA {	
	struct Foo {  }

	submodule SubB { 
		struct Bar {  }
	}
}

extension SubA.SubB {
	struct Bast {  }
}

```

Pros:

* Extends an existing pattern in a somewhat reasonable-seeming way, easily discoverable

Cons:

* Though the pattern *seems* reasonable, it’s actually an odd-duck; a sub-module does not behave the same as a type in many important ways.
* There’s some impact here on how top-level declarations are evaluated (i.e.: Protocols, global statements, etc). 
* Visually uglier (indentation)
* The mental model required for this is **much** more complicated, as submodule declarations can now be mixed within a file, and the (file)private Access Controls will span sub-modules.

—Karim



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170303/c3146ce5/attachment-0001.html>