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

[John McCall]

> 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 <mailto:cheyo at masters3d.com>> wrote:
> 
> 
> On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>> Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md <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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/86d57240/attachment.html>