Evolution process discussion

The question posed was (mostly) rhetorical, not honest confusion about why the pitch thread was not as active. But to your point:

I think there was plenty of time for such considerations to be raised. The proposal went into review nearly a month after the pitch thread was posted (and several alternatives were considered), and the pitch thread had been dead for two weeks by the time review began. I think the issue lies more with the first problem you mention—the community believing that a particular pitch would not reach the review phase, and so spending time thoroughly considering alternatives (or arguing that the status quo is satisfactory) would be wasted effort.

However, it should not be on the author of any particular proposal to consider every possible alternative to their solution, or continue bumping their thread in order to encourage participation. The expectation, IMO, should be that if you choose not to engage or to stop engaging with a topic, it may go into review in precisely its current form at any point in the future.

The more I think about it, the more I feel like the issue lies with the first "official" part of the SE process having an implicit "default" solution that must be actively fought against, rather than a more indifferent consideration of the different possible solutions to a problem. Thanks for bringing up SE-0280, @Jon_Shier—I haven't even gotten around to participating in that thread because in general I find myself more likely to participate in reviews that I have negative feelings about. This is partially because a rejection of a "good" (in my view) proposal is not as catastrophic as an acceptance of a "bad" proposal and the commitments to source and binary compatibility that may come with it. But also it's because the mere fact of a proposal making it to review at least appears (to me) to communicate a partial endorsement of the proposed solution itself.

I realize, of course, that plenty of proposals are rejected, returned for revision, deferred, etc., but that still doesn't invalidate the feeling that offering alternatives in a review thread feels like fighting an uphill battle, and that thoughtful participation in every thread pre-review is not necessarily a productive use of one's time.

3 Likes

It was explicitly stated during the Swift 3 Evolution process, by the core team, that pitches around which the community did not reach consensus could not proceed to review. Clearly this is no longer the case.

9 Likes

I wonder if part of the issue specifically with the trailing closure thread is not just that there’s no consensus but that no consensus may be possible. Reading through that thread there are a ton of very conflicting design priorities that don’t show any signs of converging.

Consensus is a nice idea but realistically it isn’t always possible. Syntax is hard and it’s not a given that it’s even possible to come up with a syntax that will achieve consensus for every feature. And as Swift matures and the low hanging easy to achieve consensus features get implemented what’s left gets harder. I question whether consensus is the right bar for this project at this time.

3 Likes

It had also been the case in the Swift 3-4 Evolution timeframe that the core team explicitly discouraged syntactic sugar proposals. Setting the bar as consensus was effectively equivalent to defaulting the answer to such proposals to no (i.e., maintaining the current syntax). This was not some unintended consequence lost on the core team. You can question whether it's the right bar, but exactly for the reasons you say, you're not going to get consensus on that either.

1 Like