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

[Xiaodi Wu]

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.

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