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

[Xiaodi Wu]

On Tue, Feb 21, 2017 at 11:08 AM, Zach Waldowski via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Feb 21, 2017, at 11:47 AM, Ilya Belenkiy via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > 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.
>
> Swift shouldn’t be unnecessarily burdened by the opinions of people who
> feel the need to spend all their time on a mailing list. A language’s
> features should be useful in their own right. If “nobody" knows how to use
> a feature appropriately, then random code from GitHub _is_ data that it
> might not necessarily be well thought out. Proposals can’t be written in
> stone because we can’t see the future. I’m sorry you no longer want to
> participate, but the world will keep on turning.
>

So, clearly, both of these positions have merit, IMO. For this process to
work, people have to understand that there is a designated time to share
viewpoints surrounding a proposal; then, a decision is taken, and that
decision should be taken as the considered opinion of the Swift community
and core team. Surely, we want to encourage people to write quality prose
to explain their thoughts and ideas to the fullest extent, but no one has
the time or energy to do that repeatedly on the same topic with no end in
sight. Therefore, it's antithetical to fostering an environment of critical
thinking to have the same topic brought up ad nauseam. That's partly
reflected in the existence of a "commonly rejected proposals" document.

Now, of course, if implementation runs into a roadblock, or if real-world
experience after implementation contradicts some fundamental assumptions of
the initial proposal, then revision or retraction may be necessary. But, to
use a legal analogy, that should be the equivalent of re-opening a case
after new evidence comes forward that places the original verdict into
serious doubt. Revisiting a topic should *not* be the equivalent of
appealing a court case after an unfavorable decision.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/8b120eb9/attachment.html>