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

Sat Jul 16 12:11:54 CDT 2016

I agree. I'll post a draft of a proposal surrounding this topic shortly :)

On Sat, Jul 16, 2016 at 12:09 PM, Paul Cantrell via swift-evolution <
swift-evolution at swift.org> wrote:

> 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) 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
>
>
> _______________________________________________
> 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/dd0378e1/attachment.html>