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. > 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
