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

Sat Jul 16 12:09:05 CDT 2016

Like others, I do find the details of this proposal hard to follow. It doesn’t seem like a simpler mental model for developers.

However, I also find the current rules around extension access modifiers hard to follow. It’s confusing that “public extension” changes the default for members, when “public class” and “public struct” don’t. And this is not ideal:

extension String: Fungible  // Extension not “public”, but the conformance is public?

IMO, every public API commitment a module makes should include the word “public” at the declaration site.

Because of all this, I have stopped using extension-level access modifiers altogether, instead always specifying access at the member level. I would be interested in a proposal to improve the current model — perhaps, for example, making “public extension” apply only to a protocol conformance, and disabling access modifiers on extensions that don’t have a protocol conformance.

Cheers, P

> On Jul 16, 2016, at 11:36 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <mailto:swift-evolution at swift.org>) schrieb:
> 
>>> On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto: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 <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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/ee489b2e/attachment.html>