[swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

[Adrian Zubarev]

If it’s possible I’d like to withdraw this proposal. I’m convinced by the feedback from the community. Feel free to reject it. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Juli 2016 um 19:33:00, John McCall via swift-evolution (swift-evolution at swift.org) schrieb:

On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
As Jordan mentioned, I don't (and I think other people don't) think of extensions as their own entities, as they can't be referred to and have no runtime representation. In that mental model, there isn't such a thing as "an extension being public." Instead, the access modifier is just a shorthand default for the properties and methods it contains, which is teachable but unique to extensions. It is a matter of opinion whether that uniqueness is a feature or a bug.

I would say that it's interesting but ultimately not worth the confusion about the nature of extensions.

John.


On Wed, Jul 13, 2016 at 12:19 Jose Cheyo Jimenez <cheyo at masters3d.com> wrote:


On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:



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
}
```

There is definitely a difference, I think that is a good thing. They look similar but they are completely different. 

public Type // the type is public
public extension Type //  the extension is public 

For extensions, public is just a modifier on extension, not the type. The default scope inside the extension is that of the "modifier" keyword on the extension. 

This is easy to explain to someone new. 



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


_______________________________________________
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

_______________________________________________
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/20160716/fb86ab39/attachment.html>