> On Feb 15, 2017, at 1:34 AM, Dietmar Planitzer via swift-evolution > <swift-evolution@swift.org> 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
These are still problematic if the extension is in a different file than the original type (even if they’re in the same module) when you’re not compiling with WMO. I’d rather not allow this. Slava > > 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
