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

Reply via email to