How about private(world), public(module), internal(file)? :-) Slava
> On Mar 25, 2017, at 4:15 PM, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > Please do not start a debate about `private(module)` which is equavalent to > `internal`, otherwise you could equally use a parametrized `public` for > everything. > > public(outside_module), public(only_inside_module), public(only_in_this_file) > or public(nowhere) > > `internal` is just fine as it is. > > -- > Adrian Zubarev > Sent with Airmail > Am 25. März 2017 um 16:43:23, Matt Whiteside via swift-evolution > ([email protected] <mailto:[email protected]>) schrieb: > >> >>> On Mar 23, 2017, at 18:35, Matthew Johnson via swift-evolution >>> <[email protected] <mailto:[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 > _______________________________________________ > 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
