[swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

David Hart david at hartbit.com
Tue Apr 18 03:20:21 CDT 2017

> On 18 Apr 2017, at 10:12, David Waite <david at alkaline-solutions.com> wrote:
>> On Apr 18, 2017, at 1:00 AM, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> All controversial proposals start their implementation in that version.
> Just one more note here, in regards to SE-0025
> Its important to realize that the swift evolution process isn’t a pure democracy, or even a democratic republic :-)

Of course :)

> 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.

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.

> 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.
> 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.
> -DW

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170418/fa6e7fb0/attachment.html>

More information about the swift-evolution mailing list