[swift-evolution] [Draft] Fix Private Access Levels

[Sean Heber]

I, too, find all of this churn exhausting - I don’t know how the core team handles it!

That said, I don’t think it is prudent to expect that accepted proposals are final forever. Unintended consequences of any change or combination of changes will always have to be dealt with either by modifying the language or debating our way to a communal rationalization.

l8r
Sean


> On Feb 21, 2017, at 10:47 AM, Ilya Belenkiy via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I thought that we already had a lengthy discussion about private semantics, naming, etc. All these arguments were already presented during the original proposal discussion and review. At that time I put a lot of time and energy into responding to every email on the subject because I was under impression that unless something changed significantly after the fact, reviews were final. If proposals can be easily reversed later or need to be defended after the fact, I am not sure how many people would be committed enough to do this. As much as I want "private" to mean private, I am not committed enough, if this is what it takes.
> 
> I joined the list primarily because I really wanted that change. After it was accepted, I stopped following, partially because I cannot keep up with all the emails. I saw this thread completely by accident when I was going to unsubscribe! I hope to be back when the discussion moves to Discourse, but if accepted proposals are not treated as final decisions (unless something significant comes up), I don't know if I will. I am sure that my absence will not be noticed, but there could be many people like me. People on this list represent a very small percentage of the actual group who use the language, but from what I read here, there seems to be an assumption that people on the list is an accurate representation of the entire group of programmers using Swift. It's not, and there could be a large number of people who silently disagree with any particular proposal, and the actual usage statistics could be different from what people here may think. Also, some people may not know about particular features, and it may be a matter of education rather than a feature not carrying its own weight. If you looked at GitHub, you could say that nobody is using feature X, so it's not useful or needed, but it could also be that if X were publicized better, GitHub would show much more adoption. I really hope that features get decided on the merit of their usefulness and not by vote of people on this list.
> 
> I'll wait a day or two to give people a chance to respond and then I'll unsubscribe for now.
> 
> On Tue, Feb 21, 2017 at 10:19 AM Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> > On Feb 21, 2017, at 5:36 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> >
> > This is true for lexical scoping, but I'd also like to see scoped be parameterized to take the name of a containing scope, such as a containing submodule.  This would be a powerful tool that allows sibling submodules to collaborate with each other.  It is similar to allowing extensions of different types collaborate within a file, but at a larger level of granularity.
> 
> If I correctly understand what you seem to be suggesting, that would mean that access levels would be, ordered from narrowest access to widest, something like:
> 
>         scoped
>         private
>         internal
>         scoped(SomeModule, OtherModule)
>         public
>         open
> 
> Having the same keyword appear in two very different places in that list seems...less than ideal.
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> 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