I think it would be a step back as it again oversimplifies access control IMHO. If we touch access control we should aim to improve it from both a library implementation point of view but for a user point of view as well.
Sent from my iPhone > On 16 Feb 2017, at 06:20, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > On Feb 14, 2017, at 11:46 PM, Jean-Daniel via swift-evolution > <swift-evolution@swift.org> wrote: >>>> Keeping with the spirit of Swift and staying consistent with its design, I >>>> see two plausible meanings for private: >>>> >>>> Private could mean either: > ... >>>> (2) accessible only to the current type/scope and to extensions to that >>>> type that are in the current file. >>> >>> I think (2) is worth discussing. My 2 cents: >>> >>> Pros >>> • Solves a high percentage of use cases of fileprivate >>> • Type-scope proponents retain some of the safety >>> >>> Cons >>> • Less straight forward to explain >>> • Access to different type/scope in same file not possible anymore >> >> Which means that if we choose 2, we must keep fileprivate. >> Being able to access other type private members in the same file is an >> important feature that can’t be easily replaced, so it would badely break >> existing code if we remove it. > > Yeah, I think you’re right, which sinks the whole idea: we should aim to > (re)simplify the access control model. (2) is also problematic because it > doesn’t allow the private members to be used by other things in the same > file. E.g. use a private member of Foo in an extension on String. > > IMO, removing fileprivate and making private match Swift 2 semantics seems > like the more promising approach. > > -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
