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

[Jose Cheyo Jimenez]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160713/368bc5d4/attachment.html>