<div dir="ltr">On Tue, Feb 21, 2017 at 11:08 AM, Zach Waldowski via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Feb 21, 2017, at 11:47 AM, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 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.<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div></div></div></div>