[swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Tony Allevato]

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 at swift.org> wrote:

>
>
> On Oct 2, 2017, at 18:06, Jose Cheyo Jimenez <cheyo at masters3d.com> wrote:
>
>
> On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution <
> swift-evolution at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171003/908d260f/attachment.html>