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 > <swift-evolution@swift.org> wrote: > > >> On Feb 14, 2017, at 3:20 AM, David Hart <da...@hartbit.com> wrote: >> >> >> On 14 Feb 2017, at 09:25, Goffredo Marocchi <pana...@gmail.com> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
