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

DevAndArtist · July 17, 2016, 6:07am

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@gmail.com) schrieb:

Regards
(From mobile)

On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution <swift-evolution@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · July 17, 2016, 6:16am

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.

···

On Sun, Jul 17, 2016 at 1:07 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:

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@gmail.com)
schrieb:

Regards
(From mobile)

On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution < > swift-evolution@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

DevAndArtist · July 17, 2016, 9:09am

Because extensions are not types.
They are still bound to the type you extend. IMHO they should obey the access rules types follow, but we don’t want to debate this anymore. It won’t ever happen.

I don’t think that attacking people for their whining and laziness is very constructive. Please respect people the same way you’d want them to respect you.
But attacking me and how I wrote the proposal in terms of eliminating the default access modifier is constructive? I don’t fell that way. Arguments about laziness are still contra productive in any manner.

I am one of those who’d like to keep them. Not out of “laziness”, but because it helps when re-reading code: it helps structure code into those access level extensions.
See, this is whole different argument and more technical than the laziness I was talking about.

···

--
Adrian Zubarev
Sent with Airmail

masters3d · July 17, 2016, 6:42pm

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.

···

On Jul 16, 2016, at 11:16 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Sun, Jul 17, 2016 at 1:07 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

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@gmail.com) schrieb:

Regards
(From mobile)

On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution <swift-evolution@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

L_Mihalkovic · July 17, 2016, 10:50am

Regards
(From mobile)

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.

···

On Jul 17, 2016, at 8:07 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

--
Adrian Zubarev
Sent with Airmail

Am 17. Juli 2016 um 05:30:28, L. Mihalkovic (laurent.mihalkovic@gmail.com) schrieb:

Regards
(From mobile)

On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution <swift-evolution@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

DevAndArtist · July 17, 2016, 11:04am

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@gmail.com) schrieb: