[swift-evolution] final + lazy + fileprivate modifiers

[Jose Cheyo Jimenez]

> On Feb 19, 2017, at 7:16 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Feb 19, 2017, at 7:55 AM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 
>>> On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> The current private is closer to other languages than the previous one we had which now has in fileprivate a better name.
>> 
>> It is closer, but it's not a goal for Swift to always follow conventions of other languages. It's useful sometimes. But in this case it goes directly against the philosophy of Swift's extension feature. Swift should be allowed to go against the norm when it serves the languages. And in this case, if only one private should exist, it's the file-s open one.
> 
> Yes, I think making private not work well with extensions was the "actively harmful" aspect of SE-0025.  Scoped access itself is not actively harmful and should not be removed, but it could be renamed so that private works the way people want it to again.
> 
I think this an excellent point. In your proposal you can also mention that perhaps the renaming on private to mean scope private was premature since the primary goal was to match other languages notion on private. The issue is that Swift's public does not match other languages public. Should we then also change Swift's public to mean the established meaning of public in other languages? By no means! Swift is different. We agree that scope private is useful to some people by we believe that it is the wrong default for Swift. It is actively harmful in that by making it the default it forces a programmer to think fileprivate the moment the want to extend a type and access their private members. This in turn forces every programmer to have to deal with two access modifiers before they even make anything public. We believe this goes against the swift  centric feature of extensibility via extensions and the philosophy of "the complexity inherited in the language needs to be progressively disclosed". In the same way that public doesn't make classes open, private should not be scope private. 

This will make it possible for people to lock down in steps instead of all together which doesn't work with extensions.  

We need more examples to make this case. 



>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> 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/20170219/77a568e7/attachment.html>