Nevin had a fantastic proposal for submodules which changed private to mean 
“private to the submodule”, where each file was implicitly a submodule unless 
you declared otherwise.  Simple and elegant.


> On Mar 23, 2017, at 6:27 PM, Drew Crawford via swift-evolution 
> <[email protected]> wrote:
> 
> 
> 
> 
> Sent from my iPhone
> On Mar 23, 2017, at 6:41 PM, David Hart <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>> I have difficulties imagining a submodule proposal that could allow us to 
>> eliminate fileprivate. Care to give an example?
> 
> The obvious example would be Rust.  Rust has exactly two visibilities, and 
> merely one keyword.  By default, members are "private" which is visible 
> inside the module (so, like Swift's internal). The "public" keyword is 
> similar to Swift. 
> 
> The reason this works is that unlike in Swift where a module is something 
> like a library or framework (Rust calls those "crates"), in Rust modules in 
> are (explicitly) lexically scoped; a "mod myscope {}" module can be created 
> for the portion of the file for which the member should be visible and it 
> won't be visible outside that scope. Likewise, "fileprivate" can be achieved 
> by enclosing the file in a "mod MyFile {}". And like all lexical scopes, they 
> can be recursively nested to arbitrary depth to achieve any number of 
> visibility behaviors (e.g., declare a module for the first half of two files) 
> that would require complex new keywords to achieve in Swift. Finally there 
> are some shortcut features like the ability to infer a module structure from 
> the file system. 
> 
> 
> 
> In Swift, modules are presently tied to libraries/frameworks in a 1:1 way. 
> Because of this we lack the flexibility of recursively nestable modules of 
> other languages and this is the underlying problem that motivates both 
> scoped/private and fileprivate.  If we fixed that, we would actually not need 
> either keyword. 
> 
> http://rustbyexample.com/mod/visibility.html 
> <http://rustbyexample.com/mod/visibility.html>
> https://doc.rust-lang.org/book/crates-and-modules.html 
> <https://doc.rust-lang.org/book/crates-and-modules.html>_______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to