[swift-evolution] final + lazy + fileprivate modifiers

Slava Pestov spestov at apple.com
Thu Feb 16 18:44:11 CST 2017

> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
>> On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> As I have said elsewhere, I think the mental anguish mostly derives from the fact that scoped private is not the right “default” in a language that uses extensions pervasively.  Chris’s suggestion of having private mean “same file *and* same type” would be a good default.  But if we’re not willing to *also* have fileprivate then the Swift 2 definition of private is the best “default’.  
>> I still think scoped access control is valuable but taking `private` as the keyword for this was a mistake.  I’d like to see us take another stab at identifying a suitable name for it.  That said, I get the feeling that not too many others have appetite for this so it may be a lost cause…
> My opinion is that a file level grouping is fine, but that people want a level between that and internal. They want to have subsystems. In Swift 2, the only level below framework-wide was the fileprivate-style scope, which had the potential to encourage lots of interrelated code to be grouped within a single source file. 

Is it really necessary to encode this subsystem grouping in a way that can be checked by the compiler though, instead of enforcing it with coding conventions?


> -DW
> _______________________________________________
> 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/20170216/cc27287e/attachment.html>

More information about the swift-evolution mailing list