> On Mar 23, 2017, at 18:35, Matthew Johnson via swift-evolution
> <[email protected]> wrote:
>
> On Mar 23, 2017, at 8:27 PM, Drew Crawford <[email protected]
> <mailto:[email protected]>> wrote:
>
>>
>> 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.
The Rust approach sounds ideal to me. I hope Swift can get to this point some
day.
But as for the current proposal, I’ve become convinced that it would cause
headaches for too many people. Parametrizing the private keyword seems a
compromise between pragmatism and elegance:
public
private(module)
private(file)
private(scope)
-Matt
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
