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