[swift-evolution] final + lazy + fileprivate modifiers

[Slava Pestov]

> On Feb 16, 2017, at 4:50 PM, Slava Pestov <spestov at apple.com> wrote:
> 
>> 
>> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org <mailto: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

This is confusing — in the first case I’m talking about serialization as in NSCoding, in the second I’m referring to .swiftmodule file generation in the compiler.

Slava

> - 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/cb57d7c5/attachment.html>