Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

On Mon, Jul 18, 2016 at 1:24 PM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > I remember it differently. The opposition to SE-0119 “Remove access > modifiers from extensions” was primarily because the proposal itself was > malformed and, to quote you from the review

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

I remember it differently. The opposition to SE-0119 “Remove access modifiers from extensions” was primarily because the proposal itself was malformed and, to quote you from the review thread, “doesn’t do what it says on the tin (aka in the title)”. In that thread Jordan Rose said “the proposal

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

On Mon, Jul 18, 2016 at 11:25 AM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > My understanding is that “being able to change access levels by > simply flipping a switch on the type itself” is a positive goal of Swift. > I agree. Therefore, it emphatically *should* be

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

> > Now if the struct’s visibility is changed, each extension member will be > accessible up to the maximum availability of the type, the extension, and > itself. …I of course meant “minimum” here. Nevin On Mon, Jul 18, 2016 at 12:25 PM, Nevin Brackett-Rozinsky <

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

My understanding is that “being able to change access levels by simply flipping a switch on the type itself” is a positive goal of Swift. Therefore, it emphatically *should* be allowed to set the default visibility for an extension the same as (or higher than!) the type it extends. For example, a

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

I have incorporated this new feedback and submitted a new PR. When (if?) it comes up for review, I hope it will prove satisfactory. Thanks all! On Mon, Jul 18, 2016 at 10:32 AM, Xiaodi Wu wrote: > On Mon, Jul 18, 2016 at 6:09 AM, Adrian Zubarev via swift-evolution < >

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

On Mon, Jul 18, 2016 at 6:09 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > +1 :) > > Let’s analyze this: public > internal > fileprivate >= private > > An extension may optionally be marked with an explicit access modifier > that specifies the default scope [see

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

+1 :) Let’s analyze this: public > internal > fileprivate >= private An extension may optionally be marked with an explicit access modifier that specifies the default scope [see SE–0025]. However, such an explicit modifier must not match (or exceed) the original type’s access level. public

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

This compromise solution looks very good to me. Thanks Xiaodi for the effort put into working through our whining to come to the best solution IMHO. > On 18 Jul 2016, at 09:50, Xiaodi Wu via swift-evolution > wrote: > > All righty, thanks for all of your feedback.

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

On Mon, Jul 18, 2016 at 2:59 AM, Goffredo Marocchi wrote: > Hello Xiaodi, > > A general principle of Swift, recently strengthened by proposals such as > SE-0117 >

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

Hello Xiaodi, > A general principle of Swift, recently strengthened by proposals such as > SE-0117, has been that public API commitments should require explicit opt-in. > Given the different behavior of classes and structs, the fact that extensions > allow public methods to be declared without

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

+1. Makes sense this way. > On Jul 18, 2016, at 9:50 AM, Xiaodi Wu via swift-evolution > wrote: > > All righty, thanks for all of your feedback. I've worked on revising the > proposal this evening, re-reading previous documents and messages and > re-analyzing what

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

All righty, thanks for all of your feedback. I've worked on revising the proposal this evening, re-reading previous documents and messages and re-analyzing what people meant. I think Jose is absolutely right in the end, and the proposal has turned out like he suggested. Here is the current draft

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

I understand how it works. By aligning access modifier rules inside extensions with those inside types, all other modifiers would continue to work as it does now (implicitly internal members would be limited by the upper bound). The only change in this respect is removing the ability to have

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

I tackled it as an upper bound but highly rejected by the community. That’s exactly what my proposal was all about. An upper boundary would be more elegant, but I still see arguments ‘because it’s not a type’. I could live without access modifiers on extensions in general. The default access

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

The proposal is that the access modifier for an extension will either be removed entirely or remain as an upper bound, losing its function as a default access modifier. The default access modifier rule permits public methods to be written without `public func`; this is a proposal to remove that

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

I still don’t catch to point here. There is no implicit public there. It’s explicit set by the default access modifier of extensions. It’s how they work and how they should remain (at least as long the community want default access modifier to exist on extensions). Disallowing setting public on

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

That's a good point. I will incorporate these into a revised draft. Only two things will change: ``` public struct Foo { // implicitly internal func frobnicate1() { } } public extension Foo { // currently implicitly public // // depending on which alternative is adopted, // the

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

I’m struggling to understand your proposal, can you provide some specific code samples how it works now and what will change. The example from the draft doesn’t help my understanding. :/ --  Adrian Zubarev Sent with Airmail Am 17. Juli 2016 um 04:40:45, Xiaodi Wu via swift-evolution

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

On Sat, Jul 16, 2016 at 7:56 PM, Jose Cheyo Jimenez wrote: > I think you can simplify this proposal by just saying something like this > and give a couple of examples that are easy to follow: > > Disallow explicit public access modifier on non-protocol-conforming type >

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

I think you can simplify this proposal by just saying something like this and give a couple of examples that are easy to follow: Disallow explicit public access modifier on non-protocol-conforming type extensions. I think if you only focus on that breaking change then the proposal will have a

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

On Sat, Jul 16, 2016 at 6:10 PM, David Hart wrote: > This proposal really confuses me. Two comments: > > 1) With the proposal, we loose the ability to use access modifiers on > extensions as a way of grouping members by access. That's a huge loss for > me. > You lose the

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

On Sat, Jul 16, 2016 at 1:13 PM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > Have you by any chance meant this? > > You can extend a class, structure, or enumeration in any access context in > which the class, structure, or enumeration is available. Any type members >

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

Have you by any chance meant this? You can extend a class, structure, or enumeration in any access context in which the class, structure, or enumeration is available. Any type members added in an extension have the same default access level as type members declared in the original type being

[swift-evolution] [Draft] Harmonize access modifiers for extensions

With the impending withdrawal of SE-0119 and the closing window for (most) source-breaking changes, I thought I'd draft up a proposal to address some of the key points raised in that discussion. The proposed changes are deliberately limited in scope to rationalizing access modifier rules without