I searched thought my code and most uses of fileprivate were for same-file extensions which would be solved by #2 as well.
The other usages are mostly "related" types, which could possibly work with #2 if these were made inner types instead. Two examples: A "Slots" struct with a collection of "Slot" enum values is able to inspect fileprivate information about each Slot to expose some external higher level functionality on the Slots struct. A CollectionObserver class which inherits from an Observer class (same file) and is able to inspect and modify detailed fileprivate state. So, while #2 would work for me most of the time, I like the ability to put related types in the same file and have them expose more functionality to each other than they do to the rest of the project. Sort of like a micro (2-3 type) submodule. In the end I find #1 simpler and more flexible. Regards, David > On 15 Feb 2017, at 10:34, Dietmar Planitzer via swift-evolution > <[email protected]> wrote: > > I do like approach #2. It would play well with extensions, look very familiar > to how private works in other main stream languages and it wouldn’t get in > the way of a possible future refinement of extensions to this model: > > a) 1st party extension (extension defined and owned by the type owner): > extension is defined in the same module as the base type: > > - allows access to private type properties and functions even if the base > type and extension are in different files > - allows the definition of stored properties for value and class types > > b) 3rd party extension (extension is defined and owned by the _user_ of a > type): extension is defined in a parent module and the base type is defined > in a sub-module: > > - forbids access to private properties and functions from the imported type > - forbids the definition of stored properties for value types > - MAY allow the definition of stored properties on class types (haven’t > really convinced myself that this would be a good idea) > > “parent module” would either mean the application that links against a module > (what is supported today) but also the parent module of a sub-module > (potential future addition). > > > Regards, > > Dietmar Planitzer > > >> On Feb 14, 2017, at 21:31, Chris Lattner via swift-evolution >> <[email protected]> wrote: >> >> >>> On Feb 14, 2017, at 3:20 AM, David Hart <[email protected]> wrote: >>> >>> >>>> On 14 Feb 2017, at 09:25, Goffredo Marocchi <[email protected]> wrote: >>>> >>>> I disagree with that as well as I still think we are damaging the language >>>> each time we take a known concept (like access levels) and give new >>>> meanings to the same keywords. I still look baffled at the redefinition of >>>> do and the addition of repeat for example... >>>> >>>> Private, the way it was before, was an admittedly curious take on how most >>>> languages mean by private and we have jumped through a lot of hoops to >>>> justify why we did not start with Java/C++/C# like access control and >>>> augmented it instead of redefining things, omitting others, and then >>>> constantly pulling the language left and right with not a lot of permanent >>>> consensus either way as this discussion and others before show. >>> >>> It's a curious take, but it is a curious take is perfectly coherent with >>> Swift extensions. How else would you access private implementation details >>> from an extension? But putting it in the same file, instead of having to >>> resort to an internal access level. >> >> Right. Swift is its own language distinct from Java/C++/etc. While it is >> intentionally designed to remain familiar (and thus reuses many keywords >> across the language family), it often does so with slightly different >> meaning / behavior. Consider ‘throw’ for example. >> >> Keeping with the spirit of Swift and staying consistent with its design, I >> see two plausible meanings for private: >> >> Private could mean either: >> 1) private to the file (Swift 2 semantics) >> 2) accessible only to the current type/scope and to extensions to that type >> that are in the current file. >> >> I don’t think we’ve ever evaluated and debated approach #2 systematically. >> >> -Chris >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
