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

Sun Jul 17 06:04:01 CDT 2016

That’s what this mailing list is for. To discuss everything with the community and the core team behind Swift. If you don’t try, you won’t get anything. If everyone would be afraid to tackle something that might go really wrong during review, nothing will happen at all. We’ll end up with a language that is driven by the core team where the community would be to afraid to step in.

Which ‘Type proposal’ exactly are you referring here?

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Juli 2016 um 12:50:32, L. Mihalkovic (laurent.mihalkovic at gmail.com) schrieb:

Regards
(From mobile)

On Jul 17, 2016, at 8: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.

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.

I thought I had clearly shared my personal view (not any truth) in the other thread. IMVHO Type<T> is ill-prepared for addressing the topic of reflection. Some of the ideas are there of course simply because it is obvious that swift currently has a gap in this area and some of the pieces of a reflection API are obvious in nature. But the proposal does not propose a cohesive vision of which Type<T> would be a small step, paving the way for the rest being additive later. 
When dealing with reflection, the first step should IMHO be to understand the 2 facets it takes (there is plenty of literature and research papers on the topic) to give a frame of reference to the solution, and then proceed with the code that will deliver the solution. Starting from the ground up with a single class and saying 'the rest will organize itself around' is asking a lot out of lady luck, and has a very high chance of creating more 'oops we didn't think about that' moments like recently happened with 0111 a week ago, or with other proposals hitting snags at the implementattion stage.
This is not unlike what happened with Any<P,Q> and all the subsequent debating.. I had offered early on that before fixating on the downstream details, a fundamental question had to be answered: whether or not to carry the semantic on a container, versus expressing it directly in the grammar. Any possible detailed syntax would just be the materialization of either of these two core choices. Instead of answering this question first -it has to do with the fundamental feel or the language, as well as deep implications for the compiler, and as such could only be answered by the core team- weeks of banter went on for no valuable outcome. IMHO this is even critical for the design of a reflection API, and i have no desire to participate in was I see as improductive without the core team making the early decisions they only can make.

-- 
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/b68c3263/attachment.html>