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

[Rien]

>>> 
>>> I’m not dead-set on this approach, but as you say, it solves a *lot* of problems that other approaches introduce. I do recognize the reasonableness of the main argument against, that file location shouldn’t have such a dramatic affect on behavior… *but* the fact is (whether by convention or expediency) we already *do* have filesystem location dependencies on our code projects… 
>>> 
>>> * One can’t willy-nilly move files around the disk and expect a project to build… if you move it somewhere the compiler doesn’t know to look for it, you’re going to break things
>>> * One can’t just move a file out of your SCM repo root, or you’ll “lose” the file
>> 
>> True, but if other files do not refer to the lost file, you don’t even know for which file to look.
>> (imo this is already a weak point in swift, but this approach to submodules would make it -much?- worse)
>> 
>> If you were to include filenames in the “submodule declaration file” at least this omission in swift would be partly covered, and you would not need to move the other files into special places. (You could though)
>> 
> 
> But isn’t this exactly the same case if you’re using Swift without an IDE? It’s true that Xcode keeps track of files in your project, and there’s no reason it couldn’t also keep track of files in a submodule (in fact it would… it just might not know they belong in the sub-module without some work from the Xcode dev team).
> 
> But as a thought-experiment, here’s how I’m thinking of this problem:
> 
> Swift (as a language) has established that a file *is* a unit of code. Not the only one of course, but it is one, as evidenced by access controls (fileprivate, Swift2 private) which bound on the file.

I disagree with this: Swift is just a set of -more or less- arbitrary rules to allow the development of applications.
The criteria for those rules are chosen by the core team and will fluctuate with time.
As such there is no “Swift way” of doing things. Any such remark is by its nature a personal preference. (not that there is anything wrong with that, its just not an argument)

(Besides, a computer only knows files, thus of course a file is a unit of code. That does not mean we should extend “code” to be something outside the files)

> I (and many others) want to be able to describe another unit of code larger than a file and smaller than a Module to help organize the file-units we have which go together within a Module, but which shouldn’t (for various reasons) describe a complete Module in and of themselves.

Sure, and I have nothing against that. However I an dead set against extending the scope of the language itself to the organisation of its files. It is traditional to leave the organisation of the files to the configuration of the compiler/linker. And I do not see how it would simplify the language itself by extending the language to cover file organisation.

I will predict that if this approach is taken you should brace for the storm that would want to reverse this feature. It would imo dwarf the private vs fileprivate debate.

Besides, why create something new? (Yes there are systems out there that do some of this) There are many existing solutions out there that we could adopt and stay completely within the bounds of the language, and give the users something they are likely already familiar with.

> 
> For the moment—though we actually propose to call this unit a sub-module—we'll call this new unit a Foo. Let's describe properties of a Foo:
> 
> * A Foo should serve to organize one or more File code units by:
>   - ensuring a File (the code-unit) may belong to one and only one Foo
>   - making clear (with or without an IDE) to which Foo a given file might belong
> * A Foo should have a unique name
> * A Foo should be able to nest under another Foo, and the name of that nesting should be clear & unique
> * A Foo should be able to be easily created, split, and merged as the codebase evolves
> * A Foo should be able to be moved, copied, and SCMed as a unit, without reference to anything outside the Foo
> 
> Having now described the critical properties of this new unit called “Foo” have we not also described a filesystem directory?

Many things in life share characteristics. And while we should certainly look to them for lessons, we should not conclude that they are the same.

Rien.

> 
> Naturally, we don’t want *all* directories to become Foos (that would be overly restrictive to authors, and backwards-incompatible), so we need a way to distinguish a normal directory from one that is acting as a Foo. I originally proposed a special “sub-module declaration file”, but there may be other ways. For example, we might establish that a directory whose name matches `[SubModuleName].swift-sub-module` becomes a sub-module of designated name, however this can cause problems due to the disjoint sets of “Legal Filesystem Directory Characters” and “Legal Swift Identifier Characters”. It also doesn’t give us a place to “grow” the declaration in the future if we choose to add additional properties to the sub-module declaration.
> 
> 
> —Karim