[swift-evolution] Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching

[Douglas Gregor]

> On Jan 28, 2016, at 4:40 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Although I think "if var" should stay (probably just because of symmetry with "if let"), I have minor concerns with this proposal, as it brings up a more fundamental issue in the evolution process:
> When is a decision final?
> 
> I guess it's hard to find the balance between discussing the same things over and over vs. stubborn insisting on a idea that is not as good as expected, but independent from this particular proposal, I think revising a decision should be done with caution, and that it is good that this discussion was started by a member of the Swift team…
> Maybe it's possible to formalize the process so that an accepted proposal will not automatically be included in a future release, but rather has to pass a "veto-phase" after it has been implemented in a beta and people got a chance play with it (cancellation should stay an exception, though).


We certainly don’t want open-ended rehashing of past decisions, and I’d like to have the baseline rule be something very close to “the core team’s decisions are final” both to prevent such rehashing and also to emphasize the seriousness of the public review process: the public review is the point at which we need to gather widespread feedback on the direction of the language. Determining that there is a problem “after we shipped it” is a failure of the evolution process.

The evolution process has a number of stages (idea/proposal draft/public review/core team), where each new stage brings additional scrutiny of the proposal. The hope is that this scrutiny is enough to prevent us from making poor decisions that may need to be overturned, and that the swift-evolution community is representative enough of the larger Swift community to provide that scrutiny. SE-0003 is somewhat special because it’s one of a few changes for Swift 3 that were decided prior to open-sourcing Swift: it didn’t go through the whole evolution process, so it didn’t have as many eyes on it as language changes do now.

So, overall, I’d say that the core team’s decisions should be considered effectively final. If something gets through the entire evolution process and then we later find out it was a bad decision—e.g., due to massive negative feedback when it reaches the wider Swift community or unforeseen difficulties in implementation/rollout/etc.—the core team could bring up the idea of backing out the change. However, the evolution process *should* prevent this.

	- Doug


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