[swift-evolution] final + lazy + fileprivate modifiers

[Slava Pestov]

> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution <swift-evolution at swift.org <mailto: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?
> 
> Slava

It’s also worth pointing out that private/fileprivate have been a constant source of implementation issues:

- They do not have a stable mangled name, and cannot be serialized in a meaningful way
- The ‘private descriminator’ adds complexity to serialization and mangling in general
- Slightly different linking behavior in WMO and non-WMO builds
- Textual SIL cannot use them, which together with the above blocks the stdlib from adopting ‘private'

I’m sure there are others. There’s an opportunity cost to keeping quirky features around and adding new ones — it prevents us from being able to spend more time on improvements that actually matter, such as compile time, crashes and diagnostics.

Slava

> 
>> 
>> -DW
>> 
>> _______________________________________________
>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170216/0721c149/attachment.html>