How about removing fileprivate, getting Swift 2 meaning of private (as most 
people here now suggest) and add additional @protected annotation for those who 
want a more fine-grained solution:

@protected private - members accessable only from the class/struct/enum/... and 
their extensions within the file

@protected internal - again, but you can access it even from extensions and 
subclasses outside of the file within the entire module.

@protected public/open - the same as above, but outside the modules.

To me, this way most people here will be happy:

- those wishing the access control gets simplified - it in fact does, you don't 
need to use @protected, if you don't want to/need to.
- those who need a fine-grained solution, here it is.



> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> While we’re bikeshedding, I’m going to add my two cents. Hold on to your 
>>> hat because this might be controversial here.
>>> 
>>> I think both ‘private’ and ‘fileprivate’ are unnecessary complications that 
>>> only serve to clutter the language.
>>> 
>>> It would make a lot more sense to just have internal and public only. No 
>>> private, no fileprivate, no lineprivate, no protected. It’s all silly.
>> 
>> Eh, I've used `private` to keep myself honest in terms of going through some 
>> book-keeping functions instead of directly accessing a property.
> 
> This is exactly the kind of thing I like it for and why I hope we might be 
> able to keep scoped access even if it gets a new name that ends up as awkward 
> as fileprivate (allowing private to revert to the Swift 2 meaning).
> 
>> 
>> - Dave Sweeris
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to