> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
