<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 18 Apr 2017, at 10:12, David Waite &lt;<a href="mailto:david@alkaline-solutions.com" class="">david@alkaline-solutions.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 18, 2017, at 1:00 AM, David Hart via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><ul class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><li class="">All controversial proposals start their implementation in that version.</li></ul></div></blockquote></div><div class="">Just one more note here, in regards to SE-0025</div><div class=""><br class=""></div>Its important to realize that the swift evolution process isn’t a pure democracy, or even a democratic republic :-)</div></div></blockquote><div><br class=""></div><div>Of course :)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I personally suspect if '25 was truly controversial amongst the people who had proper votes (e.g. the core team), that it would not have been accepted. However, there was a desire to have such features. I think there may have been some pressure to have such a feature also included within the Swift 3 release, which was meant to be the last non-backward-source-compatible release.</div></div></div></blockquote><div><br class=""></div><div>I’ve had the impression that some proposals have been accepted in the past with some core team members being against. But even if all team members think a proposal is a good idea, they might still agree that its design or implementation could need to be refined after real-world use.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I think SE-0169 and the limited choice within the Swift 4 (and all future Swift releases) exemplifies that desire by the core team - that model could be revised to allow splitting a type into extensions (in some contexts) without having to raise access control, and make the purpose of the different access control levels a bit clearer in the process.</div><div class=""><br class=""></div><div class="">IMHO, the current evolution process is not about letting the community vote, but to provide a larger pool of minds and eyes and recommendations to the core team.</div><div class=""><br class=""></div><div class="">-DW</div></div></div></blockquote></div><br class=""></body></html>