Thanks for hoisting this out into its own thread, Jordan. I was hesitant to elaborate more on another access level thread :)
I think the change should absolutely be made. Even though the "private" keyword occurs at the file level, the description of the feature in the Swift documentation simply states: "you can mark an extension with an explicit access-level modifier to set a new default access level for all members defined within the extension." To me, that implies that "private extension Foo { func bar() }" should be identical to "extension Foo { private func bar() }", but today it becomes equivalent to "extension Foo { fileprivate func bar() }". That seems fundamentally broken, because (1) it's inconsistent, (2) "private extension" and "fileprivate extension" are two ways of saying the same thing, non-intuitively, and (3) there's no way for someone to use the shorthand syntax to take advantage of the new meaning of private within same-file type extensions. While I personally never use the shorthand extension access level feature (because I prefer the explicit form, and because of situations like this one), I definitely think it should be consistent for people who do want to use it. I wonder how much existing code would be affected by this change. Do people use "private extension" when they really want "fileprivate extension"? I would hope the number of users affected would be few, at least. On Mon, Oct 2, 2017 at 6:10 PM Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > > > On Oct 2, 2017, at 18:06, Jose Cheyo Jimenez <ch...@masters3d.com> wrote: > > > On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution < > swift-evolution@swift.org> wrote: > > On 01.10.2017 1:18, Chris Lattner wrote: > > On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > Vladimir, I agree with you on that change, but it’s a separate topic from > this one. > > Tony is absolutely correct that this topic has already been discussed. It > is a deliberate design decision that public types do not automatically > expose members without explicit access modifiers; this has been brought up > on this list, and it is clearly not in scope for discussion as no new > insight can arise this late in the game. The inconsistency with public > extensions was brought up, the proposed solution was to remove modifiers > for extensions, but this proposal was rejected. So, the final design is > what we have. > > Agreed. The core team would only consider a refinement or change to > access control if there were something actively broken that mattered for > ABI stability. > > > So we have to live with *protected* extension inconsistency for very long > time just because core team don't want to even discuss _this particular_ > inconsistency(when access level in *private extension* must be private, not > fileprivate)? > > Yes, we decided that access level for extension will mean a default and > top most access level for nested methods, OK. But even in this rule, which > already differ from access modifiers for types, we have another one special > case for 'private extension'. > > Don't you think this is not normal situation and actually there IMO can't > be any reason to keep this bug-producing inconsistency in Swift? > (especially given Swift 5 seems like is a last moment to fix this) > > > I hate to say it but I'm inclined to agree with Vladimir on this. "private > extension" has a useful meaning now distinct from "fileprivate extension", > and it was an oversight that SE-0169 > <https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md> > didn't > include a fix here. On this *very narrow, very specific *access control > issue I think it would still be worth discussing; like Xiaodi said it's not > related to James' original thread-starter. > > (I maintain that the current model does *not* include a special case; it > simply means the 'private' is resolved at the level of the extension rather > than the level of its members. But that isn't what people expect and it's > not as useful.) > > > I agree that changing the behavior of *all* access modifiers on > extensions is out of scope. (I also agree that it is a bad idea. Sorry, > James, but wanting 'pubic' here indicates that your mental model of > extensions does not match what Swift is actually doing, and that could get > you into trouble.) > > Jordan > > > > I am not in favor of including a special case for “private extension” > because like Jordan said, private is resolved at the level of the extension > which is always top level currently. A change would make sense if we start > allowing extensions that are not top level. Anything private that is top > level is equivalent to fileprivate so why should “private extension” be any > different? > > > It's fair to be against this change, but I want to point out that neither > of these are "special cases". Instead it's "access is resolved at the level > of extension and then applied to the member" vs. "access is applied to the > members and then resolved". > > 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