[swift-evolution] final + lazy + fileprivate modifiers

Jonathan Hull jhull at gbis.com
Fri Feb 17 21:38:58 CST 2017


My ideal scenario:

1) Go back to Swift 2 meaning of private

2) Add the ‘hidden’ axis I talked about in another thread.  

This will provide the capabilities of protected + friend (and allow extensions organized across files) using a consistent file-based approach that is easy to reason about.  It also neatly avoids the issues mentioned in the blog post.

Thanks,
Jon

> On Feb 16, 2017, at 10:47 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution at swift.org> wrote:
> 
> https://developer.apple.com/swift/blog/?id=11 <https://developer.apple.com/swift/blog/?id=11>
> 
> 
> 
> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>>> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> 
>>>>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/5d20cc39/attachment.html>


More information about the swift-evolution mailing list