Thanks for bringing this up. We discussed this amongst the core team and have the following guidance that may help.
It’s worth noting that some additive proposals are currently in scope, where they are aligned with the themes set out for Swift 4. For example, additive proposals for String, Dictionary and Sequence/Collection are being accepted for the standard library. In upcoming releases of Swift, it is likely that additive proposals aligned with other themes, such as further string work (like native regexes), move-only types, concurrency, reflection, or further generics enhancements, will be in scope. We feel that keeping the focus on specific themes is really important for the evolution of the language, and that unconstrained additive proposals not associated with any current theme are always going to have a very high bar for acceptance.
One reason is bandwidth, both of the core team and of the community. Keeping the discussion focused on themes helps other community participants follow the mailing list (though hopefully a move to a message board format will help with this some). And by ensuring proposals are themed with the overall goals of each release, we stand a higher chance of avoiding a build-up of proposals that are accepted, but then not actually implemented.
Moreover, when discussions are focused on specific themes, we can provide a more complete, coherent design for the features within that theme. We can explore how (say) all of the new generics features of Swift 4 fit together to provide a complete, coherent system that is easier to use and explain, or how all of the new string features fit together to make Awesome Strings. It’s partly about messaging—what does Swift 4 bring to the table?—and partly about giving us a better chance at building a coherent design.
The coherent design is important both within the release—because it makes it easier for developers to learn to use the new features together—but also for the long-term health of the language. Without theming proposals, it is very difficult to see how an individual proposal fits into the overall direction of Swift. We would run the risk of making small local changes that we later regret when considering wider-reaching changes to which they are related. There is also a risk of not noticing the accretion of too many keywords or concepts in the language that individually make sense but overall don’t fit well together.
For example, recent proposals around refactoring of meta types really need to be considered in the wider context of reflection as a whole so should probably wait until that theme is in scope. Another example: the recent proposal SE-154 to change the types for the keys and values collections on Dictionary did not really make sense in isolation – it still only provided a slightly clunky way to solve the problem where dictionaries need an “initial” value, and then update that value in-place. But it needed to be considered as part of the ABI stability theme. It was partly for this reason we decided to open up a wider discussion of Dictionary for stage 2.
For Swift 3 and Swift 4, the core team set out the themes for each release. The core team would like to involve the community earlier in the process to help define the themes for future releases, but are still thinking about the best way to do so.
On Feb 23, 2017, at 11:42 AM, Adrian Zubarev via swift-evolution <firstname.lastname@example.org> wrote:
Dear core team,
I would love to have a clear statement on when purely additive proposals will be in scope of Swifts evolution? There are quite a few proposals that are marked as ‘out of scope’ since the last phase of pre Swift 3 development.
Sure these proposals do not focus on huge improvements to the language but they are significant in it’s own way.
Will it be Swift 4.1, Swift 5 or Swift 10? The issue with ABI is now deferred again and makes these proposals collect some more dust for another year or two, if not longer.
I think a clarification would be good for everyone.
Thank you for your time.
Sent with Airmail
swift-evolution mailing list