[swift-evolution] [Review] SE-0119: Remove access modifiers from extensions
Xiaodi Wu
xiaodi.wu at gmail.com
Wed Jul 13 10:46:11 CDT 2016
On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution <
swift-evolution at swift.org> wrote:
> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md
>
> * What is your evaluation of the proposal?
>
> -1. Extensions appear to me to follow the access control of the rest of
> Swift: Implicit to the type you are extending, and you can either / both
> declare as part of the extension declaration or on the method. I don’t see
> how this is confusing, and I expect people will be more confused that
> extensions don’t follow the convention of the rest of Swift for Access
> Control.
>
So, actually, the proposal is correct that extensions (at least once
fileprivate/private is implemented) don't follow the access control rules
for the rest of Swift. There is a problem to be addressed. However, I agree
that this proposal hasn't identified the issue or adequately explained how
the solution solves it. Here's the problem I'm thinking of:
```
public struct foo {
func frobnicate() { } // implicitly internal
}
public struct bar { }
public extension bar {
func frobnicate() { } // implicitly public
// at least, according to the revised rules explained in SE-0025
}
```
This is an inconsistency that may (and IMO, really is) worth addressing. If
there's adequate interest, I can circulate a draft with a proposed solution
I have in mind.
>
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
>
> I don’t think this warrants a change.
>
> * Does this proposal fit well with the feel and direction of Swift?
>
> No. This seems to go against the direction of Swift.
>
> * If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
> No.
>
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> A reading of the proposal.
>
>
> _______________________________________________
> 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/20160713/28cafa3d/attachment.html>
More information about the swift-evolution
mailing list