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

Ilya Belenkiy ilya.belenkiy at gmail.com
Tue Feb 21 10:47:54 CST 2017


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


More information about the swift-evolution mailing list