> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > On Mar 23, 2017, at 8:27 PM, Drew Crawford <[email protected] > <mailto:[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. > > This is a good example of what I meant. There is an extremely broad range of > possible designs for submodules. Some of them, such as this example, would > make it relatively easy to get by without fileprivate. There are also many > other possible designs that would not. > > We do not have any idea where Swift will end up yet. It's not reasonable to > make any assumptions about what use cases the eventual design might or might > not address.
Then why not leave private and fileprivate alone until we do? Charles
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
