> On Feb 16, 2017, at 4:51 PM, Slava Pestov <spes...@apple.com> wrote: > >> >> On Feb 16, 2017, at 4:50 PM, Slava Pestov <spes...@apple.com >> <mailto:spes...@apple.com>> wrote: >> >>> >>> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution >>> <swift-evolution@swift.org <mailto: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 > > 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.
Oh and of course just the logic for the actual accessibility checking in Sema is a bit scary now. There were holes in the implementation in Swift 3, so now Swift 3.1 has to simulate the old quirks, but emit warnings in Swift 3 mode, and emit errors in Swift 4 mode. Slava > > 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@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
