On Tue, Jun 28, 2016 at 9:06 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote:
> > On Jun 28, 2016, at 19:03, Matthew Judge <matthew.ju...@gmail.com> wrote: > > Comments inline. > > On Jun 28, 2016, at 04:14, David Hart via swift-evolution < > swift-evolution@swift.org> wrote: > > Hello everybody, > > I tried using the access rules defined in SE-0025 in some code of mine to > see what effect it would have. I came out of the experiment more > disappointed than I thought. Here are several reasons: > > 1) The new rules make `private` more prominent compared to `fileprivate` > (the latter has a somewhat worse name). But at the same time, the Swift > community has developed a style of coding where a type is defined through a > set of extensions. To hide members from other types, but have access to > them inside the type extensions, we have often used `private` and placed > the type and its extensions in the same file. Because `private` is scoped, > we are forced into using `fileprivate` pervasively (which is uglier), using > `internal` instead (which is less safe) or moving the extension code into > the type's scope (which is against the way Swift code is being written > today). All of these options look worse to be than before SE-0025. > > > If I understand SE-0025 (even with the amendment) you can still spell the > access modifier to types as 'private' and get the same characteristics as > the pre-SE-0025 meaning or private, so I'm not sure I understand the > concern here. However (continued below) > > > 2) The new amended rules look complicated to me. I think they have the > risk of being confusing in practice, but we’ll have to see. > > > I definitely agree that the amended rules look complicated. It seems to me > that the amended set of rules is favoring simplifying the implementation > over simplifying the mental model. > > My impression of what SE-0025 decided was that 'private' meant private to > the enclosing scope. If the access modifying 'private' was applied to a > type at the file scope, then it was synonymous with fileprivate and the > default access of members of that type should be fileprivate. > > If a inner type was declared private, than the default access of members > of that inner type should be private to the Outer type, not fileprivate. > There is currently no way of expressing this access explicitly, but it does > not seem like an especially useful thing to need to spell. > > Said in code, my impression of SE-0025 is that > > private class Outer { // exactly equivalent to fileprivate > var myVar = 0 // default: fileprivate > private class Inner { // private to Outer > var hiddenVar = 0 // default: private to Outer > private var reallyHiddenVar = 0 // default private to Inner > } > } > > > This is definitely one of the considered alternatives. Both Brent and I > didn’t like the idea of an access level that you couldn’t actually spell, > and even if we got past that, we’d still need a way to refer to it in > documentation and diagnostics. I would count that as a larger change than > just allowing ‘fileprivate’ in places that previously would have been > called redundant. > I'm late to the party here, but I share the feeling that perhaps the amendment introduces a complicated mental model. But a lightbulb went off reading the amendment, specifically this parenthetical statement: "(The members [defaulting to fileprivate inside a private type] still cannot be accessed outside the enclosing lexical scope because the type itself is still private, i.e. outside code will never encounter a value of that type.)" Given that this is the case, wouldn't the same problem be entirely obviated by the following change to the formal rules: The default level of access control within any type (public, internal, fileprivate, or private) is `internal`. In the case of fileprivate or private types, the `internal` members still cannot be accessed where the containing type cannot be accessed. > > Jordan > > > _______________________________________________ > 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