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

[Xiaodi Wu]

On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> Sent from my iPad
>
> On Oct 2, 2017, at 7: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 agree with this in principle but would not want to see it become a
> slippery slope back into extremely long access control discussions.
>
>
As I've said elsewhere, I too agree with this in principle. I agree with
Jordan that the current state of things is justifiable but the alternative
would be somewhat superior, agree that in a vacuum this very narrow and
specific discussion might be warranted, and agree also that this could be a
very slippery slide down a very steep slope.


> (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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20171002/62649cbf/attachment.html>