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

[Adrian Zubarev]

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.

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