Sent from my iPad
> On Mar 23, 2017, at 9:48 PM, Charles Srstka <cocoa...@charlessoft.com> wrote:
>
>> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> On Mar 23, 2017, at 8:27 PM, Drew Crawford <d...@sealedabstract.com> wrote:
>>
>>>
>>>
>>>
>>> Sent from my iPhone
>>> On Mar 23, 2017, at 6:41 PM, David Hart <da...@hartbit.com> 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?
That is what I have suggested, with an alternative of renaming if we feel
compelled to make a change now.
>
> Charles
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
