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

Sun Jul 17 15:09:44 CDT 2016

On Sun, Jul 17, 2016 at 1:42 PM, Jose Cheyo Jimenez <cheyo at masters3d.com>
wrote:

>
>
> On Jul 16, 2016, at 11:16 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Sun, Jul 17, 2016 at 1:07 AM, Adrian Zubarev via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> My first draft had some mistakes related access modifier on extension but
>> the final proposal does fully understands how they work and aims to
>> eliminate default access modifier behavior.
>>
>> There is no default access modifier on other types like classes etc. So
>> why should there be any on extensions I’d ask you. The Swift folks here
>> were just whining and arguing with their laziness on typing out and
>> repeating access modifier on each extension member.
>>
>> Jordan was in favor of removing them completely, but argued that “he
>> knows some people that would still want the default access modifier to
>> be there.”
>>
>> Right now access modifier on extensions are an ugly shake from how they
>> work with protocols combined with access modifier of classes etc. (On
>> protocols they just like default access modifier, but you cannot override
>> them member wise.)
>>
>> I didn’t want to remove them completely, but allow to set the visibility
>> boundary to the outside world.
>>
>>    - public extension - visible to everywhere.
>>    - internal extension - member cannot be public and therefore the
>>    implementation is only visible for the whole module.
>>    - private/fileprivate extension - the extension member are only
>>    visible to the current file.
>>
>> And yes with this model you’d need to repeat correct access modifier
>> member wise, but some folks already do that with extensions and everyone
>> does it with classes, structs and enums.
>>
>> Again that concept is not about being able to refer to extensions. It’s
>> about the visibility boundary set by their access modifier, which is also
>> bounded by the access modifier of the extended type in respect with the
>> protocol conformance that might be applied on that extension.
>>
>
> Well, let's see if my draft gains traction. I hope it addresses some/most
> of these concerns of yours. I'm trying to incorporate all of the feedback I
> got today and hopefully will have something improved by tomorrow.
>
>
> I don't think it would be good thing to propose (even as an alternative),
> the complete removal of access modifiers again in a new proposal.
>

I have been swinging back and forth about whether removal should be the
proposed solution; right now, I'm leaning again towards your view (i.e.
that it shouldn't be the proposed solution, because it gets rid of some
features that people like which aren't doing harm).

I would expect that it should show up as an alternative because, well, it
is an alternative. We should have a formal paper trail of the design
alternatives explored and reasons why the community and core team accept or
reject them; otherwise, it could come up again.

A better approach would be to cut to the heart of the issue (public access
> modifier) and cut the scope to the smallest possible subset requirements to
> make that work. I do think we need to be able to declare some things with a
> higher access modifier inside extensions (even though their effective scope
> will be less) in order to make `private extension` work with implicitly
> internal methods that effectively have fileprivate access.
>

Right, I will limit the proposal to those two issues.

> I think this new proposal will definitely would have a better chance of
> acceptance by keeping extension in making all methods inside the extension
> to be internal and still force public method to be explicit like everywhere
> else.
>

Great. I will aim to complete a revised draft this evening.

>
> If someone don’t get my intension right, I’m sorry for that. I’m a
>> programmer not a book author and I can’t write something spectacular
>> looking arguments like Mr. Mihalkovic does.
>>
>> That said, thats not related to your first comment about Type<T>, nor it
>> does help here anyone. I feel like I’m reading philosophical books when
>> reading comments that don’t have a clear answer on a particular
>> topic/question. It’s more like wrapping the topic around with some flowers.
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 17. Juli 2016 um 05:30:28, L. Mihalkovic (laurent.mihalkovic at gmail.com)
>> schrieb:
>>
>>
>> Regards
>> (From mobile)
>>
>> On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Wrong thread ;) If you think it’s ill-prepared than provide some feedback
>> instead of just watching and waiting to throw negative feedback during
>> review process.
>>
>> There is a lot done, but it’s not visible to the public thread yet. Will
>> be soon (by tomorrow I’d guess).
>>
>> Thanks.
>>
>>
>> A question i regularly ponder on with modern opensource is how it went so
>> fast from stallman writting gcc to today's anything-goes, where there seems
>> to be an expectatation that throwing even the worst unfinished piece of
>> code in the public should implicitely gag others, and only compel them to
>> have to fix it.
>> There has always been great as well as ludicrous ideas in the history of
>> mankind, and it would be a rare privilege of the opensource movement that
>> the latter ought not to be singled out as such, and have them become by
>> their mere presence in the public, everyone's responsibility to improve
>> upon.
>> This proposal was based on a lack of understanding of extensions. My
>> understand of the process is that the initial discussion phase is there to
>> evaluate an idea leaving, only the promissing ones reach proposal stage.
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 16. Juli 2016 um 21:21:59, L. Mihalkovic (laurent.mihalkovic at gmail.com)
>> schrieb:
>>
>> To me this is reminicent of what is happening with the T.Type / Type<T>
>> story, where there seems to be a rush to throw a proposal under the cut-off
>> date even if it is ill-prepared, or based on misunderstandinds.
>> Regards
>> (From mobile)
>>
>> On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> I tried to tackle the ability to write extensions where everyone would be
>> forced to write access modifier on member level. That’s what I had in my
>> mind all the time. But the respond on this was, as you can see purely
>> negative. :D
>>
>> Making all extensions public when there is protocol conformance makes no
>> sense, because you could extend your type with an internal protocol, or the
>> extended type might be not public.
>>
>> Anyways, I’m withdrawing this proposal. :)
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantrell at pobox.com) schrieb:
>>
>> 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.
>>
>> _______________________________________________
>> 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/20160717/a0569e08/attachment.html>