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

[David Waite]

> On Apr 18, 2017, at 1:00 AM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I'm happy to see that SE-0169 got accepted and that we've patched the issues of SE-0025. But it's been a difficult process. And I can't stop asking myself if it could have been avoided. The crux of the problem is that source-compatibility is now becoming a very strong requirement. But at the same time, Swift is still missing some very big systems: reflection, property behaviours, a concurrency paradigm. How can we continue to push Swift boldly forward with very little leeway to correct our mistakes?
> 
> Then I listened to the latest episode of the excellent [Swift Unwrapped podcast](https://spec.fm/podcasts/swift-unwrapped <https://spec.fm/podcasts/swift-unwrapped>) where they talk about the access control "saga" and ask themselves the same questions as above. One interesting idea got my attention: JavaScript has a natural breeding ground for future language features with Babel. For those who don't know, it's a transcompiler that compiles bleeding-edge JavaScript into versions supported in browsers. Perhaps Swift could also benefit from a similar experimentation time for each new proposal.

There are a number of interesting examples in how other languages handle evolution.

For a language like ECMAScript, proposals follow a specific vetting process
https://tc39.github.io/process-document/ <https://tc39.github.io/process-document/>

- proposals can proceed independent of one another 
- a proposal is responsible for the full formal definition (think - if one of the processes was to update a Swift language specification)
- the process includes a feedback stage based on usage and implementation
- the process is not complete until there is full implementation in language implementations - the implementation challenges are feedback back into the process
- there isn’t a single review gate between something being a proposal and an accepted language feature
- the language is on a release schedule, and proposals are put into the language release schedule when complete. Language releases (e.g. ES2017) are not tied to a “MVP” set of proposed features
- because implementation is required as part of the process, ideally you do not have issues where the language spec is released with no implementations

I don’t know if the level of formalism here would work for Swift yet, to be honest. Swift still has known deficiencies that make sense to have be focus areas for a language revision. I suspect features within that revision schedule may also wind up being too interdependent. This division of labor also only makes sense when you have enough independent parties trying to drive evolution and implementation - Swift just might not be big enough yet.

> Here's my rough idea:
> The Swift compiler gains a new off-by-default `next` version triggerable with the `-swift-version next` flag.
> All controversial proposals start their implementation in that version.
> Once one of the poposals feels stable enough, it is brought into an official version.
> Developers would be encouraged to try the `next` features while being warned that source compatibility on that version will *not* be garanteed.

Re: -swift-version next, care would have to be taken to make sure this doesn’t mean that multiple language features aren’t being developed within the same branch. There is also the risk that such features are *not* going to make the next release, or any release, due to implementation challenges or later user feedback. I’d recommend that this instead be an experimental version focused on periodic merging of beta features - there isn’t a requirement that such be a single tree, or be @ apple/swift, or to only contain features which have hit a certain process maturity stage.

I believe there are still challenges for users to experiment with such versions - in particular, I believe the majority of Apple platforms still don’t support building with anything other than an official release. I might expect a vendor running a store to require an official toolchain, but I believe even adhoc and local/simulator development is required to be on shipped toolchain releases.

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