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

[Xiaodi Wu]

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.


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