> On Jul 16, 2016, at 11:16 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > >> On Sun, Jul 17, 2016 at 1:07 AM, Adrian Zubarev via swift-evolution >> <[email protected]> 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. 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. 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. > >> 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 ([email protected]) >> schrieb: >> >>> >>> Regards >>> (From mobile) >>> >>> On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution >>> <[email protected]> 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 ([email protected]) >>>> 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 >>>>> <[email protected]> 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 ([email protected]) 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 >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
